One Year at Doctolib: My Journey, Challenges, and Growth
A Honest Fresh Eyes Report and Retrospective
About a year ago, I made the decision to change companies. I reached out to several organizations I had been following for years, including Doctolib, with the goal of joining the team working on the mobile application for patients. Today, one year later, I’m reflecting on my experience at Doctolib. From the concerns I had before signing the contract, the fear and uncertainty that came with changing jobs, imposter syndrome, and my accomplishments. I’ll tell you everything 🙂
Doctolib from the Outside
Initial perception of Doctolib
Before joining Doctolib, I had a somewhat mixed perception of the company. I viewed it as a startup that was no longer truly in that category, having grown into an organization with more traditional structures, one that could be weighed down by established but slow processes.
Doubts about my potential impact
Another major concern for me was the challenge of making a real impact in such a large organization. Before Doctolib, I had been able to consistently contribute, not just within my team but also across teams, with an impact that was visible at the organizational level. I had earned the trust of my peers, becoming a go-to person for several topics, launching and leading initiatives that affected multiple teams.
Building and solidifying that kind of influence takes time; it doesn’t happen in just a few days or weeks. I was afraid of having to rebuild everything from scratch. In general, I enjoy working on cross-functional topics in addition to those related to my team. But in an organization of this scale, I wasn’t sure if I would be able to maintain that approach.
My doubts only grew after speaking with Engineering Managers, Directors, and other senior professionals who, with much more experience than me, confirmed the complexity of the challenge.
Desire to stay full-stack and more
Similarly, I feared being limited in my ability to contribute to the broader project. I was applying for the mobile team, but deep down, I still wanted the opportunity to explore and contribute to different parts of the project, regardless of the stack. In other words, I wanted to retain my full-stack web and mobile engineering mindset, rather than narrowing my focus to mobile frontend development.
The advantage of this approach was clear: it would help me better understand the entire project and technical stack. It would allow me to support my team in ways beyond the mobile scope, including backend, CI, and developer experience. Most importantly, it would offer me the chance to learn and grow: a key motivator for me.
Limited information about the engineering culture
That said, while the technical aspects seemed to align with my goals, there was still much I didn’t know.
With the limited information I had from online resources and the job description, I thought I had a general sense of the tech stack I was getting into. But there was one major missing piece: I had little insight into the engineering culture. Fortunately, I connected with someone from Doctolib who answered my questions and gave me a clearer picture of the company. But even with more insight, one big question remained: Was this the right place for me?
Why I chose Doctolib
So why did I choose Doctolib? For the first time in my career, I didn’t join a company for its tech stack. Working on my side projects, I realized that the most rewarding projects were those built around products I would personally use, ones that held real meaning for me, and that allowed me to have a direct, positive impact on a large group of people. Doctolib was the perfect fit. It was the only opportunity that truly met those criteria.
Doctolib from the Inside
Good but long onboarding
Let’s start with a fact: Doctolib gave me the best onboarding experience I’ve ever had. The Doctolib Academy was designed to immerse us in the company’s culture from day one. Like every new cohort, we had access to:
A welcome talk from Stan (CEO), Matthieu (CPO), and Jean-Urbain (Managing Director).
Sessions to explore the various roles at Doctolib.
Product-focused sessions explaining how different Doctolib products function and are interconnected.
A session where we observed a user interview to better understand their pain points.
Beyond the general academy, we in tech had additional, technical onboarding sessions designed to make sure we could start contributing, regardless of our background or seniority. These covered the entire tech stack, including databases, security, and observability.
In my case, the onboarding lasted about three weeks to a month, but it felt like three months due to the intensity of the sessions. Honestly, in terms of content and organization, it was by far the best onboarding process I’ve ever experienced.
That said, the only downside? It could feel a bit long for some, especially for those like me who were eager to jump in and contribute as soon as possible. Instead, we had to attend synchronous sessions that weren’t always directly necessary to begin working as software engineers.
Starsky & Hutch
For those who want to dive deeper into certain topics or upskill in technologies used at Doctolib, the Starsky & Hutch program offers great opportunities. Through this program, I was fortunate enough to work with an amazing mentor (Alice, if you're reading this, thank you for everything! 🙏) one day per week for an entire quarter to learn Ruby and Rails. By the end of it, I felt confident enough to take on a backend Rails task right away, something that normally would have required our team to reach out to an engineer from outside our squad.
More than just a medical appointment app
Before joining Doctolib, I thought it was simply an app for booking medical appointments. While the mobile appointment booking app is one of the 6+ Doctolib products, it’s far from the only one. Doctolib facilitates the entire healthcare journey, from appointment booking (for patients) to invoicing (for doctors) and beyond.
So, how are these products structured in terms of source code?
The monolith
Most of Doctolib’s products live in a monolith, a single React + Rails repo. This modular monorepo contains around 250 frontend modules and 200 Rails engines. The code is shared but each team manages its own scope, owning a set of frontend modules and Rails engines.
While managing a single repo is simpler than handling multiple repos, the monolith comes with its own set of challenges:
Developer experience can degrade.
CI times can increase.
The local dev environment can become unstable due to constant changes, database migrations, dependency updates, etc.
This has led the core frontend and architecture teams to encourage creating separate repositories outside of the monolith, as the current setup no longer scales.
But how does Doctolib maintain quality despite the numerous contributions to the monolith?
Testing strategy
Until recently, Doctolib relied heavily on E2E tests to run most of the flows, not just critical ones. Legend says that there are around 15000 end-to-end automated browser tests! 😱
The company follows an inverted test pyramid approach, which you can read about here: https://mike-bland.com/2023/09/13/the-inverted-test-pyramid.html. Additionally, many checks are performed by the CI, but it's still common for the master branch to turn red due to flaky tests, linting issues, or backend test failures.
Devtools
One of the things I truly appreciate about Doctolib is its ability to create solutions that are specifically tailored to its needs. At Doctolib’s scale, off-the-shelf solutions don’t always cut it. That’s why the company builds its own tools. For example, Doctolib has created internal tools like:
A CLI tool that helps manage many things, such as setting up or refreshing your development environment.
A Chrome extension that integrates with GitHub and allows you to trigger commands, such as manually triggering linting.
These tools have made the developer experience much smoother.
Mature company with a startup-like mindset
One of the biggest surprises for me was the company’s mindset. At first glance, the stack and organization appeared to be well-established, but I quickly noticed areas for improvement like CI times being much longer than necessary. After digging deeper, I realized one of the tools wasn’t being fully utilized. Within a week, I communicated this through my manager to the relevant teams, and together we managed to reduce CI times by about 25%.
This experience highlighted several things:
The company is open and receptive to feedback.
Anyone can propose improvements, even a newcomer.
The company encourages innersourcing.
From web-first to native-first (in theory)
When I joined Doctolib, the company had announced that it would be shifting to a mobile-first approach, investing heavily in mobile. In practice, this has meant introducing fully native features for the mobile patient app. However, there’s still much more to do. The company’s mindset needs to evolve further, as mobile is still often treated as secondary for most technical topics. The mobile team I’m a part of frequently has to play catch-up with major changes made to the monolith.
The same is true for the design system. Currently, we have separate web and mobile design systems, managed by different teams, which makes it difficult to ensure consistency across both. However, I’m confident that things will improve gradually.
Learning is one of Doctolib’s pillars!
Learning is one of Doctolib’s core values (Serve, Care, Act, Learn). Alongside the wealth of training resources available to teams, Doctolib promotes learning and knowledge-sharing through initiatives like internal tech talks, monthly incident debriefs, and the Docto Tech Life newsletter.
Tech Holding
At Doctolib, technical topics are managed by a role called "Tech holder", a rotating Tech Lead position for each project. This role can be filled by any team member, regardless of seniority. I believe this is a great approach because it gives everyone the opportunity to lead a project and learn from the experience.
Scaling
At Doctolib, everything you do should scale. For example, even a small change or feature rolled out progressively at 0.05%, can impact millions of users.
Managing a monorepo at Doctolib’s scale is no small feat, and simple operations like linting or typechecking can slow down CI if done incorrectly. Implementing changes across the entire repo requires careful planning.
Doctolib also has large databases that require special guidelines to prevent issues like slow migrations or n+1 queries, which could affect performance.
Personal Reflections
I came to Doctolib with a great deal of motivation, backed by confidence, perhaps even an excess of confidence. I knew it would be a challenge, but nothing could have fully prepared me for what lay ahead.
From my first weeks, I managed to identify and implement solutions to cross-functional challenges, which was incredibly rewarding. Everything was going well in terms of individual contributions within my team.
That is until I faced my first real setbacks:
My lack of knowledge regarding certain technical subtleties related to the codebase, as well as some legacy parts, combined with my inexperience with Doctolib's context and operations, led to my failure in supporting a team working on a feature related to the mobile patient app.
This lack of expertise also resulted in a significant crisis/incident, largely due to my unfamiliarity with a critical part of the legacy codebase.
Despite the positive impact I was making, these isolated events happening one after another and setting a negative trend, gradually made me feel like I was struggling as a Senior Engineer. That feeling quickly turned into imposter syndrome. I wouldn't wish that feeling to anyone. I began to question whether I was in the right place and if my contributions were causing more problems than solutions. Fortunately, I believe (and hope) that phase is behind me now. I’ll share more details about it when I feel comfortable enough to do so.
Conclusion
This past year has been both my best and worst year so far. I’ve made mistakes, learned from them, made some improvements I'm proud of and pushed myself in ways I hadn’t before. More than just growing technically, I’ve developed my leadership, communication, and resilience, both in my career and as a father.
Looking ahead, I want to deepen my understanding of Doctolib’s legacy systems, improve the overall codebase quality and delivery process, and continue making a cross-functional impact.
This past year pushed me harder than ever, and I came out stronger. Now, I’m ready to take things even further and make this year my best yet. I'll work hard to make that happen.