Applying to Doctolib as a Full Stack Developer

Ramin Azhdari
Jun 15 · 8 min read
Image for post
Image for post

pplying for jobs is nerve-wracking, I wanted to share with you my experience applying and getting a job on the engineering team at Doctolib. Hopefully, you will find everything you need to know about our application process and get some helpful tips on how to prepare in advance.

Looking for an awesome developer job? Not long ago I was in a situation similar to the one you are probably in right now. I finished university a while ago, during which I got some experience by building an ultimately unsuccessful startup. After university, I worked as a freelance dev but it didn’t fulfil me. I wanted an ambitious, challenging environment in which I could deepen my skills and advance faster.

Applying to a disruptive, fast-growing company like Doctolib is ideal for that. But I was nervous. It can seem scary to take the first step and apply. I had so many questions; What will the process be like? Will I fit in? What are the expectations? How do I need to prepare myself? Questions like these occupied my brain while I applied to Doctolib. If you have the same questions don’t worry! I’m here to clear things up by sharing every step of the process with you.

First interview

Doctolib has a very informative career page where I found all information needed to learn more about the company and what is expected in terms of qualifications. I prepared all the documents and just applied.

What followed was a kind and informative invitation to a first phone call from Michael, the technical recruiter who would from then on guide me through the complete application process:

“Hi Ramin, thanks for your interest […]. We’re excited to move forward with the interview process. [..] This first discussion will be via Hangouts and help to better understand your experience and motivation. To get the most out of the call, we invite you to thoroughly research all available information online before the interview and have a good understanding of our company and product. Here are a few links to help you out: Doctolib, Doctolib’s Tech Blog and our Techlife newsletter.”

Before the interview, I spent some time on the mentioned Tech Blog as well as the engineering team’s career page to find out about Doctolib’s tech stack and approach to software design. Additionally, I watched the company portrait to get a feeling for the company and its values.

Thanks to Michael’s guidance and my preparation this first interview ended up being very enjoyable. We talked about my past work experiences and the reasons why I decided to apply to Doctolib. After that Michael asked me some questions about my understanding of the company and its product. I was encouraged to ask questions about the things I wanted to know more about. How are the teams organised? How is the tech team integrated into the overall company? Michael was happy to explain all of this to me.

One day later Michael got back to me with good news: “Hi Ramin, I am happy to inform you that we have decided to advance you in our recruitment process. As I informed you in our short call, you will find our code challenge at the following location.”

Code Challenge

I’ve done my fair share of code challenges but this one was different. At Doctolib we believe that your time is valuable and we don’t want to spoil your whole weekend by sending you a challenge that takes ages to finish. Michael didn’t exaggerate when he wrote “… it usually just takes between 45–75 min”.

But even more interesting than the allotted time is how companies design their code challenges. Often applicants just receive a list of requirements they need to fulfil but, as you can guess at this point, at Doctolib we think differently about code challenges.

You receive a task in which you either need to build a little feature or fix a bug. You can choose between doing the challenge in JS or Ruby. The task always relates to a real part of our codebase. Even though it is a small task, we designed it to give you an opportunity to do a lot of the things you will do at Doctolib — analyze, debug, write and test code. Here at Doctolib we believe in thorough testing (15k+ tests) so that we can confidently push our code into production. Therefore if you write thorough tests for your solution you will be able to be confident about it as well. As Michael told me: “Just so you know, during the test review, we analyze your code by checking if it passes our unit tests […]”

I happily finished the challenge and tested the hell out of my solution. A few days later Michael informed me: “I received the feedback from our engineering team and they liked your solution to the coding challenge.” We scheduled a quick call, during which Michael elaborated on the feedback he received from the engineers and how the process would continue from here on.

Technical Interview

On the next day I received the official invitation to the technical interview: “Hello Ramin, […] we are happy to invite you to the Code review (30 mins) and Kata Test (60 mins). The tests will be conducted with two of our Tech Engineers.”

This was the most stressful part of the interviewing process for me. Thanks to my interviewers, Victor and Matthieu, I had a lovely experience. At Doctolib, we are interested in creating a great atmosphere during the interview — it makes the whole process more enjoyable for everyone involved.

In the first part of the interview, we discussed my Code Challenge solution. This is an opportunity to show your thinking behind your solution and what you would want to change/add. While preparing for the interview I discovered a little bug in my code, so I walked them through my process of debugging and fixing my solution. We like critical thinking and we want Devs to challenge their solutions. Don’t be afraid to challenge your own code in the interview.

After that, we switched to the Kata Test. As you already know, we love testing our code, so the engineers at Doctolib decided early on to make this part of their application process. In the Kata Test, you will get a task similar to the ones you find when you literally google “Kata Test”.

Matthieu and Victor shared such a task with me and I needed to solve it in a Test Driven Development way. Michael told me several times before this interview, “This test is not there to assess your coding abilities but your problem-solving skills,” and this was exactly the case. I set up my coding environment and explained every step of my process — how I would start attacking the problem, how to break down the problem into smaller pieces and what to test during the steps. All of this happened in a continuous flow. I explained my idea on how to solve one tiny part of the problem while writing the needed test and then subsequently added the solution to turn the test green.

My interviewers didn’t expect me to be fast but instead, they wanted to understand how I think and break down problems. After a while, I was stuck and didn’t know how to proceed. I got terribly stressed out but contrary to my expectations it was not bad at all for them. They asked me to articulate my problem and then nudged me in the right direction with some comments and questions. After 60 minutes we wrapped up. I wasn’t completely done but that wasn’t important to them since they got a picture of how I tackle problems. Matthieu said explicitly at the beginning of the Kata test: “Don’t worry we don’t expect you to finish this task in 60 minutes.” And we really mean it this way.

Even with Matthieu’s words in mind, I wasn’t confident about my performance. I wanted to impress them, and an unsolved challenge didn’t fit that idea. I was convinced that I would be disqualified after this interview.

But luckily my gut feeling turned out to be wrong. While I was sitting at home worrying about their decision, Matthieu and Victor were already discussing the teams I would fit in best.

Final Interview

Once they finished their decision process Michael got back to me: “Hello Ramin, we are very happy to invite you to the next step. The architecture and methodology interview […]. To be successful in this interview we have some recommendations for you: […] think about a software architecture that you worked on before and how to explain it, think about a little presentation of yourself (5 to 10 minutes), […] and have a look at our tech values and think about your connection to them.”

Receiving this email was an incredible moment for me. All the hard work had paid off. After all of this, I wanted to make sure to present myself in the best way possible in this last interview. I took some time to think of how I would present myself and my work experiences. I asked friends and family what they thought about my presentation. This was important because even though the content of my presentation didn’t change a lot after several times discussing it I chose better words to describe the things that were important to me and stopped making long breaks in between sentences.

In the Methodo interview, as we call it internally, you will most likely meet your manager for the first time. This last interview involves a mix of technical and personal questions. The interviewers care mostly about two things at this point: to find out who you are and to find out how you fit into Doctolib.

This time I was interviewed by Matthieu and James. As you know I already knew Matthieu from the previous interview. He introduced me to James who would become my manager.

Right from the beginning, they made a great effort to make me feel comfortable. They spent a lot of time presenting Doctolib and their roles there to me. I learned how teams are organized and what my future team is working on. What makes Doctolib unique? What do we care about? You will hear about all of this in this interview.

After the introduction, I got the chance to introduce myself. This interview differed from the first one. It was less formal and I didn’t need to “sell myself” anymore. They were genuinely interested in me. What side projects and hobbies do I pursue? What interests me? After these initial questions we moved on to more technical ones, like “How would you review a Pull Request?” or “What security best practices do you know?” The questions were interesting and the interviewers shared their own ideas as well. It was more of an open debate than a strict interview and with the end of it, the whole application process came to an end.

My Decision

All in all the application process showed me a lot about how much Doctolib cares about its employees. I wanted to be part of this welcoming company and work right here on changing healthcare. I hope my experience makes it easier for you to take the first step and apply.

I’m looking forward to seeing you at the office!

Techlife Newsletter sign up
Techlife Newsletter sign up
Check out our weekly Tech Life newsletter

Thanks to James Macpherson, Matthieu Kern, Michael Münnich and Victor Schubert for the lovely application process, thanks to Shannon Pearson for taking the time to correct my linguistic shortcomings and thanks to Alexandre Ignjatovic, Yusuf Daniju and many more for taking the time to read and comment on drafts of this article.


Change Healthcare for Good

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store