1. Qu’est-ce qu’un test technique dans un processus de recrutement ?
1.1. Définition des tests techniques
Les tests techniques sont des outils utilisés dans le processus de recrutement.
Leur objectif est d’évaluer le niveau technique du candidat sur une ou plusieurs compétences clés pour le poste.
Il est souvent utilisé pour des professions IT tels que les développeurs, les devOps, les métiers de la sécurité ou encore de la data …
1.2. Quelle forme utiliser pour ses tests techniques
Vous devez prendre en compte 2 choses :
- La ou les compétences à évaluer
- L’expérience candidat que vous souhaitez proposer à vos candidats
Partant de cela, vous pourrez choisir entre :
- Des tests à faire à la maison,
- Des tests à faire sur des plateformes spécialisées (comme Codingame, Hackerrank, Isograd …),
- Des échanges ou exercices entre pairs.
Lorsque vous choisirez votre test, prenez garde à la durée nécessaire pour le réaliser.
Certains tests peuvent être passés en une vingtaine de minutes.
D’autres vont demander plusieurs heures.
La durée de passation du test aura un impact sur la perception des candidats quant à votre entreprise. Ainsi, si vous demandez de coder une feature entière, vous risquez d’éveiller la suspicion des candidats qui vont se demander si vous n’allez pas réutiliser une partie de leur code pour faire avancer votre projet sans le recruter.
1.3. Quand faire passer un test technique dans son processus de recrutement ?
Ici encore, c’est à vous de choisir en fonction de votre culture d’entreprise et l’expérience candidat que vous voulez délivrer.
Vous allez proposer ces tests à des populations exerçant des métiers pénuriques. Le risque avec un test technique proposé au mauvais moment est de perdre le candidat.
2. Pourquoi ajouter un test technique dans son processus de recrutement ?
2.1. Les avantages des tests techniques
2.1.1. Aller au-delà du CV
Les tests techniques permettent d’aller au-delà du CV car ils permettent d’évaluer le niveau de compétences actuel du candidat.
Ainsi, un candidat qui indique sur son CV la maîtrise d’une techno alors qu’il l’a étudié lors de sa formation mais ne l’a pas pratiqué depuis 10 ans sera identifié grâce aux résultats du test.
Un test peut aussi évaluer des candidats qui ne semblent pas remplir tous les critères sur le papier mais qui ont pourtant les compétences pour réussir sur votre poste.
2.1.2. Gain de temps
Les tests techniques sont une pratique courante, les candidats ont l’habitude d’en passer. C’est donc une pratique acceptée par la majorité des candidats. D’autant plus si vous l’avez annoncé dès votre offre d’emploi.
Bien positionné dans votre processus de recrutement, il peut vous permettre de gagner du temps notamment en ne sollicitant pas de Team Leader pour un entretien lorsque le candidat a des résultats non satisfaisants.
D’autre part, certains tests (sur les plateformes spécialisées) sont automatisés et permettent ainsi une correction rapide.
2.1.3. Réduire le risque d’erreur de recrutement
Une erreur de recrutement coûte cher et peut conduire à recommencer un processus de recrutement depuis le début. Il y a peu de chances que le bon candidat arrivé en 2nde position dans votre processus de recrutement soit toujours disponible.
Si votre test comporte des questions représentatives des compétences attendues sur le poste (et non représentatives des compétences du correcteur 😅).
2.1.4. Améliorer la qualité du feedback apporté
Les tests vont vous permettre de voir les points forts et les points faibles des candidats et de voir ses réflexions.
Ainsi, que le feedback soit positif ou négatif, vous aurez matière à faire un retour de qualité. Parmi les attentes des candidats autour du processus de recrutement, on retrouve des attentes liées à la qualité des feedbacks et la volonté de progresser grâce aux retours faits.
Vous pourrez creuser les choix faits par le candidat pour aller plus loin dans son raisonnement. Vous pourrez le conseiller sur les points à travailler pour progresser ou sur la manière de réaliser ses prochains tests techniques dans ses futurs processus de recrutement.
2.2. Les inconvénients des tests techniques
2.2.1. Le risque de passer à côté d’un bon candidat
Les causes sont nombreuses.
Le candidat peut rater le test à cause du stress alors qu’il aurait réussi dans des conditions de travail normales.
Il peut aussi passer plusieurs fois le test ou se faire corriger s’il réalise le test à domicile sans temps limité.
Le test peut être mal choisi ou mal conçu par rapport au poste à pourvoir.
Par exemple, le test doit être différent selon que l’on recrute un développeur front, back ou fullstack.
Les résultats ne montreront donc pas la capacité du candidat à réussir sur le poste.
L’analyse des résultats peut être biaisée car l’évaluateur n’est pas sensibilisé à ses biais et aux pratiques d’évaluation des candidats, qu’il évalue par rapport à ses propres compétences ou encore qu’il se cantonne aux tests alors qu’il n’évalue que les compétences testées et non l’ensemble des compétences du candidat.
La consigne peut être mal donnée. Ainsi le candidat ne sachant pas quels critères sont évalués pourrait vous pousser un code propre privilégiant la maintenabilité plutôt qu’un code performant ou inversement.
Le test ne prend pas forcément en compte le fait que le candidat maîtrise un autre langage ayant les mêmes prérequis et lui permettant de monter rapidement en compétence sur le poste.
Enfin, le test permet uniquement d’évaluer les compétences techniques. Il ne dit rien sur les compétences comportementales ou culturelles du candidat. Il ne faut donc pas se limiter au test mais bien l’ensemble de vos critères de recrutement.
2.2.2. Le coût de la réalisation du test
Si vous choisissez une solution de passation de test, ceux-ci auront un coût à chaque test réalisé.
Même si vous créez les tests vous-même, ils auront un coût. Vous devrez mobiliser des techs pour créer le test, le mettre à jour, le corriger même si la charge de travail peut être répartie entre plusieurs personnes de l’équipe.
Si les tests passent par un échange entre pairs, votre Team leader devra investir du temps pour connaître le déroulé afin de les anticiper les éventuelles questions techniques du candidat.
Enfin, il faudra investir du temps pour sensibiliser les opérationnels à leurs biais cognitifs, au déroulé du processus de recrutement, à l’analyse des réponses.
3. Comment choisir son test technique ?
3.1. Les QCM de connaissances
3.1.1. Cas d’usage :
Évaluer un niveau de compétence global sur un sujet précis (un langage de programmation par exemple). Il peut servir à trier les candidatures pour les profils juniors ou confirmés.
3.1.2. Les avantages :
Le candidat sait ou ne sait pas.
Par conséquent, il est rapide à passer.
Il est facile à mettre en place et à organiser.
Il est rapide à corriger.
3.1.3. Les inconvénients :
Il reste théorique et peut être éloigné de la réalité (comme l’examen du code de la route).
Il ne permet pas de savoir si le candidat saura réussir ses missions dans la pratique.
Par exemple, pour un développeur, le QCM ne dira rien de la capacité du développeur à écrire un code lisible et de qualité.
Enfin, il peut être biaisé car les QCM se ressemblent et les candidats finissent par savoir ce qu’ils doivent réviser avant de passer un test de ce type.
3.2. Les Tests “maison”
3.2.1. Cas d’usage :
Un test créé par vos équipes permet de mettre le candidat en situation selon vos conditions et contraintes de travail habituelles.
Il peut prendre différentes formes : résolution d’une problématique, proposition d’une architecture …
3.2.2. Les avantages :
Il a l’avantage d’être réaliste. Avec ce type de test, vous saurez comment le candidat raisonne, comment il fait ses choix, comment il code s’il s’agit d’un développeur.
Pour garder les avantages du test, vous devez cadrer le test et être disponible si les consignes ne sont pas comprises. L’idée étant d’éviter au candidat de passer des heures et des heures parce qu’il veut rendre un travail parfait sur tous les points.
Expliquez les critères d’évaluation et l’environnement technique dans lequel l’exercice doit fonctionner.
3.2.3. Les inconvénients :
Il demande un investissement de départ pour la création du test.
Il est plutôt long à corriger.
Il demande souvent plusieurs heures de travail pour le candidat.
3.3. Les tests de code écrits
3.3.1. Cas d’usage :
Évaluer la capacité d’un développeur à produire un code à partir d’un cahier des charges.
3.3.2. Les avantages :
Il est très facile à mettre en place car il suffit d’une feuille et d’un stylo.
Il peut s’adapter au projet facilement en testant le candidat sur une fonction ou un algorithme utilisé.
3.3.3. Les inconvénients :
Il est peu apprécié tant par les candidats que par les correcteurs.
Le test est difficile à résoudre car il faut souvent tester et itérer mais sur papier cela n’est pas possible. Le développeur perd l’assistance des outils et correcteurs qu’il utilise au quotidien et qui lui font gagner du temps sur les tâches à faible valeur ajoutée.
On perd donc de vue ce qui fait un bon développeur :
- l’attention à la qualité du code produit, sa maintenabilité
- la prise de hauteur en imaginant des solutions évolutives
- la prise en compte du cahier des charges
Pour le correcteur, c’est souvent long et difficile à corriger.
3.4. Les revues de code
3.4.1. Cas d’usage :
La revue de code, ou code review, consiste à présenter un fichier de code au candidat comportant des bugs ou des points d’amélioration et de lui demander de faire une revue de code telle qu’il l’aurait faite s’il était en poste.
3.4.2. Les avantages :
Ce test simule la réalité terrain.
Il peut s’adapter à tous les niveaux d’expérience, du profil junior au sénior.
Il permet de prendre en compte les solutions inédites que pourrait proposer le candidat.
Il peut servir de support à l’entretien technique pour voir la pertinence des questions posées par le candidat et la manière dont il réagit à la critique.
3.4.3. Les inconvénients :
S’il n’est pas réalisé au moment de l’entretien technique, il peut demander des échanges complémentaires pour comprendre les réflexions, les points relevés par le candidat.
3.5. Les sessions de pair programming
3.5.1. Cas d’usage :
Ce test consiste à préparer un exercice de code et de le réaliser en binôme entre le candidat et un développeur de l’équipe.
3.5.2. Les avantages :
C’est un exercice apprécié des candidats car en plus d’être très pratique, il permet aussi de se rendre compte de la réalité de la culture d’entreprise.
Il donne une bonne idée des compétences techniques du candidat et de la manière dont il travaille en équipe.
3.5.3. Les inconvénients :
Il va mobiliser un de vos développeurs pour toute la durée de la session de pair programming.
3.6. Les tests sur les plateformes
3.6.1. Cas d’usage :
Ils permettent d’évaluer les compétences à partir d’une suite de problèmes à résoudre dans un temps donné, d’exercices d'algorithme ou encore d’exercice d’écriture de code en ligne.
3.6.2. Les avantages :
Ils sont plutôt personnalisables et faciles à mettre en place.
Le candidat peut le réaliser chez lui quand il le souhaite.
Ils testent la logique en plus des connaissances théoriques.
Ils peuvent permettre un gain de temps dans la correction et l’analyse des résultats.
3.6.3. Les inconvénients :
Comme le candidat est à distance, rien de garanti qu’il soit seul.
Lorsque la correction est automatisée, elle peut conduire à écarter des solutions innovantes.
Elle représente un certain coût si le volume de tests à passer est conséquent.
3.7. L’échange entre pairs
3.7.1. Cas d’usage :
Il s’agit d’un entretien avec un opérationnel afin de valider les compétences techniques du candidat.
3.7.2. Les avantages :
L’échange peut s’adapter au profil du candidat et à ses réponses.
Il est moins stressant pour le candidat.
3.7.3. Les inconvénients :
Il demande du temps à l’opérationnel qui reçoit le candidat en entretien.
Il peut manquer d’objectivité si l’opérationnel n’est pas sensibilisé au recrutement.
Chaque test à donc ses avantages et inconvénients plus ou moins conséquents selon votre contexte et les compétences que vous souhaitez évaluer.
