How to make techies better interviewers

Soon after I started my very first programming job, I got to interview someone else for a similar role. I knew little about interviewing, but my co-interviewer Raj*, a two-year veteran of programming, seemed to, so I decided to follow his lead. Raj's strategy was to play good cop/bad cop, and he cast himself as the bad cop. For the half hour we interviewed, I watched the candidate squirm under Raj's uncharacteristically stern look and the staccato firing of his questions, while I was relegated mostly to whispering mine, which I read from a little quiz I had prepared.

After the interview, Raj smugly pronounced the candidate unfit for hire because it didn't seem he could work under pressure. That, apparently, had been the reason why Raj had been so tough during the interview.

In the twenty years since that experience, I've been on both sides of the interviewing table, and I've had my share of technical interviewers whose manner bordered on the hostile. I've formed a hypothesis about why this is so, and it has nothing to do with finding out whether or not someone can work under pressure.

I think techies interview like this because we know no other way. In being interviewed ourselves, this is what we've experienced – coding tests, logic puzzles, tricky questions. Besides, we pride ourselves on coming up with clever, hacky ways of solving technical problems, and we want to see if the upstart on the other side of the table has those chops too before we allow them into our little in-group. It gives us a small rush of power, I think.

In doing it this way, however, we undermine the actual purpose of the interview – to find someone who can effectively share the workload with us, and with whom we can work affably. The interview process we've learned makes us see human beings as little more than checklists of skills that we can test on a quiz or on a whiteboard. It's an ineffective process.

So how can we interview better? Today, with the benefit of a couple of decades' worth of experience in the trenches, if I had to give some interviewing advice to my rookie self, here's what I'd say.

Firstly, and rather obviously, make the interviewee comfortable. Offer them water or coffee, ask if they want to use the bathroom, make small talk. It's only polite. An edgy or uncomfortable person is not going to be able to show what they can do. Treat them like colleagues, because, really, isn't the whole purpose to hire someone to be a colleague?

Secondly, ditch the programming quiz. Programming quizzes are usually tests of memory, and anything that can be memorized can also be looked up. Also ditch lateral thinking or logic puzzles. These are often touted as ways to find out whether someone can "think outside the box", but they really only go to show whether or not the candidate is good at solving puzzles. They don't offer any insight into the way they do useful, productive work, or how well they work with other people in a team. It's more important to get a sense of work ethic than have them mindlessly answer coding questions. What's the point, really, of remembering arcane stuff from your undergrad CS textbook? That kind of thing can always be looked up on the Internet – that's how most of us do it anyway.

Clearing away the quizzes and the puzzles allows you to make space for a productive discussion. Now you're free to engage them in the real issues you see at work everyday. Perhaps you can have them do a code review, or participate in a pair programming exercise. Both are excellent ways to find out how they think and work, and both will tell you almost everything you wanted to find out with your quizzes and your tricky questions.

But even if code reviews and pair programming are not possible, at least give them a real and relevant work issue to engage with, instead of a contrived one. Give them space and whatever else they need – supplies, a whiteboard, a computer. Make them feel as if it is a regular workday – and please, don't scrutinize them while working. Working on a technical problem is an iterative process of exploring choices, going down blind alleys, and evaluating different approaches before finding one solution that suffices. To have someone with the power to recommend hiring you watch you go down multiple dead-ends can be unnerving and intimidating when you're in the vulnerable situation of needing a new job.

Interviews are already stressful, and it serves no one's purpose to make them even more so; the kind of pressure that Raj artificially built seldom happens, and is never productive. Don't turn interviews into interrogations.

As engineers, that is what we can do, but it is up to the organization ultimately to invest more effort into building these skills in their employees. People are what matters, and if the people take away a poor impression of your company because of the way they were made to feel during an interview, then it becomes harder to attract good talent.

So go get 'em, kid. You'll be fine – as long as you remember that you're hiring people, not coding machines.

* Names have been changed for privacy