Welcome here! | Articles | Main projects | About me
(FR) EXPRESS #3 - Un bon test technique, c’est quoi ?
Note importante
Cet article fait partie de la série “EXPRESS”. Il s’agit d’une série d’articles relativement courts et moins formels, axés autour d’un point sur lequel je ne me voyais pas écrire un article complet. Le ton y est volontairement plus léger afin d’en faciliter la lecture (et l’écriture !).
Bonjour !
Si vous êtes ici, c’est que vous avez lu la note en début de page (a priori juste au-dessus), et que vous ne vous attendez par conséquent pas à un article très formel comme ce que j’ai l’habitude de publier sur ce blog.
Introduction
Dans un processus de recrutement, il y a dans la plupart des cas une évaluation technique. Elle peut avoir différentes formes, mais a toujours le même but : jauger le niveau d’un candidat. Bien souvent, la personne en face de vous n’a pas les connaissances techniques nécessaires, et c’est tout à fait normal. Ainsi, votre interlocuteur passera par un test rédigé par des personnes ayant un profil plus technique.
Avant d’aborder le “bon” test technique, je souhaiterais parler de ce que je pense être un mauvais test technique. J’en distingue plusieurs cas. Avant toute chose, posons-nous les bonnes questions : que veut-on évaluer ? Veut-on un candidat qui connait un langage du bout des doigts ? Ou plutôt un profil qui, à défaut de connaître un langage par coeur, va exercer sa logique ?
Enfin, je rappelle que j’emploierai un ton plus léger qu’à l’accoutumée, ainsi vous risquez de lire çà et là quelques expressions familières.
Cas n° 1 : le faux test
Le premier cas est ce que je considère être un “faux” test, j’ai nommé le QCM. Pour être tout à fait honnête, il s’agit à mon sens d’une vaste farce, qui n’évalue en rien les compétences concrètes d’un candidat. Il n’est absolument PAS viable de se baser sur un test au résultat potentiellement aléatoire pour déterminer si un profil correspond ou non à son besoin.
En effet, même sans réellement connaître la réponse à une question donnée, on peut répondre au pif et s’en sortir. De plus, de bêtes questions ne sont jamais pertinentes face à un exercice concret.
Cas n°2 : le test sur papier
Je vais parler ici d’un exemple parmi les plus idiots qu’il m’ait été donné de rencontrer : coder sur papier. En plus de ne pas refléter votre potentiel environnement de travail (du moins je l’espère pour vous), le test papier nécessite :
- De connaître un langage par coeur ;
- De connaître potentiellement un framework par coeur ;
- De ne faire aucune faute (on ne peut ni déboguer ni modifier ce que l’on a écrit !).
Il s’agit sans l’ombre d’un doute du pire type de test possible à mes yeux, à la fois pour le candidat, mais également pour le recruteur, qui fait perdre pas mal de crédibilité à son entreprise.
Rien ne vaut un test concret, avec de vrais outils et un environnement de travail viable.
Cas n°3 : le test chronométré
Note : Par “test chronométré”, j’entends “coder quelque chose seul sur un outil en ligne en un temps imparti”. Seulement, ça faisait un peu long comme titre.
Attention, je rappelle que cela correspond à mon avis personnel ; tout le monde n’a pas le même ressenti vis-à-vis de ce type de test.
Puisque l’on parle de test concret, nous y voilà. Votre interlocuteur ne vous a proposé ni QCM, ni test sur papier. Bingo ! Ou presque. À la place, vous devez coder quelque chose en 45 minutes, en une heure, ou autre ! Seulement, tous les candidats ne réagissent pas de la même manière face au stress d’un test chronométré. Quel intérêt d’avoir un chronomètre quand on code ? Cela ressemble-t-il à une mise en situation réaliste ? De plus, cela nous force à bâcler, et à produire pour produire. Le résultat ne sera que rarement un code dont nous pourrions être fiers et dont nous pourrons solidement défendre les choix techniques.
Un bon code, ça prend du temps. Point.
Du coup, un bon test, c’est quoi ?
À mon sens, la piste du mini projet à faire -sans chronomètre- est la meilleure option. Que ce soit chez soi ou en live face à un ou plusieurs développeurs, l’intérêt de l’exercice réside avant tout dans les échanges après (ou pendant) l’exercice, entre candidat et développeurs. En effet, des échanges techniques sont une garantie de l’honnêteté du candidat, là où un bête score ne prouve rien.
Une autre alternative est la mise en situation face à une portion de code où l’on doit expliquer pourquoi on validerait (ou non) ce code dans une merge request. L’idée est de tester les connaissances du candidat, aussi bien au niveau du langage que des bonnes pratiques en programmation.
Ces deux méthodes permettent de tester de manière fiable les connaissances et la logique d’un candidat, tandis qu’un test noté sur une plateforme en ligne n’a -à mon sens- aucun intérêt.