The Last Technical Interview • Hacker News Board

Re: The Last Technical Interview

#171

Post by esafak » Sat, May 30, 2026, 4:10 PM UTC

thaumasiotes wrote: post #10

nitwit005 wrote: post #7

I gave the feedback at one Google interview that they should send Google employees through to see how many get hired. Good to see they basically tried that. The conclusion at the end that bringing someone on board is the ideal method is true I'm sure, but even that runs into the issue that employee evaluation is an even worse situation than the interview process. You can openly see some managers panic when they reali…

> I gave the feedback at one Google interview that they should send Google employees through to see how many get hired. Good to see they basically tried that. They did, but not with the intention of doing anything about the problem. This is a question of reliability , the conceptual 'correlation' of a measurement instrument with itself when measuring the same thing. Reliability is one of two major concepts in psychom…

Big companies already have standardized tests; test banks that get rotated with grading rubrics. Examiners (employees) will ask their favorite questions over and over to calibrate where a given candidate stands.

Re: The Last Technical Interview

#172

Post by ncallaway » Sat, May 30, 2026, 4:13 PM UTC

tptacek wrote: post #139

BoiledCabbage wrote: post #133

Earlier quoted context omitted.

That's absurd thinking if putting in 6-8 hrs outta what everyone else is doing and what is needed to get you a job. For all its flaws, part of the benefit of an interview is it's time bound and equal for everyone. Similar to a test.

Look, if you want to make people do work samples from an uncomfortable conference room at your office, be my guest. I am pretty confident I speak for the majority of candidates when I say that that my preference would strongly be for the ability to work on this stuff from wherever I want to.

I mean, that doesn't have to be how it works. You can have a both fixed amount of time, and the ability for a candidate to work in whatever environment they want.

Re: The Last Technical Interview

#173

Post by overgard » Sat, May 30, 2026, 4:13 PM UTC

0xbadcafebee wrote: post #120

> There is a material difference between the signal from an internship (~7 weeks of usable work time after ramp-up) vs a co-op (5 months actually working) And that's why the trades require you to perform years of work as an apprentice before you're ever qualified to pass an exam to become a journeyman. Not only is it like a years long internship, but you're paired with someone who has already passed a high bar. You'r…

I guess my concern there is that there's such a high degree of diversity to software jobs that figuring out what "qualified" means is also very diverse. For instance, what it takes to be a frontend web dev vs working on embedded systems vs working as an SRE are practically different professions.

Re: The Last Technical Interview

#174

Post by tptacek » Sat, May 30, 2026, 4:14 PM UTC

ncallaway wrote: post #172

tptacek wrote: post #139

Earlier quoted context omitted.

Look, if you want to make people do work samples from an uncomfortable conference room at your office, be my guest. I am pretty confident I speak for the majority of candidates when I say that that my preference would strongly be for the ability to work on this stuff from wherever I want to.

I mean, that doesn't have to be how it works. You can have a both fixed amount of time, and the ability for a candidate to work in whatever environment they want.

Of course, and if you want to do that, I've got no complaints. What we want is to eliminate pressure and scheduling inconvenience. We're also not unhappy to meet people who are not necessarily experts in our problem domain, but capable enough programmers that they can ramp up given a bit of extra time. I don't feel the slightest bit bad creating that affordance, so long as you can meet the rubric if you're an experienced professional in the time we allot.

Re: The Last Technical Interview

#175

Post by garretraziel » Sat, May 30, 2026, 4:19 PM UTC

jb1991 wrote: post #88

blizarre wrote: post #80

Earlier quoted context omitted.

Not exactly, if I am thinking of leaving my job and I have responsibilities, I will not even entertain taking a leap of faith, resigning from my current position and grinding for 3 month in a super-competitive environment for 1/10 of a chance of getting a better job. I'll talk to recruiters and interview at other companies on my spare time, as before.

My point was that this perspective is not lost on the author of that article, as he directly addresses it.

He addressed it as “job market is in such a bad shape, so perhaps even seniors won’t have any other option”, which might be true, but is sad nonetheless.

Re: The Last Technical Interview

#176

Post by i_am_a_peasant » Sat, May 30, 2026, 4:21 PM UTC

osigurdson wrote: post #49

Maybe three days is enough for some code bases, but if you have millions of lines of code, agents aren't going to help you that much.

you don’t need to understand millions of lines of code to be effective at a job. you just need to identify the boundaries and the subsystems you need to touch. I’ve always only worked on huge codebases, and i tend to ramp up within the first 2 weeks at every job

Re: The Last Technical Interview

#177

Post by brennanpeterson » Sat, May 30, 2026, 4:21 PM UTC

tptacek wrote: post #13

The gold standard in hiring qualification is work-sample testing. It works fine. You do not need to "make hiring a profit center" or "provisionally hire" or do internships. Work samples done correctly demand less time from candidates than interviews and scale better than interviews. They are standardizable and iterable. What I feel like I'm reading here is someone who has been poisoned by FAANG hiring practices --- a…

It would be nice to have portfolios, but systems are broken enough that that becomes hard to see. I suspect one of the reasons for the bias to hiring PHds in fields where it really isn't necessary is at least you have a work portfolio.

Re: The Last Technical Interview

#178

Post by tptacek » Sat, May 30, 2026, 4:23 PM UTC

brennanpeterson wrote: post #177

tptacek wrote: post #13

The gold standard in hiring qualification is work-sample testing. It works fine. You do not need to "make hiring a profit center" or "provisionally hire" or do internships. Work samples done correctly demand less time from candidates than interviews and scale better than interviews. They are standardizable and iterable. What I feel like I'm reading here is someone who has been poisoned by FAANG hiring practices --- a…

It would be nice to have portfolios, but systems are broken enough that that becomes hard to see. I suspect one of the reasons for the bias to hiring PHds in fields where it really isn't necessary is at least you have a work portfolio.

Why do I care about your portfolio if I can just see how effectively you do the actual work?

Re: The Last Technical Interview

#179

Post by tptacek » Sat, May 30, 2026, 4:24 PM UTC

masfuerte wrote: post #164

tptacek wrote: post #157

Earlier quoted context omitted.

Again: the rubric is defined up front. You can actually lose points for doing too much. I understand that some people are concerned that they're competing with candidates who will put in 12 hours to do what they should be doing in 4. But that's not their problem. Their problem as a professional is to evaluate whether they can do the challenge in 4 hours; that's the expectation the job is setting. It is perfectly reas…

Imagine I'm an employer who wants to adopt this system. How can I distinguish the candidate who spent four hours from the candidate who spent twelve?

If you care, you enforce a time limit or have the work sample done on site. We simply don't care.

Re: The Last Technical Interview

#180

Post by tptacek » Sat, May 30, 2026, 4:26 PM UTC

esafak wrote: post #166

littlexsparkee wrote: post #34

Earlier quoted context omitted.

I feel like you could get around the AI bit by asking about components and what they do, rationale for decisions, etc. If someone can't speak to it, it should be a clear tell.

As long as you are talking to them face to face; over the phone they will use AI with speech recognition and parrot its response, erasing all signal. Then the interview becomes all about AI detection.

I've been hearing these kinds of things since 2014 (when I wrote a long post about the work sample process we had used at Matasano). I've been hiring continuously since 2008, so 18 years, and in that entire time I have never come close to hiring a scammer.

It might be a more salient concern now, in the era of AI agents, and we are much warier today than I was at Matasano, but generally I think this risk is more talked about than experienced.