Hiring a Developer? Don’t Do These 5 Things

You are bad at giving technical interviews. Yes, you. You’re looking for the wrong skills, hiring the wrong people, and actively screwing yourself and your company. Without changing anything about your applicant pool, you can hire different people and your company will do better and you will enjoy your job more.

I realize these are bold claims. In the ten years since I became senior enough to be asked to interview people, I have conducted a great number of technical interviews, been part of a lot of teams at companies big and small, and watched the effect that different types of hires have had on those companies. I’m not claiming to be perfect at hiring — at various points, I have done nearly all of the things wrong that I’m about to tell you not to do. But here’s what I’ve learned so far.

You are looking for the wrong things

1. Don’t hire for what they already know

The primary mistake that people make when interviewing is over-valuing present skills and under-valuing future growth. Don’t hire people for what they already know; the pool of people who do exactly the thing you need them to do is much, much smaller than the pool of people who are smart enough to be good at that job.

But even worse is the way we try to determine whether people have these skills. People ask questions in interviews about obscure syntactical features of programming languages, or details of popular APIs. The famous fizzbuzz test simply asks “are you aware of the modulo operator?” If the answer is “no” then they are probably a pretty weak candidate, but it provides exactly 1 bit of data. Yet people will spend twenty minutes on it in an interview, a huge waste of limited time.

2. Don’t hire for what they can remember in an interview room

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.

Whiteboard and coding interviews also routinely ask people to re-implement some common solution or low-level data structure. This is the opposite of good engineering. A good engineer will try to maximize productivity by using libraries to solve all but the most novel problems. It’s also a poor test: how do you know if somebody is solving the problem or merely remembering somebody else’s solution? There is no value to memorizing the details of algorithms you can google in 15 seconds.

3. Don’t hire for a fancy degree

Some people are impressed by academic credentials. Having gone to a good college, or having gone to college at all, are not in my experience good predictors of ability as an engineer. Having a PhD in a relevant field is interesting but also an unreliable predictor: engineers write code and ship software; academics prove theories and write proofs of concept. Somebody smart might be able to do both but it’s by no means a given, or even very strongly correlated.

4. Don’t hire for their previous employers

People also over-value brand names on resumes. Don’t hire somebody because they worked at a hot company, or a famous one, especially not if that company is big. Variation across teams in big companies is enormous. Just because a company was successful doesn’t mean your candidate had anything to do with that. If you are familiar enough with another company’s hiring process that you can vouch for it as a good selector of qualified people, you might use that to bump them to the front of an applicant queue, but beyond that, go with what’s in front of you.

5. Don’t hire friends and family

And finally, never hire your family and if you can avoid it, don’t hire your friends either. Existing relationships create bias and implicit power structures, webs of obligation and loyalty that are at odds with what is best for your company. You will either compromise your friendship or your company, and rather than being forced to pick one or the other, just avoid the conflict entirely.

(Image via Olivier Le Moal/Shutterstock.com)

Read more at Quartz.