This repo contains the pairing test exercises that are used in our recruitment process.
Please don't try to complete these problems before the interview. A key part of the interview process is understanding your approach to designing a solution and how you collaborate with people to solve problems. We make these problems public to help candidates approach the test with the same understanding rather than privileging people who have already done these kinds of tests or who have done pair programming tests before.
The paring test takes the form of an exercise in paired programming. The interviewer will take on the role of the co-pilot; they will help with syntax (if they know it), remind you of design decisions that you have declared previously and point out syntax errors or what they think might be causing bugs or errors in the code. However you as the pilot will be responsible for writing the code and making design decisions. The problems in this repository generally have multiple ways they can be solved and we have observed that people perform better in the test if they are implementing their own solution rather than trying to understand how the interviewer might approach the problem.
The other role the interviewer plays in the interview is as the Stakeholder. While the problems are not meant to have hidden requirements many of them have a range of possible solutions and valid or invalid cases. When the interviewer answers your questions as the Stakeholder they will tell you should approach the problem and you will not be judged on any limitations or problems your solution has that has been agreed by the Stakeholder.
During the interview you are allowed to look up information and where relevant to copy freely available code to solve the problem. If you are doing this then please let the interviewer know.
You can use an external editor to format the code or do other transformations but you should let the interviewer know that you are doing this and the code that is in the shared editor is the only one the assessment will be made on.
Due to the nature of the code editor that we are using for our remote pairing sessions it can be hard to get a unit test runner up and going unless you have already used standard test runners programatically. Therefore the interviewer will discuss what will be good enough testing for the purposes of the interview.
We have learnt that generally programmers hate to finish the interview at a point where the code is not working and therefore we may end the interview earlier than the allocated time if the code is working and there is not sufficient time to add additional features to it. This is no reflection on your performance but on the reality of remote working where if one meeting overruns it can have a big impact on the whole group due to the interviewer being late.
The problem statements in this repository cannot generally be completed in an hour. Therefore typically the interviewer will each choose a subset of the problem to work on or you will be asked to choose how you are going to approach the problem and what you will attempt to complete in the time available.
This is a fork of the Guardian's pairing tests with some new challenges added that reflect the problems we encounter in building a platform to help create better content more easily and fairly.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
