How Pair Programming Can Improve Technical Interview?

Adam Nowak

Jan 20, 2014 • 6 min read

Having a programming session with a potential recruit is only one element of the hiring puzzle, but it's often the most important one.

Having a programming session with a potential recruit is only one element of the hiring puzzle, but it's often the most important one.


We use pair programming as a form of a recruitment tool, because it is way more representative of a coder’s skill rather than just looking at a CV and asking a long set of questions face to face.

How does it start?

DSC_8035 (1)

First, in order to do a pair programming session, we need 2 guys/gals: one from our company and the other one who would like to apply for a position on our team. As soon as we have them, we arrange a meeting. We're a very remote-friendly company, so if we are not able meet in the office, we just use one of well-known tools like: google hangout (which has now new desktop sharing feature enabled) or Screenhero. No matter which tool we use, the effect is still the same - we've got two great programmers seeing the same code they will be hacking on soon.

What does it look like?

A programmer from Netguru comes prepared to the meeting with one task regarding one of the real projects they actually work on. Of course, this task is chosen based on what position the candidate applies for and what the experience level of the candidate. In the next 30-60 minutes, both programmers work on the same code, talking and thinking a lot throughout the meeting (and that's how true development looks like anyway, right?).

Our developer explains the task, and then asks simple questions in order to better understand the candidate and his knowledge.

The developer on our side is regarded as the “pilot” of the pair programming session. He/she often explains what their approach would be to the problem, why it might not work, what were the disadvantages of a given approach and so on. She tries to establish a dialog with the candidate and both of them work together on solving the task.

The candidate should be prepared to be the 'navigator' of the session. It means that she's more or less responsible for the pilot’s moves in the editor. Moreover, it's better to have things this way, because we often use some fancy key-bindings in our editors, so it isn't easy to adjust in only few minutes and we don't want to introduce any unnecessary stress to the person we try to hire.

What are the typical questions asked during a pair programming session?

  • Hey Joe, this task says that we should put additional page to X, where should we start?
  • Do you know how could we shorten this and get rid of the duplication?
  • Is there anything we could do to have it in a more object-oriented way?
  • You're going to test it, right?:)
  • What's your opinion on Y?
  • Do you prefer A over B?
  • Are there any plugins you use often in your editor worth recommendation?

Why do we do this?

DSC_7814 (1)

We know more about the person we're dealing with this way. We have the 'feel' for how the person will fit within in our team (we're mostly young happy people, we like optimists!:)). And it's ALWAYS better to talk to a developer with code. It's his natural environment and he should feel good there. We programmers tend to be introverts often and we're afraid to make contact. Adding code to the dialog seems to lower that barrier and make the recruitment process less painful (sometimes it has even turned into enjoyable experience to both developers!).

And of course, we can see what kind of person our candidate is. Is he trying to do everything on his own, or rather ask if he’s stuck? How good is he in finding information (we encourage people to use Google Search/Stack Overflow during these sessions, because that’s something we do every time), because it’s one of the core skills of developer. We’re interested in how people think about given problems, what drives them or what they still have to learn.

The idea of pair programming isn’t new of course, we’re basing this on the experience of PivotalLabs, which does pair programming all the time and their developers love it. They also claim that talking to a candidate and spending some time with him shows if the person is willing to absorb knowledge and verbalize what is he thinking during the session.



We always give feedback to candidates. We tell them what could’ve been done better, or where we think they need to put additional effort in order to be a better programmer. Naturally, there’s often a chance to send an high five over when task is complete and works as expected. Even if we see that we’re not going to work together in the future, we give advice and link to resources which we think could help. Feedback is the core element to achieving progress. But that’s something for another blog post.


Pair programming is a great opportunity to talk to a potential developer recruit. It’s the place where both technical and social skills meet together. It’s also a very good way to see if the person is the kind of person we would like to work with in next months, discover his attitude and learn about his goals.

Want to check our process from the inside? Apply for one of our job offers!

More posts by this author

Adam Nowak

Codestories Newsletter

Read more on our Blog

Check out the knowledge base collected and distilled by experienced professionals.