←back to thread

Why are interviews harder than the job?

(www.mooreds.com)
56 points mooreds | 2 comments | 29 Sep 25 12:44 UTC | HN request time: 0s | source
Show context
jerf ◴[29 Sep 25 13:25 UTC] No.45413477[source]▶
The alternative I prefer isn't any of the given ones, but a scaled interview. I start with something that you can solve with a Python one-liner, if you know what you're doing, but if you solve that instantly I've got a series of questions that will scale up until we're eventually doing the task using untrusted user input, outputting into a security-sensitive environment, under heavy load that we want to be cheap, in a highly-available environment, etc. etc. I also tell the applicant up front that this is the plan, because if you don't do that, it feels like you're jerking them around by constantly changing the requirements. I've also got a number of directions it can go depending on the applicant, and depending on what they tell me about their past experience.

The other nice thing about this is your interviewee generally doesn't leave feeling like a failure; it's not like I have three questions and you can get them all wrong. Unfortunately there are some people who end up spinning on the very easiest question for the entire session, and, uh, well... I can only do so much, if you really don't know anything about programming at all. This is at least the exception, though.

I have not had to do an interview in the age of practical AI yet, though. In person I don't think I'd have to change much, I've always interviewed with a policy of "I'm not worried about whether the string split command takes its parameters in this or that order, I just want to know you know it exists" and I can basically serve as an AI in the same way I was already being the API reference. Remotely, I'm not sure what I'd do yet.

replies(2): >>45413670 #>>45413881 #
1. skeeter2020 ◴[29 Sep 25 13:40 UTC] No.45413670[source]▶
I do like your approach more than many alternatives but there are still lots of challenges. Two big issues: 1. this is not typically how even a confident, prepared, solid developer approaches coding problems, so they can be poorly prepared for this style of interview. The result is you don't get an accurate representation of the individual. 2. it takes an awful lot of the interviewer's time to prepare, even if you can scale to multiple candidates with much of the same work. You need a very strong technical resource to deliver this style of interview, and they could probably be doing higher value work.

I've hired a lot of the past ~5 years and my take away: it sucks for everyone - on both sides - except the early HR-led functions, and they don't add any value or much help. They may actually make most of the challenges much worse.

replies(1): >>45415475 #
2. jerf ◴[29 Sep 25 16:08 UTC] No.45415475[source]▶
"this is not typically how even a confident, prepared, solid developer approaches coding problems, so they can be poorly prepared for this style of interview. The result is you don't get an accurate representation of the individual."

It may not be how you approach coding problems but it tends to accurately reflect how people program in real life, so I don't think it's all that much of a stretch to ask people to show it in an interview. Nobody gets an assignment to write a scalable, testable, blah blah blah 100 pages of requirements project and just sits down and writes it linearly from start to finish. Everything is incrementally developed.

"it takes an awful lot of the interviewer's time to prepare,"

Perhaps in general, but not for me past the first couple of times. However, that's because I do strongly agree with...

"You need a very strong technical resource to deliver this style of interview"

Yes, definitely.

However I don't believe there's a way around this. I don't believe you can get high-quality results for technical hiring from any possible "interview" you can hand to a non-technical programmer.

Moreover I don't even know why people think this is or should be possible. Other than the popular "I want it therefore it should be possible" argument, which the universe doesn't particularly respect. I wouldn't expect that even armed with a prepared formal interview that I could interview an industrial chemist, oil rig engineer, or a plumber. There still seems to be a certain amount of residual contempt for programming in some circles and that includes the idea that a non-programmer should be expected to be able to interview a programmer at anything more than a super-basic level. No, programming is at this point as technical as any other career out there. It really wasn't 30 years ago, but it is now, where the basic standard for the simplest possible project now encompasses a suite of technologies and competencies just to get started and the complexity goes up from there.

Also, while a senior engineer perhaps shouldn't be doing full time interviewing, interviewing is extremely high value work. It determines the course of the entire team for years at a time. The interviews I did years ago still determine the course of my day-to-day activity. Huge impact.