L’entretien pensé pour l’IA

Les agents de programmation comme Codex et Claude Code transforment profondément la manière de concevoir des logiciels. Le rôle des équipes d’ingénierie évolue : elles passent de la construction du système à sa conception, son pilotage et son amélioration continue. À l’image des ingénieurs qui ont cessé de se soucier de la manière dont un compilateur traduit leur code en instructions machine, nous devons aujourd’hui moins nous focaliser sur les lignes de code produites et davantage sur la capacité du système à générer, de manière fiable, les résultats attendus.

Cela change profondément ce que nous devons évaluer lors des entretiens. Lorsqu’un seul ingénieur peut intervenir sur l’ensemble de la stack, sa véritable valeur réside dans la combinaison de ses compétences techniques, de son sens du produit et de sa compréhension des enjeux métier. Il ne se contente plus d’écrire du code : il définit le périmètre, arbitre entre différentes approches et collabore étroitement avec les clients pour maximiser l’impact. C’est pourquoi nous avons entièrement repensé notre processus de recrutement des ingénieurs afin qu’il reflète cette nouvelle réalité.

Cadrer le problème

Jusqu’à récemment, le processus d’entretien technique de Sierra était relativement classique : deux entretiens de programmation, suivis d’évaluations sur les algorithmes, la conception de systèmes et l’adéquation avec notre culture d’entreprise, puis de prises de références. C’est une approche éprouvée, facile à déployer à grande échelle, qui nous a longtemps donné de bons résultats.

Mais, récemment, quelque chose a commencé à ne plus coller. La plupart des signaux que nous tirions de ces entretiens portaient sur des aspects très mécaniques : écrire du code dans un éditeur, se souvenir de détails d’algorithmes ou assembler des frameworks. Or, cela reflétait de moins en moins la réalité de notre travail.

Ce décalage était particulièrement visible lors des débriefings. Faute de signaux suffisamment discriminants issus des entretiens, les responsables du recrutement accordaient de plus en plus de poids aux recommandations et à l’expérience passée des candidats.

Nous avons donc conçu un processus d’entretien pensé pour l’ère de l’IA, articulé autour de trois principes fondamentaux :

• Représentatif : il reflète le travail que les ingénieurs réalisent au quotidien, en mettant en lumière leur capacité à prendre des initiatives, à assumer des responsabilités, à exercer leur jugement, à comprendre des systèmes complexes et à raisonner en termes de produit.
• Discriminant : il nous fournit des signaux clairs sur les domaines dans lesquels un candidat excelle, ainsi que sur ceux où il aura besoin d’accompagnement.
• Engageant : il offre aux candidats une expérience authentique et stimulante, afin que, lorsque nous leur faisons une offre, ils aient réellement envie de nous rejoindre.

Présentation de notre entretien sur site pensé pour l’ère de l’IA

Nous avons remplacé nos entretiens de programmation et d’algorithmique par un nouvel entretien sur site, conçu pour refléter la réalité du développement logiciel à l’ère de l’IA.

Conception

L’entretien débute par une session de travail au cours de laquelle le candidat imagine un produit à concevoir. Il mène la réflexion, tandis que les intervieweurs l’aident à approfondir son idée en posant des questions. Nous choisissons un sujet en lien avec son domaine d’expertise afin d’observer concrètement sa manière d’aborder un problème produit.

Construction

Les intervieweurs se retirent ensuite et le candidat dispose de deux heures pour concrétiser son idée, en utilisant les outils d’IA et les frameworks de son choix. Il est libre de faire évoluer ou de redéfinir le périmètre du projet au fil de l’exercice, comme il le ferait dans un contexte réel.

Évaluation

Enfin, le candidat présente ce qu’il a construit. Nous échangeons sur les principaux parcours utilisateurs et sur les choix de conception qu’il a réalisés. Nous passons également le code en revue afin de comprendre ses arbitrages techniques (modèle de données, abstractions, extensibilité, etc.) ainsi que sa vision du passage en production. Enfin, nous analysons en détail la manière dont il a utilisé les outils d’IA tout au long de l’exercice.

Nous avons rapidement constaté que ce nouveau format était bien plus efficace. En donnant aux candidats l’occasion de construire un produit pendant l’entretien, plutôt que de simplement expliquer ce qu’ils feraient, il reflète beaucoup plus fidèlement la réalité du travail et fournit des signaux plus pertinents. Il devient notamment plus facile d’évaluer leur capacité d’initiative — changent-ils d’approche lorsqu’ils se retrouvent bloqués ? — ainsi que leur jugement : comment définissent-ils le périmètre de ce qu’ils vont construire compte tenu du temps dont ils disposent ?

L’expérience est également plus engageante, même si les candidats sont souvent un peu nerveux au départ. Pour les mettre dans les meilleures conditions, nous partageons en amont les critères d’évaluation ainsi que quelques recommandations. Nous leur expliquons, par exemple, qu’il est tout à fait acceptable de réduire le périmètre au fil de l’exercice et de laisser de côté les fonctionnalités standard (CRUD, authentification, etc.) pour se concentrer sur ce qui fait réellement la valeur du produit.

Comme l’a résumé Paul Buchheit, le créateur de Gmail : « Si c’est excellent, cela n’a pas besoin d’être parfait. »

Compléter le reste du processus

À mesure que nous avons fait évoluer notre entretien sur site pensé pour l’ère de l’IA, nous avons également repensé le reste de notre processus de recrutement. Notre entretien téléphonique de programmation demandait encore aux candidats d’écrire du code, sans assistance IA, dans un éditeur en ligne. Or, aujourd’hui, développer rapidement une application n’est plus le véritable défi. Ce qui compte désormais, c’est de concevoir des systèmes capables d’être déployés et de monter en charge de manière fiable. Nous avons donc remplacé cet entretien par un entretien de conception de systèmes, plus représentatif du travail réel.

Si notre entretien sur site évalue la capacité des candidats à imaginer un produit et à le construire de zéro, il mesure moins bien leur aptitude à faire évoluer une fonctionnalité dans une base de code existante, complexe et utilisée en production. Pour compléter cette évaluation, nous expérimentons un entretien de débogage.

Les candidats reçoivent une base de code de taille intermédiaire ainsi qu’une ébauche de pull request rédigée par un collègue, qui introduit une nouvelle fonctionnalité transverse. Leur mission consiste à relire cette proposition, à l’améliorer, à exécuter le code localement, à comprendre son comportement, puis à collaborer avec des agents de programmation pour l’optimiser.

Le niveau d’assistance IA autorisé pendant cet exercice reste encore à définir. Les modèles les plus récents sont désormais capables d’identifier et de corriger de nombreux problèmes dès la première tentative (zero-shot), ce qui nous conduit à repenser en permanence la manière d’évaluer les compétences des candidats.

Qu’avons-nous appris ?

Nous recrutons avant tout pour les points forts des candidats, et pas uniquement pour l’absence de faiblesses. Cette approche nous fournit des signaux beaucoup plus riches sur leurs forces, mais aussi sur les domaines dans lesquels ils pourront progresser. Par exemple, certains candidats se distinguent par leur vision produit et leur capacité à prendre des initiatives, tout en ayant encore des lacunes dans leur compréhension des systèmes. Nos débriefings ne se résument plus à la question : « Devons-nous recruter cette personne ? », mais plutôt à celle-ci : « Dans quel environnement pourra-t-elle exceller, et comment pouvons-nous l’aider à réussir ? »

Nous demandons systématiquement un retour d’expérience aux candidats, et beaucoup nous disent qu’il s’agit de l’entretien le plus stimulant qu’ils aient passé. Un passionné de quiz a, par exemple, conçu un jeu propulsé par l’IA pour maintenir les joueurs dans un état de flow ; sa démonstration consistait simplement à nous inviter à y jouer. Dans un autre cas, un ingénieur backend a développé un outil de simulation sans interface graphique (headless) et s’est appuyé sur un agent piloté par un fichier Markdown pour présenter son travail.

Ce format présente néanmoins certains défis. Parce qu’il est volontairement ouvert, il est aussi plus difficile à standardiser. Pour y remédier, nous avons défini une grille d’évaluation fondée sur des critères indépendants de ce que les candidats choisissent de construire, et nous conduisons chaque entretien à deux intervieweurs afin de garantir une évaluation plus cohérente.

Nous nous sommes également demandé si cette approche convenait aux profils spécialisés dans l’infrastructure. Notre réponse est oui. Aujourd’hui, de nombreux ingénieurs infrastructure développent eux aussi des outils ou des agents full-stack et collaborent étroitement avec les équipes produit afin de répondre directement aux besoins des clients. Nous avons toutefois adapté certains aspects de l’entretien afin de mieux évaluer les compétences spécifiques à ces profils.

L’émergence d’agents de développement toujours plus performants nous pousse à repenser en profondeur notre façon de travailler chez Sierra. Elle transforme notre manière de concevoir nos produits — en utilisant des agents pour créer et optimiser d’autres agents avec Ghostwriter — mais aussi notre façon de recruter. Au rythme où évoluent ces technologies, ce n’est que le début.

Et oui, nous recrutons toujours. Si vous souhaitez participer à la construction de cette nouvelle génération de logiciels avec nous, découvrez nos opportunités ici : sierra.ai/fr/careers.