This repo contains the pairing test exercises that are used in the Guardian recruitment process.
Why have we published our exercises?
Inspired to work for us?
The pairing test is the penultimate stage of the interview process for the candidate.
It is a 45-60 minute exercise where you and the candidate work as a pair writing code to solve a problem.
Similar to when you pair with a colleague, there will be a driver and a navigator. The driver will be the one at the keyboard, whilst the navigator will be on the side making suggestions and asking questions.
The candidate will typically play the role of driver and the interviewer will be the navigator.
From: How does the Guardian recruit developers?
I think pairing tests are the fairest form of interviewing you can offer. I know they can be stressful but they represent a big commitment in terms of effort and time. They create a situation that approximates the kind of work the organisation does rather than artificial trivia or whiteboard tests. They also give the candidate a chance to meet some of the people who already work at the Guardian and see if the environment suits them.
The pairing test allows us to assess a candidate’s approach to solving a problem, what they prioritise, how they communicate their thinking and how they respond to any suggestions or advice. Ultimately, its a chance for us to assess what it would be like to work with the candidate and also a chance for the candidate to assess if the Guardian is a good fit for them.
We’re not assessing a candidate’s pure technical ability and searching online is perfectly fine and encouraged.
From: Changing the Guardian's pairing test
...allow candidates to do the pairing interview in the language of their choice. We would still prefer if candidates used our core languages of Scala, Python and JavaScript but if Haskell, Clojure, Ruby or Go are more your bag, then feel free.
Whilst Scala or JavaScript, Swift/Objective C for iOS, Kotlin or Java for Android, are the preferred languages, a candidate can elect their own.
In a few cases, it may be applicable for you to drive and the candidate to navigate. For example if the candidate has no knowledge about the language they have chosen. This should be rare.
From: The Guardian's new pairing exercises
...we have decided to increase the number of pairing exercises, any of which can be picked by a Guardian developer prior to the pairing test.
We have a public repository on GitHub with our pairing exercises. These exercises are used for every role.
We have this repository on GitHub with skeleton projects that can be used.
Choose a pairing exercise, checkout the skeleton project repository, prepare your machine and setup up your IDE.
Turn off notifications and other possible distractions for the candidate; an easy way to do this is to use a different browser profile and closing your work profile.
Get some pen and paper in case the candidate (or you) need to draw anything.
The developer manager for the role will collect the candidate from reception and bring them to your desk.
Offer the candidate a drink.
Explain what you’re going to be doing today.
This is the pairing test stage of the interview process. We’ll spend about 45 - 60 minutes writing code to solve a problem. We’re not assessing you on your deep technical knowledge or your understanding of the standard library, we’re more interested in how you solve a problem. With that in mind, feel free to search online for anything, ask questions etc. It’s not about how far we get through the exercise.
Provide guidance on where to start. For example, directory structure, where to add tests etc.
Try not to touch the keyboard or dictate a solution as this doesn’t provide much detail about the candidate.
If the candidate is struggling, guide the candidate to a solution. This can take many forms, such as diagramming, pseudo code etc.
If you see a really obvious mistake, don’t let the candidate struggle with it. For example, if they’ve misspelt a variable, passed arguments to a function in the wrong order etc.
Ask why the candidate is doing things that way to help understand their thought process.
Write up some notes about the interview focusing on the assessment criteria. Candidates can see what is expected at each level in the people section of our developers site. Interviewers may also find it useful to add some inline comments to the code. These will be useful in the wash-up for candidate, where the interviewers discuss the candidate as a whole and decide if an offer should be made or not.
If the candidate is largely performing at the level they have applied for, let HR know that you’d recommend the candidate advance to the next stage of the process.
If the candidate is performing below the level they have applied for, talk with the developer manager of the team the position is for as there may be a more junior role open that the candidate would be more suited for.
If the candidate has performed below the level they have applied for and there are no open positions more suited, inform HR that we won’t be progressing the candidate’s application and provide feedback structured around the assessment criteria.
Do not push the candidates solution to remote.
Raise an issue or PR for any improvements to the exercises.
Get your name added to the list of people who perform interviews.
Ensure your calendar is up to date with holidays, working from home days etc as this helps determine availability.
More (internal) resources for Guardian Digital recruitment are available here.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent