Recruter des ingénieurs juniors : évaluer l'initiative à l'ère de l'IA

Recruter des ingénieurs juniors pour leur esprit d’initiative suppose d’examiner comment ils choisissent un problème, vérifient une hypothèse et s’appuient sur les faits pour décider de la suite. Donnez aux candidats des conditions comparables pour montrer ces capacités. Un prototype fonctionnel peut y contribuer, tout comme une décision étayée de ne rien développer.

Cette dernière possibilité compte d’autant plus qu’une démonstration convaincante demande moins d’efforts. Vous pouvez admirer ce qu’un candidat a réalisé sans savoir si le problème méritait son attention. La question utile se pose avant le code : qu’a-t-il remarqué, et pourquoi s’y est-il intéressé ?

Que change l’idée selon laquelle « l’envie compte plus que l’ancienneté » pour le recrutement junior ?

L’essai publié le 27 octobre par Felix Rieseberg offre un point de départ encourageant. Il y explique avoir modifié ses propres entretiens de code et vu de nouveaux arrivants réaliser des choses utiles avec l’IA. Ses conseils s’adressent aussi aux personnes expérimentées qui rejoignent une organisation sans y avoir encore de statut ni d’influence. Un prototype ciblé permet à une personne qui dispose de peu de reconnaissance de rendre une idée concrète. Il reconnaît aussi ne pas avoir encore arrêté le format d’entretien qui remplacera le précédent.

Pour un responsable du recrutement, il s’agit ensuite de traduire cette intuition en questions précises. Prendre des initiatives, c’est notamment décider à quoi consacrer ses efforts. Un ingénieur peut remettre en question une exigence familière, examiner une plainte récurrente des clients ou découvrir qu’un obstacle apparemment technique tient à une règle sur laquelle personne ne s’est prononcé.

Aucune de ces contributions n’exige de parler plus fort que les autres en réunion. Un candidat qui demande discrètement pourquoi une exigence existe montre peut-être exactement le comportement recherché. Encore faut-il distinguer une question utile d’une assurance séduisante.

Cette réflexion repose sur une idée plus ancienne. Dans son essai de 2011 sur les carrières, Patrick McKenzie relie le travail des ingénieurs à la valeur créée pour l’entreprise. En recrutement, cela revient à demander ce qui s’améliore pour un client ou un collègue. Cela ne signifie pas exiger d’un candidat inexpérimenté qu’il invente une stratégie de revenus sans connaître votre entreprise.

Donnez-lui assez de contexte pour repérer une contribution utile. Vous examinez sa manière de raisonner à partir des informations auxquelles il peut avoir accès.

Pourquoi une démonstration plus rapide ne suffit-elle pas ?

Les recherches sur la productivité avec l’IA invitent à examiner les conditions de travail avant de tirer des conclusions sur une personne. Elles ne démontrent ni que les juniors surpassent généralement les ingénieurs expérimentés, ni l’inverse.

Les expériences menées en entreprise par Cui et ses collègues ont porté sur 4 867 développeurs. Leurs résultats regroupés font apparaître une hausse d’environ 26 % du nombre de tâches terminées avec un assistant de programmation IA. La version de travail complète aborde prudemment les différences selon l’expérience et l’ancienneté : les tendances par sous-groupe étaient indicatives et généralement non significatives sur le plan statistique. Ces expériences, menées avec des assistants de programmation antérieurs, mesuraient le nombre de tâches accomplies. Elles ne testaient pas le discernement sur les enjeux de l’entreprise avec les agents actuels.

De son côté, l’étude observationnelle de Daniotti et de ses collègues sur GitHub a constaté des gains concentrés chez les développeurs les plus expérimentés. L’expérience désignait ici le nombre d’années d’activité sur GitHub, et non un niveau d’expérience professionnelle vérifié. L’usage de l’IA était déduit des observations, et les contributions servaient à mesurer la production. Ces choix font que l’étude porte sur une question différente de celle des expériences randomisées menées en entreprise.

Pour vos entretiens, la conséquence est concrète. Notez les outils utilisés, ce que la personne comprenait avant de s’en servir et la manière dont elle a vérifié le résultat. Ne déduisez pas son potentiel d’une catégorie générale comme junior, familier de l’IA ou expérimenté.

Il faut aussi distinguer une démonstration de l’engagement à faire fonctionner le produit dans la durée. Un prototype peut montrer qu’une interaction est possible. Il ne dit pas encore si les clients la souhaitent, si elle s’intègre au produit existant ni qui en assurera le suivi. Les questions à poser une fois la solution de code validée permettent d’examiner les choix de réalisation. Mais une autre question les précède : était-il utile de chercher cette solution ?

Distinguez l’initiative des occasions qui se sont présentées

Un portfolio montre ce qu’un candidat peut vous présenter. Il ne révèle pas toutes les occasions qu’il a eues, ni toutes les contributions utiles qu’il était autorisé à rendre publiques.

La personne peut avoir un grand projet personnel, un exemple professionnel confidentiel, une contribution à une association ou très peu de réalisations achevées. Interrogez-la sur les décisions prises avant de valoriser l’ampleur du projet. Un petit changement réalisé sous de vraies contraintes peut donner lieu à un échange plus instructif qu’une application élaborée dont l’utilité reste floue.

Proposez ensuite une autre possibilité. Un candidat qui ne peut pas partager ses travaux antérieurs doit pouvoir examiner un problème circonscrit que vous lui fournissez. Donnez à chacun le même contexte de base, les mêmes règles d’utilisation des outils, la charge de travail prévue et une définition de ce qui constitue une réponse utile. Si l’accès à un outil d’IA compte, prévoyez des conditions d’accès comparables, plutôt que de faire d’un abonnement personnel un prérequis tacite.

Les recommandations de l’Office of Personnel Management des États-Unis sur les entretiens structurés préconisent des questions communes et des critères cohérents pour évaluer les compétences liées au poste. C’est un principe d’organisation pertinent ici. Il ne valide pas cet exercice particulier et ne transforme pas une impression subjective en indicateur prédictif éprouvé.

Précisez ce que vous attendez déjà d’un junior. Les recommandations de l’OPM sur les échantillons de travail distinguent les compétences requises à l’embauche de celles qui seront enseignées ensuite. Si vous comptez former la personne à votre domaine produit, laissez l’exercice révéler comment elle s’y familiarise. Ne présentez pas une méconnaissance du contexte interne comme un manque d’initiative.

Des conditions claires aident aussi les candidats à décider s’ils souhaitent participer. Indiquez le temps maximal à consacrer à l’exercice, les usages de l’IA autorisés, le format attendu et la manière de poser des questions. Notre guide pour tester les consignes d’un exercice à domicile détaille ce travail de préparation.

Donnez aux candidats un problème qui mérite d’être étudié

Choisissez un exercice qui autorise plusieurs suites raisonnables. Si la seule réponse acceptable est la fonctionnalité que vous avez en tête, vous mesurez l’accord avec une réponse attendue que vous n’avez pas annoncée.

Prenons une startup fictive dont les nouveaux clients partent souvent avant d’inviter un collègue. L’équipe soupçonne que le parcours d’invitation doit être revu. Vous recrutez un ingénieur produit junior et préparez donc un dossier fictif : un schéma simple du parcours, des exemples de demandes d’assistance, quelques sessions d’utilisation illustratives et l’écran d’invitation actuel.

Demandez au candidat de recommander une prochaine action pour mieux comprendre ou réduire cette difficulté lors des premiers usages. Expliquez l’objectif du produit, les limites du dossier et les questions qu’il peut poser à son interlocuteur. Une courte explication écrite, un croquis ou un petit prototype conviennent. La qualité de l’analyse compte davantage que la quantité produite.

Un premier candidat développe immédiatement une fenêtre d’invitation plus simple. Le travail peut être bon. Demandez-lui quels éléments l’ont amené à intervenir à cet endroit. Sait-il distinguer une difficulté à envoyer une invitation d’une absence de raison d’inviter quelqu’un à ce stade ?

Un autre remarque que plusieurs utilisateurs de l’exemple évaluent seuls le produit avant de demander une autorisation. Il se demande s’il est réellement nécessaire d’inviter un collègue pour en découvrir la valeur. La personne qui mène l’entretien explique que l’évaluation individuelle est autorisée, mais que les textes du parcours d’intégration laissent croire que les invitations sont obligatoires.

Le candidat peut alors choisir une suite pertinente. Il pourrait réaliser le prototype d’un parcours plus clair pour les personnes qui évaluent seules le produit, proposer de tester de nouvelles consignes avant de modifier l’interface ou recommander de recueillir des informations sur les raisons des départs avant d’y consacrer du temps de développement.

Supposons qu’il retienne cette dernière option. Il cerne l’hypothèse incertaine : partir sans inviter quelqu’un ne signifie pas nécessairement que le parcours d’invitation a échoué. Il propose un court échange avec des personnes qui acceptent de participer et précise quelles réponses justifieraient une modification du produit. Il relève aussi une limite : les sessions fournies ne permettent pas de savoir si une personne qui quitte le produit y revient plus tard.

Cette réponse peut ne contenir aucune ligne de code. Elle peut néanmoins montrer de l’initiative à travers une question pertinente, une autre explication plausible et une vérification susceptible de modifier la décision. L’interlocuteur doit examiner si le test proposé permettrait vraiment de départager ces explications. Demander davantage de recherche ne doit pas non plus devenir automatiquement la bonne réponse.

Fixez des limites nettes à l’exercice. Il s’agit d’une proposition dont la validité prédictive n’a pas été établie. Utilisez des éléments fictifs ou préparés de manière appropriée, et ne faites pas des candidats une équipe non rémunérée chargée d’explorer votre produit. Si le travail devient une mission commerciale substantielle, définissez-la et rémunérez-la séparément.

Demandez ce qui a fait évoluer la décision

Une évaluation utile retrace les décisions du candidat, depuis les informations disponibles jusqu’à l’action proposée. Un autre évaluateur doit pouvoir comprendre pourquoi vous avez trouvé le travail prometteur ou préoccupant.

Dans notre exemple, notez que le candidat a interrogé le sens de l’indicateur d’invitation et l’a rapproché de l’objectif de la personne qui évaluait le produit. Consignez les informations fournies pendant l’entretien, puis la manière dont il s’en est servi. Bien exploiter un indice ne constitue pas le même élément d’évaluation que repérer le problème seul.

Quelques questions communes permettent de garder l’échange précis :

• Pourquoi ce problème méritait-il d’être étudié avant les autres que vous avez remarqués ?
• Quelle contrainte avez-vous vérifiée, et en quoi la réponse a-t-elle modifié votre approche ?
• Quel résultat vous ferait abandonner l’action que vous proposez ?
• Que reste-t-il à découvrir, et qui faudrait-il associer à la suite ?

Écoutez si le raisonnement tient face à une objection raisonnable. Si le candidat propose de nouveaux textes d’intégration, demandez ce qu’il faudrait faire si les utilisateurs continuaient à partir. S’il propose une recherche, demandez pourquoi l’information obtenue en vaudrait le coût. Savoir réviser sa position apporte davantage d’éléments utiles que savoir défendre instantanément chaque choix.

Évitez de transformer chaque observation en jugement de personnalité. « A demandé si l’évaluation individuelle était possible » est précis. « A l’énergie d’un fondateur » n’apprend pas grand-chose à l’évaluateur suivant. Cette formule peut aussi masquer un désaccord sur le travail attendu de votre future recrue.

Vous pouvez préférer une approche tout en reconnaissant la réflexion menée dans une autre. Accordez-vous sur les comportements liés au poste avant de discuter du candidat qui vous a le plus impressionné. Distinguez assez clairement les observations, leurs limites et votre recommandation pour qu’un collègue puisse contester votre raisonnement.

Que montrer sans disposer d’un grand portfolio ?

Choisissez un exemple dont vous pouvez expliquer une décision. Le projet n’a pas besoin d’être vaste, public ni couronné de succès commercial, à condition que vous soyez autorisé à en parler.

Vous pourriez présenter une tâche manuelle récurrente que vous avez étudiée, une consigne ambiguë que vous avez testée auprès de ses utilisateurs ou une fonctionnalité que vous avez cessé de développer après en avoir appris davantage. Expliquez ce que vous pensiez au départ, ce que vous avez vérifié et ce qui s’est passé ensuite. Si vous ne pouvez pas confirmer un résultat, décrivez vos observations plutôt que d’inventer un bénéfice pour l’entreprise.

Lorsque l’IA vous a aidé, précisez la répartition du travail. Elle a peut-être proposé plusieurs pistes, écrit une première version ou aidé à analyser une erreur. Montrez à quel moment vous avez choisi parmi ses suggestions, vérifié une affirmation ou rejeté une réponse. Une liste d’outils donne moins de matière à examiner qu’une décision que vous savez justifier.

Vous pouvez aussi expliquer ce que vous feriez avec un meilleur accès aux informations ou aux moyens nécessaires. Précisez la question sur les clients à laquelle vous n’avez pas pu répondre ou l’autorisation dont vous auriez besoin pour un test. Vous montrez ainsi que vous connaissez les limites des éléments dont vous disposez. Ne divulguez pas les informations confidentielles d’un employeur pour rendre votre récit plus impressionnant.

Si l’employeur demande un nouvel exercice, renseignez-vous sur l’effort attendu et les critères d’évaluation. Vous devez savoir si un prototype est nécessaire ou si une recommandation argumentée convient. Connaître les limites de la tâche permet de consacrer votre effort à la question réellement posée.

Que doivent les managers aux ingénieurs qui portent un regard neuf ?

Donnez aux nouveaux arrivants un moyen de questionner les hypothèses tant qu’ils les remarquent encore. Recruter quelqu’un pour son esprit d’initiative a peu de sens si chaque question exige ensuite une influence qu’il n’a pas encore acquise.

Les travaux de James March publiés en 1991 sur l’apprentissage organisationnel proposent une explication utile. Ses modèles examinent comment les convictions peuvent perdre en diversité au sein d’une organisation à mesure que ses membres apprennent les pratiques établies. L’apport des nouveaux arrivants vient de leurs perspectives différentes, et non de connaissances supérieures en moyenne. Il s’agit d’une théorie des organisations, pas d’une preuve que l’inexpérience rend un ingénieur plus compétent dans l’usage de l’IA.

Traduisez cette idée dans le travail quotidien. Expliquez l’objectif pour le client, prévoyez un interlocuteur pour répondre aux questions et accordez à l’ingénieur du temps de travail pour examiner une piste circonscrite. Aidez-le à distinguer une contrainte technique réelle d’une décision que personne n’a réexaminée.

Lorsque vous refusez une proposition, expliquez ce qui vous ferait changer d’avis. Lorsqu’un test échoue, reconnaissez ce qu’il a permis de clarifier. Sinon, vous apprenez aux personnes à vous présenter des récits de réussite bien préparés et à garder leurs doutes pour elles. Votre programme d’apprentissage pour ingénieurs juniors peut apporter l’accompagnement qu’un entretien ne saurait fournir.

Il faut aussi désigner la personne chargée de décider de la suite. Quelqu’un doit lire le résultat, choisir de poursuivre ou non et aider à résoudre la prochaine dépendance. Produire un prototype auquel personne ne prête attention enseigne bien peu sur l’initiative.

Gardez les éléments d’évaluation utiles dans Kit

Rassemblez le travail remis, les conditions de l’exercice et le raisonnement des évaluateurs. Vous pourrez ainsi revenir aux faits lorsque les souvenirs d’un entretien marquant commenceront à diverger.

Dans Kit, l’étape Revue de portfolio permet de recueillir les travaux antérieurs qu’un candidat est autorisé à partager. L’étape Mise en situation peut accueillir un exercice fourni par l’employeur, avec un énoncé privé, une estimation visible de l’effort attendu et un délai qui commence lorsque le candidat démarre la tâche. Les évaluateurs peuvent consigner des notes, des commentaires et des recommandations grâce au processus de revues et de retours.

Ces éléments donnent à l’équipe une base pour examiner l’initiative. Il vous appartient toujours de proposer une occasion utile de la montrer et de décider ce que les observations permettent de conclure. Commencez par un problème assez petit pour être étudié, précisez les conditions et laissez à un candidat la possibilité de montrer que la prochaine action utile consiste à poser une meilleure question.