L'ingénieur logiciel

Pensez à la cuisine d’un bon restaurant. Une personne planifie le menu et les recettes. Une autre veille à ce que 300 assiettes quittent la cuisine chaudes et à temps, chaque soir. Les deux tâches sont difficiles. Mais si la recette est mauvaise, même la cuisine la plus rapide en ville sert un mauvais repas.

Beaucoup de gens qui postulent comme ingénieurs en apprentissage automatique sont cette deuxième personne. Ce sont des ingénieurs backend (côté serveur). Un scientifique des données a construit un modèle, et ils l’ont mis en production. Ils ont créé les tâches d’entraînement nocturnes, le service rapide, le cache et le test A/B. Ils ont aimé le travail et veulent maintenant assumer le rôle au complet.

Ce profil est solide là où beaucoup de candidats en apprentissage automatique ont des faiblesses. La lacune habituelle se trouve dans l’autre moitié du travail. Que devrait prédire le modèle? Comment mesure-t-on ses résultats? Comment sait-on que le test est équitable? Tunde Bakare correspond à ce profil. Observez où ses compétences en ingénierie enrichissent la conversation, et où Ioana l’amène aux limites de son jugement en apprentissage automatique.

TB

La personne candidate

Tunde Bakare

Ingénieur backend, 6 ans d'expérience, en transition vers l'apprentissage automatique

• 6 ans en backend
• 4 ans à Lagos, 2 ans à Toronto
• Python et Go
• De garde depuis 5 ans
• Toronto

• Ingénieur logiciel principal, Marlow & Pike (vente au détail d’articles pour la maison, Toronto), de 2024 à aujourd’hui
• A conçu et déployé un système de recommandation par apprentissage automatique (« You may also like », vous pourriez aussi aimer), augmentant les revenus de 12 %
• A construit la couche de service : FastAPI et Redis, environ 2 millions de requêtes par jour, p99 inférieur à 40 ms
• A construit le pipeline d’entraînement nocturne (Airflow, BigQuery), ainsi que l’attribution des groupes du test A/B et la journalisation
• Ingénieur logiciel, Orinpay (paiements, Lagos), de 2020 à 2024. Routage des paiements et API de transactions en Go et Python; de garde depuis 2021
• Python, Go, FastAPI, Redis, Kafka, PostgreSQL, Kubernetes, Airflow
• Certificat en ligne en apprentissage automatique (2023)

Ce qu’Ioana voit avant l’appel

Ioana Petrescu est ingénieure experte en apprentissage automatique chez Fennick. Elle a construit le service d’estimation de l’heure d’arrivée. Elle a aussi trouvé le bogue de décalage entre entraînement et service l’an dernier. Elle lit le CV de Tunde en parallèle avec l’offre d’emploi.

Les preuves de ses compétences en ingénierie sont solides. Deux millions de requêtes par jour avec un p99 inférieur à 40 ms, c’est proche de la charge de Fennick. Il est aussi de garde depuis des années. Ravi, le gestionnaire responsable de l’embauche, a écrit : « Très clair sur les systèmes. Moins sûr pour la modélisation. »

Elle marque une ligne : « A conçu et déployé un système de recommandation par apprentissage automatique, augmentant les revenus de 12 % ». Qui a conçu le modèle? Et 12 % de quoi? Elle note trois points à éclaircir :

• Quelles décisions sur le modèle Tunde a-t-il prises lui-même, et lesquelles a-t-il seulement mises en œuvre?
• Comprend-il pourquoi le modèle a été entraîné et testé de cette façon?
• Pour le problème d’estimation de l’heure d’arrivée, va-t-il au-delà du service? Peut-il raisonner sur ce que le modèle devrait prédire?

Termes utilisés dans cette page

• ETA (heure d’arrivée estimée) : ici, le délai entre la commande et l’arrivée chez le client, affiché avant le paiement.
• Latence p99 : 99 % des requêtes se terminent en moins de temps. Le 1 % le plus lent prend plus de temps.
• Budget de latence : le temps maximal permis pour une requête, réparti entre toutes ses étapes.
• Magasin de caractéristiques : un système qui calcule les entrées du modèle (les caractéristiques) et les fournit. Il comprend une partie hors ligne pour l’entraînement et une partie en ligne pour les requêtes en direct.
• Décalage entre entraînement et service : une caractéristique est calculée d’une façon pour l’entraînement et d’une autre en production. Le modèle apprend une signification et en reçoit une autre.
• Cooccurrence : la fréquence à laquelle deux produits sont achetés ensemble.
• Modèle de reclassement (reranker) : un deuxième modèle qui place une courte liste de candidats dans un meilleur ordre.
• Division temporelle : vous entraînez le modèle sur des données anciennes et le testez sur des données récentes, comme en utilisation réelle.
• Quantile (ou centile) : le 90e centile des délais de livraison est le délai sous lequel se trouvent 90 % des commandes.

L’entrevue

Minutes 0 à 5 : l'ouverture

Ioana(intervieweur) :

Bonjour Tunde. Vous m’entendez bien? Je suis Ioana, ingénieure principale en apprentissage automatique chez Delivery Intelligence. J’ai créé le service ETA, alors faites attention à ce que vous en dites.

Tunde(personne candidate) :

Rit. D’accord, c’est noté. Bonjour, oui, je vous entends bien.

Ioana(intervieweur) :

Alors, voici le plan. D’abord, vous me parlez d’un modèle que vous avez mis en production, et je pose beaucoup de questions. C’est normal, ce n’est pas un mauvais signe. Ensuite, un vrai problème de notre côté. À la fin, vos questions. Une règle : pas d’assistants d’IA pour cette étape. Si vous voulez écrire sur papier, aucun problème.

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

Ioana(intervieweur) :

Alors, parlez-moi du projet de recommandation.

Tunde(personne candidate) :

D’accord. Chez Marlow & Pike, chaque page de produit avait un encadré « You may also like » (vous pourriez aussi aimer). Avant, c’était juste les meilleures ventes de la même catégorie. Très ennuyeux, les huit mêmes produits pour tout le monde. Notre scientifique des données, Adaeze, a créé un meilleur modèle. Et mon travail, c’était de le faire fonctionner en production.

Alors, voici comment ça marche : chaque nuit, une tâche compte les produits achetés ensemble dans les 90 derniers jours. Pour chaque produit, on garde environ les 200 premiers. Ensuite, quand un utilisateur ouvre une page, le service prend ces 200 produits. Un petit modèle, une régression logistique, les classe. On affiche les huit premiers. J’ai créé les tâches nocturnes, le service, le cache dans Redis et les mécanismes du test A/B.

Ioana(intervieweur) :

D’accord. Qu’est-ce que le modèle prédisait?

Tunde(personne candidate) :

Il renvoie une liste de huit identifiants de produits, avec un score. Et si le modèle n’est pas disponible, on renvoie l’ancienne liste des meilleures ventes. Comme ça, la page fonctionne toujours.

Ioana(intervieweur) :

Pardon, je parle de ce qui se passe à l’intérieur. La régression logistique. Pendant l’entraînement, quelle était l’étiquette? C’est quoi, un « un » et un « zéro »?

Tunde(personne candidate) :

Ah, d’accord, l’étiquette. Un clic, je pense. Si l’utilisateur cliquait sur le produit recommandé, c’est un. Affiché mais pas cliqué, zéro. Oui, un clic dans la même session.

Ioana(intervieweur) :

Pourquoi un clic? L’entreprise veut des ventes, non?

Tunde(personne candidate) :

C’est Adaeze qui a décidé. Je pense que c’est parce qu’il y a beaucoup de clics et peu d’achats. Pour les achats, il y en a, je ne sais pas, peut-être un pour cent clics. Trop peu de données pour le modèle. Mais je ne suis pas sûr que c’était la seule raison.

Ce que l’intervieweur vérifie

Tunde a d’abord compris la question comme une question sur le service. Ça arrive, et Ioana la pose simplement de nouveau, plus précisément. Elle veut savoir si Tunde comprend les choix à l’intérieur du modèle. Sa raison pour les clics est une bonne hypothèse, et il précise que c’est une hypothèse.

Ioana(intervieweur) :

D’accord. Et comment Adaeze a testé le modèle avant sa mise en production? Hors ligne.

Tunde(personne candidate) :

Elle a utilisé l’AUC. Et une autre mesure, quelque chose sur les huit premiers… la précision à huit, je pense. Elle a pris les journaux (logs), 80 % pour l’entraînement, 20 % pour le test. Au hasard, je pense.

Ioana(intervieweur) :

Est-ce qu’une séparation aléatoire pose un problème ici? Prenez un moment.

Tunde(personne candidate) :

Hmm. Le même utilisateur peut être dans les données d’entraînement et de test? Mais… je ne suis pas sûr que ce soit mauvais. Le même utilisateur revient aussi dans la vraie vie.

Ioana(intervieweur) :

Pensez à la façon dont vous l’utilisez. On entraîne le modèle lundi soir. Quand fait-il ses prédictions?

Tunde(personne candidate) :

Mardi. Ah, d’accord. Donc, dans la vraie vie, il prédit toujours l’avenir. Mais avec une séparation aléatoire, le test contient des jours qui sont dans la période d’entraînement. En novembre, avant le Black Friday, les produits changent chaque jour. Donc le test aléatoire donne de meilleurs résultats que dans la vraie vie. Je vois. Adaeze devrait tester sur les jours après l’entraînement. Je ne lui ai jamais posé la question, honnêtement. Pour moi, c’était sa partie.

Où cela tourne mal

« Pour moi, c’était sa partie » est honnête, et c’est la principale inquiétude pour ce poste. Chez Fennick, l’ingénieur en apprentissage automatique est responsable de ces décisions. Tunde a vite trouvé la bonne idée quand Ioana lui a donné l’exemple du lundi et du mardi. Mais une séparation aléatoire sur des données qui changent avec le temps est une erreur très courante en apprentissage automatique. Ce poste exige quelqu’un qui la repère sans aide. Voir Choisir une séparation.

Ioana(intervieweur) :

Votre CV indique une hausse de revenus de 12 %. Parlez-moi de ce chiffre.

Tunde(personne candidate) :

Oui… alors. Le test A/B était réparti moitié-moitié par identifiant d’utilisateur, pendant quatre semaines. Dans le nouveau groupe, les ajouts au panier depuis la page de produit ont augmenté d’environ 12 %. Pour les revenus, l’équipe marketing a calculé quelque chose, mais je ne sais pas comment. Donc « revenus », ce n’est pas correct. Je devrais changer cette ligne, honnêtement.

Ioana(intervieweur) :

D’accord, merci. Ensuite, qu’est-ce qui s’est passé après le lancement? Quelque chose a cessé de fonctionner?

Tunde(personne candidate) :

Oui. Ça, je m’en souviens bien. Environ cinq mois après le lancement, Adaeze a ajouté deux nouvelles caractéristiques. Elle a refait l’entraînement, les métriques d’entraînement étaient bonnes, on a déployé. Mais le taux de clics a baissé, peut-être de 10 %, dès le premier jour. Personne ne l’a remarqué pendant neuf jours. Elle l’a vu dans son tableau de bord hebdomadaire, je pense.

Le problème : dans le code d’entraînement, les caractéristiques étaient dans un certain ordre. Dans mon code de prédiction, après son changement, deux étaient dans un ordre différent. Le rapport des prix et l’indicateur de même catégorie étaient inversés. Le modèle fonctionnait encore. Aucune erreur. Juste des résultats faux.

Ioana(intervieweur) :

Sourit. Je connais ce genre de bogue. Qu’avez-vous changé ensuite?

Tunde(personne candidate) :

Alors, on a mis le code des caractéristiques dans un seul module. L’entraînement et le service de prédiction l’importent tous les deux. Pas de copie.

Ioana(intervieweur) :

Hum-hum.

Tunde(personne candidate) :

Et le fichier du modèle enregistre maintenant les noms des caractéristiques. Le service les vérifie au démarrage. S’ils ne correspondent pas, il ne démarre pas. Ah, et un test dans l’intégration continue : on compare mille requêtes enregistrées dans les journaux, avec les deux chemins.

Pourquoi cela fonctionne

C’est la partie la plus solide du projet de Tunde. Il ne s’est pas arrêté à la correction. Il a rendu difficile le déploiement du même bogue : un seul chemin de code partagé, une vérification au chargement du modèle et un test qui compare les deux chemins. Un bogue de ce genre a coûté six semaines à Fennick l’an dernier.

Ioana(intervieweur) :

Bien. Dernière question là-dessus. Avant le tableau de bord hebdomadaire d’Adaeze, qui aurait su si le modèle devenait moins bon?

Tunde(personne candidate) :

Hmm. Mes alertes concernaient le service : la latence, les erreurs, la fréquence d’utilisation de la liste de secours. Si le service est lent, je le sais en deux minutes. Si le modèle est mauvais mais rapide… personne, jusqu’à ce qu’Adaeze regarde. C’est une lacune, oui.

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 délai de livraison dans l’application avant de payer. À l’heure du souper et quand il fait mauvais, notre estimation est trop optimiste. Les jours normaux, environ 9 % des commandes arrivent plus de dix minutes après le délai estimé. Ces jours-là, c’est environ 18 %. Les gens sont fâchés, les billets de soutien augmentent. Comment aborderiez-vous ce problème?

Tunde(personne candidate) :

D’accord. Je peux d’abord demander ce que l’application affiche? Un seul nombre?

Ioana(intervieweur) :

Un seul nombre. « 35 minutes », comme ça.

Tunde(personne candidate) :

Ma première question est peut-être étrange. Est-ce un problème de modèle ou de données? Parce que l’heure du souper, c’est aussi quand les systèmes sont très occupés. Si le magasin de caractéristiques est lent au souper, peut-être que le service dépasse le délai et… pardon, j’ai perdu mon idée. Oui. Il dépasse le délai et utilise des valeurs par défaut. Alors le modèle est bon, mais il reçoit des entrées anciennes ou vides au moment où elles comptent le plus.

Ioana(intervieweur) :

Hmm. Intéressant. Comment vérifieriez-vous ça?

Tunde(personne candidate) :

L’enregistrer dans les journaux. Pour chaque prédiction : quelles caractéristiques venaient des valeurs de secours, et l’âge de chaque caractéristique en temps réel. Puis regarder par heure. Si, à 18 h, la valeur « commandes au magasin » date de 20 minutes, c’est ça, le problème.

Ioana(intervieweur) :

On n’a pas vérifié la fraîcheur par heure, en fait. Je vais le noter. Mais on a eu quelque chose de semblable l’an dernier. La caractéristique « commandes en attente au magasin ». Pour l’entraînement, elle venait d’une table mise à jour par lots toutes les 15 minutes. En production, elle venait de décomptes en temps réel. Hors ligne, tout semblait bon; en ligne, c’était moins bon. Six semaines avant que quelqu’un le remarque.

Tunde(personne candidate) :

Ah. Donc le même genre de bogue que le mien, mais plus discret. Au souper, le décompte en temps réel dépasse la valeur sur 15 minutes, parce que la file grandit vite. Donc le modèle voit un nombre qu’il n’a jamais vu pendant l’entraînement.

La correction, c’est la même idée : une seule définition de la caractéristique. Idéalement, on enregistre les valeurs des caractéristiques au moment de la prédiction, les valeurs exactes utilisées par le service. Et on entraîne le modèle sur ces journaux. Alors l’entraînement voit ce que la production voit. Il faut quelques semaines pour recueillir assez de journaux, mais après, le problème disparaît.

Pourquoi Ioana aime cette réponse

Tunde fait tout de suite le lien entre son bogue et celui de Fennick. Puis il propose la meilleure correction : entraîner sur les valeurs réellement utilisées par le service, enregistrées au moment de la prédiction. Beaucoup d’équipes appellent ça « enregistrer et attendre », parce qu’il faut attendre d’avoir assez de journaux. Ioana n’a pas eu besoin de le guider ici.

Ioana(intervieweur) :

Bien. Maintenant, on veut aussi ajouter la météo. Aujourd’hui, on ne l’a pas. Comment l’ajoutez-vous?

Tunde(personne candidate) :

Hmm, pas pendant que le client attend, non. Je ferais une tâche qui récupère la météo toutes les dix minutes pour chaque zone. Elle l’écrit dans le magasin de caractéristiques. Le service la lit comme toute autre caractéristique. Si la valeur date de plus de, disons, 30 minutes, on l’utilise quand même, mais on enregistre un indicateur.

Et pour l’entraînement, garder l’historique de ce que la tâche a écrit. Pas la météo réelle connue plus tard. Parce qu’à 17 h, on a seulement les prévisions, et la pluie à 18 h peut être différente. Si on entraîne sur la pluie réelle, c’est une fuite de données : le modèle apprend à partir de l’avenir.

Ioana(intervieweur) :

Oui. Et la latence? L’application nous appelle à chaque affichage de la page de paiement, environ 1,5 million de fois par jour. Notre budget est de 50 millisecondes au p99.

Tunde(personne candidate) :

Comment ce temps est utilisé aujourd’hui? Vous le savez?

Ioana(intervieweur) :

La lecture des caractéristiques en prend la plus grande partie. Peut-être 20, 25 ms au p99. Le modèle lui-même est très rapide, quelques millisecondes.

Tunde(personne candidate) :

Alors la météo, c’est une lecture de plus. Si elle est dans le même magasin et qu’on lit toutes les caractéristiques en un appel, ça coûte presque rien. Si c’est un appel séparé, le faire en parallèle, pas l’un après l’autre. Et chaque lecture a un délai maximal, peut-être 30 ms, parce qu’on doit rester sous 50. Après ça, utiliser une valeur par défaut et l’enregistrer dans les journaux.

Ioana(intervieweur) :

Hum-hum.

Tunde(personne candidate) :

Aussi, 1,5 million par jour, c’est seulement environ 17 par seconde en moyenne. Au souper, c’est peut-être cinq ou dix fois plus?

Ioana(intervieweur) :

Moins, peut-être trois, quatre fois.

Tunde(personne candidate) :

D’accord, donc la charge ne pose pas de problème. Le p99 est la partie difficile, pas le volume.

Vérifier le calcul

1,5 million d’appels par jour divisés par 86 400 secondes donnent environ 17 appels par seconde. L’estimation rapide de Tunde est juste et mène au bon constat : la difficulté concerne le 1 % des requêtes les plus lentes, pas le volume.

Ioana(intervieweur) :

D’accord. Très bien pour le service. Maintenant, regardons le modèle lui-même. Disons que les entrées sont parfaites. Récentes, sans décalage, avec la météo. Pensez-vous que les commandes en retard disparaissent?

Tunde(personne candidate) :

Hmm. Ça s’améliore, je pense. Mais ça ne disparaît pas, parce que… Pause. Pardon, je réfléchis. Même un modèle parfait fait des erreurs, parce qu’il y a des choses qu’on ne peut pas savoir. Un livreur a un pneu crevé. Mais je ne sais pas si ça représente 9 % ou 18 %.

Ioana(intervieweur) :

D’accord, je vais poser la question autrement. Le modèle est entraîné pour être juste en moyenne. Sous la pluie, les délais de livraison sont plus dispersés. Certaines commandes prennent 30 minutes, d’autres 60. Si le modèle est juste en moyenne, que voit le client?

Tunde(personne candidate) :

Un nombre au milieu. Et beaucoup de gens reçoivent leur commande après ce délai. Plus sous la pluie, parce que la dispersion est plus grande. D’accord. Donc on ajoute une marge? Cinq minutes de plus au souper, dix de plus sous la pluie?

Ioana(intervieweur) :

L’équipe des opérations l’a fait en mars, en fait. Cinq minutes de plus quand il pleuvait, dans deux villes. Le taux de retard a un peu baissé. Mais dans les rues tranquilles, près du magasin, l’estimation est devenue trop longue. Les commandes ont baissé d’environ un ou deux pour cent.

Tunde(personne candidate) :

Oui, parce que la marge est la même pour tout le monde. Elle devrait dépendre de la commande. Mais je ne sais pas comment un modèle fait ça. Prédire la moyenne et aussi… la dispersion?

Ioana(intervieweur) :

C’est une façon de faire. Une autre : on ne demande pas au modèle « quel est le délai moyen ». On demande « en moins de combien de temps arriveront 90 % des commandes? »

Tunde(personne candidate) :

Comme la latence p99, mais pour la livraison. Le modèle prédit directement un centile? Je ne savais pas qu’on pouvait l’entraîner pour ça. Comment il l’apprend?

Ioana(intervieweur) :

Il existe une fonction de perte pour ça, la perte quantile. Si la commande arrive après la prédiction, ça coûte beaucoup; si elle arrive avant, ça coûte peu. Donc le modèle apprend à prédire plus haut. LightGBM l’intègre déjà.

Tunde(personne candidate) :

D’accord. C’est nouveau pour moi. Il faudrait que je lise là-dessus.

Comment Ioana approfondit

Tunde atteint ici la limite de ses connaissances. Il ne connaît pas la régression quantile, et il le dit. Ioana reformule deux fois. La deuxième fois, elle utilise une image simple : le délai avant lequel arrivent 90 % des commandes. Tunde fait le lien avec la latence p99, qu’il connaît bien. Utiliser ses connaissances pour comprendre une nouveauté, c’est ce qu’on espère voir en entrevue à cette limite.

Ioana(intervieweur) :

Aucun problème. Utilisons ça. Disons qu’on a un modèle qui prédit le 90e centile. Comment vérifiez-vous s’il est bon? Hors ligne, avant de le mettre en production.

Tunde(personne candidate) :

L’erreur absolue moyenne? Hmm, non, attendez. S’il prédit haut exprès, l’erreur est toujours grande. Ce n’est pas juste. Hmm… pour la latence p99, je vérifie que 99 % des requêtes sont vraiment sous ce seuil. Donc ici : compter les commandes arrivées avant le délai prédit. Ça devrait être environ 90 %.

Ioana(intervieweur) :

Et si c’est 90 % globalement?

Tunde(personne candidate) :

Alors vérifier seulement le souper. Seulement la pluie. Chaque ville séparément. Parce que la moyenne peut être de 90 %, et sous la pluie, peut-être de 80 %. C’est exactement notre problème.

Une réponse plus solide à la limite des connaissances

Tunde a trouvé la bonne vérification, la couverture par condition. Mais Ioana a dû le guider vers l’idée d’un centile. Une personne avec plus d’expérience en apprentissage automatique partirait du client et de la cible :

« Avant le modèle : qu’est-ce qu’on promet au client? Un retard est pire qu’une avance, alors on affiche peut-être un centile élevé, pas la moyenne. Mais s’il est trop élevé, les gens ne commandent pas. Donc je suivrais deux chiffres : le taux de retard et la fréquence d’abandon de la page de paiement. »

Vous n’avez pas besoin de connaître toutes les méthodes. Vous devez demander ce que promet le nombre à l’écran. Voir Les métriques de régression.

Ioana a ensuite demandé comment Tunde testerait le nouveau modèle en ligne. Il a proposé son test A/B habituel, avec une séparation par identifiant de client. Ioana a souligné que les livreurs sont partagés. Un client du groupe A et un client du groupe B peuvent attendre le même livreur. Les deux groupes ne sont donc pas indépendants. Tunde a vite compris le problème. Il a suggéré une séparation par ville, mais a reconnu que 14 villes étaient trop peu pour comparer. Ioana lui a expliqué que l’équipe sépare par zone et par plage horaire, puis ils sont passés à la suite.

Minutes 48 à 57 : les questions de Tunde

Tunde(personne candidate) :

J’en ai quelques-unes. D’abord : le réentraînement. Qui en est responsable? Comment ça fonctionne?

Ioana(intervieweur) :

Rit un peu. La réponse honnête? C’est une tâche cron, chaque semaine. Un seul ingénieur la comprend vraiment. C’est sur notre liste.

Tunde(personne candidate) :

D’accord. C’est le genre de chose que j’aime corriger, honnêtement. Deuxième question : la garde. L’offre d’emploi n’en parle pas.

Ioana(intervieweur) :

Une semaine sur cinq, pour le service ETA. Il n’y a pas beaucoup d’alertes, peut-être deux ou trois dans une mauvaise semaine. Surtout des problèmes de magasin de caractéristiques.

Tunde(personne candidate) :

La vidéo fige un moment. …pardon, votre image a figé. Vous avez dit deux ou trois par semaine?

Ioana(intervieweur) :

Dans une mauvaise semaine, oui. La plupart des semaines, moins.

Tunde(personne candidate) :

D’accord, bien. Dernière question. Y a-t-il une équipe de plateforme, ou est-ce que Delivery Intelligence gère sa propre infrastructure?

Ioana(intervieweur) :

Il y a une équipe ML Platform. Elle est responsable du magasin de caractéristiques et de la plateforme de prédiction. On construit nos services dessus.

Les bonnes questions

Tunde pose des questions sur ce qu’une offre d’emploi cache souvent : la responsabilité du réentraînement, la garde et les limites de la plateforme. Chaque réponse lui apprend quelque chose de concret sur le poste. C’est l’entrevue comme conversation dans les deux sens.

Minutes 57 à 60 : la conclusion

Ioana(intervieweur) :

Merci, Tunde. J’ai vraiment aimé la partie sur le bogue d’ordre des caractéristiques. La prochaine étape est la conception de systèmes avec Ben. Chantal vous contactera cette semaine.

Tunde(personne candidate) :

Merci. Et je vais lire sur la perte quantile ce soir.

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

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

Tunde Bakare, entrevue approfondie en apprentissage automatique

• Service à faible latence : preuves solides. Service de recommandation traitant environ 2 millions de requêtes par jour, p99 sous 40 ms. Pour notre problème : délais d’expiration, lectures parallèles, estimation rapide de la charge, météo hors du traitement de la requête.
• Pipelines de variables et écarts entre l’entraînement et la production : preuves solides. A trouvé son propre bogue d’écart et a rendu sa réintroduction difficile au déploiement. A proposé sans aide d’entraîner le modèle sur les variables consignées. Meilleur que la plupart des candidats sur ce point.
• Définition du problème (quoi prédire) : préoccupation. N’a pas remis en question la cible de son projet (« Adaeze a décidé »). Pour notre problème, a eu besoin de deux indices pour arriver à une cible fondée sur un centile.
• Évaluation : quelques preuves. N’a pas vu le problème d’une séparation aléatoire avant que je donne un exemple. Ensuite, a bien raisonné : couverture, vérifiée par condition.
• Expériences : quelques preuves. A construit l’infrastructure des tests A/B. N’a pas pensé aux livreurs partagés, mais a compris rapidement.
• Communication et honnêteté : preuves solides. A corrigé de lui-même la ligne de son CV sur les revenus.

Recommandation : non pour ce poste, pour l’instant. Ce poste est responsable du modèle d’heure d’arrivée estimée. Aujourd’hui, Tunde aurait besoin de quelqu’un d’autre pour prendre les décisions sur le modèle. Mais c’est l’un des meilleurs ingénieurs à qui j’ai parlé cette année. Je recommande que Ravi parle à ML Platform. Leur poste ouvert correspond bien à ses forces.

La suite

Les notes de Ben sur la conception du système allaient dans le même sens. C’était la conception la plus claire de la semaine pour le service du modèle et les défaillances. Par contre, l’évaluation du modèle était un point faible. Lors du bilan, l’équipe était d’accord. Le seul poste vacant exigeait une personne responsable du modèle, et un autre finaliste était plus fort sur ce point.

Ravi a lui-même appelé Tunde. Il a transmis les commentaires honnêtement : ingénierie très solide, connaissances en apprentissage automatique insuffisantes pour cette équipe actuellement. Puis, il a demandé la permission de transmettre son profil à l’équipe ML Platform, qui avait un poste senior ouvert. Tunde a accepté.

ML Platform a repris ses entrevues chez Fennick et a ajouté une entrevue sur la conception de plateformes. Deux mois plus tard, Tunde a rejoint ML Platform. Son premier projet : remplacer la tâche cron de réentraînement hebdomadaire par un vrai pipeline.

C’est une issue réaliste, pas une promesse. Les entreprises n’ont pas toutes une équipe de plateforme et ne transmettent pas toutes votre profil. La chance joue aussi un rôle.

Ce qu’il faut retenir

• L’ingénierie solide est un vrai travail d’apprentissage automatique. Les écarts, la fraîcheur des données, la latence et les solutions de repli ont fait échouer le modèle de Fennick l’an dernier. Les compétences de Tunde dans ce domaine sont rares, et Ioana l’a remarqué.
• Comprenez les décisions de votre projet, même si vous ne les avez pas prises. « Le scientifique des données a décidé » est honnête. Mais vous devriez quand même savoir pourquoi l’étiquette, la séparation et la mesure ont été choisies. Posez-lui ces questions avant votre entrevue.
• Corrigez les chiffres de votre CV avant que la personne qui vous interviewe le fasse. Tunde a remplacé « revenus » par « ajouts au panier » de lui-même. Cela a rendu le reste de ses propos plus crédible.
• Utilisez vos connaissances pour comprendre ce que vous ne connaissez pas. Tunde est passé de la latence p99 à une cible fondée sur un centile, puis à la couverture. C’est une bonne façon de réagir aux limites de ses connaissances.
• Demandez ce que promet le nombre à l’écran. Le modèle et la mesure découlent de cette réponse.

Si votre profil ressemble à celui de Tunde

1. Interviewez votre scientifique des données. Pour chaque modèle que vous avez mis en service, notez l’étiquette, la séparation, la mesure hors ligne et la référence de base. Notez aussi les raisons de ces choix. Si vous ne savez pas, demandez à la personne qui a choisi. Si vous ne pouvez pas lui demander, décidez ce que vous choisiriez et pourquoi. Consultez Traduire un besoin et Définir une référence de base.
2. Apprenez la séparation temporelle jusqu’à pouvoir l’expliquer avec votre propre exemple. Utilisez un jeu de données avec des dates et comparez une séparation aléatoire à une séparation par date. Consultez Choisir une séparation et Caractéristiques et moment de la cible.
3. Entraînez un modèle pour un centile. Prenez un jeu de données de régression. Entraînez un modèle pour la médiane et un autre pour le 90e centile, puis vérifiez la couverture par groupe. L’étude de cas Prévoir la demande de vélopartage est un bon point de départ.
4. Ajoutez la surveillance des modèles à vos compétences de mise en service. Vous surveillez déjà la latence et les erreurs. Ajoutez une vérification des prédictions et des entrées. Consultez Planifier les vérifications en production.
5. Présentez vos expériences d’ingénierie sous l’angle de l’apprentissage automatique. Pour le bogue d’écart, dites ce que le modèle a appris et ce qu’il a reçu en production. Expliquez aussi comment vous avez empêché le problème de se reproduire. Expliquer vos décisions vous aide à le dire à voix haute.