Pair programming in developer interviews

How to evaluate coding skills without being awful

Interviewing software developers is hard. All you’re trying to do is answer two simple questions:

1. Will you like working with them?
2. Can they write good code?

While it’s usually easy to tell if you’ll like working with someone, figuring out if they can write good code is tough.

Designers can show you a portfolio, sales people can show you figures, but the only way to tell if a developer is good at writing code, is to see them write code.

Now that’s a problem, because making someone write code in an interview is awful. Whether it’s on a laptop or on a whiteboard, writing code while people watch you is awkward and stressful. If you get stuck, it’s humiliating.

Pro tip: Publicly humiliating job candidates is horrible, so don’t do it.

It’s also not a very fair test. A candidate will tend to do better if they can deal with the stress of performing in front of an audience. But we almost never work in front of an audience.

Not a normal work environment (source: https://blog.compete.com/)

If a candidate can’t code well under pressure with an audience judging them, that doesn't mean anything.

So how do we evaluate coding skills without being awful?

Solution: Ask the candidate to build something small and then build it with them.

Give the job candidate a small coding challenge, and then do it with them. Pair program, pass the keyboard back and forth, solve the problem together.

When you pair program, you can still evaluate their skill, but it takes the pressure off. In fact pair programming with someone always shows you their skill level. Even better, it gives you a chance to see how you work together.

Doesn’t pair programming in an interview just make sense? If they get the job it’s how you’ll work together anyway. How often do you ask a team-mate to do something and then pull up a chair behind them and silently judge them while they code? You would never do that, you’re not a monster. So why do it in an interview?

Picking a task

Pick a task that is small enough to finish in the interview and analogous to your work. Since I’m a front end developer I normally ask the candidate to make a small website widget like a countdown timer. I’ve found CodePen to be brilliant for interviews.

On getting stuck

Don’t let them get stuck, because why would you? Watching someone get stuck doesn’t teach you anything about how they will perform on your team. Keep the interview moving by varying your involvement depending on how well they’re doing. If they are flying through the problem, then sit back and let them lead. If they’re struggling, then be more active and help them stay on track.

Other interviewers

Normally in an interview there will be multiple interviewers. That’s fine, the other interviewers can sit back and observe. I’ve found that when the other interviewers watch a pair programming interview, they’ll make some really interesting observations about how you worked together as a team.

What else can you learn?

Pair programming is a great way to figure out how someone works in a team.

Look for how they respond to your suggestions and how they make suggestions to you. Do they contribute? Or just sit back? Do they tell you when you are wrong, or just let it slide?

Remote interviews

I’ve found this method works almost as well for remote interviews. If you have a desktop sharing program like Skype or GoToMeeting it can still be effective.

Is that all you should do?

Different interview techniques help you learn different things about a job candidate. So pair programming should just be one part of your interview line up. There are still lots of other useful techniques. The important thing is to consider each technique on the merits of what it can teach you.

Asking a candidate about their experience will help you learn about their background and their communication skills. Asking trivia questions about a programming language shows you their breath of knowledge. And asking them to name a weakness shows you if they have pre-prepared answers to stupid trick questions (e.g. I care TOO much and love TOO hard). It also lets them know that you’re a terrible interviewer. ;)

Finish strong

Here is the best bit. When you and the job candidate finish the task together as a team, give them a high 5.

Have you ever seen an interviewer and job candidate high 5? It’s weird and it’s awesome.

Artist’s impression (Source: http://files.chuv.ch/)

Developer interviews are a bit of a black art. If you have something you do that works well, let me know below…