Quarante-cinq minutes, un éditeur partagé, un inconnu qui observe chaque frappe et un problème jamais vu : inverser une liste chaînée, trouver le sous-tableau de somme maximale. Pas de documentation, pas de recherche, parfois même pas d'autocomplétion. Et en plus, on vous demande de "penser à voix haute". C'est le live coding, et dans beaucoup de processus de recrutement, c'est encore le moment qui décide de tout.
J'y suis opposé. Pas parce que c'est difficile, mais parce que cela mesure la mauvaise chose. J'ai fait des entretiens des deux côtés de la table, et dans un autre article j'ai expliqué comment je changerais les questions techniques à l'ère de l'IA. Ici, je vais droit au but : pourquoi le live coding classique ne fonctionne pas, ce que je concède à ceux qui le défendent et ce que je ferais à la place.
De quel live coding je parle
D'abord, une distinction. Je suis contre l'exercice algorithmique chronométré, observé en direct, sans outils, sur un problème sans rapport avec le poste, dont le résultat décide à lui seul si vous passez à l'étape suivante. Je ne suis pas contre le fait de travailler avec un candidat sur une tâche réaliste, avec documentation et outils à disposition, pour voir comment il raisonne. Cela ressemble à la même chose, mais ce n'en est pas une : j'y reviens à la fin.
Il mesure le stress, pas la compétence
Ce n'est pas qu'une impression. En 2020, des chercheurs de la North Carolina State University et de Microsoft ont publié une étude contrôlée menée auprès de 48 étudiants en informatique : la moitié a résolu un problème au tableau devant un recruteur, l'autre moitié seule, dans une salle privée. Ceux qui étaient observés ont obtenu des résultats plus de deux fois moins bons. Les auteurs soulignent que le format ressemble de manière troublante au Trier Social Stress Test, un protocole utilisé en psychologie précisément pour provoquer du stress.
L'étude est petite et menée sur des étudiants, je ne la prends donc pas pour une loi. Mais elle confirme ce que connaît bien toute personne qui a passé un entretien : sous observation, la mémoire de travail se rétrécit, on perd le fil, on commet des erreurs banales qu'on ne ferait jamais en temps normal. Le résultat ne répond pas à la question "sait-il programmer ?", mais à une autre : "programme-t-il bien pendant que quelqu'un le juge en direct ?". Et dans le vrai travail, cette situation n'existe pas.
Le vrai travail ne ressemble pas à un live coding
| En live coding | Dans le vrai travail |
|---|---|
| 45 minutes pour un problème jamais vu | Des heures ou des jours, avec le temps de comprendre le problème |
| Ni documentation ni recherche | Documentation, recherche et exemples toujours ouverts |
| Assistant IA interdit | Assistant IA dans l'éditeur, tous les jours |
| Un inconnu qui observe chaque frappe | De la concentration, et la review vient après |
| Des algorithmes de manuel | Lire du code existant, intégrer des API, corriger des bugs |
| Ce qui compte, c'est d'arriver à une solution | Ce qui compte, c'est la lisibilité, les tests et la maintenance dans le temps |
La personne recrutée passera ses journées à lire du code écrit par d'autres, à choisir une bibliothèque, à comprendre pourquoi un test échoue seulement en CI. L'évaluer sur sa capacité à implémenter de mémoire un algorithme, en une demi-heure et sous le regard de quelqu'un, revient à mesurer une compétence qu'elle utilisera rarement, dans des conditions où elle ne travaillera jamais.
Il récompense ceux qui s'entraînent au format, pas ceux qui travaillent bien
Le live coding algorithmique est devenu une discipline à part entière, avec des plateformes, des cours et des centaines d'exercices à répéter jusqu'à les reconnaître au premier coup d'œil. Ceux qui ont des semaines libres pour s'entraîner arrivent préparés. Ceux qui travaillent à temps plein, ont une famille ou passent simplement leur temps à construire de vrais logiciels plutôt qu'à résoudre des casse-têtes partent avec un handicap. Au final, l'entretien sélectionne surtout la préparation à l'entretien.
Et il pénalise systématiquement certaines personnes : celles qui souffrent d'anxiété, celles qui sont neuroatypiques, celles qui passent l'entretien dans une langue qui n'est pas la leur et doivent penser à voix haute tout en traduisant dans leur tête. Rien de tout cela ne dit quoi que ce soit sur la façon dont cette personne écrira du code dans une équipe.
Il coûte aussi à l'entreprise
On parle généralement du candidat, beaucoup moins de l'entreprise. Chaque faux négatif est un développeur compétent écarté parce qu'il a bloqué pendant dix minutes. Et les profils expérimentés qui ont d'autres options évitent souvent complètement les processus avec live coding : l'entreprise ne voit même pas ces candidats.
Il y a aussi un effet moins visible. En observant quelqu'un sous pression, le recruteur finit par juger l'assurance plus que le fond : celui qui parle avec aisance paraît meilleur que celui qui se tait et réfléchit. C'est un biais présent dans tout entretien, mais ce format l'amplifie.
Ce que je concède à ceux qui le défendent
- Vérifier qu'une personne sait vraiment programmer est légitime. Un CV peut être gonflé, et aujourd'hui même un exercice à faire chez soi peut être résolu par une IA.
- Les longs exercices à la maison ont un coût réel : des heures de travail non rémunéré, souvent disproportionnées par rapport au poste.
- Le live coding est peu coûteux et uniforme : le même exercice pour tout le monde, une heure et c'est fini.
Ce sont des objections sérieuses. Mais la réponse à "nous devons vérifier les compétences" ne peut pas être un format qui les mesure mal. Il faut un format qui vérifie la même chose sans la partie qui fausse le résultat.
Ce que je ferais à la place
- Une code review de vrai code. Un extrait plausible, avec un bug et quelques choix discutables, à commenter comme s'il s'agissait de la pull request d'un collègue. On voit tout de suite qui comprend le code, et personne n'a à écrire sous la dictée.
- Le projet du candidat. Un dépôt, un travail précédent, un projet personnel : "expliquez-moi ce choix", "que changeriez-vous aujourd'hui ?". Une expérience vécue résiste à cinq questions d'approfondissement ; une histoire apprise par cœur s'effondre à la deuxième.
- Une tâche courte à la maison, suivie d'une discussion. Deux ou trois heures maximum, rémunérées si possible, puis une conversation où le candidat explique et modifie sa propre solution. Si une IA l'a écrite et qu'il ne la comprend pas, quelques minutes de questions suffisent pour s'en apercevoir.
- Du pair programming sur une tâche réaliste. Si l'on veut vraiment voir quelqu'un écrire du code : un petit dépôt réel, documentation et IA autorisées, aucun chronomètre sur le résultat. Le recruteur travaille avec le candidat au lieu de le surveiller.
- Une session de débogage. Un test qui échoue et le temps de comprendre pourquoi : c'est ce qui se rapproche le plus d'une journée de travail normale.
Si le live coding reste, au moins comme ceci
Je comprends que toutes les entreprises ne changent pas leur processus du jour au lendemain. Si le live coding reste, quelques règles minimales le rendent moins injuste :
- communiquer à l'avance le format, la durée et le langage ;
- choisir un problème lié au poste, pas un casse-tête de manuel ;
- autoriser la documentation et la recherche, comme lors de n'importe quelle journée normale ;
- évaluer le raisonnement, pas seulement le résultat final ;
- laisser au candidat quelques minutes pour lire et réfléchir en silence avant de lui demander de parler.
Et si le candidat, c'est vous
Vous pouvez demander, poliment, une alternative : une code review, la discussion de l'un de vos projets, une courte tâche à faire chez vous. Toutes les entreprises n'accepteront pas, mais demander ne coûte rien. Et la réponse en dit déjà long sur leur façon de travailler : une entreprise qui ne sait pas expliquer pourquoi elle utilise un certain format ne se l'est probablement jamais demandé.
En résumé
Je suis opposé au live coding classique parce qu'il mesure la façon dont une personne supporte le stress d'être observée, pas la façon dont elle travaille. C'est une mauvaise affaire pour le candidat comme pour l'entreprise, qui écarte des personnes compétentes et sélectionne celles qui se sont entraînées au format. Les alternatives existent et vérifient la même chose, c'est-à-dire si une personne sait programmer, sans fausser le résultat. J'ai rassemblé d'autres idées pour renouveler les entretiens techniques dans cet article, et si vous préparez un entretien, vous trouverez les questions techniques classées par niveau dans le guide des 25 questions d'entretien frontend/Angular.
