Thank you for your interest in the Guardian Product & Engineering 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.
Why have we published our exercises?
Inspired to work for us? Apply now
The coding exercise is one of the stages in our 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 making suggestions and asking questions.
You will typically play the role of driver and the Guardian engineer 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 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, it's 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.
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 we prefer that you pick Scala or TypeScript for Full-stack or Server-side roles, JavaScript or TypeScript for Client-side roles, Swift/Objective C for iOS roles, Kotlin or Java for Android roles, you can still elect to use any other language (e.g. PHP/Go/Ruby), providing we can find somebody to pair with you.
Yes - at the moment we are running a trial allowing candidates to use AI tools (e.g. GitHub Copilot, ChatGPT, Claude Code, Codex) during the coding exercise, but we require full transparency if you plan to use any.
Our goal is to assess your problem-solving ability, communication, and engineering judgement. AI tools should complement your skills, not replace them.
You will not be penalised if you choose not to use AI assistance during the coding exercise.
- Ownership and understanding: you are responsible for every line of code submitted. You should be able to explain, defend, correct and refactor any generated code.
- Light-touch usage: the most successful candidates tend to use AI as an intelligent autocomplete for syntax, boilerplate or specific functions, rather than relying on it to solve the high-level problem.
- Verification: treat AI output like a draft. Check edge cases, verify correctness, and refine overcomplicated output.
- Readability: code clarity matters. Ensure any generated code meets high standards for readability and maintainability.
- Full transparency: we require you to disclose all AI usage and share all screens used in the coding exercise.
- Avoid over-rehearsing: we strongly discourage using AI to pre-solve all the exercises before the interview. Rehearsed solutions tend to hurt candidates in a live interview.
- No one-shot solutions: do not paste the full exercise prompt into an AI tool to generate a complete solution. This makes it very hard for us to evaluate your problem-solving process.
- Plan first, prompt second: spend the first few minutes understanding the core problem and forming an approach and explain your plan to your interviewer. Your design decisions should drive the AI, not the other way around.
- Work in small iterations: prompt for small, isolated pieces (e.g. single functions or utility helpers) rather than massive rewrites. Avoid setting off multiple tasks at once.
- Talk us through it: narrate your thinking out loud - including what you are prompting the AI to do and why. Silence while waiting for generated code gives us no insight into your thought process.
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 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.
More information for candidates can be found here.
More information for interviewers can be found:
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
