Test technique développeur : réussir le live coding et le devoir à la maison
· 9 min
Le test technique est l'étape qui élimine le plus de développeurs — rarement parce qu'ils ne savent pas coder, souvent parce qu'ils codent comme si personne ne regardait. Or quelqu'un regarde, et ce qu'il note n'est pas ce que vous croyez.
Qu'observe réellement l'examinateur pendant un live coding ?
Pas la solution : le chemin. Est-ce que vous clarifiez l'énoncé avant de taper ? Est-ce que vous annoncez votre approche ? Est-ce que vous testez au fur et à mesure ou à la fin ? Est-ce que vous reconnaissez une impasse au bout de deux minutes ou au bout de quinze ? La plupart de ces signaux se produisent avant la première ligne de code.
Faut-il commencer par poser des questions ?
Oui, et c'est souvent noté explicitement. Un énoncé de test technique est volontairement incomplet : taille des données, cas limites, contraintes de performance. Foncer sans demander revient à livrer une fonctionnalité sans avoir lu la spécification. Deux ou trois questions précises suffisent — au-delà, on bascule dans l'évitement.
Que faire quand vous bloquez au milieu de l’exercice ?
- Dites-le. Le silence est bien pire que l'aveu : l'examinateur ne sait plus s'il assiste à une réflexion ou à une panne.
- Reformulez où vous en êtes et ce qui coince précisément. La moitié du temps, la reformulation débloque.
- Proposez une solution naïve qui marche, quitte à l'améliorer ensuite. Un algorithme lent mais correct vaut mieux qu'un algorithme élégant inachevé.
- Acceptez les indices. Les refuser par fierté coûte plus cher que de les prendre : la capacité à collaborer fait partie de la note.
Le devoir à la maison : jusqu’où faut-il aller ?
Jusqu'à ce que le périmètre demandé soit propre, et pas plus loin. Le piège est de vouloir impressionner : ajouter une couche d'abstraction, un conteneur, une intégration continue pour un exercice de deux heures. Cela produit l'effet inverse — on en conclut que vous sur-concevez, ce qui est un défaut coûteux en équipe. Livrez le périmètre demandé, testé, avec un fichier expliquant vos choix et ce que vous auriez fait avec plus de temps.
Le temps annoncé est-il à respecter ?
Respectez-le, et dites-le si vous l'avez dépassé. Un exercice « deux heures » rendu après huit heures de travail fausse l'évaluation, et la différence se voit dans le code. Écrire « j'ai passé trois heures, voici ce que j'ai laissé de côté » est mieux reçu qu'un rendu impeccable dont l'examinateur devine le coût réel.
Que faire si le test porte sur une technologie que vous ne maîtrisez pas ?
Demandez si vous pouvez utiliser un autre langage : c'est accepté plus souvent qu'on ne le croit, car ce qu'on évalue est le raisonnement. Si ce n'est pas possible, annoncez votre niveau réel avant de commencer. Un candidat qui prévient et s'en sort à peu près est mieux noté qu'un candidat qui se tait et échoue sans explication.
On ne recrute pas un développeur pour les problèmes qu'il a déjà résolus. On le recrute pour ceux qu'il n'a pas encore vus — et le test technique est là pour observer ça.
Ce test ne remplace pas l'entretien lui-même : les questions classiques restent à préparer, et nous les détaillons dans entretien développeur. Voyez aussi la méthode STAR pour raconter vos projets sans vous perdre.