Le retour au travail

Imaginez une personne qui a conduit chaque jour pendant des années, puis a vécu sans voiture pendant trois ans. La première semaine du retour, le tableau de bord semble différent. Mais elle sait encore conduire. Elle voit encore l’enfant près de la route avant tout le monde.

Beaucoup d’ingénieurs reprennent le travail après une pause : enfants, parent malade, santé, déménagement ou études. Ils postulent souvent avec une crainte : « Les outils ont changé. Tout le monde verra le trou dans mon CV. » Les outils ont changé, un peu. Le jugement acquis au fil des années n’a pas disparu.

Suivez Hana pendant l’entrevue technique approfondie en apprentissage automatique chez Fennick. Observez comme la pause professionnelle est vite abordée, puis laissée derrière. Voyez où son expérience fait d’elle la meilleure candidate de la semaine, et où elle atteint ses limites.

HK

La personne candidate

Hana Kowalczyk

Ingénieure en apprentissage automatique, 7 ans en modèles de tarification et d'heure d'arrivée estimée, de retour après une pause professionnelle

• 7 ans comme ingénieure en apprentissage automatique
• Tarification et heure d'arrivée estimée pour le transport à la demande
• Pause professionnelle de 2022 à 2025
• Toronto, Ontario

• Ingénieure en apprentissage automatique, Tandem Rides (2015 à 2022). Modèles de tarification et d’heure d’arrivée estimée pour une entreprise de transport à la demande dans 9 villes canadiennes.
• Reconstruction du modèle d’heure d’arrivée estimée à la prise en charge (gradient boosting, amplification par gradient; caractéristiques des chauffeurs en temps réel). Réduction des prises en charge en retard d’environ 14 % à environ 8 % des trajets.
• Création du pipeline d’entraînement du modèle de tarification majorée et de sa surveillance. Garde pour les services de tarification et d’heure d’arrivée estimée.
• Pause professionnelle (2022 à 2025). Prise en charge à temps plein de mes deux jeunes enfants.
• Retour à l’apprentissage automatique (2026 à aujourd’hui). Cours sur les outils actuels d’apprentissage automatique. Projet public : prévision de la demande horaire de vélos en libre-service à Toronto, avec LightGBM, prédictions de quantiles, service FastAPI et surveillance hebdomadaire.
• Python, SQL, LightGBM, XGBoost, scikit-learn, Kafka, Redis, Airflow, Docker. Quelques connaissances de Kubernetes.

Ce que voit Ioana avant l’appel

Ioana lit le CV deux fois. Heure d’arrivée estimée à la prise en charge, caractéristiques en temps réel, prises en charge en retard comme mesure : c’est très proche du problème de Fennick. Le projet de vélos en libre-service est récent et utilise des prédictions de quantiles.

Elle voit la pause professionnelle. Le CV l’explique déjà, et elle ne concerne pas le poste. Ioana veut savoir autre chose :

• Quelle part du modèle d’heure d’arrivée estimée Hana a-t-elle construite elle-même? Se souvient-elle des raisons de chaque décision?
• Le chiffre « de 14 % à 8 % » est-il réel? Comment a-t-il été mesuré, et sur quels trajets?
• Son expérience des heures d’arrivée estimées mène-t-elle à de bonnes décisions pour Fennick, où les livreurs transportent des provisions, pas des passagers?
• Où s’arrêtent ses connaissances? Les outils de 2026 ne sont pas ceux de 2022. Que fait Hana face à quelque chose de nouveau?

Termes utilisés sur cette page

• ETA (heure d’arrivée estimée) : ici, le délai entre la commande et la livraison à domicile affiché dans l’application avant le paiement.
• Quantile (ou centile) : le 90e centile du délai de livraison est le délai que 90 % des livraisons ne dépassent pas. Une prédiction de quantile prédit ce délai pour une commande, plutôt que la moyenne.
• Perte quantile (ou pinball loss) : la perte d’entraînement pour une prédiction de quantile. Au 90e centile, une prédiction trop basse (la commande arrive plus tard) coûte 9 fois plus qu’une prédiction trop haute du même nombre de minutes.
• Couverture et calibration : si vous prédisez le 90e centile, environ 90 % des livraisons réelles devraient arriver avant ce délai. Si c’est le cas, la prédiction est calibrée. La calibration selon les conditions consiste à vérifier cela séparément à l’heure de pointe du souper, sous la pluie et dans chaque ville. On ne vérifie pas seulement la moyenne.
• Séparation temporelle : entraîner sur des données plus anciennes, tester sur des données plus récentes.
• Écart entre l’entraînement et la production : une caractéristique est calculée différemment pendant l’entraînement et en production. Le modèle reçoit donc en production des nombres différents de ceux utilisés pour apprendre.
• Magasin de caractéristiques (feature store) : un système qui calcule les caractéristiques une seule fois. Il fournit les mêmes valeurs à l’entraînement (le magasin hors ligne) et au service en production (le magasin en ligne).
• Fraîcheur des caractéristiques : l’âge d’une valeur de caractéristique en temps réel au moment où le modèle l’utilise.
• Test par alternance (switchback test) : un test en ligne où une zone entière utilise une version du modèle pendant une période, puis change de version. Utile quand les clients partagent les livreurs, car un test A/B habituel par client n’est alors pas équitable.

L’entrevue

Minutes 0 à 5 : le début

Ioana(intervieweur) :

Bonjour Hana. Alors, je suis Ioana, ingénieure principale en apprentissage automatique chez Delivery Intelligence. J’ai créé le service d’heure d’arrivée estimée, ou ETA. Je vais donc probablement poser trop de questions sur l’ETA. D’abord, un modèle que vous avez mis en production. Ensuite, un vrai problème de notre équipe. Puis vos questions. Pas d’assistants d’IA aujourd’hui, s’il vous plaît. Papier et crayon, c’est bon.

Hana(personne candidate) :

D’accord. J’ai du papier. Bien.

Minutes 5 à 25 : un modèle en production, puis on approfondit

Ioana(intervieweur) :

Alors. Parlez-moi d’un modèle que vous avez mis en production. Celui que vous voulez.

Hana(personne candidate) :

Je vais prendre l’ETA pour la prise en charge chez Tandem Rides. Ça date de 2019, donc c’est pas nouveau, mais c’est celui que je connais le mieux.

Alors, quand vous demandez une course, l’application affiche « le chauffeur arrive dans 6 minutes ». L’ancien modèle était assez simple, un modèle linéaire basé sur la distance et l’heure. Il était trop optimiste, surtout au centre-ville. Environ 14 % des prises en charge avaient plus de trois minutes de retard sur l’heure affichée. Les passagers annulaient, et les chauffeurs perdaient de l’argent.

Moi, j’ai construit un nouveau modèle avec l’amplification par gradient, XGBoost à ce moment-là. Le grand changement, c’était les caractéristiques : la position réelle du chauffeur, sa vitesse durant la dernière minute, et la circulation sur le trajet. Après le lancement, les prises en charge en retard sont passées à environ 8 %.

Ioana(intervieweur) :

Hum-hum. Et le 14 et le 8, vous les mesurez comment? Sur le même genre de journées?

Hana(personne candidate) :

Bonne question. Le 14, c’était les quatre semaines avant le lancement, le 8, les quatre semaines après. Donc pas les mêmes semaines, et c’était au printemps. On a aussi testé le nouveau modèle dans la moitié des villes pendant deux semaines, et la différence était plus petite. Je pense de 13 à 9, quelque chose comme ça. Donc l’effet réel, c’est environ quatre ou cinq points, pas six.

Pourquoi cela fonctionne

Un chiffre avant-après mélange l’effet du modèle avec tout ce qui a changé, comme la saison. Hana le sait et corrige son propre chiffre avec des preuves plus solides. Ses autres chiffres deviennent ainsi plus crédibles.

Ioana(intervieweur) :

Comment avez-vous divisé les données? Et pourquoi?

Hana(personne candidate) :

Par période. L’entraînement sur peut-être dix mois, la validation sur le mois suivant, le test sur le mois d’après. Jamais au hasard, parce que les courses du même soir se ressemblent beaucoup. Même pluie, même concert, même embouteillage. Avec une division aléatoire, le modèle voit le mardi soir dans les données d’entraînement et de test. Il semble très bon, mais il fait juste retenir ce mardi. Dans la vraie vie, il prédit toujours une journée qu’il n’a jamais vue.

Ioana(intervieweur) :

D’accord. Et les caractéristiques du chauffeur. D’où venaient-elles, pour l’entraînement et en production? C’étaient les mêmes?

Hana(personne candidate) :

Ah, oui. Dans la première version, c’étaient pas les mêmes. Pour l’entraînement, on calculait la vitesse avec la table d’historique GPS, nettoyée après coup. En production, on avait le GPS brut, avec des sauts et des trous. Donc le modèle était moins bon en production que hors ligne. On l’a vu dès la première semaine.

Après ça, le service enregistrait les valeurs exactes des caractéristiques utilisées pour chaque prédiction dans des journaux. Et on entraînait les versions suivantes avec ces journaux. Ça prend quelques semaines à recueillir, mais ensuite, l’entraînement et la production utilisent les mêmes chiffres.

Ioana(intervieweur) :

Sourit. On a appris la même chose, mais ça nous a pris six semaines pour le remarquer. Comment saviez-vous que le modèle fonctionnait encore, trois mois plus tard?

Hana(personne candidate) :

Un tableau de bord avec le taux de retard par ville et par heure, chaque jour. La course se termine, on connaît l’heure réelle de prise en charge, donc l’étiquette arrive vite. Et une alerte si une ville dépassait 12 % deux jours de suite. Pour les caractéristiques, on avait seulement des vérifications simples, comme la proportion de GPS manquants. Je pense qu’aujourd’hui, les gens surveillent plus la dérive.

Ce que l’intervieweur vérifie

Ioana vérifie l’écart entre l’entraînement et la production, le problème qui a nui à Fennick l’an dernier. Hana décrit un cas réel, comment elle l’a trouvé, et la solution : enregistrer les caractéristiques lors des prédictions et entraîner le modèle avec ces journaux. C’est encore une réponse standard en 2026.

Ioana(intervieweur) :

D’accord. Et après 2022?

Hana(personne candidate) :

J’ai pris une pause de carrière de trois ans pour m’occuper de mes deux enfants. Ils vont tous les deux à l’école maintenant, donc cette année, je suis revenue. J’ai suivi quelques cours, et fait le projet de vélos en libre-service.

Ioana(intervieweur) :

D’accord, merci. Dans le projet, je vois des quantiles. Comment vérifiez-vous que votre 90e centile est vraiment le 90e?

Vous n'avez pas à vous excuser d'une pause de carrière

Hana le dit en une phrase, sans s’excuser, puis explique ce qu’elle a fait pour revenir. Ioana passe à la suite, parce qu’il n’y a rien à juger. Vous ne devez à personne des détails sur votre famille ou votre santé. Préparez une phrase calme sur la pause et une autre sur votre retour. Puis revenez à votre travail.

Hana(personne candidate) :

Je compte. Sur les semaines de test, combien de fois le nombre réel de trajets était sous ma prédiction du 90e centile. Globalement, c’était environ 88 %, donc correct. Mais les jours de pluie, c’était beaucoup moins bon, peut-être 75 %.

Et, euh, j’ai trouvé un problème moi-même. Pour l’entraînement, j’ai utilisé la météo réelle de cette heure-là. Mais quand on prédit la veille, on a seulement les prévisions météo. Donc mes résultats sont trop bons. Je l’ai écrit dans les limites. Je l’ai pas encore corrigé.

Ioana(intervieweur) :

C’est correct. Au moins, vous le savez. Passons à notre problème.

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 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?

Hana(personne candidate) :

Je peux prendre une minute pour écrire?

Ioana(intervieweur) :

Bien sûr.

Environ quarante secondes de silence. Hana écrit.

Hana(personne candidate) :

D’accord. D’abord, qu’est-ce que le client voit? Un seul chiffre, ou un intervalle? Et le modèle prédit quoi, le délai moyen?

Ioana(intervieweur) :

Un seul chiffre, arrondi à cinq minutes. Le modèle est entraîné avec l’erreur quadratique habituelle. Donc oui, plus ou moins la moyenne.

Hana(personne candidate) :

Alors, je pense que c’est la raison principale. La distribution des délais de livraison a une longue queue du côté des retards. C’est difficile d’avoir vingt minutes d’avance, mais facile d’avoir vingt minutes de retard. Au souper et sous la pluie, la queue devient beaucoup plus longue. La moyenne bouge un peu, mais les commandes en retard bougent beaucoup. Donc le même modèle, avec la même petite marge, donne beaucoup plus souvent des retards ces jours-là.

Je prédirais donc plutôt un quantile élevé. Peut-être le 80e ou le 85e centile. LightGBM le fait directement avec l’objectif quantile. Pas le 95e, parce que le délai devient long et les gens commandent pas. Le retard est pire que l’avance, mais être trop pessimiste coûte aussi quelque chose. Savez-vous à quel point un délai plus long change les commandes?

Ioana(intervieweur) :

Un peu. 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, je pense. Je me souviens pas exactement.

Hana(personne candidate) :

D’accord, donc c’est réel, mais pas énorme. Alors je choisirais pas le quantile toute seule. Je montrerais aux équipes opérations et produit un petit tableau : pour les 75e, 80e, 85e et 90e centiles, quel est le taux de retard, et combien de minutes le délai affiché augmente en moyenne. Elles choisissent. C’est une décision d’affaires, pas une décision de modèle.

Pourquoi cela fonctionne

Deux questions sur le système actuel mènent Hana directement à la cause : le modèle prédit une moyenne. La queue des retards s’allonge au souper et sous la pluie. Elle traite ensuite le quantile comme un choix d’affaires et donne aux autres un tableau pour décider. C’est ce que signifie prendre la responsabilité d’un modèle.

Ioana(intervieweur) :

Bien. Disons qu’on choisit le 85e. Comment l’évaluez-vous hors ligne?

Hana(personne candidate) :

La perte quantile pour entraîner et comparer les modèles, avec une division par période, bien sûr. Mais la vraie vérification, c’est la couverture. Si je prédis le 85e, environ 85 % des commandes devraient arriver avant. Et pas seulement globalement. Par condition : pointe du souper, pluie, neige, chaque ville, grands commerces et petits commerces.

Ioana(intervieweur) :

Pourquoi par condition? Si c’est 85 % globalement, c’est correct, non?

Hana(personne candidate) :

Non, parce que c’est exactement votre problème aujourd’hui. Bien en moyenne, mauvais au souper. 85 % globalement, ça peut être 92 % un mardi après-midi tranquille et 70 % au souper sous la pluie. La moyenne cache ça. Donc pour chaque condition, je veux la couverture et le nombre de commandes, parce qu’un petit groupe varie beaucoup.

Ioana(intervieweur) :

Et si la couverture est mauvaise au souper sous la pluie?

Hana(personne candidate) :

D’abord, les caractéristiques. Le modèle doit savoir qu’il pleut et qu’il y a beaucoup d’activité : météo, commandes en cours au commerce, livreurs disponibles dans la zone. Pour la météo, attention, il faut utiliser ce que le service savait au moment de la commande. Pas les données historiques nettoyées. Mon erreur avec les vélos.

Si ça suffit pas, une correction après le modèle. Sur les semaines récentes, pour chaque condition, on trouve combien de minutes ajouter pour avoir la bonne couverture. Il y a une méthode pour ça, conformelle quelque chose. J’ai lu là-dessus, mais je l’ai jamais utilisée en production. En 2020, on le faisait à la main, avec un tableau par ville et par heure.

Une réponse plus solide : un risque de votre propre solution

Hana décrit la méthode avant de la nommer, ce qui est le bon ordre. (« Régression quantile conformalisée » est le nom qu’elle cherchait.) Une réponse un peu plus solide ajoute où la solution peut échouer : « Il faut ajuster la correction sur des données récentes non utilisées pour entraîner le modèle. Sinon, elle sera trop petite. » La correction par condition est parfois appelée méthode conformelle conditionnelle par groupe (Mondrian). Elle suppose que les semaines à venir ressemblent aux semaines utilisées pour l’étalonnage. Refaites donc souvent l’étalonnage et surveillez la couverture. Les personnes qui mènent les entrevues aiment entendre que vous connaissez les limites de votre propre idée.

Ioana(intervieweur) :

Maintenant, vous avez un nouveau modèle. Comment le testez-vous en ligne?

Hana(personne candidate) :

Avant ça, une question. Les livreurs, ils sont partagés? Un livreur, des commandes de différents clients?

Ioana(intervieweur) :

Oui. Un livreur peut transporter deux ou trois commandes, et la répartition choisit parmi tous les livreurs de la zone.

Hana(personne candidate) :

Alors un test A/B normal par client pose problème. Si le groupe B voit des délais plus longs, certains commandent pas. Il y a alors plus de livreurs disponibles, et le groupe A reçoit ses livraisons plus vite. A semble meilleur qu’il l’est vraiment.

Chez Tandem, on avait ça avec les chauffeurs. On utilisait des tests switchback, avec alternance dans le temps. Toute la zone utilise le modèle A pendant un certain temps, puis le modèle B. Et on alterne plusieurs fois, dans un ordre aléatoire.

Ioana(intervieweur) :

Combien de temps dure une fenêtre?

Hana(personne candidate) :

Laissez-moi réfléchir. Trente minutes? Non, attendez, une livraison dure plus longtemps que ça. Une commande de la fin d’une fenêtre est encore sur la route. Donc, une heure, peut-être. Et je compterais pas les commandes du début de chaque fenêtre. Aussi, l’unité, c’est la fenêtre, pas la commande, donc on a moins d’unités qu’on pense. Le test doit durer quelques semaines, avec des soupers et du mauvais temps.

La question avant la réponse

Hana demande comment les livreurs sont partagés avant de concevoir le test. Cette question est essentielle : quand les clients partagent des livreurs, un groupe change les livraisons de l’autre. Sa première estimation de la fenêtre était trop courte, et elle l’a corrigée elle-même. Une fenêtre doit durer plus longtemps qu’une livraison. C’est du raisonnement, pas de la mémoire.

Ioana(intervieweur) :

Dernière partie. Nos caractéristiques viennent d’un magasin de caractéristiques développé à l’interne. Certaines sont calculées par lots, comme le temps de préparation moyen du commerce. D’autres sont en temps réel, comme la position des livreurs et les commandes en cours, provenant d’un flux. À la pointe du souper, le flux prend parfois deux, trois minutes de retard. Qu’arrive-t-il à votre modèle?

Hana(personne candidate) :

Pardon, le flux prend du retard, vous voulez dire que les valeurs arrivent en retard? Ou qu’elles manquent?

Ioana(intervieweur) :

Elles arrivent en retard. Donc le magasin en ligne contient d’anciennes valeurs, et le service lit… comment dire, il lit ce qui est là.

Hana(personne candidate) :

Alors le modèle voit « cinq commandes en cours » quand il y en a déjà douze. Exactement au souper, quand c’est le plus important. Donc il est encore trop optimiste.

Chez Tandem, chaque valeur en temps réel avait un horodatage, et le service enregistrait son âge. Si l’âge dépassait une limite, on utilisait une valeur de repli, plus simple, pour cette heure-là. Et comme on entraînait le modèle avec les journaux, il avait aussi vu des valeurs anciennes.

Ioana(intervieweur) :

D’accord. Ici, le magasin construit les tables d’entraînement. Pour une commande à 18 h 42, il prend la dernière valeur avant 18 h 42. Mais avant 18 h 42 selon quelle heure? Celle de l’événement, ou celle de l’arrivée de la valeur dans le magasin?

Longue pause.

Hana(personne candidate) :

Hmm. J’ai pas utilisé ce genre de magasin de caractéristiques. Dans mon ancienne entreprise, on avait pas cette question, parce qu’on entraînait avec les journaux. Si votre magasin utilise l’heure de l’événement, l’entraînement voit des valeurs fraîches, et la production voit les valeurs en retard. Donc l’entraînement semble meilleur que la production. Comme votre problème d’écart, mais plus petit. Je pense qu’il faut l’heure d’arrivée. Mais comment votre magasin construit la table, je sais pas. Je devrais lire le code, ou demander à la personne qui l’a construit.

Ioana(intervieweur) :

C’est une bonne réponse. Honnêtement, le magasin permet les deux, et les équipes utilisent des paramètres différents. Certains d’entre nous l’ont découvert seulement l’an dernier.

La limite

C’est la limite des connaissances de Hana. Un magasin de caractéristiques construit une table d’entraînement en joignant chaque commande aux valeurs des caractéristiques « à ce moment-là ». L’horodatage choisi détermine si l’entraînement voit les mêmes retards que la production. Hana ne fait pas semblant. Elle part de son expérience pour cerner le bon risque et dit ce qu’elle vérifierait.

Une réponse plus solide à la limite

Hana pourrait aller plus loin avec ce qu’elle sait déjà : « Peu importe ce que fait le magasin, j’enregistrerais l’âge de chaque caractéristique en temps réel au moment de la prédiction. Je donnerais aussi cet âge au modèle comme caractéristique. Quand l’âge augmente au souper, le modèle peut alors apprendre à ajouter du temps. Et je mettrais une alerte sur l’âge, pas seulement sur l’erreur après la livraison. »

Ioana a ensuite posé une brève question sur le budget de 50 ms. Hana a dit qu’un modèle LightGBM comme celui-ci prédit généralement pour une commande en une milliseconde environ, ou moins. La lecture des caractéristiques était donc le vrai risque. Ioana a dit qu’il y avait un délai maximal, avec un repli vers les valeurs calculées par lots.

Minutes 48 à 57 : les questions de Hana

Hana(personne candidate) :

Première question : la surveillance. Vous surveillez les caractéristiques, ou seulement l’erreur?

Ioana(intervieweur) :

Seulement l’erreur après la livraison, rien sur les caractéristiques. C’est pour ça que l’écart a pris six semaines à détecter. On sait que c’est un risque.

Hana(personne candidate) :

Alors la surveillance des caractéristiques serait la première chose sur laquelle je voudrais travailler. Et, pardon, une dernière. Je sais que mes outils sont un peu vieux. Kubernetes, MLflow, je les ai utilisés seulement dans des cours. C’est un problème?

Ioana(intervieweur) :

Je peux pas vous dire la décision. Je peux dire qu’ici, nos outils s’apprennent en quelques semaines. Tout le monde apprend notre magasin de caractéristiques à partir de zéro, parce que personne à l’extérieur ne l’a.

Hana a aussi demandé comment fonctionne le réentraînement hebdomadaire, et comment se passent les périodes de garde. Ioana lui a répondu honnêtement : une tâche cron qu’un seul ingénieur comprend bien. Et une semaine de garde sur cinq pour le service du modèle, ce que l’offre d’emploi ne précise pas. La plupart des semaines sont tranquilles.

Les bonnes questions

Hana pose des questions sur les vrais risques du poste, et chaque réponse lui apprend quelque chose de vrai sur le travail. Consultez Une entrevue est une conversation dans les deux sens.

L'excuse

La dernière question commence par « pardon » et demande à l’intervieweuse de lever un doute. Hana n’en avait pas besoin. Ses réponses montraient déjà que son retard sur les outils est petit et que son jugement est solide. Si une lacune vous inquiète, dites votre plan, pas votre inquiétude : « J’ai utilisé MLflow dans mon projet. Je ne l’ai pas encore utilisé en équipe, et c’est la première chose que j’apprendrais. » Ou demandez de l’information : « De quoi voudriez-vous que je sois responsable après trois mois? »

Minutes 57 à 60 : la fin

Ioana(intervieweur) :

Merci, Hana. La suite, c’est la conception de systèmes avec Ben, et une conversation avec Laura des opérations. Chantal vous écrira cette semaine.

Hana(personne candidate) :

Merci, c’était intéressant. J’ai aimé la question sur le magasin de caractéristiques.

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

Ioana écrit ses notes juste après l’appel, en les comparant à l’offre d’emploi.

Hana Kowalczyk, entrevue approfondie en apprentissage automatique

• Responsabilité d’un modèle en production : preuves solides. A reconstruit un modèle d’heure d’arrivée estimée pour la collecte. L’a évalué avec un test par ville et a corrigé son propre chiffre avant-après. Surveillance par ville et par heure, avec une alerte.
• Évaluation : preuves solides. Séparation des données selon le temps, avec une raison claire. Couverture par condition, sans qu’on le lui demande. A trouvé une fuite de données dans son propre projet récent.
• Définition du problème d’heure d’arrivée estimée : preuves solides. La meilleure de la semaine. A trouvé la cause (moyenne plutôt qu’extrémité de la distribution des retards). A proposé un quantile avec un tableau des compromis pour les équipes produit et opérations.
• Expériences en ligne : preuves solides. A d’abord posé des questions sur les livreurs partagés, puis proposé des tests à alternance temporelle. A expliqué la durée des fenêtres.
• Variables en temps réel et nos outils : quelques preuves. Bons réflexes (consigner les variables, utiliser les anciennes valeurs en cas de problème). N’a pas utilisé de magasin de variables moderne. Explique clairement les limites de son expérience.
• Outils actuels (Kubernetes, MLflow, sujets liés aux LLM) : peu de preuves. Des cours et un projet. Pas une inquiétude : nous enseignons notre plateforme à tout le monde.

Recommandation : oui sans hésitation. Elle réfléchit comme une personne responsable du modèle d’heure d’arrivée estimée. Ses lacunes concernent les outils, et c’est ce que nous pouvons enseigner le plus facilement.

La suite

Ben a donné un avis favorable après l’entrevue de conception de systèmes. Hana était moins rapide avec Kubernetes et l’a dit. Laura a donné un avis très favorable après la discussion sur les valeurs. Laura a écrit : « Elle a demandé comment les livreurs se sentent quand l’application promet une heure qu’ils ne peuvent pas respecter. Personne d’autre n’a posé de questions sur les livreurs. »

Pendant la discussion de bilan, une personne a mentionné « les trois années d’absence ». Ravi a arrêté la discussion à ce moment-là. Il a demandé au comité de juger seulement les preuves recueillies pendant les entrevues. Ioana a ajouté que le jugement de Hana sur l’heure d’arrivée estimée était le meilleur qu’ils avaient vu. Elle a précisé que ce jugement ne devient pas périmé. Il y avait un seul poste à pourvoir, et Mateo Rojas était un très bon deuxième choix. L’équipe a choisi Hana.

Ravi a fait une offre dans la partie moyenne supérieure de la fourchette : 158 000 $ CA, plus prime et participation au capital. Elle n’a pas demandé un salaire plus élevé. Elle a demandé une chose : une semaine de quatre jours pendant les trois premiers mois, à 80 % du salaire. Sa famille pourrait ainsi établir une nouvelle routine. Elle a aussi demandé de commencer les périodes de garde après ces trois mois. Ravi a accepté les deux demandes et les a inscrites dans la lettre d’offre. Elle a accepté.

C’est une fin réaliste parmi d’autres, pas une promesse. Une autre entreprise aurait pu être moins juste face à la pause, ou embaucher quelqu’un maîtrisant des outils plus récents. La chance joue aussi un rôle.

Ce qu’il faut retenir

• Une pause de carrière est un fait, pas un aveu. Présentez-la en une phrase, expliquez votre retour, puis passez à autre chose. Hana y a consacré dix secondes, et l’entrevue aussi.
• Le jugement ne devient pas périmé. Hana a appris grâce à de vrais échecs, il y a des années. Ils concernaient les séparations selon le temps, les distributions asymétriques et les livreurs partagés. En 2026, ces questions restent les plus importantes.
• À la limite de vos connaissances, utilisez ce que vous savez. Hana n’avait jamais utilisé un magasin de variables comme celui de Fennick. Elle a expliqué comment son ancienne équipe résolvait le même problème. Son raisonnement l’a menée au bon risque, et elle a dit ce qu’elle vérifierait.
• Ne vous excusez pas pour vos outils. Nommez la lacune et votre plan. Pour ce type de poste, les intervieweurs s’intéressent davantage à votre raisonnement qu’aux derniers outils que vous avez utilisés.

Si votre profil ressemble à celui de Hana

1. Préparez votre phrase sur la pause et dites-la à voix haute. Une phrase sur la pause, une sur votre retour. Par exemple : « J’ai pris trois ans de pause pour m’occuper de mes enfants. Cette année, j’ai repris, actualisé mes connaissances avec des cours et réalisé un projet de prévision. » Vous n’avez pas besoin de donner plus de détails. En Ontario, le Code des droits de la personne protège la situation de famille. Une personne qui vous interviewe ne devrait donc pas vous demander si vous prévoyez avoir des enfants.
2. Inscrivez la pause sur votre CV comme une ligne normale. « Pause de carrière, soins à un proche à temps plein, de 2022 à 2025. » Une ligne claire évite les suppositions. Consultez Les éléments d’un portfolio et Se préparer aux candidatures.
3. Réalisez un projet récent qui montre vos forces antérieures avec des outils actuels. Hana a choisi une prévision avec des quantiles et une séparation selon le temps, proche du poste qu’elle voulait. Notre étude de cas Prévoir la demande de vélopartage est un bon point de départ. Ajoutez ensuite ce qu’une équipe de production ajouterait : un petit service et une surveillance de la couverture par condition.
4. Révisez les bases vérifiées en entrevue, plutôt que chaque nouvel outil. Commencez par Données d’entraînement, de validation et de test, L’analyse par sous-groupes et Planifier les vérifications en production. Apprenez ensuite un outil actuel pour chaque tâche que vous faisiez auparavant, par exemple MLflow pour le suivi des expériences.
5. Documentez vos anciens projets avant d’oublier les détails. Pour chacun, notez la cible, la séparation des données, la mesure, le problème survenu et comment vous l’avez découvert. Expliquer vos décisions montre comment en faire des réponses que vous pouvez dire à voix haute.
6. Apprenez comment un magasin de variables construit les données d’entraînement. Renseignez-vous sur les jointures « à un instant donné » et la différence entre l’heure de l’événement et l’heure d’arrivée. C’est là que Hana a atteint la limite de ses connaissances. Ce sujet revient souvent quand on parle de variables en temps réel.