Entretien de live coding : comment ça se passe et ce qui aide vraiment
Un entretien de live coding, c'est le tour où vous écrivez du code devant quelqu'un, en temps réel, en parlant pendant que vous le faites. Presque tous les conseils portent sur les semaines d'avant. Très peu portent sur ces quarante-cinq minutes-là, ce qui est étrange, car c'est précisément là que des candidats préparés à l'identique divergent.
Ce qu'est vraiment un entretien de live coding
Vous rejoignez un appel, l'examinateur ouvre un éditeur partagé — CoderPad, CodeSignal, HackerRank, ou parfois simplement un IDE en partage d'écran — et vous donne un problème. Vous avez entre trente et soixante minutes. Vous voyez tous les deux le même curseur. Il n'y a généralement pas d'autocomplétion digne de ce nom, souvent pas moyen de lancer les tests avant de le demander, et toujours quelqu'un qui observe les silences.
C'est délibérément différent d'un exercice à la maison. Un exercice à la maison mesure le code que vous produisez. Un tour en direct mesure comment vous le produisez : si vous demandez avant de supposer, si vous repérez vos propres erreurs, si vous tenez une conversation avec les mains occupées. La réponse finale compte moins que la plupart ne le croient, et le chemin pour y arriver compte bien davantage.
Ce que l'examinateur note vraiment
Presque toutes les grilles se ramènent à quatre lignes : avez-vous compris le problème avant de le résoudre, votre approche est-elle raisonnable et avez-vous dit pourquoi, savez-vous écrire du code qui marche sans qu'on vous tienne la main, et savez-vous expliquer le compromis quand on vous le demande. Remarquez qu'une seule de ces quatre lignes porte sur le code.
C'est aussi pourquoi une solution parfaite mais silencieuse est moins bien notée qu'une solution correcte commentée. L'examinateur ne peut évaluer que ce qui lui parvient, et pendant que vous réfléchissez, rien ne lui parvient.
Les deux premières minutes décident plus qu'elles ne le devraient
L'instinct est de se mettre à taper, parce que taper ressemble à du progrès et que le silence coûte cher. C'est le mauvais instinct. Consacrez l'ouverture à reformuler le problème avec vos mots, à poser la ou les deux questions qui changent réellement la solution — taille de l'entrée, tri, doublons, droit de modifier l'entrée — et à énoncer l'approche visée avec sa complexité.
Cela coûte quatre-vingt-dix secondes et achète trois choses : vous résolvez le bon problème, l'examinateur reçoit un signal positif tôt, et vous avez un plan de repli pour le moment où vous vous perdrez. Ceux qui sautent cette étape sont ceux qui découvrent à la vingtième minute que le tableau était déjà trié.
Le trou
Parfois rien ne vient. La sortie fiable est d'énoncer à voix haute la solution la plus bête possible : « La force brute consiste à tester toutes les paires, ce qui est quadratique. Je pars de là, puis je cherche ce qui se répète. » Ce n'est pas un aveu d'échec : c'est ce que l'examinateur espère entendre, parce qu'optimiser une base énoncée est un processus visible et notable, et énoncer la base révèle souvent l'amélioration.
La deuxième sortie est un petit exemple concret. Prenez une entrée de quatre éléments, déroulez-la à la main, dites ce que vous faites. Le motif dont vous avez besoin est très souvent visible dans l'exemple et invisible dans l'abstrait.
Quinzième minute : comprendre que l'approche est mauvaise
On a l'impression que l'entretien est fini. Bien géré, c'est l'un des signaux les plus forts que vous puissiez envoyer : repérer sa propre erreur avant qu'on vous la montre, c'est exactement en quoi consiste le métier.
Dites-le explicitement et sans détour : « Ça ne va pas marcher — dès qu'il y a des doublons, mon index casse. Je veux passer à une map indexée par valeur. » Ne continuez pas à rafistoler en silence une approche morte en espérant qu'elle se rattrape ; les examinateurs voient cela et le lisent comme une incapacité à réévaluer. Et ne vous excusez pas longuement. Une phrase pour nommer le défaut, une pour nommer le remplacement, puis on avance.
Le bug que vous ne voyez pas
Sous pression, on relit les mêmes cinq lignes en attendant un résultat différent. Cassez la boucle mécaniquement : affichez l'état au point que vous croyez correct et vérifiez s'il l'est vraiment. Presque tous les bugs d'entretien sont un décalage de un, une valeur initiale fausse ou une comparaison dans le mauvais sens, et les trois deviennent visibles dès que vous affichez la structure intermédiaire au lieu de raisonner dessus.
Commentez le débogage. « Je m'attends à ce que cette map ait trois entrées ici, je vérifie. » Déboguer à voix haute est un signal positif en soi ; fixer l'écran en silence ne l'est pas.
Le silence est le vrai mode d'échec
L'examinateur remplit une grille qu'il ne peut remplir qu'avec ce qui lui parvient. Trente secondes de réflexion, c'est très bien si vous les annoncez — « laissez-moi réfléchir une seconde à la structure de données » — et cher si vous ne le faites pas, car un silence non annoncé est noté comme « bloqué ». C'est l'habitude la moins coûteuse de cette liste, et celle qui manque le plus systématiquement aux candidats refusés.
Pourquoi un raccourci clavier ne marche pas en direct
La plupart des outils d'entretien en temps réel fonctionnent avec un raccourci : vous entendez la question, vous appuyez, vous recevez une réponse. Ce modèle suppose en silence que vos mains sont libres. Dans un tour de live coding, elles ne le sont pas : vous tapez, l'examinateur regarde votre éditeur, et la demi-seconde où vous allez chercher le raccourci se voit comme jamais dans un appel purement conversationnel.
C'est le seul tour où l'assistance fonctionne toute seule ou ne fonctionne pas du tout. Interview Copilot répond automatiquement à chaque question terminée, sans touche à presser : il capte l'examinateur via l'audio de l'appel, détecte que la question est finie, et affiche la structure de la réponse sur votre écran pendant que vous continuez à taper. Pas un script à lire : le mécanisme, le compromis et le chiffre qui mérite d'être dit à voix haute.
Où l'assistance en direct aide, et où elle se retourne contre vous
Les outils en temps réel sont vraiment utiles pour un ensemble restreint de choses : rattraper une question entendue à moitié, retrouver une signature de bibliothèque que vous connaissez mais ne récupérez pas, ou trouver la terminologie quand le tour n'est pas dans votre langue maternelle. Ce sont des problèmes de récupération, et récupérer sous stress est une taxe réelle et injuste qui n'a rien à voir avec la compétence d'ingénieur.
Cela se retourne contre vous avec des réponses que vous ne pouvez pas défendre. Tout examinateur relance — pourquoi cette structure, que se passe-t-il si l'entrée double, qu'est-ce qui casse avec des doublons — et la relance vise précisément ce que vous venez de dire. Sortir une réponse léchée puis échouer à la relance est un pire résultat qu'une réponse plus lente que vous maîtrisez entièrement, car cela transforme un signal incertain en non assumé.
La ligne utilisable est simple. Servez-vous de l'aide pour comprendre et pour vous souvenir. Le raisonnement, faites-le vous-même, avec vos mots, à voix haute — car c'est la seule chose qui est notée.
FAQ
Qu'est-ce qu'un entretien de live coding ?
Un tour où vous écrivez du code dans un éditeur partagé pendant que l'examinateur regarde et pose des questions en temps réel, en général de trente à soixante minutes. Contrairement à un exercice à la maison, il mesure comment vous arrivez à la réponse : les questions posées, l'approche choisie, et votre capacité à l'expliquer en tapant.
Combien de temps dure un entretien de live coding ?
Typiquement quarante-cinq minutes : quelques minutes de mise en place, un problème principal, et cinq à dix minutes pour vos questions à la fin. Certaines entreprises posent deux problèmes courts plutôt qu'un long.
Puis-je exécuter et tester mon code pendant l'entretien ?
Sur CoderPad, CodeSignal et HackerRank, en général oui, et vous devriez : exécuter va plus vite que discuter avec le code dans sa tête. Demandez d'abord si l'examinateur n'a rien dit ; certains le désactivent exprès pour voir si vous savez raisonner sur la correction sans runtime.
Que faire dans les deux premières minutes ?
Reformulez le problème en une phrase, demandez la taille de l'entrée et les cas limites, et dites quelle approche vous allez tenter. Cette séquence fixe l'objectif de complexité, fait remonter les malentendus tant qu'ils sont peu coûteux, et donne à l'examinateur quelque chose à noter avant que le moindre code existe.
Que faire si j'ai un trou ?
Dites ce que vous pensez au lieu de vous taire : décrivez la version par force brute à voix haute, puis cherchez ce qu'elle a de gaspilleur. Les examinateurs notent le raisonnement qu'ils entendent ; un candidat silencieux qui finit par écrire du code parfait est souvent moins bien noté qu'un autre ayant commenté un chemin plus lent.
Peut-on changer d'approche en cours de route ?
Oui, et le dire explicitement vaut mieux que rafistoler en silence une conception cassée. « Ça devient quadratique et les contraintes suggèrent du linéaire — je restructure autour d'une table de hachage » se lit comme du jugement d'ingénieur. Réécrire en silence se lit comme de la confusion.
Puis-je chercher des choses pendant l'entretien ?
En général oui pour la syntaxe et les détails de la bibliothèque standard — demandez d'abord. Ce qui est évalué, c'est votre capacité à décomposer un problème et à raisonner sur des compromis, pas votre mémorisation d'une signature de méthode.