Les entretiens techniques à l’ère de l’IA

• Alors que les outils d’IA s’imposent rapidement jusqu’à la rédaction et la revue de code, il faut exclure par défaut l’usage de l’IA en entretien et évaluer avant tout les compétences fondamentales
• Un bon entretien s’évalue selon deux axes : la qualité du signal (signal quality) et le coût pour l’entreprise (cost to company), deux dimensions qui ne sont pas totalement indépendantes
• Les entretiens se divisent en quatre catégories : take-home, live exercise, presentation, actual work, chacune avec un niveau différent de qualité du signal et de coût
• Avec le codage assisté par IA, les take-home deviennent trop faciles et plus lourds à relire, tandis que des questions divulguées permettent aussi à l’IA de jouer un rôle de coach très efficace
• La maîtrise de l’IA n’est qu’une instrumental skill (compétence instrumentale) ; les entreprises doivent donc se concentrer sur l’évaluation des foundational skills (compétences fondamentales)

---

Thèse principale

• Face à l’évolution rapide des modèles et outils d’IA, une question émerge : les ingénieurs écriront-ils encore et reliront-ils encore du code dans six mois, et si cette compétence centrale disparaît, les entretiens doivent-ils eux aussi évoluer ?
• La plupart des entreprises ont choisi le statu quo, y compris certaines qui sont à l’origine de cette révolution
  • Les consignes de recrutement d’Anthropic demandent que les take-home soient réalisés « sans Claude, sauf indication contraire »
• D’autres entreprises autorisent, recommandent ou rendent obligatoire l’usage de l’IA, au point que la maîtrise de l’IA elle-même devient parfois le sujet de l’entretien
• La conclusion est qu’il faut en général exclure l’IA des entretiens, tout en adaptant concrètement les entretiens à cette nouvelle réalité

Les deux dimensions d’un bon entretien

• Qualité du signal (Signal quality)

  • La capacité à identifier les candidats solides sur un ensemble de compétences donné, tout en ignorant le bruit, c’est-à-dire les éléments non essentiels au poste ou faciles à enseigner
  • Résistance à la préparation (Invulnerability to preparation) : si la performance dépend surtout du volume de préparation et d’effort, on ne mesure alors que cette caractéristique
  • Réalisme (Realism) : un entretien doit ressembler au travail quotidien, sans que cela soit une fin en soi. Les entretiens « algorithm & data structure » survivent depuis longtemps alors même qu’ils sont rarement utilisés tels quels en pratique
  • Égalité (Equality) : certains candidats partent avec un avantage grâce à une expertise préalable du domaine, du mentorat payant, plus de temps libre, des questions divulguées en ligne ou des proches récemment passés par le processus. Idéalement, les conditions devraient être équitables pour tous
  • Difficulté (Difficulty) : un bon entretien doit être suffisamment difficile pour que beaucoup échouent. Le meilleur format repose sur des problèmes vastes et ambigus qui demandent plusieurs intuitions

• Coût pour l’entreprise (Cost to company)

  • Les questions d’entretien demandent un investissement considérable : conception initiale et validation par expérimentation, rédaction de scorecards par poste et niveau, tests auprès de candidats internes et externes, documentation et formation des interviewers
  • Les questions et scorecards sont ajustées en continu, ce qui implique un investissement durable
  • Difficulté (Difficulty) : créer une question est déjà difficile ; en créer une qui soit réellement assez difficile l’est encore plus. Des questions trop faciles ou trop difficiles font perdre du temps à tout le monde
  • Attractivité pour le candidat (Appeal to candidate) : un processus trop chronophage ou des questions ennuyeuses font fuir les meilleurs ingénieurs et réduisent le taux de conversion. Les questions révèlent aussi la culture d’ingénierie de l’entreprise
• Ces deux dimensions ne sont pas totalement indépendantes ; par exemple, la difficulté influence les deux. Un entretien difficile peut faire briller les meilleurs candidats, mais aussi provoquer des false negatives (faux rejets)
• Un entretien n’a pas besoin d’être parfait : false negatives et false positives existent toujours. Les false negatives sont difficiles à identifier, mais de bons parcours d’onboarding et des jalons clairs pour le premier semestre permettent d’écarter rapidement les false positives

Classification des types d’entretien

• Take-home

  • Le candidat soumet (1) une solution à un problème ambigu (par exemple une spécification produit) en respectant (2) quelques contraintes techniques (par exemple une liste de langages autorisés)
  • Cela est souvent suivi d’un entretien de review où le candidat présente son travail et le modifie à chaud
  • Qualité du signal : élevée (avant l’IA) — donne un signal large sur la conception, le code, le soin du détail, les tests, etc. ; consacrer plus de 6 heures démontre aussi la motivation
  • Coût pour l’entreprise : moyen — l’évaluation peut être automatisée, le livrable (le code) peut être relu de façon asynchrone, mais ce format peut décourager les candidats
  • Très vulnérable à l’IA et aux personnes fortement motivées

• Live exercise

  • algorithm & datastructure, live coding, system design, postmortem review, etc., généralement sur plus d’une heure. Le candidat résout en direct devant un interviewer des problèmes du type « concevoir l’architecture de Netflix » ou « écrire un rate-limiter »
  • Qualité du signal : moyenne — lorsqu’il est bien conçu et bien mené, c’est un format objectif, mais le signal se concentre souvent sur un seul sujet
  • Coût pour l’entreprise : moyen — il faut beaucoup de questions variées pour limiter la vulnérabilité à la préparation des candidats
  • Pour réduire les coûts, certaines entreprises utilisent des services automatisés

• Presentation

  • Le candidat choisit lui-même le problème et la réponse, avec des formats du type « présenter un projet que vous avez mené », « diagramme d’architecture » ou « racontez une expérience que vous avez vécue »
  • Qualité du signal : faible — les modes d’échec sont nombreux
    • Le candidat n’a jamais travaillé sur un problème intéressant (cas fréquent chez les juniors), choisit un sujet ennuyeux, exagère son impact ou sa contribution, prépare mal sa présentation, communique très bien sans être vraiment un exécutant solide, ou encore l’interviewer manque des connaissances métier nécessaires pour évaluer correctement
  • Coût pour l’entreprise : faible — il y a peu à préparer du point de vue du calibrage
  • On peut atténuer cette faible qualité du signal par des questions rétrospectives comme « que feriez-vous différemment ? » ou hypothétiques comme « que se passerait-il si l’exigence X changeait ? ». Dans ce cas, on se rapproche d’un live exercise non calibré, au prix d’un effort et d’une expertise plus importants côté interviewer

• Actual work (pas réellement un type d’entretien)

  • Une semaine de travail rémunéré ensemble. Des entreprises comme Linear utilisent ce modèle
  • Qualité du signal : élevée / Coût pour l’entreprise : élevé
• La plupart des entreprises combinent plusieurs formats, avec une domination des live exercises

La fuite des questions n’est qu’une question de temps, avec ou sans IA

• La fuite des questions finit toujours par arriver, et des sites comme Glassdoor listent déjà les secrets des entretiens. Certains candidats vont même jusqu’à passer des entretiens pour revendre les questions
• L’ignorer affaiblit le signal et transforme la performance en un simple test de la capacité à « retrouver notre processus d’entretien »

• Tactiques de réponse

  • Contrôler la préparation (Control the preparation) : inclure des presentations dans le mix ou fournir des consignes précises (par exemple « la system design sera centrée sur la base de données », « les algorithmes porteront sur les graphes ») afin de créer des conditions plus équitables
  • Diversifier les questions par type : archiver régulièrement les anciennes questions. Si le candidat ne peut pas prédire exactement la question, il doit élargir sa préparation, et c’est bien l’objectif. Mais cela a un coût
  • Rendre la fuite plus difficile (Make it harder to leak) : organiser des entretiens sur site, utiliser un tableau blanc, placer les questions les plus vulnérables vers la fin du processus, lorsque le nombre de candidats est plus faible et donc la probabilité de fuite aussi

Le codage avec IA menace le modèle d’entretien actuel

• (1) Les take-home deviennent trop faciles pour les candidats et trop coûteux pour l’entreprise

  • D’ici 2026, la majorité des livrables seront probablement générés par IA ou fortement assistés par IA, et les exercices qui résistent encore aujourd’hui finiront tôt ou tard par être résolus au prochain saut de modèle
  • Résultat : la plupart des candidats franchiront la première étape, ce qui fera exploser le temps de review. Relire avec une IA des soumissions générées par IA n’a aucun sens
  • Le codage avec IA déplace le coût de l’entretien du candidat vers l’interviewer
    • Citation de la loi de Brandolini : l’énergie nécessaire pour réfuter du mauvais code est d’un ordre de grandeur supérieur à celle nécessaire pour le produire

• (2) Si le temps d’écriture de code diminue, il devient naturel de réduire la place du live coding

  • De la même manière qu’on est passé de l’écriture en langage machine à des langages plus haut niveau, il semble rationnel d’aligner les outils autorisés en entretien sur ceux du travail quotidien

• (3) Quand les questions fuient, l’IA devient un coach redoutable

  • Autrefois, trouver les questions et se préparer demandait beaucoup de temps et de ressources ; aujourd’hui, l’IA offre l’aide la plus puissante et la moins coûteuse

Comment le modèle classique d’évaluation scolaire a résisté à la technologie

• Les examens du lycée et de l’université en France ont globalement gardé la même forme
  • Aucun document autorisé (cours, livres, etc.), presque aucun outil admis (notamment les calculatrices), contenu tenu secret à l’avance, impossible à deviner (chaque examen est différent et n’est utilisé qu’une fois), et problèmes vastes et ambigus
  • L’exemple emblématique de l’épreuve de littérature française est la dissertation, un essai de 5 à 10 pages à partir d’un seul sujet, en usage depuis 1830. Les examens scientifiques suivent souvent une logique comparable avec 3 ou 4 problèmes ambigus à résoudre
• D’autres formes d’évaluation existent en complément — take-home, quiz de connaissances, travaux de groupe, présentations — mais elles restent l’exception plutôt que le principe
• Nouvelle application de la classification
  • Qualité du signal : élevée — l’espace de préparation est immense et demande un effort soutenu dans le temps
  • Coût : très élevé — il faut concevoir un nouveau sujet et un nouveau guide de correction pour chaque examen, tout en faisant passer tous les candidats en même temps, ce qui est totalement irréaliste pour les entretiens en entreprise
• Ce qui est intéressant, c’est que ce modèle a très peu changé malgré les bonds technologiques des outils cognitifs comme le copier-coller, Internet, les calculatrices ou les solveurs
  • L’éducation doit se concentrer sur les compétences fondamentales, non sur les outils du moment ; cela rejoint un modèle aristotélicien centré moins sur la mémoire (mneme) que sur le jugement (phronesis)

Pourquoi les entreprises devraient limiter l’usage de l’IA pendant les entretiens

• Distinguer compétences fondamentales et compétences instrumentales

  • Les foundational traits & skills sont des compétences, attitudes ou habitudes difficiles ou coûteuses à construire
    • capacités intellectuelles brutes, expertise profonde acquise au fil d’années d’apprentissage (par exemple les systèmes distribués à plusieurs millions de requêtes par seconde ou la transformation de centaines de microservices en monolithe), raisonnement de second ordre, vertus professionnelles comme l’éthique, l’integrity et la résilience
    • il s’agit d’un savoir intériorisé — les fundamentals — qui permet d’identifier, d’abstraire et de résoudre les problèmes, et sert de socle pour accumuler ensuite d’autres compétences. C’est ce qui fait dire : « cette personne est intelligente, elle saura s’en sortir »
  • Les instrumental skills peuvent être développées rapidement ou à faible coût
    • niveau intermédiaire dans un langage de programmation, usage correct d’un éditeur de texte, recherche dans la documentation, ajustement de prompts IA
  • En entretien, on utilise souvent plusieurs signaux de compétences instrumentales pour inférer des traits fondamentaux du candidat, comme sa volonté d’investir dans sa productivité ou sa capacité d’apprentissage structuré

• Raison 1 : la maîtrise de l’IA n’est pas une compétence fondamentale

  • Les outils d’ingénierie ont toujours évolué, mais les entretiens sont restés globalement les mêmes (il n’existe pas de format d’entretien low-code, et la system design repose encore le plus souvent sur des technologies basiques et non managées)
    • Les meilleures entreprises ne recherchent pas la maîtrise d’un outil unique, et l’essor des LLM renforce encore l’importance de l’Expert Generalist
  • C’est la même raison pour laquelle l’expertise dans un langage de programmation précis compte relativement peu en entretien : le langage n’est qu’un outil au service d’un objectif supérieur, la résolution de problèmes
  • L’usage de l’IA relève du même principe : prompt/context engineering, définition de MCP/skills, multi-agent workflow, harness engineering, etc. exigent des savoir-faire subtils, mais ce sont des compétences instrumentales reposant sur les mêmes compétences fondamentales que l’écriture, la revue de code et la conception d’architectures extensibles
  • Une entreprise recrute des cerveaux, pas des mains qui tapent machinalement des instructions à un agent IA
  • Review et production sont les deux faces d’une même pièce : relire du code, une architecture ou une analyse demande des compétences proches de celles nécessaires pour écrire, concevoir ou analyser. Et comme un humain reste nécessaire pour générer et valider les exigences métier, la code review ne disparaîtra pas de sitôt ; une spécification suffisamment détaillée devient déjà presque du code

• Raison 2 : l’IA masque les traits et compétences fondamentaux

  • Citation de Peter Drucker : on ne peut pas embaucher seulement une paire de mains, on embauche toujours la personne entière
  • En reprenant la distinction de Lewis Mumford — tool (piloté par le travailleur humain) vs machine (fonctionnant selon sa propre logique avec une forme d’agency) —, un usage trop important de l’IA rend presque impossible la distinction entre la contribution propre de l’ingénieur et celle du modèle
  • Il faut se méfier des ingénieurs qui utilisent l’IA non comme un tool, mais comme une machine. L’IA représente un saut de productivité qui dépasse la simple autocomplétion puissante et permet d’externaliser une grande partie de la pensée. Même des domaines supposés spécifiquement humains comme le « taste » semblent menacés, au point que la liste de Fitts paraît déjà datée
  • Comme le pharmakon de Platon analysé par Derrida, l’IA est à la fois remède (automatisation du refactoring répétitif, gain de temps sur l’apprentissage des particularités d’une bibliothèque) et poison (risque d’atrophie des compétences fondamentales)
  • Un entretien qui survalorise l’IA risque d’évaluer non pas l’humain mais le modèle (« machine »). Il faut donc concevoir des exercices qui remettent le raisonnement humain au centre de l’évaluation

• Raison 3 : l’IA évolue trop vite

  • Selon Arthur Mensch (CEO de Mistral), les modèles d’IA gagnent environ une année d’expérience en software engineering tous les 12 mois. On n’entend d’ailleurs plus vraiment la blague comparant les agents IA à des stagiaires
  • La plupart des entreprises n’ont ni les moyens de créer ni ceux de maintenir des questions résistantes à l’IA qui obligent malgré tout à mobiliser les compétences fondamentales. Avec des modèles qui progressent chaque mois et auxquels on n’a pas toujours tous accès, concevoir des questions qui résistent en permanence au meilleur modèle est une bataille perdue d’avance
    • « Designing AI resistant technical evaluations » d’Anthropic est un cas d’étude où l’on « combat » l’IA plutôt que d’évaluer le candidat
  • Concevoir des take-home plus difficiles revient à autoriser la calculatrice tout en compliquant les exercices de calcul mental
  • Les bonnes pratiques autour de l’IA évoluent elles aussi tous les mois, et l’importance du prompt engineering diminue à mesure que les modèles comprennent mieux les consignes. Vérifier si un candidat connaît les techniques les plus récentes n’est donc pas un signal très utile
  • Les fundamentals, eux, ne changent pas par définition

Réponse aux objections

• À l’objection selon laquelle il n’y a pas de données : (1) les vraies expériences statistiquement significatives, de type essai randomisé contrôlé, sont presque impossibles, et aucune entreprise n’accepterait les false negatives qu’elles pourraient produire ; (2) la plupart des décisions de conception d’entretien reposent de toute façon sur un raisonnement abstrait plutôt que sur des expériences de type essai clinique
• Tricher avec l’IA (par exemple pendant l’entretien) : si cela a été explicitement interdit, l’usage d’outils d’IA constitue un motif d’élimination immédiate
  • Citation de Warren Buffett : en recrutement, on cherche l’integrity, l’intelligence et l’énergie ; sans integrity, les deux autres deviennent dangereuses. Si l’on doit recruter quelqu’un sans integrity, autant qu’il soit stupide et paresseux
• Faut-il utiliser l’IA pour évaluer les candidats ? Non. (1) C’est éthiquement problématique — on recrute un travailleur du savoir humain, pas une machine chargée d’évaluer l’ensemble de sa valeur ; (2) l’évaluation par IA est non déterministe et sujette aux hallucinations, ce qui oblige de toute façon à revoir ensuite le jugement de l’IA

Recommandations concrètes pour les entreprises

• Ne pas autoriser l’usage de l’IA dans la plupart des entretiens. Éviter de survaloriser un outil particulier et se concentrer sur les compétences fondamentales
• Investir dans les live exercises. Ils n’ont pas besoin d’être artificiels, ennuyeux, à faible signal ou très courts. Revoir les entretiens de data structure & algorithm — ils restent parmi les plus stimulants intellectuellement. Concevoir des exercices qui exigent un véritable effort humain, et conserver un grand nombre de questions pour éviter la sur-préparation à une question unique
• Mixer les formats d’entretien afin d’obtenir un signal large à coût raisonnable
• Adapter les take-home. Soit interdire explicitement l’IA, soit l’autoriser sans perdre de temps à relire des productions IA. Un take-home doit obligatoirement déboucher sur un live exercise où le candidat présente son travail, explique son approche des trade-offs, réagit à des changements d’exigences et discute de la scalabilité
• Inclure au moins un entretien évaluant les capacités de review. Le coût de conception est faible, le signal souvent intéressant, et la charge pour le candidat moindre. Exemples : plan IA, postmortem, codebase existante (Bug squash), document de product requirements, analyse de trade-offs, review d’architecture système
• Envisager de faire venir les candidats sur site. C’est la façon la plus simple d’empêcher la triche et cela rend aussi un peu plus difficile la fuite des questions. Cela ne concerne toutefois que les entreprises en RTO (retour au bureau)
• Fournir des consignes de préparation claires pour créer des conditions équitables

[roxie]

Pour moi, c’est bien pour travailler ensemble pendant une semaine.

[linusjeh]

Même cet article a sans doute été écrit avec l’IA mdr

[jjpark78]

De toute façon, on utilisera l’IA dans le travail au quotidien, donc je me demande s’il est vraiment pertinent de l’exclure. Ne vaudrait-il pas mieux supprimer les entretiens à distance, ne fonctionner qu’en présentiel, et évaluer, grâce à des questions bien conçues et à une observation sur place, comment les candidats utilisent l’IA et raisonnent avec elle, ce qui serait plus adapté à l’ère de l’IA ?

Même face à un même problème, la manière dont quelqu’un rédige son prompt en dit long sur cette personne.