I'm the head of engineering at Tegus, a financial research startup. I write about politics, psychology, and software.
I've worked on a few open-source projects and infrequently blog.
Recent blog posts:
• Predicting the Success of Pair Programming Interviews
• The Computer Boys Take Over by Nathan Ensmenger
• Who by Geoff Smart and Randy Street
24 October 2016
Interviewing developers is difficult and, what’s worse controversial. Rather than spill ink on how to interview a candidate, I want to cover a few mistakes I see people make when making hire/no-hire recommendations after an interview.
These mistakes usually come from a place of good intentions. They are nonetheless dangerous; I very much believe that faulty hires on an engineering team can quickly do enormous damage. Fortunately, most of these errors are easily prevented with clear thinking and good judgement.
Giving someone a job is a fantastic feeling. If, like me, you’ve had moments in your life when you struggled to find work, you probably still remember how happy you felt when you finally landed a job. Extending that feeling to someone else feels pretty good as well. Unfortunately, it’s also just about the worst reason I can think of to hire someone.
When you prepare a hire/no-hire recommendation, you need to steel yourself. Don’t think about how the candidate will react to the news. Your only concern is whether or not they are the right person for the team.
Occasionally I’ve heard colleagues comment that by the standards of our hiring practices today, they might not have gotten an offer. In some cases, I think the people saying this are having a moment of imposter syndrome. But they might also be right - maybe the candidate is more qualified than they were. That doesn’t mean we should hire them, for two reasons.
First, it’s possible that extending an offer to the person feeling this way was a mistake, just one that happened to pay off. Extending an offer is always a bet; sometimes it goes well, sometimes it doesn’t. Maybe hiring the interviewer was the wrong call and the company just got lucky. In that case, it doesn’t mean much at all if the interviewer feels that the candidate is more qualified than they were.
Second, the needs of the team change over time, sometimes radically. It’s totally normal for hiring standards to change as well. If you think, “they’re more qualified than I was when I interviewed, but that’s not good enough anymore”, you aren’t being hypocritical. You’re doing your job.
This is sort of the opposite of the above mistake. “We hired me, I’m great and do great work, this person is basically mini-me – we should hire them!” Right. This is obvious self-flattery and most people see through it, but I still see echoes of it every now and then. Even if you are doing great work, you still need to ask yourself: is this the right person for the job?
(An alternate title might be “making excuses for the candidate”.)
Interviewing engineers is notoriously difficult. Given some thought, you can find major flaws in almost every single interviewing technique under the sun. Worse, the universe constantly throws wrenches into the process. Candidates miss trains, their flights get in late, they get nervous and clam up, they forget to eat over lunch, they drink too much coffee - whatever. These things happen and we, as understanding people, are tempted to call that part of the day a wash. It’s not representative of how they would do the job. No signal. Too much ‘no signal’ has to be a no hire.
It’s tempting to make excuses for candidates, especially if you like them. But ultimately you need to find positive reasons to hire someone, not the absence of reasons not to hire them. Don’t argue with yourself.
That about wraps my list for now. I might have a follow up post on mistakes people make when hiring at the organizational level, rather than the individual-level mistakes listed today.
comments powered by Disqus