Doctolib is now officially France’s highest-valued startup after recently raising €500 million to reach a €5.8 billion valuation. A tech health platform, Doctolib provides various services, such as online appointment booking and telehealth services. The platform is a huge success. Over 300,000 healthcare workers and 60 million patients use Doctolib and the company continues to rapidly expand. While it currently employs 2300 people, there are plans to hire another 3500 in the next 5 years. Roughly a quarter of these positions will be in the tech field.
Being able to scale at a fast pace is challenging. When you need to hire thousands of people, you need to optimize the hiring process to the maximum. In order to recruit developers more efficiently and ensure a candidate experience that would minimize dropoff, Doctolib turned to CodinGame and CoderPad.
We spoke to Doctolib in October to understand the exciting challenges they faced in recruiting (see our article, Tech Recruiting for Massive Growth – Doctolib Balances Efficiency With the Human Touch). Today we check back in to discover how their tech recruiting process has been streamlined since using our products.
Doctolib + CodinGame + CoderPad
We spoke with Matthieu Vignolle, who has been working as a software engineer at Doctolib for several years and also participating in the recruitment process.
At Doctolib, all software engineers are encouraged to participate in interviewing once they reach level 2 out of 5. Once people reach level 3, they can participate in more difficult interviews for more advanced-level positions.
| BEFORE | NOW |
| Candidates had to wait days after submitting assignments to find out if they’d passed | Candidates are contacted quickly |
| Candidates took 4-6 hours to complete the assignment | Candidates spend 30-60 minutes completing the test |
| 30 – 45 minutes spent grading | No time spent grading |
| Candidates used languages they weren’t as good in | CodinGame and CoderPad are adapted for different languages |
| Time was wasted on technical difficulties | Smooth experience with CoderPad with no technical hiccups |
| Subjective judgment if take-home assignments couldn’t be run correctly | Test is always objective with one fair score |
| 52% of candidates would withdraw from the process or disappear | 77% of candidates continue through the process |
The previous process prior to adopting CodinGame and CoderPad
Prior to updating the process, there were multiple steps in the tech screening process:
- The talent acquisition selected candidates based on CVs.
- Candidates did a take-home assignment based on a real problem a developer could work on at Doctolib. This task typically took 4-6 hours to complete.
- Engineers were recruited to grade the assignment. This usually took 30 minutes but sometimes took hours.
- Candidates participated in 3 tech interviews taking a total of 2 hours.
- Kata for 1 hour
- Role play about product specification for 30 minutes
- Code restitution where they challenged the code from the take-home test for 30 minutes
While the process was mostly appreciated by candidates, the process was a little long in several areas and contained a few sticking points.
The lengthy take-home test turned off some senior developers
The take-home test was praised by many who tried it as it gave an accurate view of the type of work that one would do at Doctolib. It was relevant to the job. This is much appreciated as sometimes companies choose a more general assessment and can end up assessing skills that are not directly related to the daily tasks.
The downside of the test was that it took hours to complete. For senior developers with a lot of job offers and limited time, this meant that only about half of the applicants completed the assignment.
While Doctolib wanted to provide a relevant test, it was important to reassess the time it took to complete so as not to miss out on great potential employees.
Not always simple to grade
In an ideal situation, the take-home assignment would only take 30 minutes to grade.
The engineer tasked with grading it could run a test on the code and everything would execute as expected. Unfortunately, this was not always the case. Sometimes when the test wouldn’t run, engineers would have to investigate what the issue was and make some modifications to be able to run the test.
Did the candidate import a library? Would they have to remove that so it would be compatible with their testing suite?
An engineer who has volunteered to grade the test, might have allocated 30 minutes in their busy schedule but end up needing several hours. Due to the varying amount of time that the test took to grade, the pool of engineers willing to grade the test dwindled over time.
Talent acquisition would also need to wait a day or two to get test results back from busy engineers to be able to respond to candidates.
Difficult to always be objective
When it wasn’t simple to figure out why the test wouldn’t run and an engineer didn’t have time to explore further, a decision would have to be made whether to move forward or not.
This was not a clear-cut decision to make so it required subjective judgment. Each situation would be different so it was not possible to have a clear guideline.
This means one case might be treated differently depending on who was doing the grading, an unfortunate outcome when trying to make the process as fair and unbiased as possible.
Running 3 tech interviews was time-consuming
3 tech interviews in 2-hour blocks are feasible when there aren’t a lot of interviews. In a company that is scaling for massive growth, it’s just a little too long. As engineers left the recruiting pool due to time constraints and not enough new ones joined to meet increasing demand, interviews became more frequent for those who remained. After a while, Matthieu was doing interviews frequently and often paired with the same colleagues as co-interviewers.
“Doing hiring is cool but I don’t want to do hiring all the time.” – Matthieu, Software engineer at Doctolib
Time would sometimes be wasted with setup. Candidates would often forget to set up their computers in advance and might join the interview on a computer without their regular IDE. Lacking the tools they needed, they sometimes ended up doing a test in a language that wasn’t their strongest. This meant that recruiters weren’t always seeing a candidate’s best possible work.
In other cases, people weren’t familiar with Google Meet and would struggle to share their screen, sometimes needing to reconnect to give the necessary permissions. It ate up minutes in the meeting and was potentially stressful for candidates.
A custom 30-60 minute CodinGame test replaced the 4-6 hour take-home assignment
The engineers used CodinGame to make a new test. While CodinGame provides both a raw score of points and a comparative score based on results from the thousands of people who have taken our tests, they wanted to make sure that the pass result was relevant to Doctolib.
They got Doctolib engineers to take the test so they could establish a fair minimum score.
The new test takes less than a quarter the time of the previous assignment. It’s much easier to squeeze into a busy schedule.
Several hundred engineering hours saved per year with grading eliminated
With a passing score established, the engineers didn’t have to do anything more with the tests.
Instead of spending 30 minutes to a few hours grading, talent acquisition sends the tests and if the candidate reaches the minimum score, they pass to the interview stage. If the candidate’s score is just a little below, talent acquisition takes a second look at their CV to consider whether they should make an exception and move them to the interview phase.
This has freed up time for the engineers who no longer have to grade, and talent acquisition who no longer have to wait for a result. They can access the score and report (see sample reports) and easily judge whether to pass the candidate to the next stage.
This also saves time for candidates who find out more quickly whether they’re going further.
An easy interview tool
Interviews no longer start late as candidates try to set up their IDE or struggle to share their screen on Google Meet. Now Doctolib uses CoderPad, technical difficulties are a thing of the past.
“It’s perfect for doing interviews. It’s just easier.” Matthieu Vignolle, Engineer at Doctolib
They only need to send a link from CoderPad and candidates click to join. The IDE is already integrated (see an example of the Sandbox here) so they only need a browser.
There’s no need to sign in or create an account, and no need to have anything specific installed on the computer. Without the technical difficulties, the experience is smoother for everyone and stress-free.
Doctolib decided to streamline the technical interview process by doing one interview instead of three.
The test focuses on feature building, similar to the previous take-home test. CoderPad makes it easy to do the test in various languages. Candidates no longer end up doing the test in a language they don’t excel in.
Takeaways
Doctolib has optimized the tech recruitment screening process to be able to hire for massive growth. The key steps were:
- Replacing a take-home assignment with a short, automatically-graded CodinGame test which:
- Decreased dropout by reducing time spent by candidates on initial screening
- Eliminated need for engineers to spend time grading
- Reducing number of technical interviews from 3 to 1, cutting one hour per candidate
- Adopted CoderPad for online interviews to create a smooth experience for candidates where they can perform their best
