MLOps Interview Questions 2026

Last updated: July 30, 2026

The strongest MLOps interview questions in 2026 test custody of a live model, not modeling skill, asking whether a candidate can prove which version is serving, rebuild the artifact behind any prediction, and roll it back in minutes. Modeling talent is easy to screen for. Custody is not, and custody is the job. Most panels never ask a single question about it.

By Tom Kenaley, President and Senior Partner, KORE1

I have sat in on more MLOps loops than I can count, and the same thing happens in about half of them. The panel spends fifty minutes on gradient boosting and feature engineering. Then somebody asks, almost as an afterthought, “so what’s your experience with MLflow?” The candidate says they’ve used it. Everyone nods. Loop over.

Fifty minutes. Gone.

That loop just tested nothing.

Here is the miss I get called in to clean up. A fintech client in Irvine had a risk model that had been serving the same artifact for eleven weeks, because a retraining job in Airflow had been failing silently since a dependency bump, and the alert went to a Slack channel three people had muted. Nobody caught it. Not the data scientists, who were looking at offline metrics from the last successful run. Not the platform team, who saw green pods and a healthy endpoint. The model was technically up the entire time, serving decisions on a world that had moved on without it, and the only reason anyone found out was that a compliance analyst asked a question about a March decision and nobody could answer it inside a week. They had hired for modeling. They needed custody. Different job.

So this is the guide I wish that panel had read. Where I sit, so you can weight all of it properly. We only earn a fee when the person is still there and still delivering twelve months later, which means I have zero incentive to help you fall for a good talker with a tidy GitHub. Take these questions and run the search yourself if you want. Or hand it to a desk that runs it weekly through our MLOps engineer staffing practice. If the role itself is still fuzzy on your side, start with how to hire an MLOps engineer before you write a single question, because scoping is upstream of everything below.

MLOps Is a Custody Job, and Most Loops Never Test for It

There’s a diagram from a 2015 NeurIPS paper that I still pull up on calls. Sculley and a group of Google engineers published Hidden Technical Debt in Machine Learning Systems, and its Figure 1 caption reads, verbatim, “Only a small fraction of real-world ML systems is composed of the ML code, as shown by the small black box in the middle. The required surrounding infrastructure is vast and complex.” The same paper puts a number on it later. A mature system might be at most 5% machine learning code and at least 95% glue code.

Eleven years old. Still the most accurate description of the job anyone has written, and I have read a lot of job descriptions that try.

Your MLOps hire owns the 95%. Configuration, data collection, feature extraction, serving infrastructure, monitoring, process management, the whole unglamorous mass around the small black box. When you interview them on the small black box, you learn almost nothing about whether they can run the rest of it.

Custody breaks into four questions that a good loop should be able to answer about a candidate by the end of the day. Can they tell you what is running? Can they rebuild it? Can they replace it safely? Can they tell when it has quietly stopped being right? Everything below is a way of getting at one of those four. That’s the whole guide.

Before Question One, Decide Which MLOps You Are Buying

The title covers at least four different humans, and the interview changes completely depending on which one your problem actually needs. I go deeper on scoping in the hire guide, so here is just the fast version, framed the way I’d frame it on a scoping call.

These blur in practice, especially at companies under 200 engineers where one person holds all four. Purity isn’t the point. Knowing which failure mode keeps you up at night is, so the loop spends its time there instead of spreading four hours evenly across topics that don’t matter to you.

Two adjacent loops worth reading if the boundary is unclear. The AI/ML engineer interview questions post covers the person who builds and trains the model, which is a genuinely different hire. The platform engineer interview questions post covers the person who builds the paved road for all engineering, not just ML. If you find yourself wanting both, you probably want two people, and hiring one and hoping is how teams end up with a very tired generalist who quits in fourteen months.

Lineage Questions: Can They Rebuild the Model That Made This Prediction?

Run this block first. Almost nobody runs it at all.

“A customer disputes a decision your model made on March 4. Your general counsel wants to know which model version scored them, what data trained that version, and what the feature values were at the moment of the call. Walk me through how you’d answer, and how long it takes you.”

Watch their first move. Weak answers start rebuilding from scratch, which means the lineage does not exist and they are about to spend three days doing archaeology in S3. Strong answers describe a system where the answer is a lookup. It goes like this. The prediction was logged with a model version identifier. The registry maps that version to a training run. The training run pins a data snapshot and a commit hash. And the feature values that went into that specific inference were logged alongside the prediction rather than recomputed after the fact.

That last part is the tell. Recomputing features at audit time gives you today’s answer to yesterday’s question. Useless in a dispute. Anyone who has actually been through an audit knows this and will say it unprompted.

“What is the smallest set of things you have to pin to make a training run reproducible?”

I want to hear more than “the seed.” Code commit, data snapshot or version, feature transformation code, dependency versions down to the CUDA and framework level, hardware class if the numerics matter, and hyperparameters. Candidates who have fought this fight will bring up nondeterminism in GPU kernels without being asked, and will usually admit that bit-for-bit reproducibility is often not worth the cost. That admission is a green flag. It means they’ve made the tradeoff for real instead of reciting a checklist.

“How do you know, right now, which model version is serving production traffic?”

Sounds trivial. It is not. In the fintech situation I opened with, four people gave four different answers. All four were wrong. Good answers point at a single source of truth that the deployment pipeline writes to and the serving layer reads from, plus some form of runtime assertion where the endpoint reports its own version and something compares that to what the registry says should be there. If the answer is “we check the Confluence page,” you have found the problem.

The Promotion Gate: How a Model Earns Its Way Into Production

“Describe the gate a model had to pass in your last environment to move from staging to production. Who could override it, and when did somebody last do that?”

The second half of that question is where it gets interesting. Every candidate can describe a gate. Far fewer can tell you honestly about the time the VP of Product needed the new recommender live before a board demo and the gate got waived. A candidate who never bends is not what I’m after. I want the one who knows the override happened, remembers who signed off, and can tell me what the blast radius was.

A real gate has five parts. An offline evaluation against a held-out set with a threshold agreed in advance. A comparison against the currently deployed model rather than against a paper number. A check that the serving artifact loads and returns sane predictions on a fixed set of golden inputs. Latency and payload size measured under something resembling production concurrency. And a bias or fairness check if the domain calls for one. Most teams have two of the five.

“Shadow, canary, or straight cutover. Pick one for a new fraud model and defend it.”

No correct answer exists here. That’s deliberate. Shadow mode gives you production traffic without production risk, but it does not surface downstream effects because nothing acts on the predictions. Canary surfaces real effects on a small slice, at the cost of actually harming that slice if you’re wrong. Cutover is defensible for a low-stakes model where the rollback path is genuinely instant. The candidates I like will ask what the label lag is before answering, because if fraud labels arrive 45 days later, a two-week canary tells you almost nothing about accuracy and you’re really measuring operational health.

“When did you last practice a rollback?”

Not “do you have a rollback plan.” Practice. Most teams have a documented plan they have never executed under pressure. Then the first real attempt discovers that the previous artifact was garbage collected, or the feature schema changed underneath it, or the rollback needs a config change in a repo that exactly one person can write to. That person is on a plane.

Training and Serving Are Two Systems, and the Seam Is Where Candidates Fail

Twenty minutes with a candidate? I’d spend all of it here. Every time.

“Your offline feature computes a 30-day rolling average from a nightly Snowflake batch. Online, the same feature is computed by a streaming job. Model performance in production is worse than offline and nobody can find a bug. What do you check?”

Good answers go straight to definitional drift between the two implementations. Does the batch job include the current day or exclude it? Does the streaming version handle late-arriving events, and if a record shows up two hours late, does it land in the right window? Are nulls filled the same way in both paths? Is the timezone the same? I watched a team lose six weeks to a rolling window that was inclusive in Spark and exclusive in Flink. Six weeks. One boundary condition.

Great answers go one step further and say they would not debug this by inspection at all. They would log the actual feature vector at inference time and compare it against the offline vector computed for the same entity at the same timestamp, then look at the distribution of the difference. That’s the move. Measure the skew instead of arguing about the code.

“Do you need a feature store? Talk me out of one.”

I ask candidates to argue against the tool they like, and it works on almost everyone. A candidate who cannot articulate why Feast or Tecton might be overkill for a team with three models and one online use case is a candidate who will bring you a platform you don’t need and can’t staff. The honest answer usually runs something like this. A feature store solves reuse across teams and training-serving parity. If you have neither problem yet, you are buying operational burden today to solve a problem you’ll have in two years.

“How do you handle a backfill that changes historical feature values?”

This one quietly separates people. If someone corrects six months of upstream data, every model trained on that window is now trained on data that no longer exists, and every stored prediction is now unexplainable. Candidates who have lived it will talk about immutable snapshots, effective-dated features, and never overwriting in place. Candidates who haven’t will say “we’d just rerun the pipeline.” Follow up by asking what happens to the audit trail. Watch the pause.

Monitoring When the Truth Shows Up 45 Days Late

Every MLOps candidate can say “we monitor for drift.” Push past it. Immediately.

“Ground truth for this model arrives 45 days after the prediction. What do you monitor on day one?”

Accuracy is off the table. So what’s left? Input distribution shift on the features that matter most. Prediction distribution shift. The rate of null or default feature values coming out of the feature pipeline. Feature freshness and pipeline lag. Calibration drift on whatever proxy labels arrive early. Volume of predictions against forecast. Strong candidates will also mention segment-level monitoring, because an aggregate that looks flat can hide a specific cohort falling off a cliff.

“Your drift alert fires. What is the first thing you check, and what is the thing you check that most people skip?”

First check should be whether the data pipeline is healthy, because a broken upstream job looks exactly like drift and it’s the more common cause by a wide margin. The thing most people skip is whether the alert threshold itself is still calibrated. Teams set a Population Stability Index threshold once, seasonality moves the distribution every December, and by year two the alert has fired eleven times, been dismissed eleven times, and become furniture.

“How do you decide retraining cadence?”

The lazy answer is “weekly.” Cadence should be derived, not chosen. You look at how fast performance degrades between retrains, how long labels take to arrive, what a retrain costs in compute and in review time, and what the cost of a stale model actually is in business terms. Some models genuinely need daily. Some should be retrained when a trigger fires and not on a calendar at all. If a candidate names a cadence before asking about label lag, they’re guessing. Politely, but guessing.

The Money Question Almost Nobody Asks

“Inference spend tripled last quarter. Request volume is flat. Where do you look?”

I started asking this in 2024 and it has become one of my favorite questions, because the range of answers is enormous and it maps almost perfectly to whether someone has run infrastructure with a real budget attached.

A strong candidate goes hunting in six places. Instance right-sizing, because somebody provisioned an A100 for a model that fits comfortably on an L4. Batching configuration, since a serving stack running batch size one on a GPU is burning most of the card. Autoscaling floors, where a minimum replica count set during a launch never got turned back down. Model size, if a team swapped in a larger checkpoint and nobody costed it. Idle development endpoints, which are the single most common finding and the most embarrassing one to report. Retraining frequency, if someone scheduled hourly retrains on a model that changes monthly.

Then the harder half. What would you do about it, and what does each option cost in accuracy? Quantization, distillation, caching, moving from real-time to batch scoring where the use case allows it. A candidate who reaches for quantization without asking what accuracy budget you have is optimizing the wrong thing.

LLMOps Questions, Because Half the Job Now Involves a Model You Do Not Own

Three years ago this barely existed. Now it’s in most of the reqs crossing my desk.

“Your application calls a hosted model through an API. The vendor updates it. Your outputs change. How would you have known before your users did?”

You’d know because you run an evaluation suite on a fixed set of inputs on a schedule, and you pin the model version in the API call wherever the provider lets you, and you log outputs so you can diff them across time. Candidates who have run production systems on a hosted model will describe all three without prompting, usually with a note of irritation, because they have been burned.

“What are you versioning when there are no weights to version?”

Prompt templates, system messages, retrieval configuration, chunking strategy, embedding model and its version, temperature and sampling settings, tool definitions, and the evaluation set itself. All of it belongs in source control with the same discipline as model code. If a candidate treats prompts as configuration that lives in a database and gets edited by whoever, ask them how they’d bisect a quality regression. Then wait. No good answer exists, and the way they handle not having one tells you plenty.

Worth noting where the boundary sits. If the role is mostly building the retrieval and generation system itself rather than operating it, the LLM engineer interview questions post is the closer fit. MLOps owns the pipes, the evals, the cost, and the versioning around it.

Governance Questions That Used to Be Optional

Two years ago this section would have been a nice-to-have. Not anymore. Especially not for anyone with European customers, or anyone modeling in employment, credit, or healthcare.

The EU AI Act phases its obligations in across several years, and the requirements for high-risk systems in sensitive areas including employment, credit, and critical infrastructure apply from December 2, 2027. Read the actual requirement list and it is an MLOps spec written by lawyers. Logging of activity to ensure traceability of results. Detailed documentation. High quality of the datasets feeding the system. Appropriate human oversight. Post-market monitoring and incident reporting. Sound familiar? It should. That is the lineage block from three sections ago, with penalties attached.

On the domestic side, the NIST AI Risk Management Framework is voluntary, and it’s increasingly what enterprise procurement teams reference in their security questionnaires. Its four functions are Govern, Map, Measure, and Manage. A candidate who has mapped their monitoring and documentation practice to that structure has done this in an environment where somebody was watching.

“Walk me through what a model card contains in your environment, and who reads it.”

The second half is the real question. A model card that exists because a compliance checkbox demanded it is a completely different artifact from one a risk committee reads before approving a launch. Ask which they’ve produced. Then ask what changed as a result.

What MLOps Engineers Cost, So the Loop Does Not Win You Someone You Cannot Close

The aggregator data on this title is a mess, and it’s worth understanding why before you set a band. Salary.com put the national average at $130,609 as of July 1, 2026, with a typical range of $116,687 to $139,164. That number is real. It is also nowhere near what you will pay for a senior MLOps engineer in Seattle or the Bay Area, because the aggregators pool a lot of junior and mid-level postings under a title that companies apply inconsistently. Treat it as a floor.

Full breakdown by level, region, and adjacent title sits in our MLOps engineer salary guide, and if you want to sanity-check a specific band against your market before you post the req, the salary benchmark assistant will get you closer than a single aggregator page will.

One budgeting note that has nothing to do with the number. The best MLOps people I place are almost always employed and not looking, because the ones who are good at this are load-bearing where they sit. Our IT desk averages 17 days to a hire, and MLOps searches run at the longer end of that range for exactly this reason. If a recruiter tells you they’ll have a senior MLOps engineer in front of you Thursday, ask them what the person is doing now.

Questions That Look Smart and Tell You Nothing

I sit through these constantly. They waste your best hour. Cut all four.

“Explain the bias-variance tradeoff.” An MLOps engineer does not need to derive this on command, and the answer is one search away for anyone who’s rusty.

“Kubeflow or MLflow?” This is a tooling preference dressed up as a technical question. Ask instead what the candidate would keep and what they’d tear out of a stack they inherited, and why. Now you’re testing judgment.

“Write a function to reverse a linked list.” I have never once seen this predict MLOps performance. Give them a broken Dockerfile, a failing DAG, or a serving container that OOMs on the third request, and watch them work.

Certifications get overweighted too. The AWS Certified Machine Learning Specialty or the Google Cloud Professional Machine Learning Engineer credential tells you someone studied a cloud provider’s opinion about how this should work. Useful signal about direction. Nearly useless as a proxy for whether they’ve been on the wrong end of a 2 a.m. page. Weight accordingly.

Score the Loop on Three Things, Not Twelve

Scorecards with twelve dimensions produce a number nobody trusts. Ours has three, and every question above rolls up into one of them.

Custody. Can they tell you what is running, rebuild it, and replace it safely? This is pass or fail. There is no partial credit on a person who cannot answer the March 4 question.

The seam. Do they understand that training and serving are separate systems that lie to each other? Most candidates who fail in the first six months fail here.

Cost and judgment. Can they make a tradeoff with a dollar figure attached and explain it to someone who does not care about model architecture? Senior versus mid-level lives right here. It shows up in year two, never in the interview transcript.

A candidate who is strong on custody and the seam and weak on cost is a hire. A candidate strong on cost and weak on custody is a platform engineer, which may be a fine person to hire, for a different req.

What Hiring Managers Keep Asking Me About These Loops

How long should an MLOps interview loop actually be?

Four hours of candidate time, split across two days, is the ceiling I’d recommend for most MLOps roles. Anything longer and you start losing people who are already employed and interviewing at three places.

The split I like is a 30-minute screen, a 60-minute custody and lineage deep dive, a 60-minute hands-on debugging session with real broken artifacts, and a 45-minute conversation about a system they built and what they’d do differently. Skip the algorithms round. It measures nothing here.

Should the take-home be a modeling exercise or an infrastructure one?

Neither, if you can avoid a take-home at all. Strong MLOps candidates are employed and will decline a four-hour unpaid assignment, so the take-home selects for availability rather than skill.

If you need something hands-on, do it live and make it small. A repository with a training script that isn’t reproducible, and 45 minutes to find out why, tells you more than a weekend project ever will. You get to see how they read unfamiliar code, what they check first, and whether they narrate their reasoning or go silent.

Can my data scientists run this interview?

Partly. Data scientists reliably assess whether a candidate understands what a model does, and they consistently under-assess operational skill because they have not carried the pager for a model.

Put a data scientist in the loop for one round. Put someone who has operated production infrastructure in the custody round. If nobody on your team has run a model in production before, that is worth knowing. It’s also an argument for making this hire senior rather than mid-level.

Is an MLOps engineer just a DevOps engineer who knows Python?

No, and the difference is that traditional software either works or it doesn’t, while a model can be entirely healthy by every infrastructure metric and completely wrong. That failure mode has no analog in DevOps.

A strong DevOps engineer can absolutely grow into MLOps, and some of the best people I’ve placed came that way. The gap they have to close is statistical, not operational. They need to internalize drift, skew, label lag, and the idea that a green dashboard proves nothing about correctness. The DevOps engineer interview questions post covers the base loop if you’re evaluating that crossover.

We have four models and two ML engineers. Do we need this role yet?

Probably yes, if any of the four models touches revenue or a regulated decision. The trigger is not model count. It’s whether a model being wrong for a week would cost you more than the salary.

Below that bar, contract is often the smarter first move. Bring someone in for a defined build, get the registry and the monitoring and the promotion gate stood up properly, then decide whether you need a permanent owner. We run a lot of these through contract staffing for exactly this reason, and a fair number convert once the team sees what the seat is actually worth.

What is the single biggest red flag in an MLOps interview?

Someone who has never broken production. Every genuinely experienced MLOps engineer has a story about a deploy that went badly, and they tell it without much drama because they’ve made peace with it.

The candidates who describe an unbroken record of clean launches have either been shielded from ownership or are managing their story. Ask directly. “Tell me about the worst production incident you were responsible for.” If the answer is that a colleague caused it, ask again. Then wait.

Hire the Person Who Can Put the Old Model Back

Strip out the tooling names and the framework debates, and a good MLOps hire comes down to one uncomfortable scenario. It’s Tuesday. Something is wrong with a model that is making decisions right now, and you need to know what’s running, what made it, and how fast the previous version can be back in place. The person who has lived that morning answers differently from the person who has read about it. Not more confidently. Usually less. But with specifics nobody can fake.

So build the loop around custody, spend your real time on the seam between training and serving, and let the modeling questions go. A year after we place someone, 92% are still in the seat, and that holds because we put people who have carried the pager in front of teams that need exactly that. If you’d rather not run this search yourself, talk to a KORE1 recruiter and tell us which of the four failure modes is the one keeping you up. We work this across 30-plus U.S. metros through our MLOps recruiters and AI and ML engineer staffing practices, through clean launches and ugly ones.