Les tests techniques en recrutement

Le test technique est un incontournable du recrutement dans le secteur IT 💻, redouté par les candidats et valeur étalon pour les recruteurs. Là où les entretiens et les tests psychologiques sont souvent décriés, les tests techniques jouissent d’une bonne réputation car il est forcément « objectif » car basé sur les compétences.

Et pourtant, il est souvent mal conçu, pas adapté au poste ou tout simplement mal analysé/interprété… 😱

Quels sont les différentes formes de tests techniques ? Quels sont leurs avantages, inconvénients et pièges, côté candidat comme recruteur ?

Voyons tout cela dans l’ordre car il faut bien comprendre ce que sont les tests, leurs constructions, leurs buts et leurs analyses avant d’en tirer des conclusions !

Pour les informaticiens/dev, cela vous donnera l’envers du décor et vous permettra de mieux anticiper, comprendre ce que l’on attend de vous. Si cela ne vous intéresse pas, allez directement à la 2ème partie du billet 😉

 

Un test technique c’est quoi ?

Cette question peut paraître simple de premier abord, mais pas forcément… Un test technique est un outil pour évaluer le niveau technique d’une ou plusieurs compétences/connaissances chez un candidat.

Le panel technique du test peut donc aller du très précis au très large et faire appel à un grand nombre de compétences différentes. Il peut avoir différentes durées : de 20 min ⏱ pour un QCM dans les locaux de la société à plusieurs heures pour un exercice à réaliser à la maison.

Qui fait passer le test ?

Le test est généralement réalisé par un opérationnel qui est à même de comprendre la technique. Or un technique, même s’il est manager, n’est pas forcément sensibilisé aux biais cognitifs et aux entretiens structurés comme un recruteur doit l’être…

Pas de feeling, il faut que la note soit objective et donne la même chance à tous les candidats ! 

Surtout que généralement la personne qui fait passer le test diffère. Sur un QCM cela n’a aucune importance, mais sur un échange entre pairs oui !

Cela peut paraître idiot mais il faut que l’opérationnel connaisse le test et soit assez qualifié pour répondre aux éventuelles questions du candidat. C’est une situation que j’ai vécu dans ma 1ère vie de dev avant de faire du recrutement : l’opérationnel était complètement perdu 😅 Le pauvre gars était là par hasard et c’est tombé sur lui sans qu’on lui demande son avis comme il a fini par m’avouer 😂

 

Qu’est-ce que l’on teste ?

Le test n’évalue le candidat que ce pour quoi il est testé !

Normal me direz-vous ! Et pourtant…

Dans la réalité, faute de temps ou de tests, beaucoup de sociétés généralisent le test d’une compétence à l’ensemble des compétences du candidat. Cette pratique est dangereuse car les métiers IT font intervenir de nombreuses technos complémentaires. On peut être moyen en HTML/CSS et très bon sur le back-end et l’algo. Ce sont 2 profils de postes différents…

Selon le test, on ne vas pas cibler les mêmes connaissances. Par exemple, si on évalue un dev sur :

• le langage Java : ce seront des questions qui touchent uniquement au langage, sa définition (objet, interopérabilité…), ses fondamentaux (polymorphisme, héritage…), ses API (IHM, JDBC…).
• le développement d’une application mobile : on touche aussi bien à de la conception/architecture de solution, que du développement mobile (Java/Kotlin pour Android ou Objective-C/Swift), du front-end/back-end, de la base de données, etc.

Réussir un test technique haut la main veut-il dire que le candidat est très intelligent, ou qu’il sera un excellent employé ?

Non bien évidemment… Il y a déjà de nombreuses formes d’intelligences 💡 et ce n’est pas l’objectif du test technique. De même que le candidat avec un excellent niveau technique peut se révéler un piètre employé à cause de sa personnalité (communication, ouverture d’esprit, etc.).

Il faut donc que le test soit spécifique au poste visé ! 

Ne pas être dans une logique binaire…

Le but d’un test est d’évaluer le niveau afin de coller à l’expérience du candidat. Le niveau d’un junior ne sera pas le même que celui de senior. Le test doit être capable de donner aussi un aperçu des connaissances : quels sont les points forts et les points faibles ?

Les questions doivent être progressives afin de ne pas atteindre les limites du candidat trop tôt dans le test, au risque de voir un junior prendre peur, se démotiver et ne pas aller plus loin…

Les tests qui disent « oui, il a les compétences ✔ » ou « non, il n’a pas les compétences ❌ » n’ont pas beaucoup de sens… Il est plus intéressant par exemple d’évaluer le candidat sur une échelle de 1 à 10.

On évite de se baser sur le « feeling » (cf. plus haut Qui fait passer le test). A partir de questions identiques pour tout le monde et la notation sur des résultats concrets, on peut effectuer une analyse efficace et réelle 📊.

Certains tests sont très difficiles et avoir la moyenne est déjà une excellente note ! Il faut donc bien faire attention d’interpréter la notre par rapport aux moyennes. Si tout le monde se situe entre 8 et 12/20, il faut en tenir compte !

 

Quels tests techniques et quelles différences ?

Selon les entreprises, les process ou les postes, le candidat peut être amené à réaliser un ou plusieurs de ses tests. Le but ici est de les « catégoriser » pour en analyser les forces, les faiblesses et les pièges à éviter. Par exemple, un QCM pourra être associé à un test de code écrit sur papier puis un échange avec le CTO.

Les listes ne sont pas exhaustives, n’hésitez pas à me suggérer d’autres points auxquels je n’ai pas pensé en commentaire 😊

QCM et questions simples

On alterne des questions avec plusieurs propositions, fermées ou ouvertes : c’est le test le plus courant et le plus répandu !

Avantages :

• Facile à mettre en place, on peut en trouver sur le web déjà tout prêt.
• Prend peu de temps ⌛ : on sait ou on ne sait pas.
• Facile à corriger et pour mettre une note.

Inconvénients :

• Valeur faible : teste plutôt des connaissances théoriques, souvent scolaires, éloignées parfois de la réalité.
• Les candidats sont habitués et savent quoi réviser : ces tests se ressemblent souvent.
• Pas de personnalisation en fonction du candidat.

Pièges à éviter pour les candidats :

• Ne pas avoir réviser les bases ou au contraire vouloir tout revoir, ce qui est impossible.
• Se poser trop de questions sur le sens de la question.
• Se décourager 😤 avant la fin après plusieurs questions difficiles.
• Vouloir répondre à tout : il vaut mieux être humble et dire que l’on se sait pas. Ce qui n’empêche de donner un avis ou une réflexion.
• Bien gérer son temps : les questions les plus difficiles sont souvent à la fin et il faut garder plus de temps pour y répondre en détails.

Pièges à éviter pour les recruteurs, correcteurs et opérationnels :

• Souvent bâclé et mal ciblé.
• Avoir des questions trop pointues ou hors propos : celui qui réalise le test se base sur ses propres connaissances (représentatives du poste ?) et peut faire preuve de trop de zèle.
• Etre capable d’analyser les réponses aux questions ouvertes. Certaines solutions peuvent être valables mais réfutées par le correcteur qui a sa propre réponse en tête.
• Ne se focaliser que sur des questions/problèmes que rencontre/a rencontré(e)s l’entreprise. Le risque est de rentrer dans des thématiques ultra-spécifiques sur lesquelles peu de personnes ont déjà eu l’occasion de travailler.

 

Tests de code écrit

C’est le fléau des tests techniques car il se fait très souvent sur papier… Les devs le détestent autant que les correcteurs. Et pourtant, il est encore très pratiqué 😱

Avantages :

• Facile à mettre en place avec peu de moyens (un stylo et une feuille).
• Plus ouvert qu’un QCM pour évaluer des compétences.

Inconvénients :

• Difficile à résoudre : écrire du code sur papier est contre nature et il y a toujours plusieurs essais avant d’arriver au résultat. Là, il faut écrire le code d’un coup.
• Très éloigné de la réalité : impossibilité de tester et on perd l’assistance des outils et correcteurs… Ce qui n’arrive jamais, à moins de développer dans un bloc note !
• Très difficile à lire et corriger.
• Pas de personnalisation en fonction du candidat.

Pièges à éviter pour les candidats :

• Bien réviser les bases et notamment tout ce que l’on a perdu l’habitude de faire à la main car son éditeur favori le fait si bien 🙄…
• Laisser des espaces et bien indenter pour que le code soit lisible et avoir la place de rajouter/corriger.
• Remplacer par des appels à des fonctions, que l’on laisse vide, le code que l’on ne sait pas faire.

Pièges à éviter pour les recruteurs, correcteurs et opérationnels :

• Ne pas demander à écrire des pages de code, notamment ce qui n’est pas très utile (getter/setter ou constructeur). Juste la fonction ou l’algo qui vous semble important.

Tests d’algorithmie ou de code en ligne

Il s’agit de petits exercices d’algorithme et/ou de code en ligne, de complexité graduelle et qui peuvent être réalisés dans un temps défini.

De nombreuses plateformes (CodinGame ou Isograd par exemples) proposent ce type de tests avec en sortie un graphique pour visualiser les connaissances maîtrisées. On se rapproche ici du format des concours de code 💻.

Avantages :

• Teste les connaissances mais aussi la logique du candidat.
• Facile à utiliser et à mettre en place : le candidat se connecte à une URL et peut le faire de chez lui.
• Certains sites propose des statistiques détaillées des points forts et faibles.

Inconvénients :

• Payant 💸, surtout si on veut choisir ses questions ou les personnaliser.
• Pas de personnalisation en fonction du candidat (ou alors différents niveaux : débutant, expérimenté, sénior).
• Boite noire : on ne sait pas ce qu’il y a derrière les graphiques et les réponses ne sont pas toujours accessibles.
• C’est un robot qui corrige : un candidat pourrait partir sur une solution ambitieuse et inédite sans avoir le temps la finir. Un humain le verrait et pourrait l’apprécier…

Pièges à éviter pour les candidats :

• Se renseigner sur ce que la plateforme évalue : uniquement si le résultat est correct (on ne se préoccupe alors pas de la qualité) ou si le temps d’exécution sont pris en compte (donc les performances) ?
• S’entraîner, les plateformes citées ci-dessus proposent des entraînements où vous pouvez rejouer des concours de code passés par exemple. Un article a été rédigé sur ce sujet : Les concours de code / algo : je m’y mets ?

Pièges à éviter pour les recruteurs, correcteurs et opérationnels :

• Comme il s’agit souvent de tests à distance, une autre personne peut assister le candidat ou le faire à sa place…
• On peut dénicher des talents mais résoudre des algos ne fait pas tout dans le métier.
• A systématiser le test à tous les candidats, le coût peut très vite s’envoler.

 

Exercice de mise en situation

La mise en situation est le test le plus réaliste et qui donne les meilleurs résultats de réussite dans le poste. Il s’agit le plus souvent d’une petite application ou d’un jeu, minimaliste mais complet (de l’IHM à la BDD). Il est très souvent réalisé par le candidat chez lui.

Avantages :

• Matching maximal entre le test et les conditions de travail habituelles.
• Permet de voir comment le candidat code, résonne et fait des choix.
• Peut être réalisé par le candidat chez lui : il a moins de stress et les outils qu’il souhaite.

Inconvénients :

• Demande un investissement important au candidat, très souvent plusieurs heures.
• Très long à corriger et interpréter.

Pièges à éviter pour les candidats :

• Vouloir trop bien faire 🤯 et y passer des heures. A part pour des postes front, c’est le back-end qui est souvent scruté en détails.
• Avoir un code lisible et des noms explicites (variables, fonctions, fichiers et packages).
• Ne pas oublier d’ajouter des commentaires dans le code pour aider le correcteur.
• Ne pas chercher à ajouter des fonctionnalités non demandées, mais par exemple des tests unitaires ou des logs.

Pièges à éviter pour les recruteurs, correcteurs et opérationnels :

• Ce type de test en début de process peut rebuter les candidats 💨, surtout sur un marché pénurique. Ne pas sous-estimer le temps de réalisation, la principale erreur.
• Avoir une liste de critères sur lesquels le candidat sera évalué (ne pas oublier de la lui donner bien entendu !).
• Etre sûr que l’exercice a bien été compris et toujours laisser la possibilité de contacter l’opérationnel pour des questions.
• Cadrer un environnement technique dans lequel l’exercice doit fonctionner, sinon le correcteur aura du mal à reproduire l’environnement du candidat.
• Poser des questions sur les choix faits (d’architecture par exemple) pour être sûr que c’est bien le candidat qui a réalisé le test.
• Ne pas donner des bugs de votre application à résoudre (même s’ils sont simples) : le candidat ne connait pas votre organisation technique et environnement fonctionnel.

 

Echange entre pairs

Cet échange 🙌 vient approfondir et est complémentaire aux tests cités précédemment. Il vient dans un second temps, après une première sélection.

Avantages :

• Adaptable aux réponses et au profil du candidat : on peut poser toutes les questions pertinentes pour le poste et rebondir en fonction du niveau du candidat et de ses réponses.
• Permet de creuser les résultats/réponses des autres tests.
• Moins stressant pour le candidat qu’un exercice. L’échange « entre personnes techniques » est plus ouvert, légitime et bienveillant des 2 côtés.

Inconvénients :

• Objectivité de l’opérationnel dans l’évaluation du candidat.
• Chronophage en temps pour les opérationnels et difficultés à avoir toujours le même évaluateur.

Pièges à éviter pour les candidats :

• C’est la logique et les choix d’architectures/technos qui vont être évalués. Bien réviser les projets sur lesquels on pourrait vous interroger.
• Ne pas s’inventer des projets/compétences ou se sur-évaluer, au risque d’avoir des questions précises et être démasqué…
• Mieux vaut être franc quand on ne sait pas et dire ce que l’on ferait pour se renseigner.
• Si on a du mal à vendre ses compétences techniques, il est possible d’envoyer après l’échange un mail 📩 avec un résumé des anciens projets similaires et des compétences pour le poste.

Pièges à éviter pour les recruteurs, correcteurs et opérationnels :

• Très sensible aux différents biais cognitifs, comme un entretien de recrutement classique. Sauf que les recruteurs en sont conscients, les opérationnels moins.
• Ne pas se contenter des affirmations du candidat et poser des questions précises pour vérifier les dires et le niveau.
• Au téléphone, être vigilant au temps de réponses ou aux bruits du candidat (touches de clavier) qui peut chercher de l’aide sur le web en même temps qu’il répond.

 

Les tests techniques permettent souvent de révéler des « talents » qui n’ont pas les diplômes ou toutes les expériences requises. Mais il ne faut pas l’ériger comme l’indicateur ultime d’un recrutement. Le raccourci est trop rapidement fait entre la réussite à un test et le niveau d’ « intelligence » du candidat…

Même s’ils sont très efficaces (plus qu’une prise de référence par exemple), les tests techniques 💻 ne sont ni plus ni moins qu’un indicateur dans la prise de décision, au milieu de nombreux autres.

En tant que candidat 🧑, il faut être préparé aux différents types de tests, qui ont chacun leurs spécificités.

Et pour les recruteurs 👩‍💼, il faut savoir utiliser les bons tests, les concevoir et surtout les analyser. Ne pas tomber dans l’artisanal vite fait, sinon ils ne servent à rien…

Ce thème nous a été suggéré par Barbara, une de nos lectrices. Si vous aussi vous souhaitez que notre équipe traite un sujet particulier, c’est ici 👉 Contact !

Auteur : Sylvain Lareyre – Ancien dev et recruteur pour JobOpportunIT

Les photos viennent du site pexels