Introduction

In this blog post, I’m going to describe our hiring process for data science roles, starting from an advertised role.  I’m not going to go into how to decide what the job specification should be, how to write it or how to advertise the position, because these are large topics in their own right.

We don’t work by a principle of surprise so I don’t see why the same should be true of our recruitment process.  In any case, if you do apply we’ll tell you what the process is, so it’s not exactly a secret.

We aim to find qualified candidates for the role as soon as possible while minimising both the amount of time that candidates must commit to the process before receiving a decision, and our own time evaluating candidates.  As a result, the process is split into several filtering steps. The later steps require more time and effort than the earlier ones.

Hopefully this post will be of some use if you’re thinking about hiring in data science!

Some context

At the time of writing, FreeAgent employs around 250 people.  We have a recruitment team of two full-time staff, one of whom helps us with phone screens and process management for our data science and analytics roles.  (Thanks Katie!)

We have seven full-time data science and analytics staff including myself, one senior data scientist and one mid-level data scientist.  We’re currently recruiting for a second senior data scientist.

Here’s the disclaimer – if you’re smaller or larger than us or different in another way then this process may not work for you.  We’ve done different things in the past and will probably do different things in the future.  This works for us for now.

Our evaluation process

Application screen

We ask candidates to apply with a CV and covering letter.  This is pretty standard, so we expect most candidates will already have the required information to hand in this format.

The application form asks some standard questions about salary expectations and preferences for office or remote work, as well as one specific question related to the role. We’re currently recruiting for a senior data scientist to work with the team building models in a customer-facing environment, so we ask: “Please describe your experience creating and maintaining ML models in a customer-facing environment.”

This gives us enough information to know if the candidate is motivated by the role and meets the minimum eligibility criteria.  This step is fairly fast.  If you ever read an article that says hiring managers might spend ten seconds looking at your CV, they’re probably right.  So if you’re an applicant it’s good to make it snappy!

The rejection rate at this stage is typically around 50 per cent.

Phone screen

We invite qualified candidates to a half hour phone call with a member of our recruitment team.  (Thanks Katie!)

The questions are quite general and focus on understanding why the candidate is interested in the role, what they value in the workplace and clarifying their understanding of some of the technical requirements for the role.  It’s also a chance for the candidate to ask questions about how the process will work and for us to take note of notice periods or any other constraints.

Fundamentally we’re looking for evidence that the candidate is motivated, has good people skills and can explain their technical work clearly to someone in a non-technical role.

The rejection rate at this stage is typically less than 10 per cent.

Problem and review call

Candidates have to be able to prove that they have a practical understanding of data science to progress.

We send out a zip file containing a simulated dataset and a small working system to train a machine learning model and make predictions for new data in response to HTTP requests.  We then ask the candidates to book a 45-minute call about a week later to discuss the system with two members of the data science team. We make it clear that we don’t expect more than a couple of hours of investigation of the system before the call.

We ask the candidate to describe how the system works during the call, and we may delve into some pair programming to improve it or discuss any improvements the candidate has tried before the call.

There are a couple of aspects of this that are worth commenting on.

In the past, we had asked candidates to implement a small system from scratch.  This typically resulted in boilerplate solutions based on well-known patterns, which to be fair is perfectly reasonable given the time constraints, but not great as a test.  Providing a working system with a few specific design flaws and a well understood simulated dataset made for a better evaluation.

Ensuring that candidates book a call with the team means that even candidates who didn’t have the chance to write any code in advance still get to discuss the system, explain their thinking and do some pair programming during the call.

We’re looking for evidence that the candidate understands the principles behind what they’ve written on their CV and can work together with the team on a technical problem at a level commensurate with the requirements for the role.

The rejection rate at this stage is typically around 50 per cent.

Final interview

By this stage, we should be fairly confident in the applicant’s abilities, so we rarely take more than a handful of candidates to the final interview.  Well done if you got this far!

Our final interview comprises two parts: “people skills” and “technical skills”.  Each part takes around an hour, with a panel of two interviewers each and a standard set of questions agreed in advance.

Because we can have up to four interviewers, it’s a great chance to get input from a more diverse set of people from the wider team.  The technical skills interview panel should include a data scientist at least as experienced as the role we’re hiring for, but the people skills interview panel can include anyone from the wider engineering team who has experience participating in this type of interview.

We’re looking for a degree of assurance that the candidate has the required people skills to work well in the team as well as sufficient background technical knowledge and reasoning for the role.  I’m not going to give away the exact questions here, but we do expect candidates to be able to clearly explain their choices in their approach to the problem in the previous stage, or in past project work mentioned in their application, in response to questions from the panel.

Conclusion

Following the two final interviews, the panel will reconvene with the hiring manager to agree a final decision on the candidate.  All the panel members have the chance to express their feedback on the candidate during this meeting. There’s usually some discussion because different panel members might have picked up on different strengths or weaknesses.

So now we’ve made a decision, let’s recap some of the key points:

• The process is designed to minimise both the amount of time that candidates must commit to the process before receiving a decision, and our own time evaluating candidates.
• We assess practical ability as early as possible by giving qualified candidates the chance to talk through a well-defined problem with members of the data science team.  
• Providing candidates with some data and code that we wrote and understand as a starting point for the conversation helps to keep the process fair and minimises the time candidates have to commit.
• The final interview is a confirmatory step for good candidates rather than a test to try to trip anyone up.