You suck at technical interviews – Response
A post titled You suck at technical interviews has been popping up on my twitter feed this week. It was written by the CTO of npm and makes some really good points on the difficulties around technical hiring. I agree with most of what was said, except for one or two key points – which I will outline below.
I do believe that a great many technical interviews in our industry are done poorly. Apart from having done maybe 100+ technical interviews in my career I have also been interviewed at least 30 times, so I can completely empathize with the majority of the pain points outlined.
Poor Interview Questions
Off the top of my head, here are a few interview techniques which I have experienced:
- Being asked to solve brain teasers (many, many times)
- Being asked to solve a coding problem in a fixed (and very short) amount of time
- Being asked to solve a coding problem and being penalized for using the internet to look up documentation
- Being asked to solve a coding problem in a technology I was completely unfamiliar with
- Being asked to solve a coding problem on a whiteboard (many, many times)
I could probably come up with a few more examples, but the point I’m trying to make is that there is definitely massive room for improvement in the way that our industry conducts interviews.
The Cardinal Sin of Technical Interviews
As I said, for the most part I completely agree with the article in question, my main gripe is with this section:
I used to ask people to write code in interviews. This is terrible. Writing code on a whiteboard is an experience so far removed from the real practice of writing code as to be no predictor. Even writing code on a computer, as part of a pair for instance, tests for the wrong ability — you are asking them to write code under time pressure, with somebody watching. Some of the best engineers I know would melt under those conditions. And if your belief is that writing code under intense time pressure is part of your job, then you should examine whether that’s a problem your company has.
I agree that asking candidates to write code can be done poorly, but the cardinal sin of technical interviewing is to not have candidates write any code. How on earth can you expect to judge the competency of someone who spends the majority of their day writing code without actually getting them to write code? This would be akin to interviewing a chef but never asking them to cook something or reviewing a book by watching the movie – you would be mad to even suggest it.
The real question then is: How do we pose coding questions to candidates in a way that doesn’t suck? Here are a few suggestions:
- Make sure there is an ample amount of time – a full day is preferable.
- Pair with them. This solves the issue of the candidate getting stuck on a minor detail and not being able to adequately solve the problem as a result. Even if the candidate is unfamiliar with your technology stack, having an experienced developer pair with them will give them the necessary support in order to tackle the problem.
- If at all possible, the coding problem should be a story on your real codebase. Making up problems for the interview will not give you an accurate idea of how the candidate works in your technology stack. It’s also important to show the candidate the environment and codebase they could potentially be working on.
- Make sure you setup the development environment to suit the candidate. For example, I use Vim as my editor-of-choice, but if a candidate is more comfortable in Sublime or TextMate then that’s what we will use – I want them to be comfortable, not me.
Help the Candidate Succeed
I believe the goal with these types of interviews should be to help the candidate showcase their skills. If they get completely stuck you should guide them in the right direction, don’t just sit there while they blankly stare at the screen. There are definitely good developers who are terrible at interviewing – this is something you should be very sensitive to and we need to go to every effort to help candidates succeed.
Asking candidates to write code on a whiteboard is bad. Asking them to write code under time pressure is terrible. Not asking them to write code at all is insane. Happy coding.