How We Hire Good Engineers, Faster

We had a large number of engineering vacancies to fill. Our vacancies were growing faster than we were able to fill them. We were finding hiring hard, time consuming and dispiriting. We’d heard from the people we’d hired that they’d found it difficult to be hired by us. We looked into the process and improved it.

Empty chairs at empty tables

Result: the changes were very successful and we are now in a much happier place.

(Context: this work was done within the Customer Products group at the Financial Times. Our group primarily looks after ft.com and the FT web apps)

Our Problems

Large Vacancy Count

We had engineers moving to other teams (which we encourage) plus one or two people leaving us. We’re happy with a low staff turnover rate, it’s normal and keeps new ideas coming in. No one wants to work with unmotivated, unhappy colleagues! In fact, compared to the industry average, many people stay at the FT longer than at other companies. It’s a genuinely a really nice place to work :)

This isn’t a stock image — it’s genuinely people who work here being happy at work :D

We were emerging from the other side of launching of a newly designed website on a brand new stack. Our appeal as a ‘new “greenfield” project’ with a clear end goal was waning. People were emigrating to other roles faster than they were immigrating to our teams.

In addition to this, we needed to form two completely new cross discipline teams. These circumstances combined and left us with 12+ vacancies out of a possible 45. Roughly a quarter of our positions were vacant and the total of vacancies were increasing faster than they were filling.

Poor Candidate Experience

Our recruitment agents told us that many candidates were put off by the length of our technical screener test. Other companies were offering immediate face-to-face interviews based on a candidates CV alone. The recruiters estimated that only 1 in 20 promising candidates was returning the technical screener test.

This felt wrong. Surely of 20 candidates more than 1 of them was worth interviewing and would like to work with us?

We’d also had direct feedback from candidates that:

  • The length of the technical test was off putting
  • They were not sure of the job they were applying for. They were given out of date and varying information.
  • The process was unclear; the candidate did not know how many stages were involved nor what each stage entailed.
  • If the candidate did understand the process they found it hard to understand where they’d reached within it. Some keen candidates had found it necessary to repeatedly chase their recruiter for updates. One or two received alternative roles suggestions instead of the update they’d requested. Keen candidates were being actively dissuaded from continuing to apply for our roles!

A Bad Process

We gathered feedback from all areas; recruiters, candidates and those of us involved in the reviewing and interviewing. We identified our main process problems to be:

  • A small internal group shouldered the workload. The work of reviewing CVs and screener tests was falling on a small and dedicated group. This was demotivating and unfair for those involved. Ironically we were in danger of overburdening the really dedicated and making them more likely to leave.
  • Uniformity of applicants. Diversity is not the strong suit of recruitment agents. It seemed no matter how many times we raised this problem there was no change in the diversity incoming candidates. We hired some great engineers through our recruiters. However, they were predominately white, university educated, male and from similar socioeconomic backgrounds.
  • Slow hiring rate. On average it took 113 days from initial contact with a potential applicant to hiring them! Our suspicion was this caused many of our other problems. For example, few reached the face to face interview stage — they were probably offered roles elsewhere before we even got close to responding to them. Also, we inferred our roles were not seen as easy to fill by recruitment agents so got second rate treatment

In some ways it was astonishing we managed to hire anyone.

Many of those we hired were very keen to join us already. For example, they already knew someone who worked here so knew that their time investment was worth it. Occasional candidates ‘got lucky’ and the process accidentally went quickly for them. For others the long timelines fitted in with their timescales, or they just showed an absolute and sheer determination to see our process through! But overall the process was almost certain to fail most of the time.

How We Fixed Things

Sharing the Workload — Making it visible

We created a Trello board to which all new candidates were added along with their CV and tech test. It meant we could all see a candidates progress, their waiting time and who was to take the next action. It meant we could widen the pool of engineers asked to review an application as it was clear who was doing what. We could share the the coordination of ensuring a candidate was progressing through the process.

We could generate reports showing us how much time each engineer had spent assisting with on hiring. This was a great improvement, as before the time spent was often unseen and unappreciated as it was invisible. We had the help of a delivery manager (thanks Luis Vigar!) to actually get ourselves organised.

Side note: In the past have looked at a variety of 3rd party software for managing the hiring process and candidate progression pipeline. I have set up two different 3rd party systems. They were both good to start with but then hugely increased their licensing costs after a year or so. Quickly they became unjustifiably expensive so we stopped using them. We twice lost our hiring history and had to reinvent then share the process over again. Emailing a .pdf technical screener test may not be impressive, but it’s pretty unbreakable. Ideally we’d write our own in house system for candidate management. We did have one, it was great but then is a large overhead associated with the maintenance of that too so it also had to go.

Applicant Diversity

This is a much bigger issue than just fixing our recruitment process. However, we are making great inroads into this and it is supported from the board level and considered everyone’s responsibility to improve (e.g. being included in their OKR’s). I’m hoping that at some point our Talent Aquisition team might write a separate blog post with regard to this much broader topic.

Job Description

I shortened and simplified our generic job description. Short is sweet (it’s still far too long). We use the same description for all our full stack roles which reduces our workload. The information in the description is useful for all applicants and we word the description in a way that (hopefully) doesn’t put a more junior applicant off. I tried to make sure it is worded to appeal to a diverse group e.g. by running it through Textio. It turned out it was in pretty good shape already (from a language point of view). After updating it I tried to get everyone using the same one.

A Simple Candidate Entry Point — Our Microsite

We had no clear path for people to apply for our jobs. When one of us spoke at a conference there was no URL to promote our roles to possible applicants. We had no way of sharing what it’s like to work here and how great the culture is.

This further increased our reliance on recruitment agents. We were almost shut off to applications from anyone who didn’t have an ‘in’ route via an agent.

To fix this, we formed an excellent cross discipline team of volunteers. As a side project to our regular work we made our recruitment microsite. We learnt a lot whilst doing it, hopefully someone involved will write a separate blog about this microsite :)

Our microsite allows us to showcase our culture. Also, applicants can get in touch if they’re interested in any of our roles at any time. There’s a huge pile of things we’d love to do with this to extend how useful this site is. But for now Minimum Viable Product is vastly better than no viable product!

Our microsite at https://roles.ft.com

Interview Process

Old process

In our old process a successful candidate would pass through 3 stages:

  • An initial call with our in house recruitment agent (or more than one if there was a chain of agents involved!)
  • An at home technical test. This took on average 1.5 to 2 hrs. Not an industry worst, but still a large time commitment.
  • A face to face interview taking 1.5 hrs.

Previously we held a second face to face interview that took another 1.5 hrs. Again, it still surprises me sometimes that we managed to hire anyone.

New Process

A group of engineers got together and tried to figure out exactly what it was we wanted from the long technical screener test.

We identified that what we were trying to learn was:

  • attitude — how does this person approach technical work? What are they like to work with?
  • aptitude — can this person do (and collaborate on) the technical tasks their CV claims they can?
  • team fit — are they actually interested in the sorts of roles we have / will they enjoy working here?

We now have the following process (the candidate can be rejected or drop out at any stage):

A) Screener call. Either held by the recruitment agent or our in house talent team. It covers basic checks like salary expectations, rights to work and that the role is actually likely to be what the applicant wants.

B) Short Screener Test. The applicant is sent a much shorter (15–30 min) at home screener test. An engineer reviews the short test and the candidates CV at the same time, ideally within 24 hours of us receiving the two. This means we invest no engineering time until we need to and respond very quickly. The other areas we used to test via the long screener task are looked at in later rounds.

C) 3 Part In House Evaluation: We hold an extended in house interview consisting of:

  1. 1hr Technical Task. This is part way between pair programming and a technical discussion. We try to make it easy for the applicant to show us their technical and collaborative strengths. We also try to stress them as little as possible as programming under pressure can be awful.
  2. 15 min break. During this the technical task is reviewed whilst the candidate has a break / is shown round our office. We only move to the next stage if we feel they are right for the role. This means we sometimes reject a candidate half way through our in house process, but they’re aware that this can happen before we start. If we do reject them we give immediate, constructive feedback as why we are rejecting them. We feel this is more honest and useful for all involved, far better than carrying on when both sides already know the outcome. Thus far this straightforward approach has worked well.
  3. Face to Face Interview. A 1 hour ‘traditional’ face to face interview at which we ask a mixture of technical and ‘soft skill’ questions. This is held by two different interviewers to those involved in the technical task. Overall a successful applicant will have spoken to at least 4 engineers.

D) Fast Offer / Rejection. We try and make a decision immediately after the interview (if we didn’t reject the candidate at the half way stage). We discuss whether to offer with all the people involved in the interviews whilst the interview is still fresh in our minds. We then either make an offer or a rejection (with feedback). Again, ideally this happens within 24 hours of the interview.

Interview Panel Makeup

We try to pair a senior + a mid or junior engineer together for each of the 2 face to face parts of our process. The more junior interviewer is an apprentice and can learn how to lead an interview. As importantly, we only want to hire people who work well with all engineers at all levels so feel having a less senior panelist is essential. Ideally the apprentice interviewer never feels ignored, patronised or confused during the interview. It also means we share the immediate interviewing workload and expand our available interview leaders panel in the long term. Lastly, the fact that at least 4 engineers have met the candidate means we are able to get a more balanced view as to their suitability for the role. We never have to rely on one persons opinion as that is neither fair to the interviewer nor the candidate.

Conclusion

The new in house interview style can use more of our engineer’s time than the old process did (4 hours vs. 3 hours). However, the higher success rate of significantly outweighs the extra in house time and reduced the number of interviews we hold. Overall we’re spending far less time on recruitment related work and the time spent is far more fruitful. The new process is quick. We can, and often do, turn around the whole thing within a week.

This chart shows how improved our position is with the new process than vs. where we would have been had we not changed. It is shows the impact our changes made at the time (note: it doesn’t show the ongoing impact into 2019).

We are now down to a very comfortable 2 or 3 engineering vacancies. Considering we’ve mainly relied on the process to run since last year with no major changes, it’s been great how its kept paying dividends.

The real headline statistic we took our average time to hire down from 113 days (no really) to about 18 days.

What Next?

We still have lots of things we’d like to do to improve our process.

  • Our job description is too long and contains redundant information.
  • Our screener could be more effective at showcasing a candidate’s skills. Its question set is too narrow and restrictive.
  • Our process is not set up in a way that makes it easy to consider applications from engineers who want to re-skill in a new language (we have to work around this).
  • Our in house technical task could ask questions that are much more revealing of a candidates strengths and interests. The technical task hasn’t been improved since we first came up with it and could achieve far more without taking longer.
  • Our face to face interview should have a more organised set of questions that we score in a fixed way to make our interview process as fair as possible.

I have handed the leading of this work over to my colleague Simon Legg and he’s carried on helping the talent acquisition team keep our hiring on track — perhaps one day he’ll blog about the improvements he’s made!

Remember: if you’re interested in working with us please visit roles.ft.com!

FT Product & Technology

A blog by the Financial Times Product & Technology department.

Caroline Handley

Written by

Principal Engineer at The Financial Times

FT Product & Technology

A blog by the Financial Times Product & Technology department.