Skip to main contentSkip to navigationSkip to navigation
Women talking together at a table
TEA00719 - Starbucks Coffee, Oxford Street/Oxford Road, Manchester, UK. Photograph: Trevor Cummings/flickr
TEA00719 - Starbucks Coffee, Oxford Street/Oxford Road, Manchester, UK. Photograph: Trevor Cummings/flickr

How does the Guardian recruit developers?

This article is more than 9 years old

Recruiting people is a hard process: you need to be fair to both the candidate and the organisation. As part of making it easier for candidates who apply to be a developer at the Guardian we want to be open about our recruitment process

As part of our interviewing scripts we have reminders to tell the candidate at the start of each interview how the interviewing process works and where they are in terms of progress through the different stages . In this blog post I want to summarise the whole process and also add some more detail that answers questions that people have asked us during their application process. I hope at the end of the article you will be clear about how we conduct our recruiting and I will be able to share some insight about why we do things this way.

It all starts with an application

We receive a number of applications each week and when we review them we need to sort out genuine applications from the many speculative and often poor quality efforts.

Quick Guide

How do I join The Guardian Product & Engineering?

Show

Where can I find open positions?

Apply for one of our open positions here.

What can I expect from the interview process?

We aim to be as fair and transparent as possible in our hiring process. Similar to other organisations, there is a CV screening, coding exercise and a face to face interview. Read more about what to expect and apply now here, and read more about our department here.

Was this helpful?

Some people fail to put the correct company name on their form covering letter, or are confused about which Guardian they are applying to. We do not do insurance (that’s Guardian Life), property development (Guardian Developers) or healthcare (Guardian Healthcare). We are the news organisation, just in case you were uncertain about that.

Good applications explain why someone wants to work at the Guardian, why they have decided to apply now, they point us towards source code, blogs or contributions to the community. They also tell us a bit about the applicant as a person and what they are like. Covering letters really matter and we always insist on an application having one.

Poor applications are just lists of projects and technologies that make it difficult for the reviewer to understand what is important and relevant about the application. As an organisation we care a lot more about delivering value than we do using Scala or a particular framework. We care less about what you have done in the past and more about how you have done it and why.

An overview of the interview process


The basic interview process involves three stages:

  • A phone interview

  • A pairing test

  • A face to face interview

Each stage has to be passed for the candidate to progress to the next.

Sometimes we have additional steps based on the circumstances of the role and the candidate. For example, we will occasionally conduct a remote technical test prior to asking someone to travel to London for the pairing test. Occasionally we have additional interviews after the face to face interview to deal with particular questions that weren’t covered in the general interview, or potential team assignments where a particular team want to do an additional interview. These are very rare though and for most people there will be three straightforward stages.

The phone interview

Our phone interview lasts between 15 to 30 minutes. It is our chance to find out more about the person beyond the CV.

We have some technical questions. The exact questions vary according to the role you apply for but in general our questions are designed to be straightforward: we don’t ask any trick questions. We aim to make our questions open so that experts can go beyond the basic answer and adds the nuances. Internally we rank answers according to the depth of understanding the candidate demonstrated.

One piece of advice for technical questions is not to try and bluff your way through things you don’t know. Some guesses are so strange or far from the mark that it often derails the interview for both sides. If you do not know the answer or you have not done any work on the subject of the question then move on to a question that you do know. Spend time on your strengths, not your weaknesses.

The bulk of the questions are not technical though, we want to understand how a candidate thinks and therefore a lot of the questions are simply about giving the candidate a chance to explore what they think about a topic.

There are no real right or wrong answers and I always say that the best approach is to be honest. One common mistake that people make in the phone interview is trying to second-guess what answer the interviewer wants to hear. Since we often don’t have a fixed “right” answer a candidate can end misrepresenting themselves in a pointless way.

The pairing test

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.

We have a variety of pairing tests we do depending on the role being applied for. We have a general coding exercise, one for frontend technologies like HTML and CSS, one for JavaScript. I have also used actual production bugs for the test when we have been recruiting for very specific roles.

In all cases though the critical things are the candidate’s ability to communicate, reason about problems, ask for help when needed and enjoyment of coding.

In our general pairing test we do not have specific requirements for knowledge of the programming language. If you take the pairing test in Scala and you haven’t done much in the language then you are not expected to know much about the syntax. If you say you have ten years programming experience in Java but cannot write a try-catch block then that’s a different case. We try and match our expectations about performance against the experience the candidate claims.

Just another day at the office

A pairing test is in many ways just like turning up to work or taking part in a coding dojo. It seems trite, but if you can relax and enjoy the experience then you will do okay. If you feel like you have something to prove in terms of a solution or you feel you have to complete the exercise then you will put yourself under a lot of pressure which, like any stress, will impair your ability to work.

If you have not done any pair-programming in your career then it is really worthwhile attending a coding event where you will get the chance to give it a go in a relaxed setting. Or perhaps simply persuade a friend to give it a go with you.

You can read more about our pair-programming test in this post.

The face to face interview

The final stage of the interview process is perhaps the most traditional. This is a straightforward face to face interview with two developers that have not been involved in the process to date.

To some extent the face to face covers the same ground as the phone screen but in more depth. There are some technical questions, some design ones and some almost philosophical ones about the candidate’s approach to problems.

Our interview scripts are fairly broad in scope and questions are usually based on the work the candidate has done rather than fixed questions and answers. We are more likely to ask how and why you’ve solved problems in your own projects than to discuss abstract examples.

We will ask some questions that are relevant to our main line of business: distributing news on a global scale on public platforms like the web.

You might find it helpful to think about how websites scale from a solution-design perspective but we appreciate that most people who work on websites do not have the scaling issues that the Guardian does. In fact tackling some of those problems is part of the opportunity of working here!

I try to say to candidates that the final interview is also their chance to make sure that they want to work at the Guardian. As interviewers we need to make sure we gather all the information that we need to make a decision about a candidate. For candidates it is important that they understand what it means to work at the Guardian and that they ask all the questions they need to decide whether they will take a job with us. All interviews are two-way processes but this is particularly true at this point. Think about your hopes and concerns and try to write a list of questions so you are not trying to remember them during the interview.

Communicating the results of interviews

We try to be as clear and as explicit as we can be in our communications with candidates. There are no subtle “read between the lines” statements. We aim to respond to candidates quickly, ideally with two working days. We will always get back to candidates and candidates are entitled to feedback on their performance. Occasionally we have had problems with email or missed calls – if you have not heard about the outcome of an interview in a working week you should get back in touch with us. We might be struggling to get in touch with you!

Preparing for the interviews

Some people ask what they need to do to prepare for our interviews. The key thing is to read back over your covering letter and CV. We will generally discuss what you have done as you have presented it to us. Be prepared to expand and clarify the information there. When answering questions try to stick to real examples rather than theoretical situations. If you can talk sensibly and clearly about your coding and work to date then you are prepared for most of our interviews.

Some general interview advice: remember that giving very long answers runs the risk of running out of time, particularly in phone interviews. Be prepared to check whether an answer is sufficient or whether the interviewer would like you to expand on it. Try and vary your examples: if you only ever talk about your latest work then it gives the impression that you have not done anything else.

Technical questions

Our interviews are not technical in an abstract sense. How webservers work is important, standards like HTTP, HTML and CSS are important but we are language-agnostic and we care more about general best-practices in software development, particularly around web development, than we do about the details of algorithms. We are interested in problem-solving techniques, not memory exercises.

If you don’t claim to have knowledge of a particular technology we don’t think it is fair to expect you to know about that technology, even if we use it a lot internally.

For more experienced candidates we may ask you to extrapolate on the things you know. So if you use relational databases then we might ask what common techniques are used to help scale them and what the trade-offs involved are.

Dress code

The Guardian has a very relaxed dress code (some might call it slightly shabby) so you only need to turn up in formal business dress if it makes you feel right for the interview.

Experience

We aim to have a ratio in engineering between senior and non-senior engineers of one to one. While organisations tend to be biased towards experience we also understand the importance of having people grow and develop internally. We review the current ratio quarterly to try and understand whether we have trended one way or the other.

This previous post tries to explain what we regard a senior developer to be.

Being open

We believe that being open and transparent helps people to do their work better. By being open about the context and parameters of our interview process we hope to improve the interview process both for you as a candidate and for us as interviewers. We want to give you the best chance to succeed in your application and we want to try to set a high standard for ourselves. We want to be as objective as possible in assessing potential hires.

Join us

For more information about the department, our developers and the roles we currently have open visit our developers site.

Comments (…)

Sign in or create your Guardian account to join the discussion

Most viewed

Most viewed