Key takeaways
MLOps and ML engineer interviews split into four rounds: a coding screen, ML fundamentals, ML system design, and a production round on deployment and monitoring. Most published question lists over-weight the fundamentals round because it's the easiest to write answers for, and under-weight the production round, which is where loops are actually decided. Tool trivia matters less than it looks. Only 16.9 percent of data and ML postings in Four-Leaf's index name a specific MLOps platform at all.
What rounds does an MLOps or ML engineer interview actually have?
Most loops for these roles run four distinct rounds, and candidates routinely prepare as though there were two.
| Round | What it screens for | What it does to your odds |
|---|---|---|
| Coding screen | Whether you can write and debug working code under time pressure. Usually Python, usually not ML-specific. | Mostly a filter. Passing it rarely wins you the job, failing it always ends the loop |
| ML fundamentals | Whether your mental model of modeling is sound: bias and variance, regularization, evaluation, class imbalance. | Saturates fast. Past a point, more study here stops changing anything |
| ML system design | Whether you can turn a vague business goal into a measurable, servable system. | Where strong candidates separate from adequate ones |
| Production and MLOps | Whether you've shipped: deployment, versioning, monitoring, drift, rollback. | The most common place to fail outright |
Nobody hands you a scorecard, and the weighting moves by company and by role, so treat that last column as shape rather than arithmetic. What holds across loops is that two of these four rounds are about what happens after a model works on your laptop, and those two are the ones generic question lists cover worst.
That's the practical reason to read a question list differently. With a week of preparation, the highest-return hours go to the rounds where the marginal candidate is weakest, not the rounds where the questions are easiest to find.
Why do generic ML interview question lists waste your prep time?
Start with who's actually hiring. In Four-Leaf's analysis of 145,000 open job postings across 1,195 companies, data and ML roles are 8.5 percent of the tagged role mix, against 43.1 percent for engineering. That's roughly five engineering openings for every data or ML opening.
The language in those postings points the same direction. Python appears in 12.6 percent of active postings, while the phrase "machine learning" appears in 3.8 percent. Python shows up more than three times as often as the thing it's most associated with. The term "MLOps" appears in half a percent of postings, which tells you the discipline is discussed far more than it's named.
Read together, those numbers describe a market that hires people who ship models as software, not people who study models. That's the frame the rest of this guide uses, and it's the frame most question lists miss when they open with twenty variations on bias and variance.
There's a second problem, which is that interviewers know the lists exist. In interviewing.io's 2025 survey of 67 interviewers, 52 of them at FAANG companies, 81 percent suspected candidates of using AI to cheat and 75 percent believed AI assistance was letting weaker candidates pass interviews they'd otherwise fail. The response has been more follow-up questions and more probing of whether you understand what you just said. A memorized answer survives the first question and falls apart on the second.
The same survey is worth reading in both directions. None of the 52 FAANG interviewers reported their company had moved away from algorithmic questions, and more than half expected those questions to be less prominent in two to five years. Prepare for the loop you're sitting this quarter, not the one people expect to exist later.
How to read this list
Each question below carries two notes.
Signal is what a strong answer tells an interviewer about how you'd perform on the job. Production instinct, debugging discipline, judgment about tradeoffs, systems thinking. It's the reason the question gets asked, even when the interviewer couldn't articulate it.
Trivia tax flags a question that mostly rewards having seen it before. These still get asked, so the answers are worth knowing, but memorizing them teaches you nothing you'd use building real systems. Learn them fast and move on.
The signal and trivia-tax calls are editorial judgment drawn from time spent on the interviewing side, not the output of a formal study. Cited numbers come from named public sources, linked inline. Example questions are drawn from real screens and from Four-Leaf's practice question bank.
What do ML fundamentals questions predict about how you'd work?
This round checks whether your mental model is sound. It saturates quickly. Past a certain depth, more fundamentals study stops changing your score.
Explain the bias-variance tradeoff.
High bias means the model is too simple to capture the signal and underfits. High variance means it's fitting noise in the training set and won't generalize. The strong answer moves past definitions to diagnosis: what you'd look at to tell which one you have, and what you'd change first.
Signal: whether you can diagnose a model that isn't working, rather than recite a curve. The follow-up that matters is "your model scores 0.95 on train and 0.71 on validation, what do you do next."
Trivia tax: partial. The definition is rote. The diagnostic version isn't.
What's the difference between L1 and L2 regularization, and when would you pick each?
L1 drives some coefficients to exactly zero, so it does feature selection. L2 shrinks coefficients toward zero without eliminating them. Pick L1 when you want a sparse, interpretable model or suspect many features are useless, L2 when features are correlated and you want to keep them all with reduced influence.
Signal: whether regularization is a tuning knob you turn or a modeling decision you reason about.
Trivia tax: yes, in isolation. Know it cold, spend no real time on it.
Your dataset is 99 percent negative and 1 percent positive. How do you approach it?
The strong answer starts by rejecting accuracy as a metric, then covers the options and their costs: resampling, class weights, threshold tuning, and choosing a metric that reflects the actual cost of each error type. The best answers ask what a false positive costs versus a false negative before choosing anything.
Signal: high. Class imbalance is where interviewers find out whether you optimize a number or solve a problem. The candidate who asks about error costs is showing exactly the instinct the job needs.
When would you use precision-recall over ROC AUC?
With heavy class imbalance, ROC AUC can look strong while the model is nearly useless in production, because the large negative class makes the false positive rate insensitive. Precision-recall focuses on the positive class and degrades visibly when the model is bad at it.
Signal: whether you've been burned by a metric that flattered a bad model. Candidates who have hit this in practice explain it differently than candidates who read it.
What is data leakage and how do you catch it?
Leakage is any information in the training features that wouldn't be available at prediction time. Fitting a scaler on the whole dataset before splitting, including a field that's populated only after the outcome, using future data in a time-series split. The catch is usually a validation score that seems too good.
Signal: high, and underrated. This is a bug that ships. A candidate who's caught it has run enough real projects to have been burned, which is the experience interviewers are probing for.
What is an ML system design interview really scoring?
The prompt is short. Design a recommendation system. Build a fraud detector. Rank search results. Candidates hear "design" and reach for architecture. The scoring is mostly upstream of that.
What's actually being assessed, roughly in order:
Problem framing. Turning "recommend products" into a measurable objective. What are you predicting, for whom, at what moment, and what does a good outcome look like in numbers. Candidates who skip this and start naming models lose points they never see deducted.
Offline versus online evaluation. How you'd validate before shipping, what you'd measure after, and why those differ. A model that improves offline AUC and hurts revenue is a normal outcome, and knowing that is part of the job.
The metric conflict. What you do when the model metric and the business goal disagree. This is the question that most separates people who've shipped from people who've trained. There's no clean answer, and interviewers aren't looking for one. They want to see you hold both and reason.
Latency, cost and freshness tradeoffs. Whether predictions can be precomputed or must be real time, what the budget is, how stale a feature can be before it's wrong.
Failure modes. What happens when the model is unavailable, when a feature pipeline breaks, when input distribution shifts.
A recurring trap is treating the round as an architecture recital. Drawing a feature store, a training pipeline and a serving layer proves you've read about the components. Explaining why this problem needs a feature store, and what you'd do without one, proves something else.
Reading a system design answer and speaking one under time pressure are different skills, and only the second is what gets scored. If you want structured practice with a timer and follow-up questions rather than a static answer key, our roundup of the best coding interview prep tools in 2026 compares the platforms that support that kind of session.
Design a system to detect fraudulent transactions.
The strong answer establishes the constraint before the architecture: fraud is rare, labels arrive late and are partly wrong, and a false positive blocks a real customer's payment. Everything downstream follows from that.
Signal: whether you reason from constraints or from components.
How would you decide whether to retrain a model?
The answer covers triggers: scheduled retraining, performance degradation past a threshold, detected distribution shift, or a known upstream change. The strong version explains why a schedule alone is a weak policy and why a threshold needs a definition of "worse" you can compute without ground truth arriving late.
Signal: high. This sits exactly at the seam between modeling and operations, which is where these roles live.
Which MLOps questions separate candidates who have shipped from candidates who have trained?
This is the round that decides loops and the one most question lists gloss. Weight your preparation here.
A useful calibration first. In Four-Leaf's index, only 16.9 percent of data and ML postings name any specific MLOps platform: MLflow, Kubeflow, SageMaker, Vertex AI, Airflow, Feast, Databricks, Weights & Biases, Seldon or BentoML combined. Individually, Airflow appears in 6.0 percent, MLflow in 2.7 percent, SageMaker in 2.4 percent and Kubeflow in 1.5 percent. Kubernetes, which is not an ML tool at all, appears in 12.1 percent, more than four times MLflow's share.
The lesson is that depth on any one platform is worth less than the ability to reason about the category. Interviewers know their stack isn't the one you used.
How do you version a model, and what has to be versioned alongside it?
Weights alone aren't enough to reproduce a prediction. The strong answer names the training data snapshot, the feature transformation code, the hyperparameters, the library versions and the code that produced the artifact. A model registry exists to keep those tied together and to record which version is serving.
Signal: whether you've had to answer "why did the model say that three months ago" for a real system.
Walk me through deploying a new model version safely.
Shadow the new version against live traffic first, compare its outputs to the incumbent, then move a small percentage of real traffic, watch the operational and business metrics, and expand. The part that matters is the rollback: what triggers it, how fast it can happen, and whether it's automatic.
Signal: high. Candidates who've shipped talk about rollback unprompted. Candidates who haven't describe the deploy and stop.
What problem does a feature store solve?
Training and serving compute features from different code paths, which causes training-serving skew, where the model sees one definition offline and a different one in production. A feature store centralizes the definitions so both read the same computation. It also handles point-in-time correctness, meaning a training row only ever sees feature values that existed at that row's timestamp, which is what stops future data leaking backwards into training. Feast's documentation sets out both mechanics.
Signal: whether you understand training-serving skew as a class of bug. The tool is secondary and interviewers usually say so.
Trivia tax: partial. Naming feature store products is trivia. Explaining skew is not.
How is CI/CD for models different from CI/CD for application code?
Code tests are deterministic. Model tests aren't, because the artifact depends on data. The pipeline has to validate data as well as code: schema checks, distribution checks, a minimum performance bar on a holdout set, and often a comparison against the currently deployed model before promotion.
Signal: whether you've thought about what "the build passed" means when the output is a statistical artifact.
Your training pipeline produces a different model each run on the same data. What's happening and does it matter?
Unseeded randomness in initialization, shuffling, sampling or augmentation, plus nondeterminism in parallel or GPU operations. Whether it matters depends on whether the variance is larger than the differences you're making decisions on. The strong answer distinguishes reproducibility you need from reproducibility that's expensive theater.
Signal: high, and rarely answered well. It's a real judgment question wearing a trivia costume.
Do you need Kubernetes for this work?
Given how often it appears in these postings, expect it. What's usually being tested is whether you understand why models get containerized, how a rollout is staged, and what happens when a pod won't start. Someone who's deployed on a managed service and reasons well about the tradeoffs generally scores better than someone reciting commands.
Signal: whether you can be honest about the edge of your experience and still reason past it. Claiming cluster depth you don't have is the fastest way to lose a production round, because the follow-up is always about something that broke.
Trivia tax: high for command-level questions, low for "walk me through a deploy that went wrong."
How do interviewers ask about model monitoring and drift?
Nearly a quarter of data and ML postings in Four-Leaf's index, 23.4 percent, mention drift or monitoring explicitly. It comes up, and it produces the weakest answers in most loops.
What's the difference between data drift and concept drift?
Data drift means the input distribution has moved. Concept drift means the relationship between inputs and the target has changed, so the same inputs should now produce a different answer. The distinction matters because retraining on recent data fixes the second and may not be necessary for the first.
Signal: whether you'd diagnose before reacting. Retraining is expensive and isn't always the answer.
Trivia tax: partial. The definitions are rote, the "so what would you do" is not.
A model's accuracy has quietly degraded over six months and nobody noticed. What went wrong?
The interesting answer is about the monitoring gap rather than the model. Ground truth arrived late or never, so nobody was measuring accuracy in production. The fix is proxy metrics that are available immediately: prediction distribution shift, input feature drift, changes in the rate of a particular predicted class, downstream business metrics.
Signal: very high. This is the single most useful question in the round, because a good answer requires having operated a model rather than trained one.
What would you monitor for a model where labels arrive months later?
Input distributions, prediction distributions, feature pipeline health and freshness, latency and error rates, and business outcomes that correlate with the target even loosely. Plus a plan for backfilling true performance once labels land.
Signal: whether you can operate without the feedback loop you'd want, which is the normal condition.
How do you decide the threshold for alerting on drift?
The good answer resists a single number. It ties the threshold to the cost of acting and the cost of not acting, notes that a noisy alert nobody trusts is worse than no alert, and mentions running a candidate threshold against historical data before turning it on.
Signal: operational maturity. Anyone who's owned a pager reasons about false alarms.
How does the loop change for an MLOps engineer versus an ML engineer versus a research-leaning role?
The rounds overlap heavily. Where the depth is expected differs.
MLOps engineer. The production round becomes the main event, and the fundamentals round is a sanity check. Expect infrastructure depth: pipelines, orchestration, serving, containerization, reproducibility, incident response. The ML system design round tilts toward the platform rather than the model. If a round is going to sink you, it's the one about what you did when a deploy broke.
ML engineer. The most balanced loop of the three, and the most common in these postings. Real depth is expected in system design and production, with fundamentals expected to be solid rather than deep. This is the profile the market is mostly hiring, and it's why the production round deserves your hours.
Research-leaning roles. Fundamentals go much deeper, into architectures, optimization and the literature, and you may be asked about your own published or unpublished work. Production questions get lighter but rarely disappear, because even research teams have to hand something off.
Two adjacent areas worth naming. If your loop includes SQL, statistics or business case questions, that's a different round with different scoring, covered in our data science interview preparation guide. If the coding screen is the part you're least sure about, Python interview questions runs the same Signal and Trivia tax treatment over that ground. Python is worth the attention: in the 2025 Stack Overflow Developer Survey, 57.9 percent of developers reported using it, up seven points in a year, the largest jump of any major language.
How should you prepare in the two weeks before an ML interview?
Assume roughly twenty hours. Spending them evenly is the most common mistake.
Days 1 and 2. Find out which loop you're in. Ask the recruiter what the rounds are. Most will tell you. The difference between an MLOps loop and a research loop is worth more than any ten questions above, and candidates skip the one email that would resolve it.
Days 3 to 5. Coding, briefly. Enough Python to be fluent under pressure. This round is a filter, and past a certain point more practice doesn't move your outcome.
Days 6 to 8. Fundamentals, and stop early. Work the diagnostic versions rather than the definitions. Practice answering "your model scores 0.95 on train and 0.71 on validation" out loud. This round saturates and you'll feel it when it does.
Days 9 to 12. System design and production, which is where the rest of your time goes. Take three problems, a recommender, a fraud detector and a search ranker, and talk each one through end to end. Then take one system you've actually worked on and prepare the production story in detail: how it was deployed, how it was monitored, what broke and what you changed. That story answers half the production round on its own.
Days 13 and 14. Speak it, don't read it. The gap that sinks otherwise strong candidates is between knowing an answer and delivering it under pressure with someone watching. Reading a design answer builds none of that. Practice out loud, with a timer, ideally with follow-up questions coming at you, which is what the interview prep platforms we compared are for.
One last thing about tools. Given that fewer than one in five of these postings names a specific MLOps platform, memorizing a stack you've never run is a poor use of the little time you have. Interviewers can tell within a minute or two when someone is reciting rather than thinking, and that gap has gotten easier to spot, not harder. Depth on a system you genuinely operated beats breadth across systems you read about, every time.