MLOps Engineer interview questions, with worked answers

How to use these questions

Most MLOps interviews include a design round: here is a model a data scientist trained, take it to production. Talk through data, training, the registry, release, serving and monitoring, and say where it would break first. Then tell them about a model you kept running and the worst surprise it gave you.

What an MLOps engineer is expected to know

• The practice: MLOpsRun the whole life of a model in production: build, test, release, watch and retrain, with as little hand work as possible., CI/CDTest and release models and pipelines through the same automated checks as other software. for models and data, containersPackage a model and its dependencies into an image that runs the same on a laptop and in production. and KubernetesRun training jobs and model services on Kubernetes, with sensible limits, scaling and health checks..
• The model's life: experiment tracking and a model registryTrack experiments and register models in MLflow, with the parameters, data and metrics that explain each one., model servingServe models in batch or in real time, within the latency and cost the product can carry. and model monitoringWatch a live model's inputs, outputs and quality, and raise an alarm when they move..
• The data: pipelines in tools such as AirflowSchedule and watch data and training pipelines, with retries and alerts that make sense., data versioning and, in larger teams, feature storesKnow when a feature store helps a team reuse features and keep training and serving in step..
• The people: data scientists, data engineers, product teams and the security and legal side.

Platforms come up side by side and none is a must: MLflow for tracking and the registry; Kubeflow on any Kubernetes; SageMaker, Vertex AI and Azure ML as managed ML platformsUse a managed ML platform, such as SageMaker, Vertex AI or Azure ML, or Kubeflow, and know what it does for you. on their clouds. Panels want to hear why a choice fits a team, not loyalty to one name.

From notebook to production

What does an ML pipeline look like, from raw data to a model in production?

What they check: the whole life of a model, not one tool.

Short answer: "Data is pulled and checked, features are built, the model is trained and evaluated against a fixed test set and the current model, and only a model that passes is registered. Release takes the registered version, deploys it carefully and watches it. Each step is code, runs automatically and leaves a record."

The full answer: A pipeline that only works when its author runs it is not a pipeline yet.

A weak answer: "The data scientist trains it and we copy the file to the server." Follow-up: "The model in production gives different answers from the notebook." Say where you look.

How would you set up experiment tracking and a model registry for a team of data scientists?

What they check: traceability that people will actually use.

Short answer: "Experiment tracking means logging every training run with its code version, data, parameters and metrics, so runs can be compared later. A model registry is the catalogue of trained models with their versions and stages, from candidate to production. I would pick one tool, such as MLflow, make logging one line for the data scientists, and let only registered models be deployed."

The full answer: If logging takes effort, people skip it, and the registry fills with gaps.

A weak answer: "Everyone keeps their results in a spreadsheet." Follow-up: "An auditor asks which data trained the model that scored a customer last March." Say how you answer.

How do you make a training run reproducible months later?

What they check: discipline about versions.

Short answer: "I pin the code version, the libraries in a container image, the random seeds and, hardest, the data: data versioning means storing a snapshot or a reference to the exact data a run used. The run's record links all of them. Then a rebuild gives the same model, or at least explains why it does not."

The full answer: Most failed reproductions come from data that changed under the same name.

A weak answer: "We can just run the notebook again." Follow-up: "The source table was overwritten last week." Say what you would have needed.

When does a team need a feature store, and what does it solve?

What they check: knowing when a tool earns its cost.

Short answer: "A feature store is a shared place for the features models use, with one definition for training and for serving. It helps when many models reuse the same features, or when online serving must compute features exactly as training did. For one team with a few batch models it is often more weight than help."

The full answer: The problem it solves is training and serving drifting apart, not storage.

A weak answer: "Every ML team needs one." Follow-up: "Your model scores well offline and badly online." Say what you suspect.

Release, serving and monitoring

How would you deploy a new model version without risking the service?

What they check: safe release patterns.

Short answer: "A canary release sends a small part of the traffic to the new model and grows it while the numbers hold. A shadow deployment runs the new model on live requests without using its answers, so we can compare. I use one of them, with a clear rule for going ahead and an automatic way back."

The full answer: Offline metrics say a model can work; only live traffic says it does.

A weak answer: "We replace the old model on Friday evening." Follow-up: "The new model is better on average and much worse for one customer group." Say what you do.

Batch scoring or real-time serving: how do you choose, and how do you keep latency low?

What they check: serving shaped by the product.

Short answer: "If answers can wait, batch scoring is simpler and cheaper. If the product needs an answer in the moment, I serve the model behind an endpoint, keep the model and features close, batch requests where possible, and size the machines from load tests. The latency limit comes from the product, not from the model."

The full answer: Many real-time services could be a nightly job, and are cheaper as one.

A weak answer: "Real time is always better." Follow-up: "Latency doubles at lunch time." Say where you look.

What do you monitor once a model is live?

What they check: monitoring beyond the server.

Short answer: "The service itself: latency, errors, load. The data: whether inputs still look like training data, missing values, new categories. The model: its outputs and, when the true answers arrive, its quality. And the business number it was built for. Each alert has an owner and a first step written down."

The full answer: A green dashboard for the server says nothing about the answers.

A weak answer: "We watch CPU and memory." Follow-up: "True labels arrive only after three months." Say what you watch meanwhile.

How do you detect drift, and what do you do when you find it?

What they check: a calm, measured response.

Short answer: "Drift means the data or the relation the model learned has moved since training. I compare the live inputs and outputs with a reference window, per feature, and alert on a set threshold. When it fires, I check first for a broken data feed, then whether quality has dropped, and only then decide on retraining with the data scientists."

The full answer: Half of all drift alarms are a broken pipe upstream, not a changed world.

A weak answer: "We retrain every time the alarm goes off." Follow-up: "Drift appears in one feature that the model hardly uses." Say whether you act.

When should a model be retrained automatically, and when should a person decide?

What they check: automation with judgement.

Short answer: "Retraining means training the model again on newer data. On a schedule or a drift signal, a pipeline can retrain and evaluate on its own, but a new model reaches production only after it beats the current one on agreed tests. Where the model affects people, such as credit or hiring, a person signs off."

The full answer: Automatic retraining without automatic checks is automatic risk.

A weak answer: "Retrain nightly and deploy whatever comes out." Follow-up: "Last night's data had a bug." Say what stops the bad model.

A new model is worse in production than in testing. How do you handle the rollback and find out why?

What they check: incident handling and learning.

Short answer: "First the rollback: the previous version is still in the registry and the service can switch back in minutes, which we practise. Then the cause: compare the inputs and features online with those in testing, check for leakage in the test set, and look at which groups got worse. The fix goes into the pipeline's checks, so it cannot happen the same way twice."

The full answer: A rollback you have never tried is a hope, not a plan.

A weak answer: "We retrain until it looks better." Follow-up: "The old model was deleted." Say what that tells you about the setup.

Platform, cost and the senior round

How do you run training and serving on Kubernetes, and where does it get hard?

What they check: real platform experience.

Short answer: "Training runs as jobs with resource requests and quotas per team; serving runs as services with health checks and autoscaling. The hard parts are GPUs, which need their own scheduling and drivers, large model files that slow down starts, and keeping shared clusters fair between teams."

The full answer: Kubernetes solves running containers, not deciding who gets the GPUs.

A weak answer: "Kubernetes handles everything." Follow-up: "One team's training job starves the serving pods." Say what you change.

GPUs are expensive. How do you keep the cost of training and inference under control?

What they check: cost as an engineering goal.

Short answer: "I make cost visible per team and per model, stop idle machines, use cheaper interruptible machines for training that can restart, right-size inference, and try smaller or compressed models where quality allows. A cost line in every model review keeps it on the table."

The full answer: The most expensive GPU is the one nobody remembers starting.

A weak answer: "Cost is finance's problem." Follow-up: "The monthly bill doubled and nobody knows why." Say your first step.

What changes when the model in production is an LLM?

What they check: applying the same discipline to new models.

Short answer: "The same discipline applies with new parts: prompts and retrieval data need versions too, quality is judged with evaluation sets and reviews rather than one accuracy number, cost and latency grow with the length of the text, and outputs need checks for harmful or wrong answers. Many teams call an outside model, so its versions and limits become a dependency to watch."

The full answer: An LLM in production is still a model in production, with more moving parts.

A weak answer: "LLMs do not need MLOps." Follow-up: "The provider updates the model and your answers change." Say how you would notice.

How does the EU AI Act change the work of an MLOps team on a high-risk system?

What they check: awareness of rules, without playing lawyer.

Short answer: "For systems the EU AI Act counts as high-risk, the provider needs risk management, data governance, logging, technical documentation and human oversight. Much of that is what good MLOps already produces: traceable data, registered models, monitoring records. Whether a system is high-risk is a legal question; my job is to make the evidence easy to give."

The full answer: Good records are cheaper to keep from day one than to rebuild for an audit.

A weak answer: "That is only for the legal team." Follow-up: "Legal asks for the training data of a model from last year." Say what you can hand over.

As a senior MLOps engineer or lead MLOps engineer, how would you help a junior MLOps engineer and the data scientists ship models safely?

What they check: making the safe way the easy way.

Short answer: "I build templates so a new model starts with tracking, tests and deployment already in place, write short guides, and review the first releases together. With a junior engineer I hand over one pipeline end to end with a clear goal and pair on the first incident. The measure is how many models reach production without me."

The full answer: A platform nobody uses is a hobby; adoption is the result.

A weak answer: "They can read the documentation." Follow-up: "A data science team keeps deploying by hand." Say what you do.

Where can AI tools help in MLOps work, and where must an engineer decide?

What they check: sober use of new tools.

Short answer: "AI assistants help write pipeline code, configuration and tests, summarise logs and suggest causes in an incident. I still review every change, keep secrets and data out of tools that are not approved, and keep release decisions and sign-off with people who answer for them."

The full answer: A wrong configuration written quickly is still a wrong configuration.

A weak answer: "AI will run the platform." Follow-up: "A suggested change opens a storage bucket to the internet." Say how you would catch it.

Your CV for these questions

Each line on your CV invites the questions above: which model, how it was released, what you watched. Give each line its model and its outcome, the way a lead engineer will ask about it:

Hold your CV against an MLOps engineer job with the free score; then prepare the model story for the area it finds thin, from the notebook to the rollback.