Les entretiens de live coding mesurent surtout le stress, pas les compétences en programmation

• Les entretiens de live coding mesurent en réalité mieux la réaction au stress des ingénieurs que leurs compétences en programmation
• Selon des recherches scientifiques, un environnement où l’on est observé en temps réel entraîne une dégradation des capacités cognitives et de fortes variations de performance
• En particulier, chez les candidates, on a aussi observé un phénomène où toutes échouaient en environnement public, alors qu’elles réussissaient toutes en environnement privé
• Dans la plupart des entreprises, on n’exige pas réellement une capacité d’adaptation au stress, mais les tests de code l’évaluent à tort
• Les tests blancs, l’exposition progressive et certains compléments nutritionnels peuvent aider à réduire le stress

---

Expérience personnelle avec les entretiens de live coding

• Certaines personnes aiment les entretiens de live coding, mais ce n’est pas le cas de l’auteur
• Lors de sa candidature chez Toptal, l’auteur a échoué au test de live coding, mais a résolu le même problème rapidement en le refaisant seul
• Cette expérience lui a fait comprendre qu’sous surveillance en temps réel, le stress peut empêcher d’exprimer ses capacités réelles

Le cerveau face au stress

• Dans des situations à fort enjeu et sous pression temporelle, l’amygdale du cerveau s’active et le taux de cortisol augmente
• Cela altère le fonctionnement du cortex préfrontal, chargé du raisonnement complexe et de la mémoire
• La mémoire de travail est l’indicateur le plus important pour évaluer la capacité à résoudre de nouveaux problèmes, et elle diminue fortement en situation de programmation en direct
• Même en cas d’anxiété de performance légère, il devient presque impossible de penser clairement
• On a du mal à se concentrer, à garder plusieurs étapes en tête en même temps, et l’on a l’impression d’être « bien moins compétent que d’habitude »

Résultats de recherche déterminants

• Un article mené par des chercheurs de Microsoft a comparé la résolution d’un même problème de code en environnement privé et en environnement public
• En environnement privé, les participants travaillaient seuls dans une pièce ; en environnement public, ils devaient résoudre le problème devant un superviseur tout en verbalisant leur raisonnement
• Résultat : les performances étaient divisées par deux lorsqu’ils étaient observés, avec en particulier une variabilité des résultats beaucoup plus forte
• Contrairement aux candidats masculins, toutes les candidates en environnement public ont échoué, alors qu’elles réussissaient toutes en environnement privé
• L’environnement de live coding agit comme un filtre d’exclusion scientifiquement démontré qui écarte des ingénieurs pourtant compétents

La réalité de la performance sous stress

• Le live coding n’est au fond qu’un indicateur indirect de la performance en situation de stress
• Certaines entreprises recherchent effectivement des personnes performantes dans des environnements stressants, mais la majorité ne l’indique pas clairement dans ses offres
• Étant donné que la plupart du travail quotidien implique peu de stress en temps réel, écarter un excellent ingénieur parce qu’il a échoué en live coding est inapproprié
• Il est raisonnable de considérer que le live coding mesure davantage le niveau d’hormones du stress que les compétences en programmation

Méthodes pour réduire le stress

• Comme le live coding est courant dans l’industrie, un entraînement à l’adaptation au stress est nécessaire
• Une pratique répétée dans des conditions proches du réel (Pramp, Interviewing.io, tests blancs LeetCode, etc.) peut habituer le cerveau au stress
• S’exercer avec un minuteur, s’enregistrer, ou demander à un ami d’observer permet d’augmenter progressivement la pression de manière efficace
• En complément, on peut aussi essayer des nutriments comme la L-tyrosine (pour soutenir les neurotransmetteurs sous stress) et la L-theanine (pour favoriser la détente et améliorer la concentration)
• Avant un véritable entretien, il faut impérativement vérifier en simulation ce qui fonctionne le mieux pour soi

Conclusion

• Être mauvais en live coding n’est pas un manque de qualités pour être ingénieur, mais une caractéristique humaine tout à fait ordinaire

[GN⁺]

Avis Hacker News

• Je ne prétends pas généraliser mon cas, mais je veux partager mon expérience personnelle. Aujourd’hui, je suis un développeur indépendant à mon compte qui a réussi. L’une des principales raisons pour lesquelles je n’ai pas abandonné le développement indie pendant les périodes difficiles, c’est qu’en pratique j’étais devenu inemployable. Je suis un homme d’âge mûr dans une industrie tech très marquée par l’âgisme, je n’ai pas de diplôme en informatique, et en entretien de live coding j’ai tendance à avoir le cerveau qui se vide. Tous les stress ne se valent pas. Les pompiers se précipitent dans des bâtiments en feu, mais peuvent être terrifiés à l’idée de parler devant des inconnus. Moi aussi, je supporte bien le stress du travail au quotidien, mais le fait d’être observé par-dessus mon épaule par quelqu’un qui décide de mon avenir financier m’est tellement pesant que j’en ai la nausée. Une fois l’entretien terminé, j’arrive souvent à résoudre le problème de code. Les recruteurs penseront peut-être que je suis un imposteur, mais près de vingt ans d’expérience prouvent le contraire. Beaucoup de gens semblent considérer les "false negatives" comme s’ils étaient aléatoires, mais pour certains comme moi, c’est systématique. Je rate toujours les entretiens de type audition : je ne suis pas quelqu’un qui performe sur scène.

  • Je compatis totalement sur le fait d’être évalué sous le regard des autres. J’ai un peu plus de 60 ans. Dans ma vingtaine et ma trentaine, je m’en sortais à peu près bien en entretien, mais avec le temps, j’ai eu l’impression que l’exercice lui-même devenait de plus en plus conflictuel. Avant, on avait le sentiment qu’on cherchait à vous embaucher ; aujourd’hui, on a l’impression qu’on cherche des raisons de ne pas vous embaucher. C’est peut-être lié à l’âgisme, mais aussi à une évolution générale de l’industrie. Ces quinze dernières années, mes expériences d’entretien sont devenues de plus en plus désagréables, et il m’est même arrivé de paniquer en plein entretien. Malgré tout, j’ai quand même réussi à être embauché, et j’ai aussi fait des missions sans entretien grâce à mon parcours. La dernière startup où j’ai travaillé a manqué de financement fin 2022, et j’ai décidé de partir. J’adorais vraiment le travail et je manipulais des technologies récentes, mais le plus important, c’est que je ne pouvais plus supporter les entretiens.

  • Je pense que c’est la structure elle-même qui pose problème. Les entretiens de code récents semblent conçus pour vérifier si les jeunes ont fait leurs devoirs de structures de données en informatique. Ça avait peut-être un sens dans des entreprises qui recrutaient en masse comme les FAANG dans les années 2010, mais pour des PME ou des entreprises de taille intermédiaire, il vaudrait bien mieux se concentrer sur des situations réelles de travail, comme lire du code ou discuter des cas limites. Cela fait plus de 20 ans que je travaille dans des startups, et je n’arrive toujours pas à passer ce genre de test. Je refuse aussi de bachoter de force. Si c’est incompatible avec un poste, tant pis. J’ai été CTO, j’ai lancé plusieurs entreprises, je gère bien des équipes, et pourtant on me traite encore comme un junior. J’ai déjà été recalé parce que je n’ai pas réussi à implémenter rapidement et proprement un cache LRU, alors je me demande à quel point c’est utile dans une startup aujourd’hui. Je n’ai même pas eu à en utiliser récemment. Le fait de ne pas résoudre ce type de problème immédiatement peut donner l’impression qu’on est incompétent, mais je ne vois pas l’intérêt de tester quelque chose qui ne sert pas dans le travail réel. C’est comme choisir un architecte sur sa maîtrise de la règle à calcul. Ce type de recrutement produit au final des bases de code complexes, alors que le vrai besoin devrait être d’atteindre les objectifs métier plutôt que d’ajouter de la complexité. J’ai envie de travailler avec des collègues capables de découper les problèmes et de garder la logique et la structure simples. Filtrer les gens intelligents avec leet-code a peut-être quelques avantages, mais quelqu’un qui résout des problèmes concrets de façon constante et efficace vaut mieux.

  • J’ai été confronté à cette situation du point de vue du recruteur. J’ai eu un entretien téléphonique avec un étudiant impliqué depuis longtemps dans un projet, et il semblait incapable de montrer son vrai niveau à cause de différents stress et de la barrière de la langue. J’étais prêt à changer de format, mais le candidat a lui-même dit qu’il ne voulait pas continuer. D’un autre côté, si on bascule vers un entretien de code asynchrone, on risque surtout de tester si la personne utilise un LLM ou non. Au final, s’il faut choisir entre filtrer les gens qui se figent en entretien ou ceux qui sont de complets imposteurs sans compétence, je préfère filtrer les premiers.

  • Je vois souvent ce décalage de tempérament en entreprise. Beaucoup de programmeurs sont introvertis, alors que les recruteurs sont souvent extravertis. Si cette différence est mal gérée, on finit par exclure ou mal comprendre les talents introvertis. Les open spaces posent un problème similaire. Les managers aiment la collaboration, mais pour les introvertis, c’est un environnement très difficile.

  • Je suis curieux de savoir à partir de quand vous avez commencé à réussir en développement indie. J’ai moi aussi presque 40 ans, je programme comme loisir depuis longtemps, et j’ai décidé l’an dernier d’en faire sérieusement mon métier. J’ai beaucoup de projets publics sur GitHub, j’ai déjà réussi dans d’autres domaines, et je ne suis pas mauvais en communication. Mais j’ai du mal avec le live coding. J’aimerais savoir ce que vous pensez d’une voie d’independent contribution qui permette de montrer son vrai niveau. Si on a de vraies compétences, on aimerait pouvoir en vivre.

• J’ai interviewé cette semaine un candidat en Data Engineering. Je lui ai donné quatre requêtes SQL très basiques ; il a lu les problèmes à voix haute et a tout de suite donné les bonnes réponses avec la bonne syntaxe. La dernière était un peu plus difficile, et là il a bloqué. Je lui ai dit de "vérifier le résultat", mais il n’a pas compris et s’est mis sur la défensive. Quand je lui ai dit de "dump la table", il n’a toujours pas compris et n’a fait que se justifier. Au final, le SQL qu’il a collé contenait [redacted].ai dans la sortie. Il a probablement résolu les premières questions avec de l’IA, puis s’est trahi sur la dernière. Sans ce type de question technique, on n’aurait pas pu repérer la triche.

  • Les outils de triche à l’entretien basés sur l’IA se sont énormément répandus chez les jeunes. Dans certains cas, c’est évident, mais les candidats expérimentés arrivent à masquer l’usage de l’IA en lissant la conversation et en glissant des "je ne vous entends pas" ou autres artifices pour gagner du temps. Dans le groupe de managers dont je fais partie, c’est devenu le sujet de recrutement le plus discuté récemment. Les entreprises qui en ont les moyens font le dernier entretien en présentiel. Il arrive que quelqu’un semble correct en partage d’écran à distance, puis ne soit même pas capable de répondre à des questions de base une fois sur place, et on le recale. C’est une perte de temps et d’argent, mais on estime que c’est toujours moins coûteux qu’une mauvaise embauche. L’usage de l’IA ne touche pas seulement les entretiens techniques, mais aussi les CV, les questions comportementales, et même les réponses au format S.T.A.R. générées par ChatGPT. Les prises de référence fiables sont plus importantes que jamais. J’ai déjà vu plusieurs fois des écarts complets entre ce qu’un ancien manager raconte du travail effectué et ce qui était écrit sur le CV. Si la personne avait été honnête dès le départ sur son absence d’expérience directe dans notre domaine, on aurait peut-être pu l’embaucher ; mais quand le mensonge prend cette ampleur, toute confiance disparaît.

  • En ce moment, sur les candidats que j’interviewe, environ 50 % utilisent du GenAI en direct. Jusqu’ici, il a toujours été très facile de repérer qui utilise l’IA. Cela ressort vite dans une conversation naturelle. Ironiquement, le dernier candidat répétait lui aussi systématiquement l’énoncé avant d’attendre 10 à 15 secondes. Cela montre justement que ce type de test n’est pas une solution au problème de fond. Au contraire, il crée de nouveaux problèmes et fait échouer d’excellents candidats.

  • Et si utiliser l’IA n’était pas de la triche, mais simplement une préfiguration de ce que la personne fera dans son vrai travail ? Sous cet angle, cet entretien était en fait un exemple très efficace, à petite échelle, d’<i>interprétation des exigences</i>. Je pense qu’il serait plus positif de laisser les candidats utiliser librement les outils qu’ils utiliseraient au quotidien, tout en testant à l’intérieur de ce cadre leur compréhension réelle du métier et du langage. L’exigence, c’est simplement de sortir de Leetcode pour trouver une meilleure méthode.

• Au final, tout dépend du contexte. C’est vrai aussi pour les entretiens de live coding. Ce n’est pas la meilleure expérience pour le candidat, mais dans de très grandes entreprises comme Meta ou Google, cela réduit mieux les false positives que d’autres méthodes. En revanche, les intervieweurs sont souvent insuffisamment formés et les questions trop proches d’énigmes, ce qui rend l’exercice difficile à moins d’avoir beaucoup pratiqué LeetCode ou de sortir tout juste des études. J’ai travaillé six ans dans l’évaluation, et j’ai vu de près des processus de recrutement allant de Fortune 10 à des startups. Je recommande des évaluations proches du travail réel, et je n’aime plus l’expression de "vrai travail" quand elle ressemble à du travail non rémunéré. Une évaluation doit servir à permettre à l’entreprise de proposer sereinement un salaire élevé. Avec l’arrivée de l’IA, même les petits take-home tests ont du mal à rester équitables. C’est pourquoi certaines entreprises reviennent à des méthodes extrêmes comme les entretiens on-site et la surveillance en temps réel. La solution parfaite, à mon sens, serait de garantir à tous les candidats le même temps, le même environnement et les mêmes outils pour qu’ils puissent donner le meilleur d’eux-mêmes. Je réfléchis toujours à ce problème, mais je n’ai pas encore trouvé la réponse.

  • On dit que "ça marche bien chez Meta et Google", mais en réalité il n’y a pas de données. J’ai travaillé avec des développeurs de niveau F sortis de Facebook ou Google. En pratique, ces grands groupes licencient aussi 3 à 5 % de leurs effectifs, ce qui prouve que les entretiens ne capturent pas correctement les false positives. Au regard du temps investi par les intervieweurs, un taux d’erreur de 3 % me paraît beaucoup trop élevé. En réalité, ce n’est guère différent de l’ancien niveau "Fizzbuzz".

  • C’est comme si, pour recruter un maçon, on ne lui demandait pas de construire un mur, mais qu’on l’embauchait directement dès qu’il montre un certificat. Beaucoup de métiers fonctionnent comme ça. Si la personne n’a pas le niveau, on la sort après embauche. Pas besoin de lui faire subir un processus d’entretien humiliant.

  • Les meilleurs ingénieurs que j’ai connus étaient souvent classés en false negative. Ils stressaient en entretien de live coding et ne montraient pas leur vrai niveau. Je ne pense pas qu’on puisse affirmer aussi catégoriquement que ce type d’entretien "fonctionne".

  • Dire d’abord "ça dépend du contexte" puis affirmer ensuite que "les entretiens de live coding marchent" est contradictoire. Moi aussi, je pourrais dire "ça dépend du contexte, mais les entretiens de live coding ne marchent pas". Il n’y a pas de différence logique.

  • Réussir le leet-code peut servir à filtrer les gens qui n’ont vraiment aucune capacité de résolution de problèmes. La meilleure solution serait de créer un environnement où le candidat peut exprimer son maximum avec ses propres outils et son propre cadre de travail. Mais en pratique, je me demande si la forme la plus juste ne serait pas de faire du leetcode en présentiel, sur tableau blanc, en pair programming avec l’intervieweur. Ce serait vraiment un environnement confortable.

• Je pense que les deux explications peuvent être vraies en même temps. Il existe réellement des développeurs "senior" incapables de faire le travail, et le live coding peut aider à les filtrer. Mais on peut aussi rater un entretien pour d’autres raisons.

  • Il y a aussi beaucoup de développeurs capables de réussir le live coding mais qui manquent d’expérience en conception de systèmes à grande échelle. Ce sont souvent eux qui introduisent de la dette technique, des anti-patterns et des incohérences, et qui détériorent encore davantage la base de code. En pratique, c’est vraiment le profil à éviter. Les entreprises pensent que leurs seniors en place contrôleront les juniors, mais comme partout on entend "notre codebase est un désastre", cette parade ne semble pas très efficace.

  • Si on laissait simplement les gens coder seuls dans une pièce, on éviterait de passer à côté d’excellents profils qui ne sont pénalisés que dans des conditions artificielles.

  • Dernièrement, le live coding ne se limite plus à un simple test de code : il faut mémoriser beaucoup d’algorithmes et combiner deux ou trois approches en 30 minutes pour résoudre le problème. On passe tout le temps à résoudre le puzzle, au point de ne plus avoir de temps pour montrer son vrai niveau en code.

  • En 20 ans de carrière, je n’ai jamais vraiment travaillé avec un de ces "seniors incompétents". Un CV et 15 minutes de conversation suffisaient à les écarter. À l’inverse, j’ai vu bien plus de personnes qui avaient réussi des entretiens sur tableau blanc mais nui à la productivité de l’équipe.

  • Je ne comprends pas pourquoi il serait indispensable de travailler sous un délai très court, debout devant un tableau blanc, tout en réfléchissant et en expliquant en même temps. Si le but est de filtrer les gens incapables de faire le travail, on n’a pas besoin d’aller aussi loin.

• À mes yeux, la seule façon de vérifier correctement la capacité à exercer un poste est de faire réellement faire ce poste. Même s’il existe des méthodes d’évaluation alternatives, si on peut faire faire le travail réel, il n’y a aucune raison d’utiliser autre chose. Si le travail de l’entreprise est tellement complexe qu’on ne peut pas l’isoler pour un entretien, il est aussi possible que l’entreprise ne fasse que des choses inutilement compliquées. Par exemple, si le poste exige de soulever 10 kilos, il suffit de demander à la personne de soulever effectivement une charge de 10 kilos. Au lieu de ça, on invente un test absurde du type : "pour évaluer votre force, enlevez votre pantalon et soulevez un seau d’1 kg avec les fesses". Il suffit d’évaluer les compétences réellement nécessaires au travail. Pour un chef, on peut faire cuisiner dans une vraie cuisine ; pour un poste de support, on peut observer la communication dans une mise en situation. Pour le screening téléphonique, on peut aussi regarder un écran en direct.

  • Certains rétorquent que faire exécuter un vrai travail en entretien pose des problèmes de triche ou d’exploitation non rémunérée. Si l’entreprise réutilise la production du candidat, cela peut devenir juridiquement problématique.

  • Certains proposent aussi d’embaucher directement les gens pour une journée, une semaine ou un mois, puis de les recruter si ça colle. Mais ce modèle s’accorde mal avec le système américain d’assurance santé liée à l’employeur.

  • Du point de vue de l’entreprise, cela prend tout simplement trop de temps. Elle préfère donc un proxy biaisé vers les false negatives plutôt que vers les false positives.

  • Je serais curieux de savoir ce que vous pensez de l’objection selon laquelle faire faire le vrai travail en entretien revient à exiger du travail gratuit.

  • Comme il faut du temps pour s’adapter à une nouvelle organisation, tester via le travail réel peut au contraire être inefficace. Un live coding évalue mieux la communication, la résolution de problèmes et la compétence pure en programmation.

• Depuis que j’ai des enfants, mes performances en entretien de code se sont effondrées. Avant, cela ne m’était jamais arrivé, mais aujourd’hui j’ai l’impression que trop de choses sont en jeu. Quand je pense à l’assurance santé, au crédit, à la retraite, la pression devient énorme. Me retrouver complètement bloqué pendant l’entretien et ne trouver la solution qu’après coup est très douloureux. Plus j’essaie de consacrer du temps à l’entraînement, plus j’ai l’impression de devenir mauvais. Avec des personnes à charge, plus je m’entraîne, plus je culpabilise. L’effet d’apprentissage est faible, et cela me démoralise encore plus. Après avoir travaillé dans la big tech, j’ai compris que ce type d’entretien a été introduit au nom d’un idéal très abstrait de "test égal pour tous", alors qu’en pratique il ne tient aucun compte des changements de situation personnelle ni des déséquilibres. Même un collègue solide face au stress peut être très différent quelques années plus tard. On part avec l’idée d’éliminer les biais, mais je pense qu’il faut changer de méthode.

  • Vous n’êtes pas seul à ressentir cela. En vieillissant, on apprend plus lentement, on a moins de temps libre, et l’entraînement au leetcode devient moins rentable. C’est frustrant de voir que les gens qui ont simplement plus de temps sont davantage récompensés.

  • Pour atténuer le stress, je recommande d’essayer la méditation, la respiration, la L-Theanine, les bêtabloquants, etc. Je conseille aussi d’utiliser une montre connectée pour surveiller la fréquence cardiaque et la tension. Concrètement, ce type de méthode aide à casser la spirale du stress.

• C’est un type de stress très intense, qualitativement différent du stress du travail réel. Pour partager mon expérience des entretiens chez Google : j’ai créé le premier moteur de recherche local des Pays-Bas, et chez Google un intervieweur coiffé d’un chapeau de cow-boy m’a demandé d’écrire une recherche binaire au marqueur sur un tableau blanc. Or je n’écris jamais à la main, j’utilise toujours un clavier, et personne n’a cherché à examiner mon expérience de conception d’index de recherche. J’en suis venu à penser que Google cherchait peut-être surtout un esprit "cow-boy".

  • Moi aussi, à l’époque, je me suis laissé convaincre par un recruteur Google de passer des entretiens, mais les intervieweurs étaient tellement mauvais que j’ai même sauté l’entretien technique, et depuis je refuse toutes les propositions de Google. La plupart des questions relevaient du piège ou portaient sur des structures UNIX très anciennes sans lien avec la réalité, comme les inodes. Cela n’avait aucun rapport avec le poste. Les entreprises ont absolument besoin d’un processus de suivi et de retour sur les questions posées, ainsi que d’une formation des intervieweurs. Il y a encore énormément d’entreprises où les questions dépendent simplement des préférences personnelles de l’intervieweur.

  • En réalité, ce système a parfaitement fonctionné comme prévu. Ces entreprises veulent des gens prêts à endurer n’importe quelle humiliation pour travailler chez elles. Vous n’étiez simplement pas compatibles, donc tout le monde y a gagné.

  • Si vous vous êtes senti insulté parce qu’on vous a demandé une recherche binaire, c’est peut-être que vous avez un ego un peu trop fort.

  • Avec 250 000 dollars par an et des stock-options Google en plus, je peux très bien accepter une journée d’"humiliation".

• J’aborde le live coding screening comme une "conversation autour du code". J’explique clairement au candidat que l’objectif de l’entretien est de vérifier si nous communiquons bien. Avoir uniquement de bonnes compétences techniques ne suffit pas : il faut aussi pouvoir collaborer. Par exemple, un candidat qui implémente quelque chose de faux à cause d’un malentendu pendant la discussion, ou qui code très bien mais ne peut pas avoir de conversation technique, pose problème. C’est pourquoi les questions de type Fizzbuzz sont importantes : elles ne testent pas seulement la compétence brute, mais aussi la capacité à avoir une discussion technique.

  • Oui. L’essence même de l’entretien de live coding, ce n’est pas de savoir si l’on peut résoudre le problème, mais si l’on peut expliquer comment on le résoudrait. L’essentiel, c’est un minimum de bases techniques et des capacités de communication. Une grande partie du travail réel consiste à expliquer des sujets techniques à des managers non techniques ; on peut donc voir cela comme un test de cette compétence.

  • J’aime bien cette approche. Je peux faire FizzBuzz en au moins 3 langages, de 4 manières différentes, et je serais capable d’expliquer les 12 versions.

• Moi aussi, je vois bien ce problème, et je suis d’accord sur le fait qu’il n’existe pas de vraie alternative évidente. Au cours de ma carrière, j’ai rencontré plusieurs personnes qui parlaient et se comportaient comme des ingénieurs, mais qui en réalité ne savaient pas coder. J’ai souvent regretté des recrutements où j’avais ignoré la compétence de code en entretien. J’aimerais aussi que les jeunes développeurs comprennent que plusieurs étapes du processus d’embauche avantagent davantage les candidats plus âgés. Je sais qu’il y a dans l’industrie beaucoup d’ingénieurs sans vraie capacité de code qui se cachent derrière une façade inutile d’"expert". Embaucher quelqu’un sans jamais voir comment il code, c’est un peu comme recruter un guitariste dans un groupe uniquement sur son CV, sa conversation et ses références. On peut très bien engager un soi-disant expert en guitare qui n’a jamais réellement joué. Il existe bel et bien des gens qui passent ainsi sans qualification particulière. Dès qu’on doit se contenter de suppositions sans preuve directe en entretien, les biais et les préjugés finissent inévitablement par intervenir.

  • À ceux qui disent "il y a un problème mais pas d’alternative", on peut répondre qu’il existe des systèmes fondés sur des certifications, comme pour les médecins ou les avocats. On ne leur demande pas de faire une démonstration avant une opération, alors même que l’enjeu est bien plus élevé. En réalité, les procédures de vérification sont surtout strictes pour les postes subalternes, tandis que les managers et les postes à fort impact passent beaucoup plus facilement.

  • Je pense qu’il vaut mieux demander d’écrire du pseudocode au tableau blanc. Cela réduit le stress lié à la syntaxe et permet de mieux voir la logique de résolution du problème. En même temps, cela correspond bien à ma manière de collaborer, qui consiste à échanger des idées ensemble sur tableau blanc.

• Le phénomène "le stress est distinct de la compétence" revient sans cesse. L’article de Microsoft était accablant. La plupart des conseils se résument à "fais plus de LeetCode", en ignorant le stress et le cortisol. De mon côté, je m’entraîne à m’habituer à l’environnement stressant lui-même. Les amis ne peuvent pas vous entraîner avec une intensité suffisante, et un coach coûte trop cher à l’heure. Du coup, je développe en ce moment un side project appelé Tough Tongue AI. C’est un éditeur de code en direct où l’on répond à la voix, avec questions en temps réel, interruptions et feedback immédiat. Cet entraînement permet de s’habituer progressivement à cette tension de "quelqu’un me regarde". Tant que les entretiens de live coding continueront d’exister, il faudra des méthodes pour entraîner non pas l’algorithme, mais la réaction physiologique elle-même, c’est-à-dire le stress.

  • C’est l’un des meilleurs outils d’apprentissage.