Entretien blanc ML Engineer — pratique avec l'IA

Les entretiens de ML engineer se situent quelque part entre la data science et le backend, et les candidats qui réussissent sont ceux qui cessent de prétendre être l'un ou l'autre. Les recruteurs veulent quelqu'un capable de prendre un notebook Jupyter, de le livrer comme un service, et de remarquer quand l'AUC offline cesse de prédire le comportement en ligne. Ce guide montre comment utiliser les entretiens blancs IA pour répéter précisément les loops ML qui produisent des offres — pas le parcours du combattant de coding à la FAANG, mais la conversation pratique « êtes-vous vraiment capable de livrer un modèle ».

Les tours d'entretien typiques pour les ml engineers

Le loop de ML engineer varie énormément selon l'entreprise. Dans les entreprises ML-first (labos de recherche, startups IA), attendez-vous à 5 ou 6 tours : un phone screen sur les fondamentaux, un entretien de coding (Python plus NumPy/PyTorch), un tour de ML system design, un tour de discussion de papier ou de research-fit, un behavioral, et un échange avec le hiring manager. Dans les product companies (la majorité du marché), le loop se compresse à 4 tours : un phone screen, un entretien de coding, un ML system design et case study, et un behavioral. Temps total : 5 à 7 heures de conversation réparties sur 1 à 2 jours.

Le tour au plus fort levier pour l'entraînement en entretien blanc IA est le ML system design. Il colle presque parfaitement au format d'entretien blanc — énoncé ouvert (« concevez un système de recommandation pour des vidéos courtes »), allers-retours sur les compromis, notation sur la structure et la profondeur. Le tour de case study est la deuxième meilleure cible : « la précision de notre modèle de churn est passée de 0,84 à 0,71 la semaine dernière, que faites-vous ? » — exactement le type d'investigation qui se déroule en direct et que les entretiens blancs IA gèrent bien.

Les principaux sujets techniques

Feature engineering et data pipelines

La barre est passée de « savez-vous écrire une SQL window function » à « savez-vous concevoir un feature store ». Attendez-vous à des questions sur le training-serving skew, la point-in-time correctness, les features online vs batch, et quand matérialiser vs calculer à la demande. Outillage : Feast, Tecton, DIY maison — connaissez les compromis. Une question favorite : « votre modèle prédit bien offline mais se dégrade online — déroulez-moi votre investigation. » Les bonnes réponses enchaînent fraîcheur des features, label leakage, distribution shift et bugs au moment du serving.

Entraînement et modélisation

La plupart des rôles ML produit ne vous demandent pas d'inventer des architectures inédites. Ils demandent de choisir la bonne classe de modèle, de débugger l'entraînement et d'expliquer les compromis. Soyez prêt à discuter : gradient boosting vs réseaux de neurones pour les données tabulaires, quand les transformers sont overkill, la régularisation au-delà de L2 (dropout, early stopping, data augmentation), le compromis biais-variance en termes concrets, et à quoi ressemble vraiment un « ce modèle est en overfit » dans les loss curves. Abordez le déséquilibre de classes, la calibration et la différence entre accuracy et AUC sans qu'on vous le demande — les recruteurs adorent quand vous anticipez la question suivante.

Model serving et MLOps

C'est là que le ML engineer se distingue du data scientist. Soyez prêt à parler de : batch vs real-time serving, latency budgets (que signifie vraiment 50 ms p99 pour un modèle de la taille d'XGBoost vs un LLM de 7B), versioning de modèles, infrastructure d'A/B testing pour le ML (pas juste pour des boutons), shadow deployment, stratégie de rollback quand un modèle régresse, et patterns de feature flags pour le ML. Outils : BentoML, KServe, Triton, Ray Serve, vLLM. En connaître un bien vaut mieux que connaître cinq noms.

Évaluation et métriques

Les métriques online bougent rarement de la même façon que les offline. Soyez prêt à expliquer pourquoi et ce que vous y feriez. Sujets : corrélation offline-online, métriques proxy, évaluation counterfactual, off-policy estimation pour le ranking, populations holdout, et les pièges spécifiques de la modélisation de CTR (selection bias, position bias). Une question courante : « l'équipe veut livrer un modèle qui améliore le NDCG de 2 % offline — que répondez-vous ? » Les réponses qui interrogent le framework d'éval notent plus haut que celles qui se contentent de faire confiance au chiffre.

LLM et la nouvelle stack

La moitié des fiches de poste ML en 2026 mentionnent les LLM même si le rôle n'est pas spécifique aux LLM. Soyez prêt : prompt engineering vs fine-tuning vs RAG (quand choisir lequel), évaluation d'embeddings, choix de vector DB (Qdrant vs pgvector vs Pinecone), économie de latence et de coût à l'échelle, atténuation des hallucinations. Si le rôle est spécifique aux LLM, ajoutez : curation des données d'entraînement, conception de l'eval harness (le vôtre, pas seulement MMLU), distillation, compromis de quantization.

Questions de scénario courantes

• « Concevez un système de recommandation pour une appli de vidéos courtes à la TikTok, 100M DAU. » (Candidate generation, ranking, diversité, cold start, feedback loops.)
• « La précision de votre modèle de fraude est passée de 0,91 à 0,74 du jour au lendemain. Que faites-vous ? » (Distribution shift, label delay, changement de feature pipeline, drift adversarial.)
• « Construisez un copilot de support client propulsé par un LLM. Quel est votre framework d'éval ? » (Eval set offline, ratings humains online, suite de régression, tests d'hallucination.)
• « L'équipe veut fine-tuner Llama pour de la code review. Devraient-ils le faire ? » (Coût vs prompt engineering vs RAG, disponibilité des données, éval, drift dans le temps.)
• « Vous avez un classifieur binaire à 99,5 % d'accuracy. Devriez-vous le livrer ? » (Déséquilibre de classes, base rate, coût business des faux positifs vs faux négatifs, calibration.)

Axes behavioral — ce que les recruteurs recherchent

Les recruteurs ML recherchent trois signaux moins évidents. D'abord, la confiance calibrée — le ML est la discipline où le sur-claim se fait démasquer par les données. Les bons candidats disent « je ne suis pas sûr, voici comment je le découvrirais » sans broncher. Ensuite, le sens business — les ML engineers capables de relier un lift de 0,03 du NDCG offline à une valeur en euros décrochent des offres senior plus vite que ceux qui ne savent parler que de maths. Enfin, la collaboration avec les non-ML — la plupart des travaux ML échouent à cause de la communication avec le PM, le data engineering ou les ops, pas à cause de l'architecture du modèle. Attendez-vous à des questions sur un projet qui a échoué, et répondez par la friction transverse, pas la friction algorithmique.

Comment utiliser l'entraînement IA pour ce poste

Réglez le type d'entretien sur « ML System Design » et choisissez honnêtement votre séniorité. Les loops ML senior attendent que vous meniez la conversation ; le niveau intermédiaire attend que vous répondiez bien aux relances ; le junior attend des fondamentaux propres. Collez la fiche de poste si vous en avez une — l'IA pondère les questions vers la stack de l'entreprise (les entreprises recsys reçoivent plus de profondeur ranking, les entreprises LLM plus de profondeur éval et serving).

Pour la pratique de coding, utilisez l'entretien blanc pour l'explication verbale d'un pipeline ML (« comment implémenteriez-vous une cross-validation leave-one-out pour une prévision de série temporelle ? ») et associez-le à un vrai notebook. Ne l'utilisez pas comme substitut à l'écriture effective de PyTorch.

Un exercice qui rapporte vite : faites cinq case studies à la suite où vous triez un modèle dégradé. La reconnaissance de patterns pour « est-ce du label leakage, du distribution shift ou un bug de pipeline » est la compétence d'entretien la plus transférable en ML.

Questions fréquentes