Le développeur autodidacte

Beaucoup de personnes qui postulent en ingénierie de l’IA n’ont jamais occupé un emploi en développement logiciel. Elles travaillent dans un entrepôt, un magasin ou un hôpital, et elles apprennent le soir. Certaines construisent quelque chose de réel. Elles postulent souvent à des postes qui demandent « 4 ans ou plus ».

Yusuf est l’une de ces personnes. Il n’a pas postulé par le site d’offres d’emploi. Deux mois avant cette entrevue, il a donné une présentation de 20 minutes lors d’une rencontre locale sur l’IA appliquée. Son titre était « Ce qui a mal fonctionné dans mon outil de recherche de règlements municipaux pour mon quartier ». Joel Okafor, ingénieur dans l’équipe Claims Intelligence de Quillfield, était dans la salle. Il a lu le README dans le train du retour. Une semaine plus tard, il a proposé de recommander Yusuf. Yusuf a montré ce qu’il avait construit, et la bonne personne l’a vu. C’est une chance que vous augmentez vous-même.

YD

La personne candidate

Yusuf Demir

Chef d'équipe en entrepôt, autodidacte, créateur de Bylaw Helper

• 26
• Aucun emploi en développement logiciel
• 4 ans comme chef d'équipe en entrepôt
• Études le soir, sans diplôme
• Recommandé après une présentation à une rencontre

• Bylaw Helper (de 2025 à aujourd’hui, à code source ouvert) : système de questions-réponses sur les règlements et procès-verbaux du conseil municipal de ma ville, environ 3 800 documents publics. Recherche hybride (mots-clés et plongements (embeddings)); chaque réponse cite l’article.
• Jeu d’évaluation de 150 questions, rédigées avec deux bénévoles de mon association de quartier. Recall@5 de 0,88; 80 % des réponses entièrement correctes.
• Problème de découpage des tableaux dans les PDF trouvé et corrigé (recall@5 des questions sur les tableaux passé de 0,39 à 0,83).
• Déployé pour l’association de quartier : environ 60 utilisateurs, 400 questions par mois, coût de fonctionnement d’environ 11 $ CA par mois.
• Chef d’équipe, centre de distribution régional (de 2022 à aujourd’hui) : direction d’une équipe de nuit de 12 personnes; scripts Python pour nettoyer le rapport quotidien des erreurs de préparation de commandes.

Ce que Nadia voit avant l’appel

Nadia lit le CV à côté de l’offre d’emploi. La première exigence est de 4 ans ou plus d’expérience professionnelle en génie logiciel. Yusuf n’en a aucune, et son CV ne prétend pas le contraire.

Le reste du CV contient des chiffres précis : 150 questions, de 0,39 à 0,83, 11 $ CA par mois. Un chiffre précis est soit réel, soit facile à réfuter avec une seule question. La recommandation de Joel dit seulement : « Posez-lui des questions sur les tableaux. »

Elle note trois choses à vérifier :

• L’a-t-il construit lui-même, et sait-il pourquoi il fonctionne? Elle posera des questions sur des détails que seul le créateur connaît.
• Jusqu’où vont ses connaissances? La récupération, l’évaluation et les cas d’échec sont les aspects les plus difficiles de ce poste.
• Qu’est-ce qu’il n’a jamais eu à faire? Révision de code, garde, passage à grande échelle, données personnelles. Voilà ce que l’exigence de « 4 ans ou plus » vise vraiment.

Termes utilisés sur cette page

• RAG (génération augmentée par récupération) : le système cherche d’abord du texte pertinent. Il donne ensuite ce texte à un modèle de langage pour rédiger la réponse.
• Plongement : une liste de nombres qui représente le sens d’un texte. Les textes dont le sens est semblable obtiennent des nombres semblables.
• Segment : un des petits morceaux obtenus en découpant les documents avant d’y faire des recherches.
• Jeu d’évaluation : un ensemble fixe de questions dont on connaît les bonnes réponses. Vous l’utilisez pour mesurer le système de la même façon chaque fois.
• Recall@5 : la proportion de questions où au moins une source correcte apparaît dans les 5 premiers résultats de recherche. Cette mesure évalue la recherche, pas la réponse.
• BM25 : une formule courante qui mesure à quel point un texte correspond aux mots-clés d’une question.
• Similarité cosinus : un score qui mesure la proximité de deux plongements, donc la ressemblance du sens de deux textes.
• Fusion des rangs réciproques : une méthode qui combine deux listes classées en utilisant seulement les positions, pas les scores. C’est important, car les scores de mots-clés et de sens utilisent des échelles différentes.
• Tâche cron : une tâche qu’un ordinateur exécute automatiquement selon un horaire, par exemple chaque nuit.
• VM (machine virtuelle) : un ordinateur loué dans le nuage.
• OCR (reconnaissance optique de caractères) : logiciel qui transforme une image de texte, comme un formulaire numérisé, en texte. Il fait des erreurs, surtout avec l’écriture manuscrite et les nombres.
• LLM comme juge : un modèle de langage qui note la sortie d’un autre modèle à la place d’une personne. C’est rapide et peu coûteux, mais il fait ses propres erreurs.
• PII (renseignements permettant d’identifier une personne) : renseignements qui identifient une personne, comme un nom, une adresse ou un numéro de police d’assurance.

L’entrevue

Minutes 0 à 5 : le début

Nadia(intervieweur) :

Bonjour Yusuf, je suis Nadia. Je suis ingénieure principale en IA dans l’équipe Claims Intelligence. J’ai développé la plupart de notre système d’extraction à la réception. Alors, voici le plan : vous me parlez d’abord de quelque chose que vous avez construit, et je pose beaucoup de questions. C’est normal. Ensuite, un problème que nous avons, puis vos questions. Et comme indiqué dans l’invitation, pas d’assistants d’IA dans cette étape. Vous pouvez prendre des notes sur papier. Ça vous va?

Yusuf(personne candidate) :

OK, oui. Je dois dire que c’est ma première entrevue comme ça. Si je parle trop longtemps, arrêtez-moi, s’il vous plaît.

Nadia(intervieweur) :

Je le ferai, ne vous inquiétez pas.

Minutes 5 à 25 : le projet, puis les détails

Nadia(intervieweur) :

Joel dit que votre présentation était bonne. Parlez-moi de Bylaw Helper. C’est quoi, qui l’utilise, comment ça fonctionne?

Yusuf(personne candidate) :

Alors, dans notre association de quartier, les gens posent toujours les mêmes questions. Est-ce que je peux construire une clôture de cette hauteur? Qu’est-ce que le conseil a décidé pour la piste cyclable? Les réponses sont publiques, mais elles sont dans environ 3 800 documents. Environ 1 100 sont des règlements et des modifications, le reste, c’est des procès-verbaux du conseil. Surtout des PDF. Personne n’arrive à bien chercher dedans.

Alors j’ai construit un système de questions-réponses. Vous posez une question en anglais courant, il trouve les articles. Puis un modèle de langage écrit une réponse courte avec l’article, comme « Règlement 2019-114, article 4.2(b) ». C’est de la génération augmentée par récupération, du RAG, en gros. La recherche est hybride. La recherche plein texte de Postgres pour les mots-clés, et des plongements (embeddings) dans pgvector, et je combine les deux. Environ 60 personnes l’utilisent. Et j’ai 150 questions de test, deux bénévoles m’ont aidé à les écrire. Comme ça, je peux mesurer quand je change quelque chose.

Nadia(intervieweur) :

OK. Restons sur les segments. Comment avez-vous découpé les documents?

Yusuf(personne candidate) :

Au début, j’ai fait comme tous les tutoriels. 512 jetons (tokens), avec un chevauchement de 64. Ça fonctionnait mal.

Nadia(intervieweur) :

Mal comment?

Yusuf(personne candidate) :

Un article de règlement, c’est court. La médiane est, je pense, autour de 90 jetons. Donc un segment avait cinq ou six articles, et la référence pointait vers le mauvais. Et les segments coupaient les sections.

Alors maintenant, je découpe selon la structure du document. Un segment correspond à une sous-section, maximum environ 350 jetons. Et il ne dépasse jamais le… comment dire, le bord de la section. La limite. Et chaque segment reçoit un en-tête, comme « Règlement sur les clôtures 2019-114, partie 4 Hauteur, article 4.2 ».

Nadia(intervieweur) :

Pourquoi l’en-tête?

Yusuf(personne candidate) :

Parce que l’article seul dit juste « la hauteur maximale est de 2,0 mètres ». Le mot « clôture » est seulement dans le titre. Sans l’en-tête, pour une question sur une clôture, aucune des deux recherches ne le trouve.

Ce que l’intervieweur vérifie

Il n’existe pas de « meilleure taille de segment ». Nadia veut savoir s’il a choisi ses segments à partir de ses propres données. « Le mot clôture est seulement dans le titre » est quelque chose qu’on sait seulement après avoir examiné les documents soi-même.

Nadia(intervieweur) :

Et vous combinez deux classements. Comment?

Yusuf(personne candidate) :

La fusion des rangs réciproques. Pour chaque liste, chaque segment reçoit un divisé par la somme de soixante et de son rang. Puis on additionne. D’abord, j’ai essayé une somme pondérée des scores. Mais ts_rank et la similarité cosinus ne sont pas sur la même échelle. Et ts_rank n’est même pas du vrai BM25. Chaque fois que je changeais quelque chose, le meilleur poids changeait. Avec les rangs, je n’ai pas ce problème.

Nadia(intervieweur) :

Est-ce que ça a aidé? Avez-vous des chiffres?

Yusuf(personne candidate) :

Oui. Sur les 150 questions, le rappel à 5 avec les mots-clés seuls était autour de 0,63. Les plongements seuls, 0,71, je pense. Et la recherche hybride, 0,84. Le tableau est dans le README. Les plongements aident quand les gens disent « logement pour les grands-parents » et que le règlement dit « logement accessoire ».

Nadia(intervieweur) :

Qui a décidé quel article était correct pour chaque question?

Yusuf(personne candidate) :

Dans la réponse? Le modèle choisit parmi les premiers segments, et ensuite…

Nadia(intervieweur) :

Non, pardon, je veux dire dans vos données de test. Qui a noté l’article correct?

Yusuf(personne candidate) :

Ah, OK. Les bénévoles et moi. Et là, j’ai fait une erreur. Au début, j’ai enregistré les identifiants des segments comme réponse correcte. Puis j’ai changé le découpage, tous les identifiants ont changé, et mes étiquettes étaient inutiles. J’ai dû toutes les refaire.

Nadia(intervieweur) :

Aïe. Et maintenant?

Yusuf(personne candidate) :

Maintenant, les étiquettes sont des références d’articles, comme « 2019-114, art. 4.2(b) ». Le script vérifie si un segment récupéré contient cet article. Donc je peux changer le découpage autant que je veux.

Nadia(intervieweur) :

Sur quoi les bénévoles n’étaient-ils pas d’accord?

Yusuf(personne candidate) :

Oh, beaucoup de choses. Hélène va à presque toutes les réunions du conseil. Dev s’occupe de l’infolettre. Ils ont étiqueté les mêmes 40 premières réponses, et ils étaient d’accord sur… 31, je pense. La grosse discussion, c’était ça : la réponse est juste, mais elle cite un article qui a été modifié après. Dev disait que c’était correct, le numéro était bon. Hélène disait que c’était faux, parce que si vous montrez cet article à la Ville, on vous dit qu’il est ancien.

Nadia(intervieweur) :

Qui a gagné?

Yusuf(personne candidate) :

Hélène. Ensuite, on a écrit un guide d’une page. Trois étiquettes, et une question oui ou non : « Est-ce que l’article cité appuie la réponse? » Après ça, ils étaient d’accord sur 36 réponses sur 40.

Ce que l’intervieweur vérifie

Cette question vérifie qu’il a construit le système lui-même. Seule la personne qui a travaillé avec les bénévoles connaît leurs désaccords et sait qui a gagné.

Nadia(intervieweur) :

Ce désaccord ressemble à un problème que nous avons avec les avenants aux polices d’assurance. OK. Joel m’a dit de poser des questions sur les tableaux.

Yusuf(personne candidate) :

Ah, oui. Les frais. « Combien coûte un permis de piscine? » Les frais sont dans des tableaux à la fin du règlement. L’outil d’extraction de texte PDF les lisait ligne par ligne, donc les colonnes se mélangeaient. Et mon outil de découpage coupait les tableaux en deux. Le segment avec les chiffres n’avait donc pas de ligne d’en-tête. Le modèle donnait le tarif commercial pour une maison. Avec beaucoup d’assurance.

Nadia(intervieweur) :

Comment l’avez-vous découvert?

Yusuf(personne candidate) :

18 de mes 150 questions portent sur des tableaux. Le rappel à 5 pour ces questions était de 0,39. Je m’en souviens parce que c’était vraiment mauvais. Maintenant, j’utilise un outil PDF qui détecte les tableaux. Je transforme chaque tableau en Markdown, et un tableau est toujours son propre segment. S’il est trop long, je le découpe par lignes et je répète la ligne d’en-tête dans chaque morceau. Les questions sur les tableaux sont passées à 0,83. Globalement, de 0,84 à 0,88.

Nadia(intervieweur) :

De 0,84 à 0,88 sur 150 questions, ça fait six questions. Comment savez-vous que ce n’est pas du bruit?

Yusuf(personne candidate) :

Hmm. Honnêtement, je n’ai pas fait de test statistique. J’ai regardé quelles questions avaient changé. Huit sont passées d’un échec à une réussite, deux d’une réussite à un échec. Les huit étaient des questions sur les tableaux. Donc je crois que la correction des tableaux fonctionne vraiment, parce que je vois pourquoi chaque résultat a changé. Mais 0,88 globalement, je ne dirais pas que c’est très exact.

Pourquoi cela fonctionne

C’est une réponse solide, même sans statistiques. Sur 150 questions, 4 points peuvent varier par hasard. Mais Yusuf a comparé les mêmes questions avant et après, et il peut expliquer chaque changement. L’outil statistique pour ce genre de comparaison avant-après est le test de McNemar. Avec si peu de questions modifiées, le test de McNemar ne serait pas significatif (p ≈ 0,1). Ici, l’explication de Yusuf, question par question, constitue la preuve la plus solide.

Nadia(intervieweur) :

Passons au fonctionnement du système. De nouveaux procès-verbaux du conseil sont publiés toutes les deux semaines. La mise à jour a-t-elle déjà échoué?

Yusuf(personne candidate) :

Oui. Une tâche cron s’exécute chaque nuit : collecte, extraction, découpage, création des plongements, insertion. Une petite machine virtuelle, la base de données est dessus aussi. En mars, la Ville a changé son site Web. L’outil de collecte recevait encore un 200, mais les liens menaient à une nouvelle page de visualisation. Alors, pendant une semaine, il a indexé environ 40 pages HTML qui disaient seulement « Loading » (chargement).

Nadia(intervieweur) :

Qui l’a remarqué?

Yusuf(personne candidate) :

Hélène, pas moi. Elle m’a demandé pourquoi les réponses étaient si étranges. Maintenant, la tâche vérifie que chaque fichier est un vrai PDF avec du texte. Et elle m’envoie un courriel si une exécution n’ajoute rien.

Nadia(intervieweur) :

Maintenant, imaginez que ce ne sont pas 60 voisins, mais 4 000 experts en sinistres. Et ce n’est pas vous qui recevez le courriel à 2 h du matin. C’est la personne de garde. Comment sait-elle ce qui ne va pas, et que fait-elle?

La vidéo se fige pendant quelques secondes.

Yusuf(personne candidate) :

Pardon, votre image s’est figée. Pouvez-vous répéter la dernière partie? Après les 4 000 experts en sinistres.

Nadia(intervieweur) :

Bien sûr. La personne de garde reçoit l’alerte à 2 h du matin, pas vous. Comment sait-elle ce qui ne va pas, et que fait-elle?

Yusuf(personne candidate) :

OK. Il lui faut plus qu’un courriel. Un tableau de bord, peut-être. Les documents reçus, les échecs, le temps que prennent les réponses. Et une page qui dit « si vous voyez ceci, vérifiez cela ».

Honnêtement, là, je fais des suppositions. Je n’ai jamais fait partie d’une rotation de garde. Je ne sais pas à quoi ressemble une vraie alerte, ni comment une équipe décide quand réveiller quelqu’un. Pendant mon quart de nuit, je sais exactement quoi faire quand quelque chose tombe en panne. Mais c’est un entrepôt.

La limite, une première fois

Ici, Nadia atteint la limite des connaissances de Yusuf. Il avance une hypothèse, et il dit que c’est une hypothèse. Il nomme aussi l’expérience qui lui manque.

Nadia(intervieweur) :

C’est honnête. Est-ce que quelqu’un d’autre a déjà révisé votre code?

Yusuf(personne candidate) :

Une fois. Quelqu’un du groupe de rencontres a ajouté Docker dans une demande de tirage (pull request). Il a vu ma clé d’API dans un fichier de configuration, dans le dossier du dépôt. Pas enregistrée dans un commit (enregistrement des changements), mais pas loin. J’ai des tests pour l’outil de découpage et le script d’évaluation, parce que ce sont eux qui ont le plus échoué. Pour l’outil de collecte, aucun.

Minutes 25 à 48 : le problème de Quillfield

Nadia(intervieweur) :

Je passe à la suite. Voici un vrai problème chez nous. Un dossier de réclamation arrive : 20 à 60 pages, formulaires numérisés, notes de l’expert en sinistres, courriels, photos, estimation d’un entrepreneur. Les experts en sinistres nous disent qu’ils passent environ 40 minutes à lire un dossier avant de pouvoir agir. Nous voulons leur donner une ébauche de résumé d’une page : les faits importants, les questions ouvertes et ce qui manque. Comment aborderiez-vous ça?

Yusuf(personne candidate) :

OK, ma première idée. Les pages passent par la reconnaissance optique de caractères, l’OCR. Puis un modèle lit tout le dossier et écrit le résumé, et chaque ligne renvoie à une page. Comme mes références d’articles. Ensuite…

Nadia(intervieweur) :

Avant de concevoir le système, qui pensez-vous qui lit ça?

Yusuf(personne candidate) :

Oui. L’expert en sinistres, je suppose? Avant de lire le dossier? Et alors, l’important, c’est ce qu’une erreur lui coûte. Si ça dit que la date du sinistre est le 12, et que c’est le 21, ça change ce qui est payé?

Nadia(intervieweur) :

Oui, les experts en sinistres, avant d’ouvrir le dossier, pour décider quoi faire en premier. Les faits importants changent selon le type de réclamation. Et une mauvaise date de sinistre peut déterminer si la police était même en vigueur. L’expert en sinistres confirme et décide toujours. Le résumé ne décide jamais rien.

Yusuf(personne candidate) :

Alors mon idée devient plus stricte. Chaque ligne renvoie à une page. « Date du sinistre : 12 mars, page 3. » Un clic, et l’expert en sinistres voit la page.

Nadia(intervieweur) :

Hum-hum. Et « ce qui manque »?

Yusuf(personne candidate) :

Vous avez déjà les 32 champs de l’extraction à la réception, non? Alors « ce qui manque », c’est en partie une liste de vérification. Une réclamation pour dégâts d’eau a besoin d’une cause, d’une estimation, de photos. Si le champ est vide, ça manque. Pour cette partie, le modèle n’a pas besoin d’écrire quoi que ce soit.

Pourquoi cela fonctionne

Yusuf reprend deux habitudes de son projet sans aide. Chaque affirmation reçoit une référence. Et il réutilise ce qui existe déjà. Une liste de « ce qui manque » fondée sur l’extraction existante est aussi beaucoup plus facile à tester qu’un texte libre.

Nadia(intervieweur) :

Récupéreriez-vous des segments du dossier, comme dans Bylaw Helper? Ou donneriez-vous tout le dossier au modèle?

Yusuf(personne candidate) :

Pour un seul dossier… je commencerais avec tout le dossier. Quarante pages, c’est peut-être 20 000 à 40 000 jetons. Les modèles actuels acceptent ça facilement. Mais je testerais exprès les dossiers les plus longs.

Nadia(intervieweur) :

Et les références?

Yusuf(personne candidate) :

Je mettrais un numéro sur chaque page dans l’entrée. Le modèle donne un numéro de page et une courte citation pour chaque fait. Ensuite, je vérifie que la citation est vraiment sur cette page. Avec les documents numérisés, la vérification doit permettre une correspondance approximative, à cause des erreurs d’OCR. Et si l’OCR lit un 7 comme un 1, le modèle le cite parfaitement et c’est quand même faux. Même leçon qu’avec mes tableaux.

Nadia(intervieweur) :

Comment sauriez-vous que les résumés sont bons, avant qu’un expert en sinistres en voie un?

Yusuf(personne candidate) :

Comme pour les règlements, mais avec vos spécialistes des réclamations, pas Hélène et Dev. Prendre 30 dossiers, avec différents types de réclamations. Les spécialistes notent les faits importants avec les pages. Pour chaque résumé, je compte les faits manquants, les faits faux et les affirmations que le dossier n’appuie pas. Ce sont des erreurs différentes, et on les corrige de façons différentes.

Oh, et d’abord, les deux spécialistes font les mêmes dix dossiers. Pour voir s’ils sont même d’accord sur ce qu’est un fait important.

Nadia(intervieweur) :

Nos deux spécialistes des réclamations ont environ quatre heures par semaine à eux deux, au total. La plupart de ce temps va à l’échantillon hebdomadaire des dossiers reçus.

Yusuf(personne candidate) :

Quatre heures pour les deux? Hmm. Donc peut-être une heure pour moi, dans une bonne semaine. Alors ils ne peuvent rien écrire pour moi. Je leur montrerais un résumé à côté du dossier. Ils marquent chaque ligne comme juste, fausse ou non appuyée, et ajoutent ce qui manque. Vérifier, c’est plus rapide qu’écrire.

Nadia(intervieweur) :

Quels dossiers leur donneriez-vous?

Yusuf(personne candidate) :

Les difficiles. Les dossiers longs, les réclamations pour blessures. Et un modèle comme juge, peut-être, pour des vérifications rapides entre les changements. Je l’ai essayé sur mes réponses sur les règlements. Il était d’accord avec les bénévoles sur 51 réponses sur 60, quelque chose comme ça. Mais il était trop indulgent avec « partiellement correct ». Donc le juge sert aux vérifications rapides, et les spécialistes décident.

Nadia(intervieweur) :

Est-ce que quelque chose dans les données elles-mêmes vous inquiète? Pensez au contenu d’une réclamation pour blessures.

Yusuf(personne candidate) :

Oh. Oui. Des renseignements médicaux. Des noms, des adresses, des problèmes de santé. Je n’y ai pas pensé du tout, et j’aurais dû. Toutes mes données sont publiques.

Alors le résumé doit être visible seulement pour les personnes qui peuvent déjà voir la réclamation. Je ne peux pas enregistrer les requêtes (prompts) et les sorties complètes dans les journaux (logs), comme maintenant. Et les données d’évaluation avec 30 vrais dossiers sont aussi pleines de renseignements personnels. Donc elles ne peuvent pas être sur l’ordinateur portable de quelqu’un. Ici, la loi, c’est la LPRPDE?

Nadia(intervieweur) :

Pour les entreprises privées, au fédéral, oui. Certaines provinces ont leurs propres lois. Vous n’avez pas besoin de connaître la loi par cœur. Vous devez remarquer la nature des données. C’est cette habitude qu’il faut avoir.

Où cela tourne mal

Yusuf n’a pas remarqué les renseignements personnels avant que Nadia les signale. C’est fréquent après des projets avec des données publiques. Ici, c’est important, car beaucoup de dossiers contiennent des renseignements personnels (PII : renseignements qui permettent d’identifier une personne). Ils contiennent aussi des renseignements de santé, encore plus sensibles. Il s’est bien repris. Mais dans une décision d’embauche, un risque manqué comme celui-ci peut compter plus que trois bonnes idées.

Une meilleure réponse

Il aurait pu soulever la question lui-même, juste après que Nadia lui a dit qui lit le résumé. Il en savait déjà assez :

« Une chose est très différente de mon projet : mes données étaient toutes publiques. Les vôtres sont les réclamations des gens, et les réclamations pour blessures contiennent des renseignements de santé. Alors, avant la conception, je veux connaître les règles. Où les données peuvent-elles aller? Qui peut voir un résumé? Qu’est-ce qu’on peut enregistrer dans les journaux? Et les données d’évaluation sont de vraies réclamations, donc elles ont besoin de la même protection. »

Cette réponse ne demande aucune connaissance juridique. Elle demande une question : « En quoi ces données sont-elles différentes des données que je connais? »

Nadia(intervieweur) :

Dernière partie. Nous recevons environ 9 000 dossiers par jour. Disons que nous écrivons chaque résumé quand le dossier arrive. Maintenant, c’est lundi, 9 h. Les dossiers accumulés pendant la fin de semaine arrivent : 4 000 dossiers en une heure. Le fournisseur commence à renvoyer des erreurs de limite de débit. Qu’arrive-t-il à ces dossiers?

Yusuf(personne candidate) :

Ils vont dans une file d’attente. Des processus réessaient, et ils attendent entre les tentatives, plus longtemps chaque fois.

Nadia(intervieweur) :

OK. Combien de processus? Et que voit l’expert en sinistres pendant l’attente?

Yusuf(personne candidate) :

Ça, je ne sais pas. Combien de processus, comment empêcher les nouvelles tentatives d’aggraver le problème, ce que l’expert en sinistres voit… Je n’ai jamais fait fonctionner une file d’attente avec une vraie charge. Si une de mes 400 questions par mois échoue, la personne repose la question. Mais votre extraction reçoit les mêmes 9 000 dossiers, non? Je voudrais d’abord voir comment elle gère ça.

La limite, une deuxième fois

C’est la principale limite, et c’est la même qu’avant : faire fonctionner un système à grande échelle, en équipe. Yusuf raisonne correctement et arrive à une file d’attente, avec des tentatives qui attendent plus longtemps chaque fois. Puis il s’arrête. Il indique l’extraction existante, qui résout déjà ce problème.

Minutes 48 à 57 : les questions de Yusuf

Yusuf(personne candidate) :

D’abord, la question directe. L’offre dit 4 ans ou plus. Moi, j’en ai zéro. Est-ce une limite stricte?

Nadia(intervieweur) :

Je vais être honnête, parce que vous l’avez été. Pour moi, ce n’est pas un filtre. Ce nombre représente des choses. Vous avez travaillé dans une base de code dont d’autres personnes sont responsables. Votre code a été révisé, vous avez été de garde, vous avez causé une panne en production et l’avez corrigée. Dans ce poste, la personne devient seule responsable d’une fonctionnalité assez rapidement. Aujourd’hui, vous avez montré une vraie maîtrise de la récupération et de l’évaluation. Vous avez aussi montré que ces autres choses sont nouvelles pour vous. Je vais noter les deux.

Yusuf(personne candidate) :

OK. C’est clair. Merci. Alors, si je me joins à vous un jour, de qui est-ce que j’apprends, au quotidien? Comment fonctionne la révision?

Nadia(intervieweur) :

Chaque changement est révisé par quelqu’un de l’équipe. Les nouvelles personnes travaillent en binôme avec quelqu’un pendant les premières semaines. Il y a aussi une rotation de garde, une semaine sur six. Les nouvelles personnes observent deux rotations avant d’en faire une seules.

Yusuf(personne candidate) :

Et l’offre dit « aider à définir notre stratégie d’évaluation ». Donc il n’y en a pas encore? Comment savez-vous aujourd’hui que l’extraction fonctionne?

Nadia(intervieweur) :

Pour l’extraction, les spécialistes étiquettent 200 dossiers par semaine, et nous mesurons chaque champ. Pour tout le reste, c’est au cas par cas. Et vous venez de voir pourquoi : le temps des spécialistes. C’est une des raisons pour lesquelles nous embauchons.

Pourquoi cela fonctionne

Les trois questions portent sur le travail. La première est courageuse, et elle obtient une réponse honnête. La question sur l’apprentissage est la bonne pour quelqu’un sans expérience en équipe. Sa réponse révèle aussi quelque chose que l’offre ne dit pas : il y a des périodes de garde. La dernière question relie une phrase vague de l’offre au temps des spécialistes. Voir une entrevue est une conversation dans les deux sens.

Pendant les trois dernières minutes, Nadia explique les prochaines étapes. Elle écrit ses notes le jour même, et Hannah contactera Yusuf dans un délai d’une semaine. Yusuf dit qu’il va réfléchir davantage à la question de 2 h du matin.

Après l’appel : les notes de Nadia

Candidat : Yusuf Demir. Poste : ingénieur en IA, Claims Intelligence (intermédiaire à senior).

Preuves solides. Récupération : segments conçus à partir de ses propres données; recherche hybride comparée à chaque méthode utilisée seule. Évaluation : étiquettes au niveau des clauses, accord entre les personnes qui étiquettent mesuré et amélioré, vérification appariée des changements. Mieux que certains candidats seniors. Honnête et calme aux limites de ses connaissances.

Quelques preuves. Déploiement : une machine virtuelle, cron, Docker, quelques tests; à petite échelle. Adaptation à notre problème : une page pour chaque fait, réutilisation des 32 champs.

Aucune preuve. Travail en équipe (une seule révision de code à ce jour). Production à grande échelle : files d’attente, surveillance, garde.

Préoccupation. N’a pas remarqué les renseignements personnels et de santé avant qu’on attire son attention dessus. A bien réagi ensuite.

Paternité du travail. Aucun doute. Personne n’invente les étiquettes refaites, le désaccord sur la clause modifiée ou la panne de l’extracteur Web en mars.

Recommandation. Pas au niveau de cette offre. Pas à cause des années exigées, mais à cause du manque d’expérience en équipe et en production. Oui sans hésitation pour le poste d’ingénieur en IA junior prévu au prochain trimestre. Marcus, gardez-le dans le processus; pas de refus standard.

La suite

Marcus était d’accord. Deux jours plus tard, Hannah a appelé Yusuf. Sa candidature n’irait pas plus loin pour ce poste. Mais l’équipe voulait le recruter pour un poste junior qui n’était pas encore affiché. Elle lui a aussi transmis les commentaires de Nadia en trois points : données personnelles, exploitation en production, travail en équipe.

Yusuf était déçu, et il l’a dit. Puis il a ajouté une section à son README : « Ce que je ferais autrement avec des données privées ».

Le poste junior ouvrira un mois plus tard que prévu, à cause du cycle budgétaire. Hannah a déjà invité Yusuf à une entrevue de conception de systèmes avec Owen pour ce poste, dans la nouvelle année. Rien n’est promis. Il postule aussi à des postes juniors dans d’autres entreprises.

Ce que « 4 ans ou plus » voulait dire ici

Mais un niveau, c’est plus qu’un chiffre. Il détermine l’échelle salariale. Il détermine l’aide que l’équipe prévoit offrir et ce que la personne doit faire seule dans les premiers mois. Yusuf n’a pas pu démontrer son expérience en équipe et en production. Pour ce poste, l’exigence a donc été maintenue, et pour une bonne raison. Postuler restait une bonne décision. Il a obtenu une évaluation honnête et une place dans le prochain processus.

Ce qu’il faut en retenir

• Un vrai projet peut soutenir une entrevue exigeante. Chaque réponse venait de quelque chose que Yusuf avait fait et mesuré. Consultez montrer un travail proche de la réalité.
• Les détails montrent que vous l’avez construit. Seule la personne qui l’a construit connaît les désaccords entre bénévoles. Vous ne pouvez pas préparer ces réponses. Vous devez avoir vécu ces situations.
• Votre limite, c’est ce que votre projet n’a pas pu vous apprendre. Quand on travaille seul, c’est généralement le travail en équipe, la grande échelle et les données privées. Quand vous atteignez cette limite, dites-le clairement.
• Demandez ce qui distingue les nouvelles données. Yusuf a apporté ses méthodes. Il a aussi apporté ses habitudes acquises avec les données publiques.

Si votre profil ressemble à celui de Yusuf

1. Construisez un projet avec de vrais utilisateurs et de vrais cas d’échec. Un petit projet suffit. Utilisez des données désordonnées, puis ajoutez des données d’évaluation, un déploiement et un README présentant vos décisions et vos limites. Utilisez Les éléments d’un portfolio comme liste de vérification.
2. Mesurez séparément la recherche et les réponses. Étiquetez selon des références stables, comme des clauses ou des pages, pas selon des identifiants de segments. Vos étiquettes resteront ainsi valides après le prochain changement. Demandez à une deuxième personne d’étiqueter les mêmes 30 éléments et comptez combien de fois vous êtes d’accord.
3. Tenez un journal des pannes et de la façon dont vous les avez découvertes. Les détails sont vos meilleures réponses, et vous les oubliez vite.
4. Travaillez délibérément sur vos lacunes. Ajoutez de fausses données personnelles à une copie de votre projet. Décidez ce que vous consignez et qui peut voir quoi. Placez le projet dans un conteneur, avec des tests et un pipeline : les cours L’essentiel de Docker et du nuage pour les développeurs en IA et CI/CD, tests et mises en production sûres vous aideront. Faites ensuite réviser votre code. Quelques demandes de tirage (pull requests) acceptées dans un projet à code source ouvert vous apprendront la révision de code. Elles vous apprendront aussi à lire du code que vous n’avez pas écrit.
5. Exercez-vous à l’expliquer à voix haute, puis en public. Utilisez Expliquer vos décisions : le problème, les options, le choix, les chiffres, les limites. Faites ensuite une courte présentation lors d’une rencontre. C’est aussi du réseautage.
6. Postulez quand même et évaluez honnêtement le niveau demandé. Postulez à des postes un peu au-dessus de votre niveau, ainsi qu’à des postes juniors. Quand on vous dit « pas à ce niveau », demandez ce que ce niveau exige et notez-le. Consultez Se préparer aux candidatures.