Interviewing tactics for a post-LLM world

L'obsolescence des take-home assignments

Les exercices à domicile (take-home assignments) ont longtemps été considérés comme une alternative plus humaine aux entretiens de code en direct. Ils offraient au candidat le temps de réfléchir, de structurer son code et de livrer un résultat représentatif de son travail réel. Mais l'émergence des LLMs a fondamentalement changé la donne.

Un candidat peut désormais soumettre un exercice à Claude, ChatGPT ou tout autre assistant IA, obtenir une implémentation fonctionnelle, la peaufiner légèrement, et la présenter comme son propre travail. Le résultat sera propre, bien structuré, avec des tests et de la documentation. Il sera souvent meilleur que ce que le candidat aurait produit seul — et impossible à distinguer d'un travail authentique.

Face à ce constat, deux approches s'offrent aux recruteurs : interdire l'IA ou repenser les entretiens. L'article argumente fermement en faveur de la seconde option.

Pourquoi interdire l'IA ne fonctionne pas

Tenter d'interdire l'utilisation de l'IA pendant les processus de recrutement est une bataille perdue d'avance pour plusieurs raisons :

• Il est techniquement impossible de vérifier si un candidat a utilisé l'IA pour un exercice réalisé chez lui
• Les outils de détection de texte généré par IA sont peu fiables et produisent de nombreux faux positifs
• Interdire l'IA revient à évaluer le candidat dans un contexte qui ne reflète pas son environnement de travail réel — personne ne code sans assistance IA en 2026
• Cela crée une asymétrie injuste entre les candidats qui respectent l'interdiction et ceux qui ne la respectent pas

Stratégie 1 : creuser l'expertise spécifique

La première approche consiste à demander au candidat de parler en profondeur d'un système qu'il a réellement construit ou d'un problème qu'il a effectivement résolu. L'entretien prend la forme d'une conversation exploratoire où l'on creuse les décisions de design, les compromis acceptés, les erreurs commises et les leçons tirées.

Ce que le LLM ne peut pas simuler, c'est l'expérience vécue. Un candidat qui a réellement travaillé sur un système distribué peut expliquer pourquoi tel choix a été fait dans tel contexte, ce qui s'est passé quand ça a cassé en production, et ce qu'il ferait différemment aujourd'hui. L'IA peut générer des réponses plausibles, mais elle ne peut pas improviser des détails spécifiques issus d'une expérience réelle sous le feu des questions de suivi.

Stratégie 2 : évaluer la pensée critique sur les outputs IA

La deuxième approche inverse la dynamique : au lieu de demander au candidat de produire du code, on lui demande d'évaluer du code ou des outputs générés par l'IA. On peut présenter une architecture proposée par un LLM et demander au candidat d'identifier les problèmes, les approximations et les angles morts.

Cette approche est particulièrement pertinente car elle évalue une compétence qui sera centrale dans le travail quotidien : la capacité à utiliser l'IA de manière critique. Un bon ingénieur en 2026 n'est pas celui qui code le plus vite, c'est celui qui sait quand l'IA a raison, quand elle a tort, et pourquoi.

Les questions peuvent prendre plusieurs formes :

• Voici une architecture proposée par Claude pour ce problème. Quels sont les trois principaux risques ?
• Ce code passe les tests mais a un bug subtil. Trouvez-le.
• L'IA recommande cette approche. Dans quel contexte serait-elle inappropriée ?

Stratégie 3 : tester le jugement contextuel

La troisième approche cible le jugement — la capacité à prendre des décisions adaptées à un contexte spécifique. On présente au candidat des scénarios réalistes qui nécessitent de peser des compromis, de prioriser sous contrainte et de naviguer dans l'ambiguïté.

Ces scénarios sont difficiles à résoudre avec un LLM parce qu'ils dépendent de facteurs contextuels que l'IA ne connaît pas : la culture de l'équipe, les contraintes business, l'historique technique, les relations interpersonnelles. Le candidat doit mobiliser son expérience pour proposer des réponses nuancées, pas des réponses parfaites.

Exemples de questions :

• Votre équipe hérite d'un service legacy critique. L'IA propose une réécriture complète. Votre lead veut migrer progressivement. Quelle approche recommandez-vous et pourquoi ?
• Vous devez choisir entre livrer une feature demandée par le business et rembourser de la dette technique critique. Comment prenez-vous cette décision ?

Repenser l'évaluation, pas l'interdire

L'article conclut que le défi n'est pas de trouver comment empêcher les candidats d'utiliser l'IA, mais de concevoir des processus d'évaluation qui mesurent ce qui compte vraiment : la capacité à résoudre des problèmes dans un contexte réel, à exercer un jugement critique, et à tirer parti de l'IA comme un outil plutôt que comme une béquille.