Pour sélectionner un développeur compétent, les tests de code sont-ils efficaces comme outils de recrutement ?

Des tests souvent trop prévisibles

Demander à des développeurs d'effectuer une tâche telle que l'écriture d'un algorithme pour trier une liste est peu efficace comme test de recrutement.

La solution peut être facilement mémorisée à l'avance et donc le test n'offre aucun aperçu des compétences d'un candidat autre que sa force de mémorisation. Ce serait aussi absurde que de demander le code ASCII du caractère "A" pour sélectionner le bon candidat qui saura travailler sur un projet informatique.

Les solutions détaillées à de nombreux exercices utilisés dans les tests d’embauche sont largement disponibles en ligne, ou dans des livres spécifiques.

-Témoignage d’un développeur :

« Alors que je travaillais pour une entreprise, j'ai parlé avec un collègue du processus d'entretien d’embauche qu'il avait passé pour travailler dans ce grand fond d’investissement. Il avait soigneusement mémorisé toutes les questions techniques qu'ils allaient lui poser. Un employé embauché auparavant avait publié toutes les questions d'entretien à l’avance. »

« C’était un ingénieur qualifié pour le poste, mais il avait accepté de se soumettre à cet exercice franchement monotone et banal pour obtenir le poste. Il n'aurait pas dû avoir à faire cela - non seulement c'était une perte de son temps précieux, mais cela n'a rien donné à l'entreprise qui l'a engagé pour vérifier ses compétences. »

« Il est parti un an plus tard, fatigué de leur faible niveau intellectuel et de leurs pratiques de gestion de projet continuellement inefficaces... »

Un bon développeur n’a pas à connaître dans le détail les nuances syntaxiques

Aucun développeur travaillant dans le monde réel n'écrirait une section de code sans une aide à la vérification de la syntaxe (telle que la complétion de code intégrée par un éditeur), sans se référer à une documentation technique ou sans simplement copier une solution déjà mise en œuvre, si elle existe déjà. Il n'y a pas de sens à réinventer la roue.

-Témoignage d’un développeur :

« En pratique, travailler avec la syntaxe d'un langage de programmation particulier est une question d'usage et de familiarité. Alors qu'un recruteur peut penser que tester un candidat sur les nuances syntaxiques d'un langage particulier est un indicateur de sa compréhension, je peux, par exemple, affirmer catégoriquement que bien que j'utilise le langage C depuis près de trente ans, je me trompe encore régulièrement dans la syntaxe. »

« En fait, au fur et à mesure que ma carrière d'ingénieur logiciel a évolué et que je me suis familiarisé avec les langages qui m'intéressent, je confonds régulièrement les nuances syntaxiques du C et du C++, par exemple, ou de l'Objective-C. Ce n'est pas parce que je suis un terrible développeur (bien que certains puissent ne pas être d'accord...) mais parce qu'il y a une limite aux connaissances que vous pouvez avoir en tête et dont vous pouvez vous souvenir directement à tout moment. » Souvent, un bon ingénieur en logiciel ne connaît pas la réponse à une question spécifique de prime abord, mais il saura certainement où chercher pour trouver la réponse.

Peut-être envisagez-vous de demander le meilleur endroit où trouver des informations comme une question pour un entretien d’embauche ?

Les tâches courantes en informatique

Un point que j'ai brièvement abordé plus tôt est de ne pas réinventer la roue. Par exemple, si vous travaillez en C et que vous avez besoin d'un code de gestion de port série, vous n'avez pas besoin d'en réécrire un à partir de zéro, à moins que la situation ne l'exige spécifiquement. Vous avez peut-être besoin d'un parser JSON, une exigence très courante, vous devriez alors simplement en tirer un pré-écrit à partir d'une bibliothèque. Il y a de fortes chances qu'il soit utilisé depuis longtemps, qu'il ait été entièrement testé et qu'il dispose d'une documentation détaillée (et correcte).

Il est peu probable qu’un développeur trouve une tâche courante qui n'a pas déjà été automatisée dans une bibliothèque pré-écrite ou dont la mise en œuvre n'est pas largement disponible sous forme algorithmique. Si vous êtes comme moi, alors vous implémentez des choses qui ont été implémentées auparavant.

En fait, le concept de développement informatique a déjà été comparé à celui « d'archéologue du code », où un développeur réutilise principalement le code existant et passe relativement peu de temps à concevoir et à coder des algorithmes nouveaux et inédits.

Savoir discuter

Une simple discussion sur la question de savoir si un langage particulier serait un bon choix pour une implémentation spécifique, ou si une méthodologie particulière de génie logiciel (agile par exemple) est pertinente ou non, sont des sujets de discussion bien plus enrichissants au cours d’un entretien d’embauche.

Dirigez la discussion pour mettre en évidence les notions générales, et essayez de voir quelle est la perspicacité du candidat face à de nouveaux problèmes. Comment voit-il les choses évoluer, comment commencerait-il à s'attaquer à un projet. Restez ouvert, ne vous attardez pas sur les détails et les particularités.

-Témoignage d’un développeur :

« La clé, c'est de discuter. La détermination de la valeur ne se limite pas à cocher des cases et je suis sans cesse surpris de constater que de nombreuses entreprises considérées comme "prometteuses" et "leaders dans leur domaine" se rabattent encore sur des pratiques d'embauche dépassées, monotones et totalement prévisibles qui ne permettent guère d'évaluer le véritable savoir-faire technique. »

« On dit souvent que la personne interrogée doit interroger l'entreprise tout autant que l'entreprise l'interroge. Je suis tout à fait d'accord avec cette idée. »

Passé un entretien d’embauche avec quelqu'un qui a une liste de questions techniques précises est presque toujours un signal d'alarme. Cela montre souvent que le recruteur peut ne pas comprendre entièrement ce qu'il demande et que donc toute réponse qui ne correspond pas précisément à ce qui est écrit sur son scénario sera classée comme incorrecte. Certaines entreprises ont adopté de meilleures méthodes, mais d'autres sont loin d'avoir atteint leur but.

Des entreprises demandent ainsi que des projets de plusieurs jours soient réalisés par des candidats. C’est abusif, car le temps c’est de l’argent.

D'autres ont des "tests d'aptitude" génériques, avec des questions à choix multiples (QCM) à cocher dans un court espace de temps.

Cela ne vaudra jamais une discussion avec un recruteur qualifié sur le plan technique.