Interviewing and hiring developers


Methodologies and philosophies on screening, interviewing, and hiring software developers go through fads and phases, as popular wisdom is debunked, thought leaders share their methods, and developers themselves are promoted and bring their own experience to bear. Most of us would agree that nobody's really doing this right, and we don't really agree what "right" would look like.

This week, Max Howell, aka mxcl, who is the author of the amazing Homebrew package manager for MacOS, tweeted about being rejected by Google in an interview.

It's fair to say that when your interview process generates that result, you're doing it wrong. 

I've been in the position to hire engineers for six years now. My methods and approaches have changed over time, and I feel pretty good about where they stand today. The goals are simple: spend as little time as possible on recruiting and hiring, minimize your false negative (declining a candidate you should want to hire) and false positive (hiring a candidate you regret hiring) ratio during screening and interviewing, and hire people likely to grow in value to the company. This means containing the effects of human bias, using screening and interviewing criteria that are relevant to the work the job requires, and fail early with true negatives (candidates you really don't want to hire).

Ultimately, I have four questions my hiring process is meant to address. Four and only four.

  1. Can this candidate write code that I want to read and review code that I write?
  2. Is this candidate able and hungry to learn and grow?
  3. Can this candidate follow instructions and build to spec?
  4. Is this a candidate that I can put in front of a client or customer without jeopardizing that relationship?

That's it. That's all I care about.

I have recruiters I work with who function as the initial screen. Ideally, my recruiter team reflects the diversity I want in my engineering team - and a diverse team of recruiters is less likely to exhibit strong unconscious bias against gender or ethnic minority candidates. I don't task them with traditional bullet points like 3-5 years experience with Django or lists of specific technologies or software products; I don't actually care at this point whether this candidate has experience with my technology stack or if they have professional experience coding. So long as they prefer Python and understand web programming, they're in the running.

What I want my recruiters to pursue are questions I'm interested in about the person. "Tell me about a software project you really liked working on?" "Why did you want to be a software developer?" "Why did you choose web development instead of any other area of expertise?" My recruiters aren't super technical people, but I'm interested more in how a candidate responds versus what the actual answers are. Are they passionate, or are they a 9-to-5'er? Are they able to step outside their comfort zone and grow, or do they like to stay close to what's familiar?

If the first date between the recruiter and the candidate goes well, now I want a code sample. I've given my recruiters a couple of straightforward programming problems, and they pick one to give to the candidate to implement. For example, one of my favorites is: "Write me a web application using a Python web framework that accepts a decimal number and outputs that decimal number as a Roman numeral." This problem isn't complicated; I don't want the candidate to spend more than an hour or two working on it. But it gives me a well-rounded taste of their code: a simple algorithm, hooking it up to a web framework, and basic HTML form processing.

I specifically do not want to know the candidate's name or to see a resumé before I see the code. I read the code without any knowledge of who wrote it, because I don't want any of my biases to creep into my analysis of their work product. Their code is all that matters. If the code is something I wouldn't mind reviewing and being delivered to a client or customer, only then do I want to see a resumé, but even then I still don't want to know the candidate's name or address. I want their work history to speak for itself, so I can gauge their seniority and whether the quality of their code matches up to the place they are in their career. It's only after I've evaluated anything else that I'm willing to know the candidate's name.

When we schedule an interview with the candidate, I pick a member of my engineering staff who is around the same level of seniority as the candidate to be their technical contact with our company. That staff member meets the candidate along with the recruiter when they come in for an interview and also does the technical interview of the candidate. What I ask my engineer to do is to give the candidate a pull request in peer review for an actual project for an actual client, and to ask the candidate to review it. It helps us see how they think and work using real scenarios.

Finally, the candidate meets with me. At this point, assuming my engineer responded favorable, I'm looking to sell the candidate on my practice and on working for me, answering any questions and gauging their comfort reporting to me as part of my team. At the end, the recruiter, their technical contact, and I see them out. The candidate knows within 24 hours whether we'll be extending them an offer or not.

I like my approach because it does the most possible to defer any possibility of unconscious bias from entering the process until it's simply unavoidable; it efficiently uses my time, my team's time, and the candidate's time; it gives me actionable insight into the candidate's ability to perform the job we're hiring for; and it doesn't involve irrelevant hoops to jump through like inverting a binary tree on a whiteboard.

Do you have your own techniques and strategies? Let me know in the comments below.

(Photo credit)

Current rating: 5