Resumes are dangerous

I've been interviewing engineers for a while now, and it seems the more interviews I do, the more I realize how many my initial assumptions about hiring were wrong.

For example, take resumes. Initially, before every interview I'd carefully review resumes. I'd look at candidate's past experience, at their skills and interests, and I'd take it all into account. However, over time I've come to a conclusion: resumes are dangerous.

Often, when I'm reading a resume I'm thinking: "This guy is great, look at all this experience. He clearly knows Ruby and JavaScript like the back of his hand, and this interview is just going to be a formality". Then, come the interview, the guy can barely code, much less know the ins and outs of variable scope. It turns out there is very little correlation between how good a resume is, and how the interview actually pans out.

At best resumes give you some ideas on follow up questions to ask during the actual interview. At worst they give you a false sense of security that you actually know something about the candidate's abilities.

Well, you say, what about sourcing? Surely resumes are the only way to deal with the volume of job requests some companies get? I honestly think that, at least for engineers, you can solve this problem with practical coding challenges. These can sort most of the wheat from the chaff and, as well as being reviewed by an engineer, they can serve as a point of discussion during the interview.

The first thing I look for in a resume is a GitHub URL. If I can find that, I stop reading the resume and start reading code. Doing open source is not a be-all and end-all by any means, but it's a good starting point. After five minutes of reading through a candidate's code I have a good handle of their skill level and style, making the interview run much more smoothly.

As I'm talking to candidates we run through some of their code, and I will ask about the reasons behind the decisions they've made. The interviews are spent discussing code, and writing code. It's what we programmers do day in, day out. It's the one things that matters.

Above all, I try to hire people who I'd want to pair with tomorrow. People who are better than me, and people who I can learn from.

Getting hiring right is the most fundament part to any company. Valve put it well in their handbook:

Hiring well is the most important thing in the universe. Nothing else comes close. It’s more important than breathing. Here are some questions we always ask ourselves when evaluating candidates:

• Would I want this person to be my boss?
• Would I learn a significant amount from him or her?
• What if this person went to work for our competition?

So my message is evaluate the candidate, not their resume. During the interview focus on code that tackles common problems in your organization. Above all, hire people better than you.

The opinions here are mine, and not necessarily those of my employer, or even mine tomorrow