Tech interviews are in most cases worthless.

I hate technical interviews. Like seriously hate them. Both giving and receiving them. I'm moving to San Francisco soon, which has put me on the job market, and I was suddenly and rudely reminded of this feeling.

Why do I hate them? Because frankly, I’m not good at them. Or at least not initially, and never reliably. But I am good at what I do (or so I like to think), so it’s a bit ridiculous that I’m not good at interviewing to be able to do it. Tech interviews should not be a skill you have to build up separately from just being a good developer. And as I’ve come to know, a lot of other developers seem to share this sentiment.

What I won't do is cry for getting rid of tech screenings. I like talking about technologies and what I’m working on with other developers, and I know no one wants to hire someone without seeing what they can do. What I am going to do is give some examples of tech interview approaches that I find effective, and those I don’t.

Approach One: asking obscure and pointless questions

Here’s some examples I’ve been asked recently.

• Explain {{insert language}} garbage collection for me.
• What are the principles of object oriented programming?
• How is blah blah blah implemented blah blah performance time blah?
• Explain TCP.

Great. Even when I do answer correctly, knowing this stuff doesn’t bear much relevance to how good of a programmer I am. I could know all of this top to bottom and write some of the worst code you have seen in your life.

I know what the argument is. It’s not that the interviewee get it right, it’s just that you want to see their thought process. Well screw that. My thought process isn't exactly normal during an interview, this isn’t making anyone more comfortable. You get an interview where the outcome is a combination of luck and studying up on algorithms and obscure programming knowledge that I haven’t had to know since college. Pass.

Approach Two: screen share or whiteboard code challenges

Interviews like this typically involve setting up the interviewee on some shared screen or white board and asking them to write out functions that do x-y-z. As the interviewee I’m already nervous and miserable, you’re not likely to see me at my best here. Or even close to it. I swear I forget at least 60% of everything I know in these sitations. Maybe 80%. True story.

Please don’t put a keyboard in front of me or pass me a pen, and ask me to do coding challenges while you sit back and glare at my progress without blinking. Also if you do, at least let me use google or work in any way close to one that would reflect how I would be working day to day.

This approach is better than the barrage of questions I think, as long as you understand you are mostly seeing the interviewee at their worst.

Approach Three: code at your leisure

This is my go to approach for interviewing. It's not perfect either, but the best I have been able to find.

What I do is ask the interviewee to build out something simple in the language of their choice. Nothing too crazy, and something that can be completed in 30 minutes to an hour. Like a bowling scorer, or a sales terminal, or some such project. Then I ask them to send it to me in a day or two.

They have complete control over this. No worrying about time constraints or someone looking over your shoulder. Moreover, this way I get to look at what type of code they actually produce, and code that they think is good. Not just some function that they had to write on the spot while being too nervous to think straight. I get to see what type of tests they write, if they write tests, and how they organize their project.

And from there I can just have a conversation with them about it. Nothing scary, maybe pair up with them to refactor or add a new feature together and see what it's like working with them. This way though, they are on their home turf, in a codebase they have created, and you are working together as a team.

Final thoughts

I disagree that having a tech interview means making someone sweat bullets by making them take a whole goddamn test while being relentlessly watched over.

I’ve been interviewed with all of the approaches I mentioned, as well as used them all as an interviewer. Sometimes it went well, sometimes it didn’t, but to me it seemed a bit like luck as to how it turned out. What it boils down to is allowing the interviewee to demonstrate their best ability, and turning the interview into a conversation rather than a one-sided questioning.

That said, I have to go now to study up on b-trees or something else I havent thought about in years in order to prepare for my next interview.