Hiring an ML Engineer in 2026: 12 Questions That Predict Job Performance

What this reveals: Do they jump straight to fine-tuning, or do they reach for retrieval first? Do they ask about volume, latency, and cost before picking an architecture? Do they think about eval before they think about model selection? This is the single highest-signal prompt for distinguishing a builder from a tutorial-watcher.

A great answer looks like: They start with a clarifying question about what "answer" means and what wrong looks like. They propose a v0 RAG pipeline before reaching for fine-tuning. They mention eval (golden set, regression suite) within the first three minutes. They have an opinion on which embedding model they would start with and why.

Red flags: "I would fine-tune a 7B model on the docs." No mention of eval. No discussion of cost or latency. They treat the LLM as a black box that just needs to be picked correctly.

What this reveals: Do they have a mental model of what can go wrong in production ML? Do they distinguish data drift, label drift, infrastructure issues, and training-serving skew? Do they instinctively reach for the right tools?

A great answer looks like: They start by asking what changed three weeks ago. They check whether the eval set itself drifted. They look at the input distribution for shifts. They check the serving pipeline for silent feature changes. They differentiate "model is worse" from "world is harder" before concluding.

Red flags: They immediately suggest retraining. They jump to model architecture changes. They have no framework for differentiating data issues from model issues.

What this reveals: Whether they have ever had to actually ship something. Theory-only candidates default to "bigger is better." Builders have shipped enough things to know latency, cost, debuggability, and update cadence all matter.

A great answer looks like: They give a concrete scenario from their experience. They mention serving cost or latency budgets. They talk about how a simpler model is easier to retrain, debug, or explain. They have an opinion on when complexity is worth it.

Red flags: They cannot generate a scenario. They argue that bigger is always better. They have no opinion on cost or latency trade-offs.

What this reveals: How they think about eval, which is the single hardest part of applied ML and the thing tutorial-watchers consistently underestimate. The strongest signal in the entire ML engineer interview is how naturally they reach for eval design.

A great answer looks like: They propose a golden set. They distinguish offline eval from online eval. They talk about A/B testing or shadow deployment. They acknowledge that "better" is task-specific and ask what users do with the results.

Red flags: "We compare accuracy." "We run more queries through it and see." No distinction between offline and online. No mention of business outcomes.

What this reveals: Whether they can design a real ML system at scale. The numbers matter — 50M users × 10 items × daily refresh is a real engineering problem, not a notebook problem.

A great answer looks like: They start by asking about latency, freshness, and cost budgets. They consider candidate generation separately from ranking. They think about precomputation, caching, and incremental updates. They have a position on whether to score every user-item pair or use approximate methods.

Red flags: They propose a single end-to-end model that scores every (user, article) pair in real time. They ignore the scale numbers. They have no concept of candidate generation vs ranking.

What this reveals: Whether they have ever owned a model in production for more than a few weeks. This is one of those questions where the right answer is more nuanced than candidates expect.

A great answer looks like: They distinguish scheduled retraining from triggered retraining. They mention monitoring metrics (data drift, performance drift, business KPI drift). They talk about cost-of-retraining vs benefit. They have a tested opinion.

Red flags: "When accuracy drops." "On a schedule." No discussion of monitoring. No mention of cost or operational considerations.

What this reveals: Whether they know that data is usually the leverage point, not architecture. Strong applied engineers default to investigating data first.

A great answer looks like: They start by looking at the labels. They check label quality, label distribution, and class balance. They sample examples the model gets wrong and look for patterns. They consider whether the training data matches production distribution.

Red flags: They start by changing model architecture. They suggest a bigger model. They never look at the data.

What this reveals: Whether they can translate ML behavior into language a product manager or executive can act on. Many strong technical ML engineers fail badly here, and the failure surfaces quickly in cross-functional work.

A great answer looks like: They start by acknowledging that no recommendation system is perfect. They walk through plausible reasons in concrete language. They give the stakeholder a vocabulary for distinguishing systematic failures from one-off ones.

Red flags: They explain the loss function. They blame the data. They get defensive.

What this reveals: Whether they have ever actually shipped a model. Whether they take ownership of failure. Whether they learned something.

A great answer looks like: Specific story, specific root cause, specific lesson. They take responsibility. The change they made is concrete and reasonable.

Red flags: They cannot generate a specific example. They blame the data, the team, or the stakeholders. The "lesson" is generic.

What this reveals: Whether they think adversarially about the systems they build. ML engineers who deploy without stress-testing are a specific category of risk in fraud, security, and trust-and-safety applications.

A great answer looks like: They propose adversarial examples. They check for distribution shift. They think about gaming behavior. They consider what happens when the attacker knows the model exists.

Red flags: They test on a held-out set and call it done. They have no concept of adversarial robustness.

What this reveals: Whether they have actually built something with the modern AI stack, or whether they have read about it. The specifics matter: which embedding model, which vector store, what chunking strategy, what reranking.

A great answer looks like: They have a specific embedding model they would start with and a reason. They have a specific vector store choice and a reason. They mention chunking strategy. They consider whether to add a reranker.

Red flags: They cannot name a specific embedding model. They cannot distinguish dense from sparse retrieval. They have no opinion on chunking.

What this reveals: Whether they reason about engineering trade-offs the way the rest of the company does. Strong applied ML engineers default to shipping the heuristic v0, learning from it, and earning the right to invest in the model. Pure researchers default to the model.

A great answer looks like: They ask about the cost of being wrong. They propose shipping the heuristic and using the production traffic to inform the model. They have a position and a reason.

Red flags: They reflexively pick the model. They do not consider the operational cost of a half-finished v0. They cannot reason about uncertainty.