USA
Canada
UK
Europe
Australia
Singapore
Japan
IndiaQ1. What is MLOps and how does it differ from DevOps?
Short answer: MLOps applies DevOps practices to ML, adding data and model lifecycle concerns.
Strong answer: MLOps operationalizes machine learning: automated training, deployment, monitoring and governance of models. Beyond DevOps it must handle data versioning, model versioning, experiment tracking, drift/decay, and reproducibility — because ML behavior depends on data, not just code. The unit of change is code + data + model, not just code.
Likely follow-up: Why does model performance degrade over time even with no code change?
What the interviewer is checking: Understanding of what makes ML ops different.
Common mistake: Treating a model like a static binary you deploy once.
Q2. How do you design a model training and deployment pipeline?
Short answer: Automate data prep, training, evaluation, registry, and gated deployment with monitoring.
Strong answer: Build a pipeline that ingests and validates data, trains and evaluates against a baseline, registers the model with metadata/lineage, and deploys behind a gate (offline metrics + shadow/canary) — then monitors in production. Everything is versioned and reproducible so you can roll back and retrain on a schedule or trigger.
Likely follow-up: What gates would you require before promoting a model to production?
What the interviewer is checking: End-to-end MLOps design.
Common mistake: Manually training and copying model files with no evaluation gate.
Q3. What is model drift and how do you detect it?
Short answer: Drift is when data or relationships change so the model degrades; detect via monitoring.
Strong answer: Data drift is a change in input distributions; concept drift is a change in the input→output relationship. Detect by monitoring input feature distributions, prediction distributions and (when labels arrive) live accuracy against baselines, with statistical tests and alerts. Trigger retraining or rollback when drift crosses thresholds.
Likely follow-up: How do you monitor accuracy when ground-truth labels are delayed?
What the interviewer is checking: Production ML reliability.
Common mistake: Deploying a model with no drift or performance monitoring.
Q4. What is a feature store and why is it useful?
Short answer: A central system for computing, storing and serving consistent features for training and inference.
Strong answer: A feature store manages feature computation, storage, versioning and serving so the same feature logic is used in training and online inference — eliminating training/serving skew. It also enables reuse across teams and point-in-time correctness for training data. Useful once feature reuse and consistency become pain points.
Likely follow-up: What is training/serving skew and how does a feature store prevent it?
What the interviewer is checking: Awareness of a core MLOps component.
Common mistake: Recomputing features differently in training vs serving.
Q5. How do you version data and models for reproducibility?
Short answer: Version datasets, code, config and model artifacts with lineage in a registry.
Strong answer: Reproducibility needs versioned data (DVC/lakehouse snapshots), code (git), environment/config, and model artifacts in a model registry with metadata linking each model to its training data, code and metrics. This lets you reproduce, audit and roll back any model. Without it, "which data trained this?" becomes unanswerable.
Likely follow-up: A model in production misbehaves — how do you trace what trained it?
What the interviewer is checking: Governance and reproducibility.
Common mistake: Only versioning code, not data and artifacts.
Q6. What deployment strategies suit ML models?
Short answer: Shadow, canary and A/B deployments reduce risk when promoting a new model.
Strong answer: Shadow deployment runs the new model alongside production without serving its results, to compare safely. Canary routes a small share of traffic to validate on live data. A/B tests compare business metrics between models. These limit blast radius because offline metrics don’t guarantee online performance.
Likely follow-up: Why is offline evaluation not enough before full rollout?
What the interviewer is checking: Safe ML release practice.
Common mistake: Swapping models in production with no shadow/canary.
Q7. How do you serve models at scale and control cost/latency?
Short answer: Choose real-time vs batch, right-size compute, batch requests, cache, and autoscale.
Strong answer: Decide between real-time endpoints and batch scoring by latency needs. Optimize with request batching, model optimization (quantization/distillation), caching repeat inputs, GPU/CPU right-sizing and autoscaling. Monitor latency, throughput and cost per prediction. For LLMs, token/cost control matters even more.
Likely follow-up: When is batch scoring a better choice than a real-time endpoint?
What the interviewer is checking: Serving and cost awareness.
Common mistake: Defaulting to always-on GPU endpoints for infrequent predictions.