Developer Pamela Fox on technical interviews:
If you’re an interviewer: seriously consider the format of the on-the-spot technical interview and whether that’s the best way to judge all candidates. In my experience, when we are programming on the job, we’re given the problem and we have time to think about it. We have time to research possible solutions, we have time to try stuff out that we know will most likely fail, and we can wait until we have something decent before we show it to our colleagues. Nothing like an on-the-spot interview.
I agree. I once had a hiring manager ask if we could “chat for 15 minutes about what you’re looking for and what this role is all about.” He called a half-hour early, and our 15-minute chat ended up being an hour-long technical interview that I wasn’t at all prepared for.
Even if I had done well (or by some chance they decided to move me on to the next round), it left a really bad taste in my mouth about the company. That’s sneaky and manipulative. I don’t want to work for someone like that.
A Different Approach #
Obviously you should try to hire the best people you can. So if not technical interviews, what?
Pamela’s suggestion: a take-home assignment. It’s a sentiment echoed by Ike Ellis in I will not do your tech interview:
Since that day, I have refused to take traditional tech interviews. I politely suggest that a short contract job might be the best option for a company to evaluate a senior developer. This works very well if they are unsure about you. It works even better if they really want you. As an added benefit, you get to see what it’s like to really work with a team before you take a job with them.
Couldn’t agree more.