MLOps Interview Questions and Answers
Defend a model release from training data to recovery, with questions that connect ML quality and reliable delivery.
MLOps interviews test whether you can make a model reproducible, release it safely and recognise when it stops serving its purpose. Explain the evidence required at each stage and the recovery plan when a candidate fails.
Reproducibility and experiment records
1. What makes an ML run reproducible?
Record the code revision, data version, configuration, dependencies, preprocessing and evaluation method. Seeds help control randomness but may not guarantee identical output across hardware or libraries. Define whether you need exact reproduction or statistically comparable results.
2. What belongs in an experiment tracker?
Track parameters, metrics, artefacts and the identifiers needed to connect a run to code and data. Keep evaluation context with the score. A number without a dataset, split and metric definition cannot explain why one model was selected.
3. How is a model registry different from experiment tracking?
Tracking records runs and results. A registry organises model versions and their release lifecycle. A registered model is not automatically approved for production; the team's tests and review process decide whether it is suitable.
Sources: MLflow: experiment tracking. Checked 23 October 2026.
Pipelines and deployment
4. How does ML delivery differ from ordinary application delivery?
The release may depend on data and training as well as source code. Test feature schemas, preprocessing and model quality alongside application behaviour. A passing unit suite is not sufficient evidence that a newly trained model improves outcomes.
5. What checks would block a model release?
Examples include schema incompatibility, missing artefacts, unacceptable performance on important data slices, a failed latency budget or an untested rollback. Define thresholds for the use case before evaluating a candidate; do not choose the threshold after seeing its result.
6. When should predictions run in a batch?
Batch inference suits work that can wait, such as a scheduled scoring job. Online inference suits requests that need an immediate answer. Compare freshness, volume, latency and failure recovery. Neither option is universally cheaper or more accurate.
7. What is a canary release?
A canary exposes a controlled portion of traffic to a candidate while monitoring defined signals. Agree on how to stop or reverse the change. Random traffic assignment can be unsuitable for some experiments, so choose a design that fits the users and evaluation question.
Sources: Google Cloud: MLOps delivery and automation. Checked 23 October 2026.
Monitoring and recovery
8. How do data drift and concept drift differ?
Data drift refers to a change in the input distribution. Concept drift refers to a change in the relationship between inputs and the target. An input shift is a signal to investigate, not automatic proof that predictions are wrong.
9. What can you monitor before labels arrive?
Monitor service errors, latency, missing values, schema changes and input or prediction distributions. These are operational and proxy signals. When labels become available, evaluate actual model performance and account for feedback delay and selection bias.
10. Should drift automatically trigger retraining?
Not always. First check for a broken data pipeline, a measurement change or a temporary event. Retraining on unsuitable data can worsen the system. Define validation, approval and rollback for any automated training process.
11. What must a rollback preserve?
Keep a compatible model, preprocessing version and configuration, plus a way to route requests back. Check input-schema compatibility. Retaining an old model file is not enough if the application can no longer provide the features it expects.
12. What would you do if offline quality improves but production results worsen?
Investigate data leakage, training-serving differences, changed traffic, measurement errors and mismatched success metrics. Compare relevant slices and trace the deployed artefact. Stop or reverse a harmful rollout while collecting evidence, rather than assuming the offline metric is authoritative.
Practise an incident explanation
A new model produces valid responses, but customer complaints increase. Walk through how you would verify the release version, compare inputs and outputs, check monitoring and obtain delayed labels. Explain who can stop the rollout and which fallback the application will use.
A strong answer distinguishes what you know from what you suspect. Describe the first safe action, the evidence you would collect and the condition for resuming the release. Include communication and documentation; operations is a team responsibility.
Common questions
Are these questions suitable for DevOps engineers?
Yes. Use them to connect deployment experience with model quality, data contracts and reproducibility. Practise one complete model lifecycle rather than only infrastructure commands.
Which MLOps tool should I learn first?
Start with Git, Python, an experiment record and a repeatable model release. Add a tracking or orchestration tool when you can explain the problem it solves.
