Anonymising job applications for technical roles at FutureLearn

Mal Pinder, a Developer at FutureLearn, discusses why and how we’ve started to anonymise job applications for technical roles at FutureLearn.

Since August, I’ve been helping organise Technology Team hiring here at FutureLearn. This involves both day-to-day tasks (arranging interviews, organising schedules and guiding discussion about whether to hire) and also documenting and improving the way we hire. This is a blog post about an improvement we made to our process; how we approached it, what happened, and what we do now.

The decision to anonymise applications

When we decide to bring an applicant in for interview, we have to do our interview preparation first. This involves thinking about areas of interest, highlighting potential concerns, and working out some guideline questions to help make sure we get good quality information; it’s a very important step to avoid wasting our and the applicant’s time.

We don’t want to risk making assumptions about how a person works, or their technical skill or style, because they might be inaccurate or make us overlook an area that would be beneficial to talk about.

We thought that anonymising applications might help us avoid this risk – removing information from the materials we use to prepare, so that we don’t have the opportunity to be biased about who a person is, talks they’ve done, or what projects they’ve been involved in, especially with how relatively small the London tech scene can seem at times.

I’ve never done anonymisation before, and most of what’s written is geared toward large companies that use CVs as a filtering mechanism, rather than a preparation guide. We weren’t sure how much time anonymisation would take up – none of us have done it before for a technical role – and we were worried it would be too much overhead in an already time-consuming process.

We were also concerned about accidentally arranging interviews between people who knew each other. So we decided to give it a try, see how it went, and then reassess after we’d done it with a few candidates.

The first step to anonymisation

As a first step, we wanted to remove just the identifying information – names, photographs and employers where we thought that would reveal who the candidate was. Since we were already spending the effort to redact CVs, we also decided it would be worth removing other irrelevant information that sometimes appears, such as date of birth or marital status.

Both Joel (our CTO) and I organise interviews and planning, so we started referring to applications by the candidate’s initials. We redacted CVs and cover letters using Preview, the standard OSX PDF viewer, and we were careful to use the gender-neutral pronoun ‘they’ when sharing details or talking about candidates.

The other place we have identifying information is in code exercises. We ask candidates to work on a short technical exercise before their interview, and some candidates use Git to keep a history of what they did. Git stores author name and email alongside each commit; we also had to edit any repositories we were sent so that this was removed.

The results of anonymisation

After trialling anonymisation with six Ruby developer candidates, we could see that it was good for our preparation; it was much easier for the team to pay attention to relevant information, and it was particularly useful guidance for team members who’d not done hiring before.

As the benefits were clear, and the effort needed turned out to be so low, we decided to carry on anonymising applications. In fact, we decided to start redacting even more!

We now remove company names, to help us avoid bias about where a person has worked. Most educational history isn’t relevant, so we also remove childhood education, institution names, and grades. (Although we are interested in any MOOCs a candidate might have done, because it can give us useful insight into how much they already know about online education, so we leave those in). And lastly, we remove information about interests, hobbies, and other spare-time activities.

The benefits of anonymisation

The other benefit is more subtle – it sends a strong signal to our team (and, via this blog, to the wider world) about what is and isn’t important to us as a company, and what we do and don’t care about when we’re looking for more people to join our team. We don’t care about having worked at big-name tech companies – we care about job responsibilities. We don’t care about having given talks at prestigious conferences – we care about being able to communicate with us.

It can be very challenging to make sure everyone involved in hiring is on the same page about these traits, and going so far as to remove something is a good way of making it clear it’s not relevant.

The challenges of anonymisation

It’s not without its problems. This isn’t as thorough as anonymisation could be: the first stage of the process is a phone call from Joel, who has access to the unredacted CV; as soon as anyone comes to the office, the interviewers will know who they are, what they look like etc; and during the interview itself, most candidates will talk about their previous employers.

And we couldn’t find a good way to avoid the risk of interviewing someone you already know; we have ‘backup’ interviewers in case someone has to drop out at short notice, but that’s far from ideal.

We’re keeping an open mind about how we could improve on this in the future, but for now, we’re happy with the positive effect it’s had on how we interview. We’re confident it’s made our process fairer and more robust, and we’re keen to start doing it for other developer positions as they open.

Do you have experiences of anonymising job applications? Share them in the comments below. Do you want to know more about how we do things at FutureLearn? Check out more of our Making FutureLearn posts.