Si vous postulez chez Doctolib, il y a une petite chance pour que l’on se rencontre. Depuis le mois de juin 2021, je participe et fait passer l’entretien de « System Design ». Sans dévoiler en détail son contenu, je vous propose de découvrir d’une part son fonctionnement, d’autre part ses objectifs et la méthode pour évaluer un candidat.
23 entretiens en 2021 sur 6 mois, cela permet de rencontrer beaucoup de personnes. Pourquoi telle personne m’a marqué ? Pourquoi pour celui-ci c’était catastrophique et pour celle-là c’était parfait ? Que cherche-t-on à évaluer durant cet entretien avec le candidat ?
Le « System Design » est un exercice intéressant dans le processus de recrutement pour les développeurs. Son déroulé est assez simple, je vais en parler dans quelques instants. Les buts de cette entretien sont multiples. Cela permet par exemple d’évaluer la culture technique de la personne. Il permet aussi d’estimer son savoir-être et son approche pour résoudre les problèmes que l’on présente. Nous sommes aussi sensible à la qualité de communication, à la démarche utilisée par le candidat. C’est donc un mélange entre ce que l’on appelle en Anglais les Soft skills, et les connaissances purement technique.
L’exercice est un jeu de rôle que nous animons à deux personnes chez Doctolib. Le candidat est guidé dans des itérations de 10mn environ. Au début de chaque itération, nous soumettons un problème à résoudre au candidat. Pendant que l’une des personnes de Doctolib pose les questions, la deuxième peut écouter et relancer. Nous inversons les rôles après chaque itération pour garder le rythme.
Pour des raisons évidentes d’équité, je ne pourrai pas vous citer les cas de System Design utilisés chez Doctolib. Il va nous falloir une autre idée.
Un exemple basé sur Devoxx France
Alors prenons par exemple le site de l’appel aux conférenciers de Devoxx France (cfp.devoxx.fr).
« Je vous propose pour démarrer de me demander de représenter simplement une architecture Web, qui permettra à un orateur de créer une seule proposition de sujet, pour venir parler à la conférence, après s’être authentifié. Et je vous indique que vous disposez de 2 semaines. Votre solution doit être livrée sous la forme d’un site Internet. Les propositions doivent être sauvegardées, afin que l’orateur puisse recharger son sujet et éventuellement l’éditer.
Comment allez-vous construire votre solution ? Quelles technologies ? Comment allez-vous stocker la proposition envoyée par un orateur ?«
Il est important lorsque vous êtes candidat de poser vous aussi quelques questions, afin de vous assurer d’avoir bien compris la consigne. Les choix technologiques sont ouverts, vous pouvez prendre ce que vous souhaitez. Il sera par contre important de pouvoir justifier vos décisions.
Les interviewers vont vous poser des questions techniques, demanderont des précisions, et ajouteront ensuite de nouveaux éléments à intégrer.
Après avoir complété ou lorsque nous jugeons que l’itération est terminée, nous passons alors la main à notre binôme.
« Le site pour l’appel aux conférenciers est en ligne et il fonctionne. Les orateurs proposent des sujets. Par contre, votre équipe de sélection vous fait remarquer qu’il faut qu’elle se connecte sur le site pour découvrir les nouveaux sujets. L’équipe aimerait être notifié par courrier électronique lorsqu’un sujet est déposé. Comment faites-vous ? Quel est l’impact sur votre base de données ? Quels outils utilisez-vous pour envoyer les emails ? »
Et ainsi de suite, pendant une bonne heure.
A la fin de l’entretien, vous aurez construit une solution, intégré de nouveaux services et d’autres petites surprises, selon votre avancement et vos progrès.
Nous utilisons un support type « tableau blanc partagé » comme Excalidraw ou Lucidchart. Ces entretiens se déroulent en vidéo conférence, pendant 1h. Au bout d’une heure, nous terminons et nous laissons du temps pour que le candidat puisse nous poser toutes les questions qu’il souhaite sur notre métier chez Doctolib.
Quelle est la grille d’évaluation ?
Le candidat est évalué sur plusieurs critères, et chaque élément doit être justifié avec des faits. Nous ne pouvons pas simplement dire « Communique bien ». Il faut apporter de la précision, argumenter et détailler chaque élément.
Il est fréquent que les personnes ne disposent pas de l’ensemble des connaissances pour résoudre l’exercice. Si vous n’avez jamais testé Heroku ou que vous n’êtes pas une experte côté frontend, il faudra proposer des solutions et des idées pour résoudre les cas présentés.
Certains candidats présentent plusieurs idées, et ensuite nous expliquent le choix, ce qui est intéressant surtout pour les personnes expérimentées. D’autres personnes sont plus sensibles sur le côté produit, et même si leurs questions sont passionnantes, nous les orientons vers la résolution et la construction d’une solution technique. Ce n’est pas un exercice pour un Product Owner. C’est une exercice pour un architecte, une personne à même de résoudre un problème, en prenant en compte les contraintes que nous ajoutons durant les itérations.
Comment peut-on dire que l’entretien est réussi ?
Lorsque nous avons pu évaluer correctement les qualités de présentation, de synthèse, d’analyse et d’approche technique, alors l’entretien est un succès.
Nous évaluons aussi comment chacun réagit lorsqu’il est contredit, ou que nous mettons en doute une affirmation. C’est important, et dans ce type d’approche, je me demande toujours si à la fin, j’ai envie de travailler avec vous (ou pas).
Les candidats dont je me souviens le plus, sont les personnes avec une culture technique assez détaillée, et un vrai sens produit. Ce sont des candidats sur lesquels vous arrivez à faire 60 minutes, et qui terminent en étant capable d’avoir des réponses techniques/organisationnelles qui impactent l’ensemble de l’entreprise, voire de l’industrie. Là où un junior sera amené à impacter son équipe, nous attendrons qu’une personne Senior soit capable d’impacter plusieurs équipes, puis rapidement un département complet.
C’est cet élément qui constitue réellement votre séniorité. Etes-vous une personne capable d’impacter l’ensemble de votre département ? Ou alors l’ensemble de votre entreprise ?
Doctolib propose 2 voies : soit le chemin du manager technique, soit le chemin de l’Individual Contributor. Prenons une personne qui ne souhaite pas exercer un rôle de manager (pour l’instant). Chez Doctolib nous avons ce framework de contributeur individuel. Cela vous permet d’évoluer et d’acquérir au fil des années de plus en plus d’autonomie, sans vous forcer à devenir manager. Software Engineer, Senior Software Engineer, Principal Engineer, Distinguished Engineer, etc. A noter cependant que vous pouvez basculer d’une voie à l’autre, selon les projets ou votre envie.
Dans l’exercice du « System Design » nous allons donc chercher à évaluer aussi votre niveau en tant que contributeur individuel. D’où ces questions techniques, et d’où ensuite ce jeu de rôle afin d’évaluer au mieux votre expérience.
Pour Doctolib, nous travaillons en comité pour revoir régulièrement notre approche sur cet exercice de recrutement.
Peut-être qu’au moment où vous lirez ces lignes, l’entretien aura évolué et sera différent.
Peut-être que vous verrez ma tête apparaître après avoir postulé chez Doctolib.
A bientôt ?
J’adore la démarche !
Sur Doctolib, dans la rubrique « Jobs », il y a des offres d’emploi pour Software Engineer. Il est aussi indiqué que la stack c’est du Ruby + du React.
Il est aussi indiqué que ce n’est pas un soucis de ne pas maîtriser la stack Doctolib pour postuler et que je ne serai pas le premier.
Imaginons que j’ai déjà fait du React, mais jamais de Ruby.
Imaginons que je viens du monde Java et que j’ai plus de 10 ans d’xp en développement web avec ce langage.
Est-il vraiment envisageable que ma candidature soit prise en compte ?
Je suis curieux de connaître la réponse car ce n’est pas commun dans l’IT.
Salut Joël
Oui, je te confirme tout d’abord que l’entreprise recrute d’abord des développeurs (H/F) et que la maîtrise de Ruby, ou de TypeScript, n’est qu’un plus.
Lorsque tu rejoins Doctolib, nous avons créé 1 programme de formation qui permet d’apprendre à son rythme Ruby & Rails. Nous avons aussi 1 programme de mentoring, appelé « Starsky & Hutch » qui te permet chaque semaine de passer 1h avec 1 dev pour travailler sur ton code et avoir de l’aide.
Il faut avoir une grosse motivation pour passer du status de « je sais tout, j’ai 10 ans de Java » à celui de « je ne sais rien, et je dois m’en remettre aux autres ». Tout le monde n’a pas forcément envie de faire ce saut. Pourtant c’est intéressant, et tu vois rapidement que Doctolib c’est du Ruby/Rails, mais aussi beaucoup de JS/TypeScript avec React. Il y a aussi d’autres projets avec Kotlin, avec Rust mais cela reste minoritaire par rapport à l’application au coeur de Doctolib.
Donc OUI ta candidature sera toujours évaluée, et tu pourras avoir aussi un moment de « vie ma vie » avant d’etre recruté, pour passer par exemple un peu de temps avec ta « future » équipe. Cela te permet de te dire « ok j’y vais… ou ce n’est pas pour moi « .
En espérant avoir répondu à tes questions, sinon mon mail c’est nicolas.martignole AT doctolib point com
A noter que j’ai enregistré une interview en Podcast sur ce sujet, invité par Nicolas Darcis et Pierre-André Fortin, en compagnie de Jérémy Buget (PIX.fr), https://www.linkedin.com/video/live/urn:li:ugcPost:6892799396354822144/