Here’s a webinar I did recently (with our friends at Greenhouse) about the Stack Overflow developer interviewing process. Give it a listen!
First: it’s hard
Technical interviewing is hard. The best companies in the world haven’t cracked this nut. Here’s what Google had to say about the process.
Years ago, we did a study to determine whether anyone at Google is particularly good at hiring. We looked at tens of thousands of interviews, and everyone who had done the interviews and what they scored the candidate, and how that person ultimately performed in their job. We found zero relationship. It’s a complete random mess...
This is coming from a company that interviews tens of thousands of engineers, and knows a thing or two about analyzing the data. If it’s hard for them, it’s hard for all of us.
Smart and Gets Things Done
Even so, we have some strong opinions about how to hire (and keep) good developers -- our founder wrote the book on the subject, called Smart and Gets Things Done. This forms a framework for our process.
Mostly Remote
We perform most of our technical interviews remotely, using Google Hangouts and a shared doc for code. It’s quite rare for a technical interview to happen in person. Stack Overflow has a strong culture and history of remote work, and our interview process reflects that. More than ⅔ of our technical staff works remotely (and you could too!).
A conversation, not a quiz
Our interviews are designed for conversation, and to learn how the candidate thinks. We don’t want our interviews to feel like a quiz. To be clear, the interview is highly technical and challenging. However, we work hard to make sure the questions lead to productive exploration and conversation.
Fairness and comfort
The interviewing process is artificial. We know this. In real life, no one expects an engineer to program on the spot, in an hour or less, with someone watching. It is in our interest, and the candidate’s, to relieve their nervousness as much as possible. A relaxed interview is much more informative. We explicitly tell them to think out loud, take their time, and if they need to back up and fix something, that’s great. That’s how programming works. We reiterate that we are not looking for the answer to the question, per se.
Decisive
After each interview, the interviewer must make a clear decision: Hire or No Hire. We don’t do “maybe” – that’s not good for us or the candidate. If the interviewer is on the fence, that’s a No Hire. We would prefer to risk losing a good candidate rather than hire the wrong person.
Mitigating subjectivity
We also work to mitigate the subjectivity of the process. We standardize on a small number of technical problems, and we write out a script to guide the interviewer. We want to give every candidate a fair shake. But we also acknowledge that every interviewer, candidate and interview is different.
When the answer is No
We want the candidate to feel respected, even when it’s not a match. Programmers have friends! It’s important to maintain our employer brand.
OK, now tell me about the interviews...
Sure thing. Watch the video above.