Pairing exercise

We ask candidates to spend an hour pairing with an engineer on the team they are applying to. The pairing exercise is not used for technical evaluation. That’s what the async coding exercise (which comes first in the interview process) is for.

The assumption is that any candidate who gets to this stage meets the technical requirements for the job in question.

All pairing sessions should include a third engineer in the room as an observer. As such, they can stay muted for the bulk of the interview. Having another person in the room provides a more complete picture of the candidate and helps to reduce bias.

Details of the exercise

  • We will schedule a 60-minute timeframe to work with a Sourcegraph engineer.
  • In this exercise you write a command-line application that performs a simple task.
  • You may use the language of your choice.
  • You can use your own development environment, and look up documentation on the internet.

What we’re looking for

At a high level, this is what we are evaluating our candidates for:

  • Clear explanations of ideas and decisions.
  • Frequent communication while pairing.
  • Keeping the other engineer in the loop while driving.
  • Flexibility in considering other ideas and approaches, and in making changes to the code.
  • Ability to break down a problem and decide on an approach as a pair.
  • Healthy responses to feedback.

Before the interview

The engineer leading the pairing exercise should choose a task to work on from this list. An ideal exercise should:

  • be easy to explain
  • be language agnostic, so the candidate can use whatever language/tools they are most comfortable with
  • require no specialized knowledge
  • take 30–60 minutes to complete
  • have multiple ways to extend it: more features, add tests, etc.

Having ways to extend the exercise is important if you finish the exercise before the interview is over. Finishing the exercise is not a goal; the goal is to pair for as much of the interview as possible, since that provides the signal we are looking for. (This implies not finishing the exercise.)

All candidates applying for the same position should pair on the same exercise with the same people.

Important: If the engineer leading the interview has not led a pairing interview with the chosen exercise before, they must do a dry run with the hiring manager first. This is to ensure that any wrinkles are ironed out before we meet with a candidate.

Leading the interview

For the engineer leading this interview: Pair as if you are working with a colleague, not evaluating a candidate. Work together. Offer help if the candidate gets stuck. It’s totally fine if a candidate doesn’t know something or wants to look something up. In short: if it’s cool for a teammate to do, it’s cool for the candidate to do.

Finally, save the last 10 minutes of the interview for any Q&A the candidate might have. (No need to finish up that last task; just stop coding.)

For the engineer observing: Pay close attention to the items we are looking for, listed above. Don’t get sucked into the exercise itself, or offer ideas/solutions/feedback. The observer should be as invisible as possible outside of the inital introductions and the final 10 minutes.