MLOps and Deployment Interview Questions for Machine Learning
25 MLOps and Deployment questions with answers for machine learning roles — 5 easy, 14 medium, 6 hard.
About MLOps and Deployment
Interviews for ML engineer roles increasingly test production skills. Learn batch versus real-time inference, saving pipelines, serving models with FastAPI, Docker images, MLflow tracking and model registry, CI tests, shadow and canary releases, data and concept drift, PSI, training-serving skew, feature stores, latency tuning and monitoring models after launch.
Sheet progressStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
✓ 3 questions free • Unlock the rest in seconds
01
What does it mean to deploy a machine learning model?
Deployment makes a trained model available to produce predictions for real users or systems. It can be batch, scoring data on a schedule and writing results to a table, or real-time, serving predictions through a REST API, or streaming, scoring events as they arrive. It includes packaging the model with its preprocessing, setting up infrastructure, logging, monitoring and a retraining plan.
Save the whole fitted pipeline so preprocessing travels with the model.
import joblib
joblib.dump(pipe, 'model_v1.joblib')
pipe = joblib.load('model_v1.joblib')
preds = pipe.predict(new_df)
Load with the same scikit-learn version used for training, and never load pickle or joblib files from untrusted sources because they can execute code. ONNX or skops are safer portable options.
MLOps applies DevOps practices to machine learning: version control for code, data and models, automated training pipelines, testing, CI/CD for model releases, model registries, monitoring and automated retraining. Its aim is to move models from notebooks to production reliably and keep them healthy. Common tools are MLflow, DVC, Airflow, Kubeflow, and cloud platforms like SageMaker, Vertex AI and Azure ML.
Docker packages the model, code, Python version and exact library versions into one image that runs the same on a laptop, a test server or Kubernetes. This removes 'works on my machine' problems, especially with scikit-learn version mismatches. Images can be scanned, versioned and deployed through CI/CD, and scaled horizontally behind a load balancer on platforms like Kubernetes, ECS or Cloud Run.
05
How do you work with data engineers and software engineers on an ML project?
I agree early on interfaces: which tables or APIs provide features, the input and output schema, latency targets and who owns monitoring. I share a short design document and keep my code in the same repository standards as theirs, with tests and reviews. In my last project weekly syncs with data engineering helped us fix a late-arriving data issue before launch rather than after.
Data drift, or covariate shift, means the distribution of input features changes, such as average order value rising after a pricing change. Concept drift means the relationship between features and target changes, such as fraud patterns evolving. Data drift can be detected without labels using PSI or KS tests; concept drift usually needs labels and shows up as falling performance. Both trigger investigation and retraining.
A model registry is a central store of model versions with metadata: training data version, parameters, metrics, owner and stage such as staging or production. It makes promotions and rollbacks controlled and auditable, and lets serving systems load a model by name and version. MLflow Model Registry, SageMaker Model Registry and Vertex AI Model Registry are common examples.
Batch scoring runs on a schedule, for example nightly churn scores for all customers written to a table; it is simple, cheap and tolerant of slow models. Real-time inference returns predictions on request, such as fraud checks during payment, and needs low latency, high availability, scaling and fresh features. Choose real-time only when the decision must happen at the moment of the event.
09
What are shadow deployment and canary release for models?
In shadow deployment the new model receives a copy of live traffic and its predictions are logged but not used, so you can compare it with the current model safely. In a canary release a small share of real traffic, such as 5 percent, is served by the new model, and the share grows if metrics stay healthy. Both reduce the risk of a bad model affecting all users.
10
What should you monitor for a model in production?
Monitor service health such as latency, error rate and throughput; input data quality such as missing values, schema changes and out-of-range values; feature and prediction distribution drift; and real performance once labels arrive. Also track business KPIs the model influences. Set alerts with thresholds and owners, and keep a dashboard so issues are found before users report them.
11
A model's accuracy dropped 10 percent over three months in production. How do you investigate?
I would first check data pipelines for broken features, nulls or schema changes, then compare current feature distributions with training data using PSI to find drift. I would check whether the label definition or business process changed, and analyse errors by segment. If drift is real, retrain on recent data, possibly with time-weighted samples, and set up automatic drift alerts and scheduled retraining.
12
A new model version performs badly right after release. How do you handle it?
Roll back immediately to the previous version from the model registry, which should be a one-step action. Then investigate: compare the input features served with those used in validation, check for training-serving skew, version mismatches or a wrong artifact. Add the failure case to automated pre-release checks, and use canary or shadow releases next time so issues affect only a small share of traffic.
13
Your team retrains models manually in notebooks every month. How would you improve it?
I would convert the notebook into a versioned training pipeline with separate steps for data extraction, validation, feature building, training and evaluation, scheduled with Airflow or a cloud pipeline. Each run would log to MLflow, compare against the production model on a fixed holdout, and register the new model only if it passes thresholds. Promotion would stay a reviewed step, at least initially.
Situation: our demand model ran only in a notebook on my laptop. Task: make it run daily for 300 stores. Action: I refactored it into modules with a scikit-learn pipeline, added tests and input checks, containerised it with Docker and scheduled it with Airflow writing forecasts to the warehouse. Result: forecasts became available by 6 a.m. daily without manual work, and failures triggered alerts instead of silent gaps.
19
Tell me about a time a production model failed and how you communicated it.
Situation: our daily scoring job silently produced all-zero scores for two days after an upstream column was renamed. Task: fix it and inform affected teams. Action: I rolled back to cached scores, patched the feature mapping, and sent a short note explaining impact, cause and fix. I then added schema validation and a check on score distribution. Result: the issue never repeated, and teams trusted our alerts more.
20
What is training-serving skew and how do you prevent it?
Training-serving skew is when features at prediction time are computed differently from features used in training, causing silent accuracy loss. Causes include separate code paths, different data sources, or time windows that use future data in training. Prevent it by sharing one feature-computation code path or a feature store, logging served features and comparing their distributions with training data.
21
Your real-time model API takes 400 ms but the requirement is under 50 ms. What do you do?
Profile first to see whether time goes to feature lookup, preprocessing or the model. Then cache or precompute features, load the model once at startup, reduce trees or features, use a faster library like LightGBM or ONNX Runtime, and batch requests if possible. Run several workers and keep the service close to its data store. Re-measure p95 and p99 latency, not just the average.
22
Labels for your loan model arrive only after 6 months. How do you monitor it meanwhile?
I would rely on proxy signals: input data drift with PSI, prediction score distribution, approval rates by segment, and early indicators like first missed payment at 30 or 60 days. Once enough early outcomes arrive, I would check performance on these. I would also set up a delayed evaluation job that computes full metrics as labels mature and compares them with the validation baseline.
23
Your model must run on a mobile app with no internet. What do you consider?
Model size, memory and latency on low-end phones become key. I would choose a compact model, reduce features, and convert it to a mobile format such as ONNX, TensorFlow Lite or Core ML, applying quantisation if needed. I would make sure all preprocessing is replicated on-device, test accuracy after conversion, and plan how model updates will ship with app releases.
24
Calculate the Population Stability Index for a feature.
A feature store is a system that defines, computes and serves features consistently for both training and real-time inference, with an offline store for historical data and an online store for low-latency lookup. It prevents training-serving skew and lets teams reuse features. It is worth it when many models share features or need real-time features; small teams can start with well-managed tables.
Frequently asked questions
How important is MLOps and Deployment in Machine Learning interviews?
Interviews for ML engineer roles increasingly test production skills. Learn batch versus real-time inference, saving pipelines, serving models with FastAPI, Docker images, MLflow tracking and model registry, CI tests, shadow and canary releases, data and concept drift, PSI, training-serving skew, feature stores, latency tuning and monitoring models after launch.
How should I use the MLOps and Deployment sheet?
Go top to bottom — easy to hard. Answer before opening each answer, tick what you solved and save misses to Last-Minute Revision.