Je vous propose de partager mon bilan après un mois chez Doctolib, entreprise que j’ai rejoins en mars 2021. Si on m’avait dit il y a un an que j’allais vivre cette aventure, j’aurai eu du mal à y croire. Je passe par mon blog personnel mais cet article pourrait tout à fait aussi être sur le blog Medium de Doctolib. Cependant, vous connaissez la maison et le blog le Touilleur Express est un peu un vieux monument que l’on respecte : on était là avant medium. Donc : 😘 et ça sera sur mon blog perso.
Les entretiens d’embauche
La phase d’entretien est assez poussée. J’ai passé 5 entretiens avant d’atteindre la phase finale. Cela prend plusieurs semaines, et demande un peu de préparation.
- un entretien général de présentation sur son parcours, sur une présentation du poste et de Doctolib de 30 minutes. Entretien en Anglais, afin d’évaluer déjà son niveau d’expression orale. L’entreprise est implantée en France, en Allemagne et en Italie ;
- un entretien System Design de conception et d’architecture d’1h30 assez poussé. Sans dévoiler son contenu, c’est un exercice qui peut se préparer en lisant des articles de blog sur l’architecture, ou en se passant des vidéos de Devoxx France. Vous allez devoir concevoir l’architecture d’une solution complète, de A à Z. J’ai beaucoup aimé cet entretien qui fait appel à votre culture générale, qui permet de montrer votre personnalité et de partager votre expérience ;
- un entretien de management et de mise en situation, d’1h30, afin d’évaluer mon expérience en tant que manager. Cette étape dépend de vos futures responsabilités ;
- une présentation d’1h sur un sujet d’architecture. Pour ma part j’ai du préparer un dossier sur le support off-line de l’application mobile de Doctolib. Vous avez une semaine pour préparer le sujet. Architecture technique, chiffrage, planning, et mise en situation. Lors de la restitution vous devez soutenir et répondre aux questions/objections. Ce n’est pas que technique, mais aussi axé sur vos idées de planification et de gestion des risques ;
- un dernier entretien sur le poste lui-même et sur la mission. J’ai plus vécu celui-ci comme un échange afin de s’assurer que les 2 pièces du puzzle allaient matcher ;
- En plus de cela il y a un exercice de code à faire en Ruby ou en Javascript. J’ai opté pour Ruby pour ma part. Clairement ce n’est pas ma zone de confort, mais on s’en sort. J’avais fait du Ruby/Rails du temps de Captaindash il y a quelques années. Mais j’ai senti que j’étais un peu rouillé sur cette partie ;
Au final, j’ai rejoins Doctolib début mars, en tant que Principal Engineer. Qu’est-ce que ce terme, et quel est ton job ? Au bout d’un mois, je peux vous en parler et expliquer notre mission. Vous allez voir que c’est intéressant pour des développeurs expérimentés comme moi.
Le poste de Principal Engineer
C’est assez simple. Nous ne sommes pas sous la direction des équipes techniques/produits, mais directement rattaché au responsable de l’architecture, David Gageot. Nous sommes 7 personnes aujourd’hui, bientôt 8. Il y a environ 300 personnes côté produit et développement. Notre mission est de suivre, d’aider et d’être en tant que « check & balance » comme dit Nicolas de Nayer (VP of Engineering). Nous traitons les sujets d’architecture long terme, mais aussi les soucis techniques immédiats, comme des problèmes de charge. L’équipe est constituée de personnes expérimentées chez Doctolib, et aussi de développeurs séniors, avec 15 à 20 années d’expériences.
La semaine type est organisée autour de plusieurs petits événements/formats de travail. Après un daily le matin, nous avons chacun une partie du logiciel sous notre responsabilité. Cela nous amène à travailler avec plusieurs équipes. Chaque P.E interagit avec entre 5 et 20 développeurs/responsables techniques selon le domaine qu’il gère.
Nous avons un travail de suivi des risques techniques/sécurité/performance qui nous amène à faire travailler les équipes, et à les aider sur ces sujets. Nous intervenons aussi chaque semaine sur des revues de tâches techniques. Ces « T.T. » sont des activités de modernisation, de ré-architecture ou d’amélioration de la fiabilité, à réaliser par trimestre.
L’important pour une entreprise comme Doctolib, est de trouver un équilibre entre le développement de fonctionnalités, et les tâches de développements/d’amélioration indispensables à la qualité du produit.
C’est un poste où l’on met encore les mains dans le code, mais pas que. La semaine passée par exemple j’ai contacté Guillaume Rozier, l’auteur de la plate-forme CovidTracker.fr. Vous avez peut-être vu le nouveau service « Vite ma dose de vaccin« . Le site fonctionne entre autre à partir des disponibilités des centres de vaccination, mis en ligne sur plusieurs sites, dont Doctolib. Je l’ai contacté afin de comprendre leur fonctionnement et de vérifier qu’ils n’allaient pas dégrader les performances sur la plate-forme. Sinon par défaut, les systèmes de sécurité bloquent les requêtes répétées et rapides sur le site. Nous avions noté une augmentation du trafic le vendredi après la mise en ligne. Grâce à un travail commun, nous avons pu aider et nous assurer que les équipes de Covidtracker n’étaient pas bloquées.
Là j’ai beaucoup aimé les échanges en interne pour aider les équipes de Covidtracker. Les équipes de Docto sont bienveillantes et tout le monde aide pour que cela fonctionne. Et ce, alors que les plannings sont déjà assez chargés, en raison de la gestion de la vaccination en ce moment. Cela m’a rendu heureux et fier de travailler pour Doctolib. On sert à quelque chose.
Le premier mois pour les nouveaux arrivants
En mars nous étions 83 nouveaux arrivants, dont 21 personnes pour les équipes produit/développement uniquement. Doctolib c’est 1700 personnes, dont 300 personnes pour le développement du produit. Intégrer autant de personne chaque mois demande une organisation et un framework bien organisé, ce qui est le cas. La première semaine c’est la D.A (Doctolib Academy). Nous sommes tous ensemble (en visio conférence en ce moment). Nous avons rencontré Stanislas Niox-Chateau, l’un des 3 créateurs et le CEO de Doctolib. La semaine s’organise autour d’ateliers et de présentations. Découverte du secteur médical, présentation du logiciel Doctolib Patient, Doctolib Médecin. Marketing, commercial, organisation de l’entreprise, vie au bureau, support client, programme de formation pour les employés, présentation des différentes bureaux, etc.
Les 2 semaines suivantes sont différentes selon votre future poste. Un commercial aura 2 semaines différentes d’un futur développeur. Pour ma part donc, avec 20 autres nouveaux, j’ai suivi une formation sur le logiciel, l’architecture, la code base, le produit, l’intégration continue, Github, la mise en prod, etc. J’ai écouté des appels au support, j’ai testé et configuré le logiciel pour des praticiens, nous avons rencontré une Psychologue, utilisatrice de Doctolib, qui nous a parlé de sa vision en tant que client. Nous avons parlé sécurité, architecture, tests unitaires et d’intégration, nous avons fait du live coding, etc.
Enfin la dernière semaine d’intégration est consacrée à votre poste. Pour ma part j’ai donc démarré des « vie ma vie » en suivant mes futurs collègues. Cela permet de comprendre sa future mission, et de s’approprier le vocabulaire.
Explique moi Doctolib en avril 2021
Chaque entreprise a son histoire, son patrimoine et sa façon de fonctionner. Le quotidien des équipes est chargé en ce moment. En mars dernier, le site a géré 12 millions de RDV pour la vaccination lié à la crise du COVID-19. Et ce, en plus des quelques dizaines de millions de rendez-vous, que les personnes prennent chaque mois sur le site.
C’est une énorme machine derrière. Le coeur est une application monolithe en Ruby/Rails. Les applications clientes, dont le site grand public, sont écrites en Javascript avec React. Je vous invite à regarder d’ailleurs la présentation « The Boring Architecture » de Michel Domenjoud et de Nicolas de Nayer, de Devoxx France 2019. Ce système a été conçu par 2 développeurs brillants : Jessy Bernal et Ivan Schneider. Avec Stanislas Niox-Chateau, ces 3 fondateurs ont lancé en 2013 Doctolib. Et je pense qu’ils ont une caractéristique assez rare : être capable de penser produit/client plutôt que de penser technique/architecture. Cela correspond au besoin de Doctolib, qui est une entreprise informatisé, mais dont la mission n’est pas de construire le prochain moteur de base de données NoSQL… juste d’améliorer la santé des personnes en Europe.
L’enjeu c’est d’assurer la croissance de la plate-forme, de le faire dans des coûts maîtrisés, et de pouvoir absorber des événements comme la vaccination par exemple. Cela a bouleversé la road-map il y a un an. Doctolib cependant grâce à la solidité de son architecture, et à son apparente simplicité, a pu encaisser ce Tsunami. Car oui, c’est violent. On parle de 300 000 requêtes par minute, de 70 millions de visites par mois, de 3 mises en production par jour, d’une batterie de 25000 tests d’intégration/interface utilisateur avec Capybara, et d’un système élastique qui peut démarrer/arrêter les serveurs selon la charge en quelques minutes.
Je terminerai par répondre à la question qui te creuse la tête depuis tout à l’heure : pourquoi moi qui suit plutôt du monde de la JVM avec 22 ans de Java au compteur, mais aussi 9 ans de Scala… oui pourquoi aller sur des technos comme Ruby et Javascript ?
Je pense que la technologie est accessoire au bout d’un certain nombres d’années. Si j’avais 25 ans, je serai à fond sur Rails et sur React. J’irai jusqu’à me faire tatouer React 2021. Et puis tu rajoutes 20 années, et tu regrettes ce tatouage React qui aura mal vieillit. Je peux t’assurer que tu seras pertinent pour tout un tas d’autres choses, dont l’architecture, mais pas que.
C’est ce que j’ai compris, et c’est aussi ce que les personnes de Doctolib ont compris, en faisant appel à plusieurs personnes plus expérimentées comme moi, comme Loïc ou Jonathan.
A suivre…
PS : Doctolib recrute, c’est sur https://about.doctolib.fr/jobs/ . Jobs techniques à Paris, à Nantes, à Niort, en Allemagne et en Italie.
Bonjour Nicolas. Et bien sacrée entrée en matière chez Docolib. Je suis assez surpris de ce parcours de recrutement. Même si je me souviens avoir passé 7 entretiens chez Arcelor-Mittal quand j’étais plus jeune, avec les années, mes entretiens se simplifient. Je rejoins totalement cet avis que la technique n’est pas là pour résoudre un problème technique mais un problème métier; un point de vue dont j’ai eu réllement conscience avec le temps. Je travaille toujours sur les solutions qui me semblent les plus pertinantes et surtout les simples pour le besoin, quite à sortir de ma zone de compétences. Moi même, après plus de 20 ans de Java, me voilà en ce moment à apprécier des interfaces en Powershell (la vache, il est vraiment « Power » ce shell!). J’ai aussi changé d’employeur début 2021 en passant d’architecte Java à DSI. J’ai déccroché ce poste en seulement 2 entretiens où j’ai été bien cuisiné mais sans avoir à faire le moindre schéma, juste en expliquant ma vision pour l’entreprise. Au plaisir d’en lire davantage sur cette expérience Doctolib. Alexandre