Extending a job offer to a new software developer is a big risk. Hiring the right person might unlock your team's potential. Hiring the wrong person sends a team into a tailspin. Given that, you want to make sure your interviews help you figure out whether the person you're talking to is the right one. For years, many companies relied on whiteboard interviews or take-home projects to evaluate potential hires. Both of these interview techniques have positives, but also real downsides. Whiteboard interviews are nothing like writing actual code. You might find that someone is great on a whiteboard but struggles mightily with an IDE. Take-home projects can be unfair to candidates, asking them to spend a significant chunk of unpaid time. They also can rule out candidates who have minimal free time or significant responsibilities outside work.
In the last few years, a third option has taken root for companies seeking that next good hire: the pair programming interview. Today, we're going to talk about what a pair programming interview is and how to make the pair programming interview work for you as an interviewer.
What Is a Pair Programming Interview?
First, let's talk quickly about what pair programming is. Pair programming is a system in which two developers pair up to work on a feature. One takes on the mechanical actions of writing code: thinking up variable names, actively typing, fixing syntax. The other developer is a "navigator." They think about the bigger-picture parts of writing code. Should you refactor that logic into a function? How should you handle a piece of data? Would this logic fit into an existing part of the codebase? Teams that adopt a pair programming approach often cite research by Alistair Cockburn and Laurie Williams that shows pair programming only slightly reduces total code written while significantly reducing bugs and mental strain on developers.
From there, it's not too hard to see what a pair programming interview is. It's where you use the structure of pair programming to interview candidates, with the candidate and interviewer working on code together.
Why Use Pair Programming Interviews?
The rise in adoption in pair programming interviews is attributable to a few factors. One is that they're easy to conduct from anywhere. It's challenging for companies that adopt a distributed-first or distributed-welcome culture to interview developers in person. Flying someone across the country and asking them to work in a nonnative time zone makes it difficult to show their skill. Additionally, pair programming interviews aren't as time-intensive for the candidate as a take-home project. And they're a lot more like actual coding than questioning someone in front of a whiteboard. As Anna Carey notes, whiteboard interviews often exclude people from nontraditional tech backgrounds. Pair programming interviews are an inclusive way to find top talent for your team.
How Do I Run an Awesome Pair Programming Interview?
I've personally done well over a hundred pair programming interviews as a developer and interviewer. Here's what I've found works the best from both sides to make an awesome experience.
Keep the Candidate Relaxed
When you're an interviewer, you don't have as much stake in an interview as the candidate. You'll probably run six interviews this week. The person on the other side of the call might only have one interview, or this job might be a huge deal for them. They won't do their best work if they're stressed, so work to ensure they stay calm. Take a moment at the start of the interview to break the ice, and if you sense a candidate tensing up, invite them to slow down for a moment, think, and talk through their thought process.
Only Test One Problem Per Interview
This is where a lot of interview processes break down. The candidate hops into a pair programming interview, and the interviewer asks them to solve a small problem. The dev does, and then they take a second, hoping they might be able to talk about the code they've just written. Instead, the interviewer pops another question, then another. Instead of examining code in-depth, the interview is a series of toy programming problems. This is challenging for the candidate because they're paying the costs of context switching. It's especially frustrating if the candidate receives a rejection. After a focused interview, a candidate can look back on their performance understand how to improve. When the candidate answered six questions, they probably have no idea where they didn't match up.
Instead, focus on one problem per interview. Take time to dive into the question and examine it. You can talk with the candidate about how they'd modify code when presented with new requirements to get a sense of how they'd work in your environment. Maybe you expand on the code they wrote by adding unit tests or thinking about documentation. But don't inundate them with a series of surface-level questions. You'll get a poorer sense of their capabilities due to the mental overhead, and they'll find the experience frustrating.
Use the Right Tech
Pair programming interviews can happen in person or remotely. Many companies are moving to remote environments for a variety of reasons. They'll often mix and match, with one interview remote and then another couple on-site. Whether you're in person or remote, make sure you're using the right tech. It should be easy for both candidate and interviewer to connect to a session, share their code, and hear and see one another. This is a place where CoScreen is a big win. By making it easy to share interactive windows across computers, it's simple for an interviewer to work directly with a candidate in a way that's low stress for both. Add integrated audio to the session, and both participants can communicate about the problem they're solving trivially.
Limit Your Interview to One Interviewer
This is probably a controversial opinion, but my experience tells me that more than one interviewer in a pair programming session is a recipe for trouble. There is a growing trend of sending three or more developers to unravel particularly knotty problems called swarm programming, but I've never seen it used effectively in an interview. Multiple interviewers create dynamics that are less comfortable for candidates and interrupt the pairing workflow. If you want multiple interviewers to evaluate the coding skills of one candidate, schedule multiple interviews.
Sometimes, you'll choose to have an inexperienced interviewer sit in on an interview to train them. That's OK! When you do this, clearly communicate to the candidate who the extra person is and why they're present. The trainee should refrain from contributing to the interview except at the very beginning and very end.
Record Your Interview
A lot of interviewers forget to do this. You'll likely have initial impressions from an interview that you capture immediately. Sometimes, you'll know whether a person would be a good fit right away. But often, you'll need to go back and reexamine part of the interview. A high-quality recording makes that possible. Also, having a recording allows you to evaluate your own performance in the interview. Interviewing is a skill just like coding, and getting better at it is important for your company your candidates. Examine how you perform in interviews to make your interviews the best you can.
Stay Focused
I can remember the worst pair programming interview I ever had. It was for a job that I wanted badly and was part of an on-site interview. I'd already done three pair programming interviews, and this was the last one. My interviewer sat down and outlined the problem we'd be working on. I started to talk through how I might solve the problem, and he interrupted me to ask if I'd heard of a specific algorithm. When I replied that I hadn't, the disappointment on his face was clear. At that moment, he checked out. While I dove into the problem for an hour, eventually putting together a working but non-optimal solution, he checked Slack, composed emails, and chatted with passers-by. When I received a rejection notice, I asked for feedback. I'd passed every part of the interview but his.
I can't help but think that if that interviewer had spent a little more focused time during our interview, we might've put together something that passed. Instead, my lasting memory of that day is the look of disappointment on his face at my not having memorized a niche sorting algorithm. Strive to make your interviews positive experiences, even for candidates you reject. Work with everyone like they're your top prospect, and some people will surprise you with how well they do.
Pair Programming Interviews: One Piece of the Puzzle
I caution against hinging every hiring decision exclusively on pair programming interviews. They're one of the best ways to figure out if someone can write code—but they're not going to tell you everything about a candidate. You'll still want the candidate to meet the team, and for many developer roles, you'll want to spend time talking about bigger-picture software design, too. But they do give you a great insight into how a candidate might fit your team, and they respect the time of both the interviewer and the candidate. Just remember that pair programming itself is a skill, as is using it for interviews. Don't expect the pair programming interview to be a silver bullet, and don't expect you'll be perfect at it your first time. Practice and reevaluate your performance as an interviewer, and you'll find that pair programming interviews help you make the best decisions about who to hire.
This post was written by Eric Boersma. Eric is a software developer and development manager who's done everything from IT security in pharmaceuticals to writing intelligence software for the US government to building international development teams for non-profits. He loves to talk about the things he's learned along the way, and he enjoys listening to and learning from others as well.
