Recruter un développeur passe forcément par une évaluation technique de ses compétences. Comment intégrer un test technique dans un processus d’embauche, suivant le niveau de seniorité ?
L’embauche d’un développeur est une opération coûteuse pour n’importe quelle entreprise. Entre le temps investi à la recherche, l’évaluation et l’onboarding du candidat, sans parler d’éventuels frais de recrutement, une erreur de casting coûte très cher et n’est souhaitable pour personne, aussi bien côté recruteur que développeur.
Il est donc nécessaire de bien structurer son processus d’embauche de développeur et anticiper la préparation de l’entretien technique.
Edit 2024 : WeLoveDevs.com lance une plateforme de tests innovante pour vos candidats techs : CodersTests. Son gros point fort et de proposer des tests mis à jour chaque jour par une communauté de passionné pour vous assurer d’avoir des questions utiles dans un processus de recrutement !
Quelles sont les différences entre le test technique et l’entretien technique ?
Lors des processus de recrutement pour un développeur, il est commun de retrouver une étape où le candidat est amené à rentrer dans des détails techniques sur ses expériences précédentes et sur ses connaissances.
Les tests techniques en revanche ont pour but de servir d’entonnoir aux process de recrutements afin de savoir, à l’aide de questions techniques et d’exercices de code, si le candidat doit, ou non, poursuivre le processus de recrutement en fonction de son niveau de connaissances sur différents aspects techniques.
Les différents formats de tests techniques
Le test sur plateforme
Les tests techniques sur des plateformes en lignes tels que Codeingame ou Hackerrank permettent de faire un premier tri rapidement entre les candidats. Ces plateformes testent la maîtrise syntaxique d’un langage et à moindre mesure sa capacité à résoudre des problèmes algorithmiques via des exercices de code à faire dans un temps imparti.
La meilleure utilisation du test technique sur plateforme en ligne est lorsqu’il sert d’outil d’ évaluation aux recruteurs afin de donner une chance à des profils de développeurs ne cochant pas toutes les cases sur le CV d’intégrer quand même un processus d’ embauche.
Les tests en lignes doivent se faire sur un temps limité, en temps réel et refléter un niveau de compétences global sur un ou plusieurs langages de programmation.
Ils peuvent être utiles sur des profils juniors jusqu’aux profils confirmés afin de faire un premier tri dans les candidatures afin d’avoir un aperçu des compétences techniques spécifiquement liées à un langage ou à certaines connaissances théoriques de programmation, telle que la programmation orientée objet par exemple.
En revanche, ces tests automatisés ne peuvent pas servir pour savoir si le candidat au poste de développeur produit un code lisible ou un code de qualité. Ces points devront être évalués lors d’une autre session de questions techniques ou par un test complémentaire, lors d’un entretien technique par exemple.
Le test technique à la maison
Les tests techniques à faire « à la maison » ont l’avantage de demander relativement peu de temps à l’équipe technique chargée d’évaluer le candidat. Hormis le temps investi pour créer l’exercice, il suffira de partager un document ou un repository GitHub privé pour faire démarrer un candidat en totale autonomie.
Lorsque le candidat vous revient avec son travail, l’évaluation peut également être faite par différents membres de l’équipe, même s’il ne s’agit pas de ceux qui font passer les entretiens techniques. La correction se fera de manière asynchrone, lorsque les évaluateurs auront un moment dans leur journée.
Le test technique « à la maison » est le test le plus confortable pour l’équipe qui recrute. Il nécessite aucune préparation et l’évaluation du rendu du candidat est facile.
Attention toutefois aux pièges que renferme ce genre de test technique.
Les tests à faire « à la maison » prennent souvent un temps considérable. Ils représentent plusieurs heures de travail pour le candidat, d’où le fait qu’ils soient étalés sur plusieurs jours voir plusieurs semaines.
Certains candidats, notamment les plus seniors, ont déjà des postes à responsabilité, ont probablement une vie de famille et ne souhaitent pas s’ajouter cette charge mentale chaque soir pendant une semaine. Ils préféreront un test technique en personne, même si le process d’entretien dure deux à trois heures.
Les tests techniques à la maison requièrent un engagement fort du candidat. Ce n’est qu’une fois que vous avez suffisamment investi de temps avec ce candidat et qu’il soit réellement motivé par l’opportunité que vous lui présentez qu’il décidera d’investir le temps pour ce test technique. Si vous lui proposez ce type de test trop tôt dans le processus d’ embauche, il risquera de se retirer par simple fait qu’il n’est pas si intéressé que ça par votre poste et votre entreprise. Je recommande de proposer ce test qu’APRÈS avoir déjà passé l’entretien technique.
Enfin, l’étape la plus critique de ce test et là où je vois beaucoup d’entreprises se pénaliser est l’étape de la correction et du feedback.
À ce stade, le candidat a passé plusieurs heures à travailler sur votre exercice là où l’évaluateur va passer sûrement moins de 15 minutes à l’évaluer. Lorsque le test est réussi, il n’y a aucun problème, le candidat est invité à avancer dans le processus d’entretiens d’embauche. En revanche, si le test technique n’est pas concluant, le feedback au candidat est très important pour ne pas détériorer la marque employeur.
J’ai moi-même connu les deux scénarios.
Dans un premier cas, mon test n’était pas concluant mais, comme me l’a promis le Tech Lead qui m’a fait passer l’entretien technique, il a pris 20 minutes de son temps dans une conversation en visio pour me donner du feedback sur mon test, essayer de comprendre pourquoi j’ai fait ces choix et me donner quelques conseils sur les points à travailler ainsi que la façon de faire mes prochains tests. Je garde un excellent souvenir de cette personne et donc de son entreprise, je recommanderai n’importe quel développeur d’aller travailler avec lui.
Dans un second cas, mon test technique était selon moi mieux réussi mais visiblement pas assez au goût du Tech Lead, ce qui est complètement acceptable. En revanche ce qui l’est moins est qu’il ait à peine pris le temps de me répondre par e-mail en 3 lignes. Mon expérience avec cette entreprise en a été fortement dégradée et même si initialement j’avais plutôt une bonne impression de ce Tech Lead, l’amertume d’être laissé sur le carreau après plusieurs heures de travail est le dernier souvenir que je garde de cette entreprise.
C’est pourquoi, bien que le test technique à la maison soit peu chronophage pour l’équipe tech au début du processus, il faut bien prendre le temps de débriefer, idéalement de vive voix, avec chaque candidat qui vient d’investir une durée conséquente de son temps. Un développeur va toujours apprécier les conseils d’un développeur senior et cette bienveillance dans le feedback va laisser une bonne impression sur plusieurs années. Qui sait, d’ici 2 ans il sera peut-être à nouveau sur votre radar de recrutement, ou bien son collègue à qui il aura partagé son expérience de ses entretiens d’ embauche chez vous…
La session de code review
Parmi les différents types de tests, la revue de code celui qui simule la réalité. L’équipe technique prépare un ou plusieurs fichiers de code, pouvant comporter des bugs ou des points d’améliorations. Le but est de présenter ce code au candidat au poste de développeur et de lui demander d’effectuer une code review, telle qu’il l’aurait fait s’il était en poste dans une situation réelle.
Le but est de se servir de ce support pour rentrer dans des conversations techniques. A-t-il bien saisi le fonctionnement du langage de programmation ? Est-ce que le code présenté comporte des tests unitaires ? Si oui, sont-ils bien unitaires ou sont ils une autre typologie de tests automatisés? Si non, pourquoi ne sont-ils pas présents ?
Ce type d’exercice en entretien d’embauche permet d’avoir rapidement l’opportunité de poser et voir si le candidat pose également des questions pertinentes sur différents sujets techniques.
Ce test est facilement réalisable lors des entretiens technique. Il peut se coupler avec d’autres exercices en live tel qu’un problème d’algorithmie sur tableau blanc.
Ce genre de test va proposer une expérience candidat très intéressante car il sera un terreau de discussions techniques avec l’interlocuteur. Il se prête bien à tous les niveaux de séniorités des candidats. Il sera en revanche difficile de faire une évaluation complète en se basant uniquement sur une code review. C’est pourquoi je conseille ce genre de test lors de l’entretien d’embauche technique ou en amont d’une session de pair programming.
La session de Pair Programming
C’est selon moi le test technique qui offre le meilleur aperçu sur le niveau de compétences du candidat lors d’un entretien d’ embauche.
L’idée est de préparer un exercice de code et de le réaliser en binôme entre le candidat et un développeur de l’équipe. Il peut également être observé par un 2e membre de l’équipe technique.
Le test technique pour un prestataire ?
Lors de l’embauche d’un CDI, le développeur a probablement démissionné de son poste précédent et purgé son préavis pour se rendre disponible. Bien que la période d’essai permette à l’entreprise de se défaire rapidement d’un nouvel employé, les entreprises vont le plus souvent prendre le temps d’observer pendant plusieurs semaines voir plusieurs mois une nouvelle recrue développeur s’il y a des doutes. Forcément, tenir une telle position a un coût énorme, à la fois sur le budget RH mais également sur le temps de l’équipe qui va devoir donner une chance et intégrer cette personne qui ne sera peut-être plus là dans quelques semaines.
D’où l’intérêt de faire un bon travail d’évaluation technique, quitte à prendre du temps, lors de l’embauche d’un CDI.
En revanche, lorsqu’il s’agit d’un Freelance ou d’une société de services, la position est tout autre !
L’intérêt de passer par un prestataire est la rapidité. Vous pouvez agir et réagir rapidement en fonction du niveau du prestataire par rapport au niveau espéré.
En effet, il est complètement acceptable qu’une entreprise mette fin à une mission de prestation avec un Freelance ou une entreprise de services numérique après une ou deux semaines si elle n’est pas satisfaite du niveau attendu. Cela fait partie du jeu et tout le monde sait que c’est acceptable.
Lors du recrutement d’un prestataire, il faut capitaliser sur la vitesse pour continuer à tirer tous les avantages de ce format. En effet, une bonne ressource va passer que très peu de temps à l’écoute du marché avant de trouver sa mission suivante.
Recrutez-le pour une demi-journée, qui vous sera facturée, et prenez le temps de lui faire faire un travail en binôme avec un de vos développeurs. Il peut s’agir d’un exercice ou d’un cas concret sur lequel votre équipe travaille.
Ne passez pas trop de temps à expliquer tout le contexte métier lors de cette demi-journée. Choisissez un segment compréhensible en une heure puis commencez votre session de pair programming. À la fin de la demi-journée, le développeur doit pouvoir vous dire « oui, il a bien compris le problème, de ce que j’ai vu il a l’air d’avoir le niveau technique et je me vois bien travailler avec lui ».
Si la réponse est oui, contractualisez immédiatement puis commencez à travailler. S’il ne convient plus au bout d’une semaine, mettez fin à la mission.
Pour conclure
Il n’existe pas de test technique qui permettrait d’identifier parfaitement les meilleurs profils dans la communauté des développeurs. Ils permettent simplement de se faire une idée des compétences que le candidat présente au moment de son éventuelle embauche en entreprise.
