Le scientifique des données

Imaginez une cuisinière qui a dirigé la cuisine d’un petit restaurant pendant cinq ans. Elle planifiait le menu, achetait les aliments, cuisinait et entendait chaque plainte. Maintenant, elle postule dans la cuisine d’un grand hôtel. Elle n’a jamais cuisiné pour 2 000 personnes à la fois. Mais elle sait ce que signifie un plat qui revient en cuisine.

Beaucoup de scientifiques des données qui postulent comme ingénieurs en apprentissage automatique ont un parcours semblable. Dans une petite entreprise, ils s’occupaient de tout pour un modèle, des données aux appels de clients mécontents quand un problème survenait. Ils n’avaient aucune équipe de plateforme, un seul conteneur Docker et beaucoup de responsabilités. Suivez Mateo pendant l’examen approfondi de l’apprentissage automatique. Observez comment sa responsabilité d’un modèle l’aide à aborder un nouveau problème. Voyez aussi où le volume et les tests en ligne le poussent à ses limites.

MR

La personne candidate

Mateo Rojas

Scientifique des données, 5 ans en crédit à la consommation à Bogotá, au Canada depuis un an

• 5 ans comme scientifique des données
• Risque de crédit, de bout en bout
• Résident permanent
• Toronto, Ontario

• Analyste de données, Brookvale Home (détaillant de meubles), Mississauga (depuis 2025). Rapports hebdomadaires sur les ventes et les stocks avec SQL et Power BI. Un petit outil de prévision en Python pour les stocks des magasins.
• Scientifique des données principal, Lunaria Crédito, Bogotá (2022 à 2025); scientifique des données (2020 à 2022). Petits prêts personnels offerts par une application mobile.
• A créé et déployé le modèle de risque de crédit (LightGBM) qui a remplacé une grille de pointage basée sur des règles. Environ 15 % d’approbations de plus au même taux de défaut.
• L’a rendu accessible par une API Flask dans Docker pour les décisions de prêt en temps réel. A aussi mis en place le calcul des scores par lots chaque nuit pour réviser les limites de crédit.
• Responsable du cycle de vie complet du modèle : entraînement, déploiement, surveillance, réentraînement.
• A mis en place la surveillance de la dérive après un changement dans la composition de la clientèle en 2023. PSI sur toutes les variables du modèle, rapport hebdomadaire et alertes.
• Python, SQL, LightGBM, scikit-learn, Docker, Airflow, AWS.

Mateo travaille au Canada depuis un an comme analyste de données. Beaucoup de personnes qui immigrent acceptent d’abord un poste moins élevé. Son expérience principale, ce sont ses cinq années à Bogotá.

L’expérience canadienne n’est pas requise. Depuis le 1er janvier 2026, une offre d’emploi publique en Ontario ne doit pas exiger d’expérience de travail canadienne. L’offre de Fennick le précise. Pour Ravi et Ioana, les cinq années de Mateo en Colombie sont cinq années d’expérience. Si vous avez immigré récemment, ne cachez pas votre travail dans votre pays d’origine et ne vous en excusez pas. Décrivez-le comme vous décririez un emploi au Canada.

Ce qu’Ioana voit avant l’appel

Mateo n’a jamais travaillé dans la livraison ni sur des systèmes en temps réel de la taille de ceux de Fennick. Mais il a mis un modèle en production et l’a surveillé après son lancement. La mention du PSI indique qu’un problème est survenu et qu’il a créé une solution. C’est souvent l’histoire la plus intéressante d’un CV.

Elle note ce qu’elle veut découvrir :

• « 15 % d’approbations de plus au même taux de défaut. » Comment connaître le taux de défaut des personnes rejetées par l’ancien système?
• « Responsable du cycle de vie complet du modèle. » De quoi était-il responsable exactement? Qui assurait la garde?
• L’histoire de dérive. Comment l’a-t-il remarquée, et combien de temps cela a-t-il pris?
• Peut-il passer des décisions de crédit à un modèle qui répond 1,5 million de fois par jour? Pense-t-il au client et aux livreurs?

Termes utilisés sur cette page

• Défaut : l’emprunteur ne rembourse pas. Chez Lunaria, un prêt était « en défaut » si un paiement avait plus de 60 jours de retard dans les six premiers mois.
• PSI (indice de stabilité de la population) : un nombre qui indique le changement de distribution d’une variable entre deux périodes. Une règle courante : sous 0,1, elle est stable; de 0,1 à 0,25, le changement est modéré; au-dessus de 0,25, il est important.
• Latence p99 : 99 % des requêtes prennent moins de temps que cette valeur. Le budget de latence de Fennick pour le service d’heure d’arrivée estimée est d’environ 50 ms au p99.
• Prédiction d’un centile (ou quantile) : plutôt que le temps moyen, le modèle prédit un temps que, par exemple, 90 % des commandes ne dépasseront pas. C’est le « 90e centile » ou le « quantile 0,9 ».
• Écart entre l’entraînement et la production : une variable est calculée d’une façon à l’entraînement et d’une autre en production. Le modèle reçoit donc en production des nombres différents de ceux utilisés pour son apprentissage.
• Test par alternance (switchback test, test qui alterne entre deux modèles) : un test en ligne qui fait alterner une zone entière entre l’ancien et le nouveau modèle par blocs de temps. Il ne sépare pas les clients en groupes.

L’entrevue

Minutes 0 à 5 : le début

Ioana(intervieweur) :

Bonjour Mateo. Vous m’entendez bien?

Mateo(personne candidate) :

Oui, oui, je vous entends bien. Bonjour, enchanté.

Ioana(intervieweur) :

Enchantée. Je suis Ioana, ingénieure principale en apprentissage automatique chez Delivery Intelligence. J’ai créé le service ETA, celui qui affiche le temps de livraison dans l’application. Alors, voici le plan : vous me parlez d’abord d’un modèle que vous avez mis en production. Je vais poser beaucoup de questions. Ensuite, un vrai problème de notre côté. À la fin, vos questions. Une chose : pas d’assistants d’IA pendant cette étape, s’il vous plaît. Le papier, c’est permis.

Mateo(personne candidate) :

D’accord. Et, désolé, avant de commencer : mon anglais est correct, mais pas parfait. Si je dis quelque chose de pas clair, demandez-moi.

Ioana(intervieweur) :

C’est pareil pour moi, l’anglais est aussi ma deuxième langue. On va y arriver. Commençons.

Le dire dès le début

Mateo le dit une fois, puis passe à la suite. Votre anglais n’a pas besoin d’être parfait. Une bonne personne qui mène l’entrevue écoute votre raisonnement. Voir Votre anglais n’a pas besoin d’être parfait.

Minutes 5 à 25 : le modèle de crédit, puis les questions approfondies

Ioana(intervieweur) :

Alors, parlez-moi du modèle.

Mateo(personne candidate) :

D’accord. Alors, Lunaria offre de petits prêts dans une application, entre 500 000 et 3 millions de pesos. C’est pour des gens qui n’ont souvent pas d’historique bancaire. À mon arrivée, la décision reposait sur une grille de pointage. C’était une régression logistique créée par un consultant des années avant, avec beaucoup de règles manuelles. Le problème, c’est qu’on refusait beaucoup de bons clients. J’ai donc créé un modèle LightGBM avec les données des demandes et celles du bureau de crédit. Il est passé en production en, je pense, mars 2022. L’API décide dans l’application pendant que la personne attend. La nuit, on recalcule le score de tous les clients pour modifier les limites de crédit.

Ioana(intervieweur) :

Hum-hum. Qu’est-ce que le modèle prédit exactement?

Mateo(personne candidate) :

Si la personne sera en défaut de paiement. Pour nous, c’était un retard de plus de 60 jours, dans les six premiers mois du prêt.

Ioana(intervieweur) :

Pourquoi six mois? Pourquoi pas toute la durée du prêt?

Mateo(personne candidate) :

À cause du temps. Certains prêts durent 18 mois, donc j’attends 18 mois pour connaître la réponse. Et la plupart des défauts arrivent tôt. J’ai vérifié : environ, hum, 80 % arrivaient dans les six premiers mois. C’était donc un compromis.

Ioana(intervieweur) :

D’accord. Et comment avez-vous divisé les données?

Mateo(personne candidate) :

Selon le temps. L’entraînement sur les anciens prêts, le test sur les plus récents. Et je ne pouvais pas du tout utiliser les six derniers mois. Ces prêts n’ont pas encore d’étiquette. C’était difficile. Les données les plus récentes sont les plus utiles, et je ne pouvais pas y toucher.

Ce que l’intervieweur vérifie

Deux questions de base : quelle est l’étiquette, et comment les données ont-elles été divisées? Mateo montre que le temps compte à deux niveaux. Les données futures ne doivent pas entrer dans l’entraînement. Et une étiquette a besoin de temps pour « mûrir ». Voir Données d’entraînement, de validation et de test.

Ioana(intervieweur) :

Votre CV indique 15 % d’approbations de plus, avec le même taux de défaut de paiement. Comment connaissez-vous le taux de défaut des personnes refusées par l’ancienne grille de pointage? Elles n’ont jamais reçu de prêt.

Mateo(personne candidate) :

Oui. C’est le gros problème du crédit, le… comment dire, reject inference, l’inférence sur les demandes refusées. On ne sait pas. Alors pendant trois mois, on a approuvé au hasard 2 % des personnes refusées par la grille, pour un petit montant. L’équipe de gestion des risques n’était pas contente. Mais ensuite, on avait des étiquettes pour certaines de ces personnes.

Ioana(intervieweur) :

Et les 15 % venaient de là?

Mateo(personne candidate) :

Hum. En partie. Les 15 %, c’était l’estimation hors ligne, plus les premiers mois. Honnêtement, après un an, le vrai chiffre était plus bas. Plutôt 10, peut-être 12 %. Je devrais le changer dans mon CV.

Ioana(intervieweur) :

Dix pour cent, c’est quand même bien. D’accord, l’histoire de dérive. Qu’est-ce qui s’est passé en 2023?

Mateo(personne candidate) :

Ah, cette histoire. L’équipe marketing a fait un partenariat avec une chaîne de magasins de téléphones. Vous achetez un téléphone, vous pouvez obtenir un prêt dans le magasin. Très vite, beaucoup de nouveaux clients. Mais ils étaient très jeunes, et plusieurs n’avaient aucun historique au bureau de crédit. Avant, les personnes sans historique représentaient environ 10 % des demandes. Après, en quelques semaines, environ 35 %.

Ioana(intervieweur) :

Et le modèle?

Mateo(personne candidate) :

Le modèle en approuvait beaucoup. Il avait vu peu de personnes comme ça pendant l’entraînement. Et personne ne regardait. Après presque trois mois, l’équipe de recouvrement a demandé pourquoi autant de gens ne faisaient pas le premier paiement. Pour ce canal, c’était environ le double de la normale.

Ioana(intervieweur) :

Trois mois. Comment avez-vous trouvé la cause?

Mateo(personne candidate) :

J’ai comparé les distributions des variables, avant et après. C’est là que j’ai commencé avec le PSI. Le score du bureau de crédit avait un PSI de presque 0,4, avec une classe distincte pour les valeurs manquantes. Très élevé. J’ai donc créé une tâche hebdomadaire : le PSI de chaque variable par rapport aux données d’entraînement. Et une alerte si une valeur dépasse 0,25. Aussi, un tableau de bord des défauts au premier paiement par canal. Parce que cette étiquette arrive en un mois, pas six.

Pourquoi c'est la meilleure partie de son projet

Mateo ne s’est pas contenté d’ajouter un outil de surveillance. Il a trouvé une étiquette qui arrive plus vite que la vraie. Un premier paiement manqué se voit en un mois, un défaut en six. Un signal rapide comme celui-ci vous avertit tôt.

Ioana(intervieweur) :

Et vous avez corrigé le modèle?

Mateo(personne candidate) :

D’abord, une règle : un montant plus petit pour le canal des magasins de téléphones sans historique au bureau de crédit. Ça, c’était la même semaine. Ensuite, on a réentraîné avec les nouveaux clients quand on avait les étiquettes, peut-être cinq mois plus tard. En 2023, on a changé aussi le réentraînement : tous les trois mois, pas une fois par an.

Ioana(intervieweur) :

D’accord. « Responsable du cycle de vie complet. » Qui assurait la garde pour l’API?

Mateo(personne candidate) :

Hum. Honnêtement, les alertes de l’API arrivaient d’abord à l’équipe backend, responsable de la partie serveur. Si l’API était en panne ou lente, ils s’en occupaient. Ils m’appelaient si c’était le modèle. C’est arrivé peut-être deux ou trois fois. Donc le modèle, c’était ma responsabilité. Les serveurs, pas vraiment.

Ioana(intervieweur) :

Et l’API était rapide comment?

Mateo(personne candidate) :

Je ne me souviens pas exactement. Moins de 300 millisecondes, je pense, la plupart du temps. Personne ne s’inquiétait, parce que la personne remplit un formulaire. Deux cents millisecondes de plus, ce n’est rien pour elle.

Le mot « responsable »

« Responsable du cycle de vie complet du modèle » dépassait la réalité. Mateo n’était pas responsable du service en production. Il a rectifié lui-même, donc cela lui a peu nui, mais il a perdu un peu de confiance. Décrivez vos responsabilités avec des mots simples : « Responsable du modèle, de sa surveillance et de son réentraînement; l’équipe backend gérait l’API. »

Minutes 25 à 48 : le problème de Fennick

Ioana(intervieweur) :

D’accord, maintenant un vrai problème de notre côté. Les clients voient un temps de livraison dans l’application avant de payer. À l’heure du souper et par mauvais temps, notre estimation est trop optimiste. Les jours normaux, environ 9 % des commandes arrivent plus de dix minutes après l’heure estimée. Ces jours-là, c’est environ 18 %. Les gens sont fâchés, les billets de soutien augmentent. Comment aborderiez-vous ça?

Mateo(personne candidate) :

D’accord. Je vais noter ça. Neuf pour cent normalement, dix-huit au souper et par mauvais temps. Il écrit. Première question : que signifie le chiffre dans l’application aujourd’hui? Est-ce le temps moyen? Le plus probable?

Ioana(intervieweur) :

Aujourd’hui, le modèle est entraîné pour prédire le temps attendu. Donc, plus ou moins, la moyenne.

Mateo(personne candidate) :

Alors je pense que le problème vient en partie de la question, pas seulement du modèle. Si vous montrez la moyenne, beaucoup de gens seront en retard par définition. Au souper, les temps sont plus… dispersés? Plus de variance. Donc la moyenne est loin des mauvais cas.

Ioana(intervieweur) :

Alors, qu’afficheriez-vous?

Mateo(personne candidate) :

Un centile plus élevé. Peut-être le 80e ou le 90e. C’est comme le crédit, en fait. Être en retard est pire qu’être en avance. Comme approuver un mauvais prêt est pire que refuser un bon prêt. Les coûts ne sont pas les mêmes, donc la prédiction ne devrait pas être au milieu.

Ioana(intervieweur) :

D’accord. 80 ou 90, qui décide?

Mateo(personne candidate) :

Pas moi seul. Si le chiffre est trop élevé, les gens ne commandent pas. Je demanderais donc à l’équipe produit : si on affiche cinq minutes de plus, combien de commandes perd-on? Et je demanderais aux opérations ce que les retards leur coûtent, les billets, les remboursements. Ensuite, on choisit ensemble. Peut-être 85.

Pourquoi cela fonctionne

Mateo transforme le problème : au lieu d’« améliorer le modèle », il demande « quel chiffre le client devrait-il voir »? C’est l’étape la plus importante. Son expérience en crédit l’aide : des coûts inégaux signifient que la meilleure prédiction n’est pas au milieu. Et il ne choisit pas le centile seul.

Ioana(intervieweur) :

Nous avons une donnée. En mars, les opérations ont ajouté cinq minutes quand il pleuvait, dans deux villes. Les commandes ont baissé d’environ un ou deux pour cent. Comment entraîneriez-vous le modèle pour le 85e centile?

Mateo(personne candidate) :

LightGBM a un objectif quantile. Vous donnez un alpha de 0,85, et il apprend ce point avec la perte pinball, une perte quantile. Je l’ai utilisé une fois, pour une prévision de trésorerie, pas pour le crédit. Une autre façon serait de garder le modèle moyen et d’ajouter une marge. Mais la marge est la même pour toutes les commandes, et le problème concerne celles du souper.

Ioana(intervieweur) :

Bien. Et comment savez-vous, hors ligne, que ça fonctionne?

Mateo(personne candidate) :

Tester sur les semaines les plus récentes, selon le temps, comme avant. Ensuite, je vérifie : environ 85 % des commandes sont-elles arrivées avant l’heure affichée? Mais pas seulement au total. Séparément pour le souper, la pluie, la neige, par ville. Si c’est 85 % au total, mais 70 % au souper, le problème est toujours là.

Ioana(intervieweur) :

Hum-hum. C’est ce qu’on appelle la couverture par condition. D’accord. Quelles variables manquent, selon vous?

Mateo(personne candidate) :

La météo, c’est sûr. Et l’achalandage du magasin en ce moment, et le nombre de livreurs libres près du magasin.

Ioana(intervieweur) :

Nous avons les deux dernières. La météo, pas encore. Comment l’ajouteriez-vous?

Mateo(personne candidate) :

Hum. Il faut faire attention ici. Pour l’entraînement, c’est facile de prendre la météo historique, ce qui s’est vraiment passé ce soir-là. Mais au paiement, on connaît seulement la météo actuelle, ou les prévisions. Donc, pour l’entraînement, je dois utiliser la météo connue au moment de la commande. En crédit, on avait la même chose avec le bureau. Les données au jour de la demande, pas celles d’aujourd’hui, sinon le modèle apprend du futur.

Ioana(intervieweur) :

Oui. Nous avons eu un bogue semblable l’an dernier. À l’entraînement, une variable venait d’une table calculée par lots toutes les 15 minutes. En production, c’était des comptes en temps réel. Six semaines avant qu’on le remarque. Ma question : votre PSI l’aurait-il détecté?

Mateo(personne candidate) :

Je réfléchis. Pause. Si je compare la distribution d’entraînement avec la distribution en production de cette variable… Le compte en temps réel bouge plus, celui par lots est plus lisse. Donc peut-être que la forme est différente, et que le PSI monte un peu. Mais peut-être pas au-dessus du seuil d’alerte. Ce n’est pas une vérification solide pour ça. Il vaut mieux enregistrer les variables réellement utilisées par le service pour chaque commande. Puis calculer plus tard les variables d’entraînement pour les mêmes commandes. Ensuite, comparer commande par commande. Si elles sont différentes, c’est un bogue, pas une dérive.

Comment Ioana approfondit

Ioana transforme son propre bogue en question sur l’outil de Mateo. Elle vérifie s’il comprend le PSI ou s’il l’utilise simplement. Sa réponse est juste. Le PSI compare deux groupes de nombres. Un bogue d’écart entre entraînement et production crée une différence pour la même commande. On le trouve donc en comparant les mêmes commandes, ligne par ligne.

Ioana(intervieweur) :

D’accord. Maintenant, le service. L’application appelle le modèle ETA chaque fois qu’une page de paiement est consultée. Environ 1,5 million d’appels par jour, et le budget est de 50 millisecondes au p99. Comment cela change-t-il votre conception?

Mateo(personne candidate) :

Hum. 1,5 million par jour, c’est… environ 17 par seconde, en moyenne? Mais pas la nuit, donc le soir c’est plus. Peut-être cinq fois plus au souper?

Ioana(intervieweur) :

Un peu moins, mais vous êtes proche.

Mateo(personne candidate) :

D’accord. Le modèle lui-même n’est pas le problème, je pense. LightGBM avec 120 variables est rapide, environ une milliseconde. Le temps passe à récupérer les variables. Celles en temps réel doivent être prêtes en mémoire, pas calculées pendant la requête. Mais honnêtement, je n’ai jamais travaillé avec un budget comme 50 millisecondes. Je devrais apprendre comment votre feature store, votre magasin de variables, fonctionne.

Une réponse plus solide sur la latence

Le raisonnement de Mateo est juste, mais général. Une personne ayant de l’expérience en temps réel diviserait les 50 ms en parties : « Réseau, quelques millisecondes. Récupération des variables en ligne, peut-être 10 à 20 au p99. Modèle, une ou deux. Et une solution de repli : si une récupération est trop lente, utiliser la dernière valeur connue ou une ETA simple par défaut. Ne jamais bloquer la page de paiement. » Mateo a dit honnêtement qu’il ne l’avait pas fait. C’était la bonne chose à faire, car si vous inventez les chiffres, la question suivante le révèle.

Ioana(intervieweur) :

Bien. Maintenant, vous avez un nouveau modèle, et il semble meilleur hors ligne. Comment le testez-vous avec de vrais clients?

Mateo(personne candidate) :

Un test A/B. La moitié des clients voit la nouvelle estimation, l’autre moitié l’ancienne. Au hasard, par client. Ensuite, comparer le taux de retard, les billets et le nombre de personnes qui commandent.

Ioana(intervieweur) :

D’accord. Un problème. Les livreurs sont partagés. Les commandes des clients du groupe A et du groupe B vont aux mêmes livreurs, dans la même zone. Quel effet cela a-t-il sur votre test?

Mateo(personne candidate) :

Désolé, pouvez-vous répéter? J’ai manqué la partie après « partagés ».

Ioana(intervieweur) :

Bien sûr. Les clients des deux groupes utilisent les mêmes livreurs. Un livreur qui prend une commande du groupe A ne peut pas en prendre une du groupe B. Les deux groupes ne sont donc pas indépendants. Quel effet cela a-t-il sur le test?

Mateo(personne candidate) :

Ah, d’accord. Hum. Longue pause. Donc, le nouveau modèle affiche des temps plus longs, surtout au souper. Certaines personnes du groupe B voient un temps plus long et ne commandent pas. Alors il y a moins de commandes… et les livreurs ont plus de temps… pour tout le monde? Aussi pour le groupe A?

Ioana(intervieweur) :

Oui. Continuez.

Mateo(personne candidate) :

Alors le groupe A devient plus rapide à cause du groupe B. Donc la différence entre A et B est fausse. Plus petite, ou… je ne suis pas sûr dans quel sens. Je comprends le problème. Mais je ne connais pas la méthode pour le corriger. En crédit, le prêt d’un client ne change pas celui d’un autre.

Ioana(intervieweur) :

Une réponse courante est un test switchback, un test par alternance. Vous ne divisez pas les clients. Vous divisez le temps et les lieux : une zone utilise le nouveau modèle pendant une heure, puis l’ancien. Elle alterne plusieurs fois pendant quelques semaines.

Mateo(personne candidate) :

D’accord, je vois. Donc dans une zone, pendant une heure, tout le monde a le même modèle, et les livreurs ne sont pas mélangés. Alors l’unité est la zone-heure, pas la commande. J’ai donc moins d’unités, et il me faut un test plus long. Et… le moment du changement est un problème? Une commande de 18 h 55 est encore en route à 19 h 10, avec l’ancienne estimation. Alors peut-être que j’ignore la première partie de chaque bloc?

Ioana(intervieweur) :

Oui, exactement. C’est le problème de l’effet résiduel. Nous excluons habituellement une courte période après chaque changement.

À la limite de ses connaissances

Mateo atteint sa limite, et c’est la minute la plus utile de l’appel. Il demande de répéter la question au lieu de répondre à une question qu’il n’a pas entendue. Il ne connaît pas les tests switchback, et il le dit. Après les deux phrases d’Ioana, il trouve lui-même les prochains problèmes. L’unité d’analyse, le nombre réduit d’unités et l’effet résiduel à chaque changement.

L'erreur dans la première réponse

« Au hasard, par client » est le test A/B standard, et il convient à beaucoup de produits. Dans une place de marché, ce qu’un groupe voit change ce qui arrive à l’autre. Avant de proposer un test en ligne, demandez : les deux groupes partagent-ils quelque chose, comme des livreurs, des stocks ou un budget?

Dans les dernières minutes consacrées au problème, Ioana a posé des questions sur le réentraînement. Mateo a souri : chez Fennick, le vrai temps de livraison est connu une heure plus tard, pas six mois. Pour lui, la difficulté n’était donc pas le réentraînement hebdomadaire. C’était de vérifier chaque nouveau modèle avant sa mise en production. Et de savoir qui comprend la tâche de réentraînement.

Minutes 48 à 57 : les questions de Mateo

Mateo(personne candidate) :

J’ai trois questions. Premièrement : quand le taux de retard augmente au souper, qui le voit d’abord, votre équipe ou les opérations?

Ioana(intervieweur) :

Honnêtement? Les opérations. L’équipe de Laura voit les billets le soir même. Nous voyons l’erreur dans le rapport du lendemain matin. Nous n’avons aucune surveillance des variables, seulement de l’erreur après la livraison.

Mateo(personne candidate) :

Donc comme mon histoire de magasins de téléphones. Les équipes d’affaires le voient avant l’équipe du modèle.

Mateo a aussi demandé qui était responsable du réentraînement hebdomadaire et si le poste comprenait des périodes de garde. Ioana a répondu honnêtement : une tâche cron qu’un seul ingénieur comprend vraiment. Et une semaine de garde sur cinq, ce que l’offre ne dit pas.

De bonnes questions

Chaque réponse donne à Mateo une information concrète : les équipes d’affaires voient les problèmes en premier. Le réentraînement dépend d’une seule personne. Et il y a des périodes de garde que l’offre ne mentionne pas. Sa première question lui appartient : elle vient de son histoire de magasins de téléphones. Beaucoup de candidats ont peur de poser des questions sur la garde. C’est une question normale. Voir Une entrevue va dans les deux sens.

Minutes 57 à 60 : la fin

Ioana(intervieweur) :

Merci, Mateo. Ensuite, il y aura l’étape de conception de systèmes avec Ben, et une discussion avec Laura des opérations. Chantal vous écrira cette semaine.

Mateo(personne candidate) :

Merci, c’était intéressant. J’ai appris quelque chose aujourd’hui, le switchback.

Après l’appel : les notes d’Ioana

Ioana écrit ses notes le même après-midi, en se basant sur l’offre d’emploi.

Mateo Rojas, entrevue approfondie sur l’apprentissage automatique

• Responsabilité d’un modèle en production : preuves solides. Choix de l’étiquette justifié (six mois), séparation chronologique tenant compte de la maturité des étiquettes, vraie référence de base (l’ancienne grille de pointage), test d’inférence sur les demandes refusées. Surveillance mise en place après un incident réel, avec une étiquette de substitution rapide.
• Définition du problème et sens des affaires : preuves solides. Est passé directement à « quel nombre le client devrait-il voir ». A proposé un percentile élevé et nommé les responsables de la décision (produit, opérations).
• Évaluation : preuves solides. Couverture par condition, pas seulement globale. Données météo disponibles au moment de la prédiction, sans indice. Bonne réponse sur le PSI par rapport à l’asymétrie : comparer les mêmes commandes.
• Prédictions en temps réel à notre échelle : quelques preuves. A bien compris que les variables, pas le modèle, consomment le budget de temps. N’a jamais travaillé avec un budget de 50 ms, et l’a dit.
• Expériences en ligne avec interférence : aucune preuve avant aujourd’hui. Ne connaissait pas les tests par alternance temporelle. Après deux phrases, a trouvé lui-même l’unité d’analyse et le problème des effets persistants.
• Réserve (mineure) : « responsable de tout le cycle de vie » dépassait la réalité; il s’est corrigé lui-même. Le 15 % du CV est plutôt de 10 à 12 %; il l’a aussi corrigé.

Recommandation : oui. Bon jugement en apprentissage automatique et vraie prise de responsabilité. Les lacunes concernent les systèmes en temps réel et les expériences sur les places de marché. Il peut apprendre les deux dans l’équipe; l’entrevue de Ben permettra de vérifier le premier point.

La suite

L’entrevue de conception de systèmes avec Ben s’est bien passée. Mateo a conçu un pipeline clair. Mais il avançait lentement sur le traitement des variables en temps réel et avait besoin d’aide pour la mise en cache. L’entretien sur les valeurs avec Laura a donné un oui clair. Elle a écrit : « Il a demandé combien nous coûte une commande en retard avant de parler de modèles. »

Il y avait un poste vacant et deux finalistes solides. L’équipe a choisi Hana Kowalczyk, qui avait déjà créé des modèles d’heure d’arrivée estimée. Ravi a appelé Mateo lui-même : « Vous étiez notre deuxième choix, et la décision était serrée. J’aimerais garder le contact. » Mateo a demandé une rétroaction. Ravi lui a donné deux points à travailler : fournir les variables en ligne et concevoir des expériences pour les places de marché.

En janvier, Fennick a approuvé un deuxième poste d’ingénieur en apprentissage automatique dans l’équipe, pour la prévision de la demande. Ravi a appelé Mateo en premier, avant la publication de l’offre d’emploi. Mateo a eu un autre bref appel avec Ravi et Ben, puis une offre près du milieu de l’échelle salariale. Il a accepté.

C’est une fin réaliste parmi d’autres, pas une promesse. Beaucoup d’entreprises ne rappellent jamais leur deuxième choix. La chance joue aussi un rôle.

Ce qu’il faut retenir

• Votre expérience dans un autre pays compte. Mateo a décrit son travail en Colombie comme il décrirait un emploi canadien, avec des chiffres et des décisions. En Ontario, une offre d’emploi ne peut pas exiger d’expérience canadienne.
• Votre responsabilité se voit dans le récit de l’après-lancement. Les meilleurs moments de Mateo portaient sur les problèmes en production et sur ce qu’il avait construit ensuite.
• Appliquez votre ancien domaine au nouveau problème. Les coûts inégaux en crédit ont mené à un percentile élevé pour les heures d’arrivée estimées. Les données du bureau de crédit disponibles à un moment précis sont devenues des données météo disponibles au moment de la prédiction.
• Demandez de répéter la question, puis raisonnez. « Désolé, pouvez-vous répéter? » a coûté cinq secondes à Mateo. À la limite de ses connaissances, il ne connaissait pas la méthode. Mais il a compris pourquoi le test simple échoue et a poursuivi après une courte explication.
• Corrigez vos propres chiffres. « C’était plutôt 10, peut-être 12 % » a rendu ses autres chiffres crédibles.

Si votre profil ressemble à celui de Mateo

1. Préparez votre récit de production. Ce que vous avez construit, les problèmes après le lancement, comment vous les avez détectés et ce que vous avez changé. Utilisez les chiffres dont vous vous souvenez vraiment. Expliquer vos décisions vous aide à le dire à voix haute.
2. Vérifiez les mots « responsable » et « de bout en bout » dans votre CV. Remplacez-les par ce que vous avez fait et ce que les autres équipes ont fait.
3. Apprenez à prédire des percentiles et à vérifier ces prédictions. Entraînez un modèle LightGBM avec l’objectif quantile sur un jeu de données public. Vérifiez ensuite la couverture par groupe, pas seulement la couverture globale. L’étude de cas Prévoir la demande de vélopartage fournit un bon jeu de données pour cet exercice. L’analyse par sous-groupes montre comment examiner les groupes.
4. Apprenez le volet temps réel. Lisez comment fonctionne un magasin de variables en ligne. Créez un petit service avec un budget de latence strict, et mesurez le p99, pas la moyenne. Les cours Créer et déployer votre première API et L’essentiel de Docker et du nuage pour les développeurs en IA vous aident à créer le service.
5. Apprenez à concevoir des expériences pour les places de marché. Lisez sur l’interférence, les tests par alternance temporelle et les effets persistants. Expliquez pourquoi un test par client peut être incorrect quand les clients partagent les mêmes livreurs ou stocks.
6. Exercez-vous à voix haute, en anglais, à parler de vos propres projets. Vous n’avez pas besoin de parler comme une personne de langue maternelle anglaise. Vous devez être clair.