Pourquoi la majorité des entretiens techniques est inadaptée

Comment réaliser un bon test technique

Le problème actuel et ce qu’il ne faut pas faire

La plupart des tests techniques donnés aux candidats sont inadaptés. Une majorité de sociétés recrutent encore sur des aspects ayant peu de rapport avec leur mission. Très souvent, la réussite d’un candidat dépend plus de la chance que des compétences réelles.

Voici un petit florilège des pires pratiques actuelles et pourquoi ça ne fonctionne pas.

Le qcm

Le questionnaire à choix multiples est souvent orienté sur de la syntaxe ou des aspects précis d’un langage. C’est une des pires manières d’évaluer un candidat. En condition réelle, un développeur aura toujours accès à de la documentation ou à internet. De plus, juger un candidat sur sa connaissance des arcanes d’un langage est un très mauvais indicateur de ce qu’il est capable de réaliser.

Le petit exercice scolaire en temps limité

Malheureusement très courant, ça consiste à donner un exercice de “competitive programming”, de manière très scolaire. C’est-à-dire en temps (très) limité, avec des notions qu’un candidat n’utilise peut être plus, puisque les data structures et les algorithmes utilisés dépendent de la mission. En condition réelle, le candidat se remettrait simplement à jour. C’est très utilisé car ça ne coûte pas cher à donner, il suffit d’aller piocher un ou deux exercices sur des sites dédiés.

Il y a deux problèmes majeurs avec ce genre d’exercice.

Le type d’exercice: Le petit exercice qui demande à connaître des astuces sur le bout des doigts (parcours de graphe, récursion, combinatoire, dynamic programming, etc…), va plus loin que simplement en connaître leur existence. C’est un type d’exercice qui demande des révisions spécifiques. Un candidat, ça fait des années qu’il fait autre chose (architecture, gros composant, solution from scratch, étude de cas, intégration de composants, formation de junior, etc…). Donc réviser quelque chose qu’il ne fait jamais et ne fera plus jamais après l’entretien, c’est assez éloigné de la réalité. C’est comme demander à un médecin, au pied levé, de faire un exercice d’asymptote en moins de 5 min. Ça ne dit rien de ses compétences et ça teste complètement autre chose (qu’il réussisse ou non l’exercice ne démontre pas ses capacités à exercer la médecine).

Les contraintes: souvent, ce n’est pas un problème de difficulté, un candidat fera l’exercice sans problème (si on lui laisse le temps de regarder la doc, se remémorer ses algos, etc…), mais le temps extrêmement court, allié au stress de le faire rapidement, est complètement inadapté. C’est un type d’exercice qu’on fait en sortie d’école, et qui est plus simple à faire par un étudiant qui est “encore dans le bain”. Ici, c’est l’équivalent de juger un boulanger à la vitesse à laquelle il pétrie une pâte. C’est assez loin d’une situation réelle, où le temps est bien plus malléable. Dans la vie réelle, une deadline courte peut toujours se compenser par des heures supplémentaires (ou plus de ressources), on peut “créer du temps” et ne jamais vraiment être dans cette situation (on parle vraiment ici d’une situation extrême, style “sablier”, où on voit le temps défiler).

C’est à cause de ce type d’exercice qu’on se retrouve dans une situation hypocrite où les candidats doivent réviser spécifiquement pour ce genre d’exercice qu’ils ne referont plus jamais pendant plusieurs années avant leur prochain entretien. Avec ce type d’exercice, on ne fait que juger la capacité d’un candidat à passer un exercice d’entretien, mais pas sa capacité à être bon dans son futur travail.

Le live coding ou tableau blanc

Ce type d’exercice consiste à donner un petit exercice scolaire mais sur un tableau blanc (ou dans un fichier texte partagé en ligne). Ce sont les mêmes problèmes que pour le petit exercice scolaire, mais en plus exacerbés. En plus d’avoir tous les défauts du précédent point, on ajoute encore des difficultés inutiles: pas de coloration syntaxique, pas de compilateur, aucun moyen de tester ce que l’on fait, aucun temps de réflexion puisqu’il faut parler pendant qu’on réfléchit, …

Il faut ajouter à cela, qu’il est difficile d’avoir la solution du premier coup (surtout avec le stress). En condition réelle, il arrive souvent qu’on tâtonne. Or, comme il est demandé de parler en permanence pour décrire son cheminement de penser, il arrive que l’on doive expliquer une voire plusieurs solutions fausses. Normalement ce n’est pas un souci, puisque seul le résultat final compte. Avec ce genre d’exercice, explorer trop de pistes avant d’avoir la solution sera mal vu.

État de l’art

La grande majorité des sociétés ne s’est pas réellement penchée sur cet aspect du recrutement. On est dans une situation un peu kafkaïenne, où les sociétés reprennent ces types de tests sans autre raison que “si les autres font comme ça, faisons nous aussi comme ça”. Les candidats sont jugés sur des compétences parallèles à leur mission, et par chance, s’ils sont aussi bons dans leur domaine, ça “tombera en marche”, tout en donnant le biais que le processus était adapté. Si le candidat réussit le test, mais n’est pas bon dans son travail, on se dira juste que c’est la faute du candidat, sans remettre en question le test de recrutement. En plus de cela, un candidat “moyen”" dans son travail est souvent gardé, augmentant encore le biais de réussite.

Les entretiens techniques actuels sont plus proches du “lancer de pièce” qu’autre chose…

Même un développeur senior avec beaucoup de talent doit passer des semaines de
travail pour espérer avoir une chance à ces entretiens. Peu importe d’où tu
viens ou ce que tu as accompli. T’as oublié l’algorithme du parcours en
profondeur ? Ça dégage !

Et il est là le problème. Cette « double compétence » doit être maintenue ou
rattrapée avant tout entretien technique. C’est quand la dernière fois que tu as
inversé un arbre binaire au boulot ? Pourtant si tu sais pas le faire de tête en
entretien technique, t’es nul.

Le boulot de tous les jours de développeur ne te prépare pas à ce type
d’entretiens techniques qui se démocratisent. C’est absurde.


             Tiré de `L’entretien technique est une compétence à part entière`

Quelques ressources sur ce problème:

Comment réaliser un vrai test technique

Il existe de meilleures solutions pour juger un candidat, mais ça demande de prendre du temps et de donner au candidat les moyens de montrer ce qu’il sait faire.

Portfolio

Tout d’abord s’intéresser à son passif. Plutôt que d’essayer de deviner ce qu’un candidat est capable de faire, il suffit simplement de s’intéresser à ce qu’il a déjà réalisé. Un junior aura des projets personnels ou des projets d’écoles, un sénior aura des projets professionnels marquants.

Cette étape ne devrait pas être superficielle. Il faut creuser et “challenger” le candidat. Pourquoi a-t-il pris ces décisions ? Peut-il expliquer son architecture ? Quelles sont les problèmes rencontrés et comment il les a résolus ?

Il est aussi envisageable de demander au candidat de venir présenter un projet complexe dont il est fier, afin d’en discuter (même s’il ne peut pas montrer de code, il doit pouvoir en parler).

C’est une étape cruciale qui permet, mieux que n’importe quel autre exercice, d’évaluer les capacités d’un candidat.

Dépôt de code

Un candidat sérieux a forcément déjà programmé, et a donc certainement du code sur un dépôt qu’il peut partager. Lui demander d’accéder à ce qu’il a déjà codé, c’est une bonne manière de rapidement voir comment il code, et s’il a déjà réalisé des projets complexes.

Test technique

Le portfolio et les codes partagés devraient être suffisants, mais si un doute subsiste, il est tentant de vouloir tester un candidat avec un projet. La meilleure façon de tester un candidat c’est de le mettre en situation réelle.

Pour cela, il suffit de tester un candidat sur ce qu’il fera dans l’entreprise directement. Si celui-ci est capable de réaliser un produit qui lui aurait été demandé s’il avait été embauché, alors c’est qu’il sera capable d’intégrer la société sans problème. A contrario, s’il n’est pas en mesure de le réaliser, le candidat ne sera pas pris pour des raisons indiscutables, qu’il comprendra immédiatement, et acceptera. C’est très pragmatique et ça permet aux deux parties de se mettre d’accord sans frustration. En revanche, ça nécessite un peu plus de préparation (surtout au début, après on peut réutiliser le ou les tests).

Il ne faut pas avoir peur de donner un test qui dure plusieurs heures, voire plusieurs jours. Un très bon test, serait de demander à réimplementer un composant existant, en fournissant un cahier des charges.

Ce test, en plus de détecter si le candidat est apte techniquement, permet aussi de voir les “à côtés”. C’est-à-dire: la présence de tests unitaires, de commentaires, de documentation, de bench, le soin apporté aux finitions, la structure et la propreté du code, les choix architecturaux, etc…

Le seul défaut de ce genre de test, est qu’il faut soigneusement le préparer et ça prend du temps.

Test d’architecture (pour un sénior)

La différence majeure entre un sénior et un junior, c’est l’expérience (savoir ce qui fonctionne ou non, trouver des points de contentions, savoir ce qui “scale” ou pas, analyser un produit sous-jacent pour trouver une solution produit qui peut être meilleure qu’une solution algorithmique, etc…) et sa capacité à architecturer (concevoir un système complexe de composants). On ne recrute pas un sénior comme on recrute un junior. Un sénior sait coder, et ce qu’il faut tester c’est capacité à créer des systèmes complexes.

On peut le tester via une étude de cas, en lui soumettant un projet fictif et lui demander de dessiner et justifier l’architecture, et les composants qu’il utiliserait.

On peut aussi lui demander de critiquer, comprendre et améliorer l’existant (tant niveau produit que technique). On peut rapidement créer un débat d’idées, et avoir des questions et des interrogations sur le choix actuel. Le candidat peut alors essayer de deviner les contraintes invisibles qui ont poussées à des choix non optimaux (manque de temps, manque de moyen, absence de technologie disponible à l’époque, dette technique, etc…).

Conclusion

J’ai plus souvent été amené à être du côté du recruteur que du recruté, et en passant du côté des candidats, je me suis aperçu que la situation était assez catastrophique. La grande majorité des entretiens techniques sont sur le même (mauvais) modèle. Les candidats sont sélectionnés sur des critères hors sujets et ça les oblige a acquérir une seconde compétence inutile dans leur futur travail: apprendre à réaliser des petits exercices scolaire en temps très court.

Si vous êtes recruteur et que vous passez par là, voici un document que j’ai écrit lorsque j’étais moi même recruteur pour normaliser les processus de recrutement et éviter ce genre de situation ubuesque:
Backend interview (En anglais).