The developer of this repository has not created any items for sale yet. Need a bug fixed? Help with integration? A different license? Create a request here:
Thank you in your interest in the Guardian Digital Department's coding exercises. This repo contains exercises used in the Guardian's recruitment process. These exercises are used for all engineering roles, at all levels.
Inspired to work for us? Apply now
The coding exercise is the penultimate stage of the interview process.
It is a 45-60 minute exercise where you and a Guardian Engineer 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.
You will typically play the role of driver and the Guardian Engineer will be the navigator.
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 coding exercise allows us to assess your approach to solving a problem, what you prioritise, how you communicate your thinking and how you respond to any suggestions or advice. Ultimately, its a chance for us to understand what it would be like to work with you and also a chance for you to assess if the Guardian is a good fit for you.
This isn't a whiteboard coding exercise; searching online is perfectly fine and encouraged.
Although rare, you may elect a language that you do not have much experience with. In this scenario, the Guardian Engineer may play the role of driver.
...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 use the exercises in this repository and they are used for every Engineering role.
We also have this repository on GitHub with skeleton projects that can be used.
Choose an 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 coding exercise 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 them 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.