The short answer: MLOps interviews test whether you can get machine learning models into production reliably and keep them working. Expect questions on ML pipelines and continuous training, experiment tracking and model registries, feature stores and training-serving skew, deployment patterns, serving at scale, monitoring for drift, testing ML systems, and increasingly LLMOps, plus scenarios like “the model’s accuracy dropped in production.” Interviewers want engineering discipline applied to the parts of ML that ordinary software practices miss: data, models and feedback loops.
Core concepts
“What is MLOps, and how is it different from DevOps?”
MLOps applies DevOps practices (automation, CI/CD, monitoring) to machine learning systems, which add data and models to code. A model can degrade without any code change because the world changes, so MLOps adds data validation, model validation, continuous training and model monitoring.
A well-known 2015 paper by D. Sculley and colleagues, Hidden Technical Debt in Machine Learning Systems, argued that “it is common to incur massive ongoing maintenance costs in real-world ML systems.” Citing it shows you understand why MLOps exists.
“Describe the levels of MLOps maturity.”
Google Cloud’s architecture guide describes three levels:
| Level | What it means |
|---|---|
| Level 0: manual process | Every step (data analysis, preparation, training, validation) is manual and script-driven; deployment is rare and handed off manually |
| Level 1: ML pipeline automation | The pipeline is automated so the model is continuously trained on new data, with automated data and model validation |
| Level 2: CI/CD pipeline automation | The pipelines themselves are built, tested and deployed automatically, so teams can update them rapidly and reliably |
Be ready to say where a team you worked on sat and what you did to move it up.
Pipeline questions
- “What are the stages of an ML pipeline?” Data ingestion, validation, preparation and feature engineering, training, evaluation, model validation against the current production model, registration, deployment and monitoring.
- “What is continuous training?” Automatically retraining a model when triggered by a schedule, new data, or detected performance or drift, then validating it before deployment.
- “Which tools have you used?” For example Kubeflow, Airflow, Vertex AI Pipelines, SageMaker Pipelines or MLflow. Explain the design, not just the names.
Experiment tracking and model registry questions
- “Why track experiments?” To reproduce results and compare runs: code version, data version, parameters, metrics and artifacts.
- “What does a model registry do?” Stores versioned models with metadata (training data, metrics, lineage) and manages stages such as staging, production and archived, with approvals and rollback.
- “How do you make training reproducible?” Version code, data (or snapshots and queries), environment (containers, pinned dependencies) and random seeds, and record them with each run.
Feature store and skew questions
- “What is training-serving skew?” A difference between how features are computed in training and at serving time, causing worse production performance. Prevent it by sharing feature logic, using a feature store with offline and online views, and logging serving features to compare.
- “What is a feature store?” A system to define, compute, store and serve features consistently for training (offline, point-in-time correct) and serving (online, low latency).
- “What is point-in-time correctness?” Building training data using only feature values available at each event’s time, to avoid leakage.
Deployment questions
- “Batch vs online inference?” Batch scores data on a schedule (cheap, simple, fine when predictions can be precomputed); online serves predictions on request with latency requirements.
- “How do you deploy a new model safely?” Shadow deployment (run alongside without affecting users and compare), canary (send a small share of traffic, watch metrics, then expand), A/B testing for business impact, and fast rollback through the registry.
- “How do you serve models at scale?” Containerized model servers, autoscaling, batching requests, model optimization (quantization, distillation), GPU scheduling where needed, and caching. See our Kubernetes interview questions.
Monitoring and drift questions
“What kinds of drift do you monitor?”
- Data drift: input feature distributions change (for example, a new customer segment).
- Concept drift: the relationship between inputs and the target changes (for example, fraud patterns evolve).
- Prediction drift: the distribution of model outputs changes.
Monitor with statistical tests or distance measures on features and predictions, alongside operational metrics (latency, errors, throughput) and data quality checks (missing values, schema changes).
“How do you monitor model performance when labels arrive late?”
Use proxy signals in the meantime (prediction drift, business metrics, feature drift), track performance on labeled data as it arrives, and set alert thresholds that trigger investigation or retraining.
Testing ML systems
- Data tests: schema, ranges, null rates, distribution checks before training and serving.
- Model tests: minimum performance on held-out data, comparison with the production model, performance on important slices, fairness checks, and behavioral tests (invariance to irrelevant changes).
- Infrastructure tests: the pipeline runs end to end, the serving API meets latency targets, and rollback works.
LLMOps questions
- “How is operating LLM applications different?” Prompts, retrieval pipelines and model versions all need versioning; evaluation relies on test sets, rubric-based or model-graded scoring and human review; plus guardrails, cost and latency monitoring, and handling provider model updates. See our LLM engineer interview questions.
- “How do you evaluate a change to a prompt or model?” Run it against a fixed evaluation set, compare with the current version on quality, safety, latency and cost, and roll out gradually.
Scenario questions
“Accuracy dropped 8% in production last week. What do you do?”
“I’d first rule out a data or pipeline problem: a schema change, a broken upstream feed or a feature that started returning nulls. Then I’d compare current feature and prediction distributions with the training data to look for drift, and slice performance by segment to see where it dropped. If it’s a data bug, fix and backfill; if it’s genuine drift, retrain on recent data, validate against the current model and roll out through a canary. Afterwards I’d add an alert on whatever we missed.”
More scenarios
- “Design a pipeline to retrain a fraud model weekly.” Data extraction with point-in-time features, validation, training, evaluation against the current model and fairness slices, registry, canary deployment and monitoring, with manual approval for large changes.
- “Training costs are too high.” Profile jobs, use spot or preemptible instances, cache intermediate data, train less often if drift is slow, and right-size hardware.
Behavioral questions
- “Tell me about a model you took to production. What went wrong?”
- “Tell me about a time you improved an ML team’s workflow.”
- “How do you work with data scientists who prefer notebooks?”
Use the STAR method.
Related guides: data scientist interview questions, DevOps engineer interview questions, site reliability engineer interview questions and Snowflake interview questions.
Frequently asked questions
What questions are asked in an MLOps interview?
What are the MLOps maturity levels?
What is the difference between data drift and concept drift?
What is training-serving skew?
How do you deploy a new ML model safely?
Sources
- Google Cloud, MLOps: Continuous delivery and automation pipelines in machine learning. Read on 2 October 2026.
- D. Sculley et al., Hidden Technical Debt in Machine Learning Systems, Advances in Neural Information Processing Systems 28 (2015). Read on 2 October 2026.
