L'heure la plus à contre-courant de notre processus de recrutement ne comporte aucune IA. Une base de code que le candidat n'a jamais vue, quelques tickets réels, dont un bug en production, soixante minutes avec un tech lead, et aucun agent autorisé. Les candidats en sont régulièrement surpris. Certains ont demandé si nous n'étions pas en retard.
C'est le contraire. La session sur les fondamentaux existe à cause des agents, et non malgré eux.
Voici le raisonnement, et c'est la phrase sur laquelle repose l'ensemble du livre blanc : si vous ne pouvez pas raisonner sur le système sans l'agent, vous ne pouvez pas savoir quand l'agent se trompe. Dans nos projets, 80 à 90 % du code en production est écrit par un modèle, ce qui signifie que la véritable contribution d'un ingénieur est tout ce qui entoure la génération : savoir quoi demander, lire ce qui revient, repérer l'erreur commise avec assurance. Tout cela repose sur les fondamentaux. Écrire du code est devenu facile ; comprendre comment un système s'articule, non. Alors avant d'observer qui que ce soit travailler avec un agent, nous retirons l'agent et voyons ce qui reste.
La session est délibérément ordinaire. Pas d'énigmes, pas de tableau blanc, pas d'arbres binaires. Le candidat prend en charge les tickets et avance, pendant que nous observons sa façon de travailler, en évaluant six éléments.
La compréhension technique vient en premier et se manifeste le plus vite : la maîtrise de la stack, des flux complexes de l'application, et du terminal. Les candidats les plus solides lancent l'application et inspectent la base de code avant de modifier quoi que ce soit. Les plus faibles ne lancent jamais l'application, ce qui paraît impossible jusqu'à ce qu'on l'ait vu arriver, et modifient du code qu'ils n'ont pas lu.
Le débogage, c'est le bug en production. Le bon profil, c'est travailler du symptôme vers la cause de façon structurée et tester le correctif avant de déclarer le ticket résolu. Le mauvais profil, c'est tâtonner jusqu'à ce que les erreurs disparaissent, puis fermer le ticket rapidement en laissant le problème intact. Ce critère se transpose directement à l'ère des agents, car déboguer du code généré que vous n'avez pas écrit est désormais l'essentiel du travail.
La priorisation est discrètement révélatrice. Les tickets sont accompagnés d'une urgence déclarée, et le bug en production passe toujours en premier. Un ingénieur qui traite le ticket intéressant avant le ticket urgent vous indique comment il se comportera sur votre feuille de route.
La communication est évaluée sur leur capacité à exposer les compromis et à dire ce qu'ils n'ont pas eu le temps de traiter, plutôt que de se taire, et à poser des questions quand un ticket est ambigu plutôt que de supposer. Se taire quand on est bloqué est l'un des signaux négatifs les plus clairs que nous observons. Le niveau d'anglais s'y ajoute : compris et compréhensible, à l'oral comme à l'écrit, suffisamment pour défendre un point sous une question de suivi plutôt que de simplement le réciter. Quand la majeure partie du code est écrite par un agent, la façon dont quelqu'un partage le contexte compte au moins autant que sa compétence technique, ce qui explique aussi pourquoi un entretien culture et une vérification des références suivent les sessions techniques.
Et l'hygiène de changement de contexte : garder la trace des tickets ouverts et de l'avancement de chacun, reprendre une tâche sans tout relire. Nous l'évaluons à nouveau lors de la deuxième session avec les agents actifs, car cela concerne l'ingénieur et non les outils, et orchestrer quatre agents avec un mauvais suivi des tâches ne produit que quatre flux de travail confus au lieu d'un.
Remarquez ce que cette grille d'évaluation mesure vraiment. Rien n'y est nouveau. Chaque élément aurait décrit un bon ingénieur en 2015. Ce qui a changé, c'est à quoi servent ces éléments : ils constituaient autrefois le travail lui-même, et désormais ils représentent la licence pour faire le travail, ce qui donne à la vérification par un ingénieur de la production d'un agent toute sa valeur. C'est pourquoi la session sur les fondamentaux précède la session AI-native et pourquoi l'échec à cette étape met fin au processus. Il ne reste rien à mesurer pour la deuxième session.
Cela clôt six semaines de publications construites autour de The Next 10X Engineer : ce qu'est le métier aujourd'hui, ce que signifie AI-native, pourquoi les anciens filtres ont cessé de fonctionner, la grille d'évaluation AI-native, et maintenant les fondamentaux qui sous-tendent tout cela. Le livre blanc contient les deux sessions et les deux grilles d'évaluation dans leur intégralité, et le standard de sélection est public.
Une question pour conclure, dans l'esprit de celle du début. Votre processus d'entretien teste presque certainement encore les fondamentaux. Mais si un agent s'était assis à côté de votre dernière recrue dès le premier jour, votre processus vous aurait-il indiqué si elle est capable de vérifier son travail, ou seulement si elle aurait pu faire ce travail elle-même en 2021 ?
Téléchargez The Next 10X Engineer pour accéder aux deux évaluations et aux deux grilles d'évaluation. Le benchmark des responsables ingénierie est ouvert, et les contributeurs reçoivent le rapport en avant-première.
