Jusqu'en 2024, nous recrutions comme la plupart des entreprises le font encore. Un exercice à domicile ou un projet de démonstration, quelques questions de code, une discussion sur ce qu'ils avaient construit. Cela fonctionnait parce que construire quelque chose était difficile. Si quelqu'un livrait une application propre et fonctionnelle, cela voulait dire quelque chose.
Ce n'est plus difficile, et la conséquence est mécanique : tous les tests à domicile reçus lors de nos derniers recrutements se ressemblaient, car tous avaient été écrits par un modèle, et rien ne permet de les distinguer à l'écran. Résultat, les équipes qui s'en servent encore ne filtrent que les candidats prêts à passer une soirée à superviser un agent.
Les tests de style LeetCode ont le problème inverse. Ils mesurent quelque chose de réel, mais ce qu'ils mesurent, c'est le rappel de patterns sous contrainte de temps, ce qui n'a jamais été un bon prédicteur pour les postes senior, même avant que les outils changent. Vous n'apprendrez pas comment un ingénieur senior gère un changement de schéma en le regardant inverser un arbre binaire. Pire encore, le rappel que ces tests récompensent est précisément le travail que les agents ont absorbé. Vous sélectionneriez le plus rigoureusement sur la compétence qui compte le moins.
Ce qui est cassé, en une phrase : les processus de recrutement ont été conçus pour évaluer les livrables, et les livrables ont cessé de porter de l'information sur la personne. Aucun des deux formats ne révèle plus les fondamentaux, ni les compétences en matière d'agents. Nous avons donc remplacé les deux par deux sessions de travail dans une base de code réelle, l'une sans agents et l'autre avec, où nous observons comment les gens travaillent concrètement.
Aucune des deux sessions ne se suffit à elle-même. Ce sont les troisième et quatrième étapes d'un processus plus long : l'examen du CV selon une grille d'évaluation et un appel de présentation de trente minutes les précèdent, un entretien culturel et la vérification des références les suivent, car lorsque la majeure partie du code est écrite par des agents, la façon dont quelqu'un partage le contexte et travaille avec les personnes qui l'entourent compte au moins autant que ses compétences techniques.
La première session teste les fondamentaux, sans IA. Le candidat reçoit une base de code qu'il n'a jamais vue, quelques tickets réels, dont un bug en production, et dispose de soixante minutes. C'est une session de travail normale, pas un test : il prend en charge les tickets et avance, pendant que nous observons. Écrire du code est devenu facile, mais comprendre comment un système s'articule ne l'est pas, et si les fondamentaux font défaut, le candidat n'a rien pour valider la production d'un agent. Ce que « bon » signifie est précis : lire le flux de données et les modes de défaillance avant de toucher au code, traiter le bug de production en premier et être capable d'expliquer ce qu'il affecte, trouver la cause racine plutôt que le symptôme, ajouter le test qui aurait détecté le bug. Ce tour repère les personnes qui ont servi de relais à un LLM pendant quelques années de travail à distance, ce qui est plus courant que le secteur ne veut bien l'admettre. C'est aussi là que nous découvrons s'ils peuvent parler de l'architecture d'un système de façon fluide en anglais, critère sur lequel nous sommes plus exigeants que la plupart.
La deuxième session a la même forme de travail avec la contrainte inverse : un nouvel ensemble de tickets, et les outils d'IA pour le code que le candidat utilise normalement. Nous observons alors ce qu'il fait lorsqu'un agent réalise l'essentiel du travail, évalué selon six critères : s'il vérifie ce que l'agent produit, comment il orchestre les outils, s'il décompose le travail en morceaux avant de générer, comment il paramètre les prompts et le contexte, comment il débogue, et s'il garde la trace de tout ce qu'il a commencé. S'il planifie d'abord, s'il lit ce qui revient, et s'il peut expliquer un changement qu'il n'a pas tapé.
Cette deuxième session est celle où un candidat récent avec treize ans d'expérience s'est effondré. Son CV était bon et la session sur les fondamentaux s'était bien passée. Puis il a eu le droit d'utiliser des agents, et à partir de ce moment il a cessé de lire. Chaque modification a été acceptée, chaque prompt a reçu un « allez-y », et il a fermé des tickets sans en vérifier aucun. La plupart des entreprises l'auraient recruté. Nous aussi, il y a deux ans, parce que la plupart des processus ne voient jamais l'heure que nous avons vue. Si vous filtrez encore sur des exercices à emporter et des tests de code, il passe vos entretiens en ce moment même, et vous le découvrirez quand son code arrivera en revue.
Si vous reconstruisez votre propre processus, la structure en deux sessions est le principe qui mérite d'être retenu, plus qu'une tâche précise. Les fondamentaux sans l'agent, parce que ce sont eux qui rendent la vérification possible. Un travail réel avec l'agent, parce que c'est le métier. Les parties du recrutement qui n'ont jamais porté sur l'artefact, le filtrage, l'entretien culture, les références, conservent leur rôle habituel ; si tant est que la vérification des références compte davantage maintenant.
Et si vous évaluez un prestataire plutôt qu'un candidat, la même logique s'applique avec un élément supplémentaire : demandez à voir le processus. Toute société qui place des ingénieurs devrait être en mesure de vous montrer ce qu'elle teste, comment c'est noté et pourquoi des personnes échouent. Nous publions le nôtre intégralement. Un processus de sélection qui ne peut pas survivre à sa publication mesurait les mauvaises choses.
Le processus complet, avec les deux grilles d'évaluation et des exemples de bonnes et mauvaises réponses pour chaque entretien, se trouve dans The Next 10X Engineer. Si vous souhaitez comparer vos pratiques de recrutement actuelles à celles d'autres responsables, le benchmark des responsables ingénierie est ouvert.
