<How we scaled our interview process to hire more developers>

Disclaimer : ??

I found this draft article when digging in my drive, I had started writing it back in 2019 and I never actually posted it. ??

Even if things have evolved in Tech Recruiting in the past few years, a lot of stuff still makes sense for a fast-growing start-up looking to scale their tech hiring machine.

It's also a nice reminiscence for me, a look-back into the Doctolib period, where we scaled Tech & Product teams from 15 to 500 people. ??

<How we scaled our interview process to hire more developers>?

I joined Doctolib in November 2017, at the time I was the only Tech Recruiter and the challenge was simple: <Double the size of the engineering team>.?

I’m sure that you will agree that “simple” isn't really the best word when describing hiring in tech right? You perhaps have more appropriate phrasings, like extremely painful, bloody hard and even sometimes nightmarish.?

Well after almost 18 months we already doubled the size of the team almost twice.

From 15-30, then 30 to 50 developers.? Things are still VERY challenging but there has been some massive changes in both Recruitment & Engineering teams that has allowed us to hire +30 developers and +8 recruiters.

This article describes some of the most important things we changed in the past year in the way we hire developers at Doctolib and the journey that led the tech & talent teams to own more of the process.??

At Doctolib, teams are growing significantly both in tech and talent. What worked when I was alone booking an interview for Nicolas ( VP Engineering) and a couple of developers had to scale to our new reality, a team of 8 recruiters dealing with +50 developers and 10 engineering managers between Paris ???? & Berlin ????.?

We deal with approximately 10 code reviews per week and up to 8 onsites.

This implies a lot of synergy between different players to meet the standard we aim for the candidate experience.?

The interview process?

The 5 step process has remained the same from day one, here is what it looks like:

1-Phone screen with tech recruiter?

2-Home test?

3-On-site interviews with developers and engineering managers?

4-Half day immersion in a feature team?

5-Offer?

Our test challenge is a home-made test very close to what our engineers do on daily basis. We give the test before physical interviews for different reasons :

• To be able to deal with the high volume of candidates we screen by phone. We do have “fast tracks” for very high potential or strong referred candidates.
• Give candidates the possibility in giving their best shot in a “360 tailored test” that checks clean code, tests, performance & algo at the same time.?
• But mostly because we have very high technical standards, making sure that the gap is not too important before getting to onsite interviews is essential.

The immersion is a special bit that we implemented to give the full picture to the candidate and be 100% transparent in the way we work, our team, atmosphere…?

It’s also a great moment to meet the product peeps or grab a coffee with Jessy, Nico or Philippe.?

We tried a lot of different options in the rhythm & order of on-site interviews, and eventually finished with this breakdown :

• Product roleplay 30mn?
• Code restitution 30mn?
• Coding kata interview? 60mn??
• Methodology interview 75mn?
• Architecture interview 60mn (only for senior developers)?

We challenge ourselves continually to adapt this demanding process to our growth but also candidates availabilities.?

Hiring More Managers = More Hiring Managers?

Another very important stage was the transition phase with our VP Engineering Nicolas, being the only direct report for +10 developers, to hiring a layer of middle management with Engineering Managers. This implied that all the magic that relied on one person needed to be diffused to all the other Engineering Managers. This was essential in order to scale and give even more ownership to the team.

We did a lot of shadowing with each EM at first where Nico kept the lead, to the point he only observed and eventually stopped doing them. That was a great achievement that took a couple of months, but the outcome was worth it, no more bottle necks, we were able to hire an engineer without him meeting our VP.?

More recruiters = More interviews?

As we scale, we hire more recruiters and we are able to build stronger pipelines. This results in more and more tests to review and more and more on-site interviews to schedule.?

In the first months I used to run the candidate’s code on my own machine to check how many unit tests he passed successfully, then I would assign the code review in Jira. I just chose the developer that was the closest ( physically and emotionally). My?goal was to get back to the candidate in a day or two max. If the test was good, the same people would do the on-site interviews as well.?

But this became more and more difficult because I often asked the same people and sometimes a developer would end up doing 3 to 4 code reviews per week and 1 or 2 on-site on top of that.?

To make this fairer and less time consuming for everyone, we quickly came up with a round-robin that respects a better order in choosing within the pool of? interviewers. Developers that have not been solicited come on top of the list and we can also filter between lead interviewers and shadowers to make sure than all the team is continuously leveling up on our interview process.??

Similarly to the interview shadowing for engineering managers we had to make sure all the new joiners were rapidly able to correct a home test or run a kata interview. This also gave full ownership to junior developers that had joined the team recently but that could already play an important role in the choice of their future colleagues.

Decision-making as a process in the ATS

The feedback forms we built in Lever (our ATS) helped us a lot in sharing guidelines to how we want to assess and how to run the interviews.

We have 8 different feedback forms that all check different stages of the process.??

We also built a debrief section in each of them that automatically generates a debrief sheet that we use at the end of the interviews for the decision-making.?

Getting the full picture of the candidate’s scorecard only at the very end of the process helps us avoid bias in the individual feedback, but on the other hand also gives the opportunity to change a soft no hire into a hire, by listening to other POV.

The decision process of hiring a developer is linked to several criterias, the most important (inspired by the bar raiser rule at Amazon) making sure we hire only someone if he is better than the average developer, so that we constantly raise? the level of the teams. More genuinely our checklist is very close to our tech values.

• User first: both patients and professionals, we always put our users first.
• Ownership: The product must be ours so we can make the right decisions.
• Keep the stack simple: be pragmatic, no tech just for the sake of tech.
• Learn & Grow: everything goes fast, but we help you to grow and learn with us.
• Security and Reliability: We take this very seriously and embrace privacy by design

Making offers

Once we decide to make an offer to a developer, the ultimate stage is inviting him for a half day immersion with the feature team he will be working with. Seeing our real codebase, working on a small feature or bug. Meeting the team, including product owner or data analysts. This stage is essential for the candidate to picture himself with us and be confident in accepting the offer we will put in front of him.?

All the work done to make this process smooth has obviously helped in decision making and assessment.?

But hiring isn’t only about how we assess, candidate experience must remain the main driver in the way we build the interview process.?

Getting sure that we hire the right people is great, but that doesn’t give all the picture to a candidate. We also need to give love :) inspiration & vision to close the deal ??.

We still have a lot that we want to improve in the way we collaborate with our engineering team and in our candidate experience.?

We are currently working on some cool stuff like for 2019 :?

• Messaging workshops to get better in the way we reach out to developers
• Closing and selling training for hiring managers?and new recruiters
• Referral?boost sessions, sitting 1:1 with developers to look into their network
• Retro-engineering our data and conversion rates, to get better in predicting our hiring capacity

Improving healthcare for good is the ultimate mission for people that want to have a strong impact in their code, but we still need to deliver this vision even stronger, share our ambition in how we are going to grow with new products & new countries and especially that we are only at the very beginning of our journey.

Because yes, as Stan says "It's only the beginning...my friends" ??

Rassam Yaghmaei (Feb 2019)