Live coding ou exercice à rendre : comment aborder un test de code en recrutement IT, gérer votre temps, expliquer vos choix et livrer un travail soigné.
Le test de code fait aujourd'hui partie de la plupart des recrutements de développeurs, et il s'étend aux profils data, DevOps ou test. Il impressionne parce qu'il ressemble à un examen où la moindre erreur serait éliminatoire. En réalité, l'évaluateur regarde surtout votre manière de travailler. Voici comment aborder les deux grands formats sans vous laisser piéger par le stress.
Live coding, exercice à la maison, plateforme en ligne : trois logiques
- Le live coding : vous codez en direct, en partageant votre écran ou dans un éditeur en ligne, face à un ou deux développeurs. Le temps est court et le problème ciblé. On évalue votre raisonnement et votre communication autant que le résultat.
- L'exercice à la maison : vous recevez un sujet, souvent une petite application ou une API, à rendre dans un délai fixé. On évalue la qualité du code, l'organisation du projet et vos choix techniques.
- Le test sur plateforme en ligne : des exercices algorithmiques chronométrés, corrigés automatiquement. On évalue surtout la justesse et la gestion des cas limites.
Dès l'invitation, demandez quel format vous attend, sa durée, si le langage est imposé ou libre, et si la documentation ou un assistant de code sont autorisés. Ces questions sont normales et montrent que vous prenez l'exercice au sérieux.
Se préparer sans apprendre des solutions par cœur
Mémoriser des corrigés sert peu : l'exercice proposé sera rarement identique, et l'évaluateur s'intéresse justement à la façon dont vous adaptez votre approche. Travaillez plutôt vos réflexes :
- choisissez un langage que vous maîtrisez vraiment quand le choix est libre, plutôt que celui qui vous semble le plus valorisé ;
- revoyez les structures de données courantes (tableaux, dictionnaires, ensembles, piles, files) et les situations où chacune s'impose ;
- pratiquez de petits exercices en vous chronométrant et en parlant à voix haute, même seul devant votre écran ;
- prenez l'habitude d'écrire des tests rapides, que beaucoup de candidats oublient sous la pression ;
- préparez votre environnement : éditeur configuré, projet vide prêt à lancer, raccourcis familiers.
Le live coding, étape par étape
La tentation est de commencer à taper immédiatement. Résistez. Une démarche structurée rassure l'évaluateur et vous évite de partir dans la mauvaise direction.
- Reformulez le problème avec vos mots et vérifiez que vous l'avez bien compris.
- Posez des questions sur les entrées : taille des données, valeurs vides, doublons, nombres négatifs, format attendu en sortie.
- Prenez un ou deux exemples et déroulez-les à la main.
- Annoncez une première solution simple, même peu performante, et codez-la.
- Testez-la sur vos exemples, puis sur un cas limite.
- Améliorez-la si le temps le permet, en expliquant ce que vous gagnez.
Tout au long de l'exercice, commentez ce que vous faites. Quelques phrases qui aident à garder le fil :
« Je vais d'abord écrire une version simple qui parcourt toute la liste, puis nous verrons comment l'optimiser. »
« Ici, je suppose que la liste n'est jamais vide. Est-ce une hypothèse acceptable ? »
« Cette version fonctionne, mais elle parcourt les données deux fois. Avec un dictionnaire, je peux le faire en un seul passage. »
Si l'on vous parle de complexité, exprimez-la simplement : combien de fois votre code parcourt-il les données, et que se passe-t-il quand leur volume augmente fortement ?
Quand vous bloquez
Le blocage fait partie de l'exercice ; c'est votre réaction qui compte. Dites où vous en êtes : « Je bloque sur la gestion des doublons. » Revenez à un exemple concret et déroulez-le pas à pas. Si l'évaluateur vous propose une indication, acceptez-la et rebondissez dessus : savoir exploiter une piste donnée par un collègue est une compétence recherchée. Le silence prolongé, lui, ne permet ni de vous aider ni de vous évaluer.
Si le temps se termine avant la fin, expliquez ce qu'il resterait à faire et comment vous vous y prendriez. Une solution inachevée mais bien expliquée laisse souvent une meilleure impression qu'une solution complète écrite en silence.
L'exercice à la maison : rendre un projet qu'on a envie de lire
Ici, vous disposez de temps, et c'est justement ce qui rend l'évaluation plus exigeante sur la forme. La personne qui ouvrira votre projet doit pouvoir le comprendre et le lancer en quelques minutes. Avant d'envoyer, passez cette checklist :
- le projet se lance avec les instructions fournies, sur une machine qui ne l'a jamais exécuté ;
- un fichier README explique l'installation, le lancement, les tests et vos choix ;
- le code est organisé en modules ou en couches cohérents, avec des noms explicites ;
- les cas d'erreur sont gérés : entrée invalide, ressource introuvable, service indisponible ;
- quelques tests couvrent la logique principale ;
- l'historique Git raconte votre progression, avec des messages de commit lisibles ;
- aucun mot de passe, aucune clé d'API ni aucun fichier inutile ne traîne dans le dépôt.
La partie la plus sous-estimée est la section du README consacrée aux choix. Elle vous permet de dire ce que vous auriez fait avec plus de temps, sans que cela passe pour un oubli. Par exemple :
« Choix techniques : j'ai utilisé SQLite pour simplifier l'installation ; en production, je passerais à PostgreSQL. La pagination n'est pas implémentée, faute de temps. Prochaines étapes : authentification et tests d'intégration sur l'API. Temps passé : environ une journée. »
Respectez le périmètre demandé. Trois fonctionnalités bonus ne compensent pas un point du sujet traité à moitié. Si le sujet vous paraît démesuré par rapport au délai, demandez au recruteur ce qu'il attend en priorité : la question est légitime. Et si vous utilisez un assistant de code alors qu'il est autorisé, soyez capable d'expliquer chaque ligne, car l'entretien de restitution qui suit souvent l'exercice portera précisément sur vos choix.
Les erreurs qui coûtent le plus cher
- Coder avant d'avoir compris le sujet.
- Ignorer les cas limites : liste vide, valeur nulle, entrée très volumineuse.
- Viser d'emblée la solution optimale et ne rien terminer.
- Rendre un projet qui ne se lance pas.
- Reprendre une solution trouvée en ligne sans pouvoir l'expliquer.
- Se braquer quand l'évaluateur signale un bug, au lieu de l'analyser avec lui.
Après le test, quel que soit le résultat
Notez le sujet, ce qui vous a ralenti et ce que vous feriez autrement. En cas de réponse négative, demandez poliment un retour sur votre travail : tous les recruteurs ne le donnent pas, mais lorsqu'ils le font, c'est l'information la plus utile pour progresser. Chaque test passé rend le suivant plus facile, parce que vous connaissez mieux vos propres réflexes sous pression.
Avant votre prochain test, retenez cinq gestes : clarifier le format, vous entraîner à voix haute, reformuler avant de coder, tester votre solution et soigner le README d'un exercice à rendre. Pour repérer les postes qui vous intéressent, parcourez les offres en développement logiciel ou en full stack JavaScript, puis créez votre compte candidat pour recevoir les nouvelles annonces par alerte e-mail.