The MLOps questions that quietly sink candidates.

The single most important framing for the whole MLOps round: an ML system is code plus data plus a model, and all three drift. In traditional software, you write logic, test it, ship it, and it behaves identically until you change it. An ML model is different — its behavior is learned from a snapshot of data, and the moment that snapshot stops matching reality, the model gets quietly worse without anyone touching a line of code. This is why "it passed all the tests at deploy" means much less for ML than it does for a backend service.

The lifecycle is also a loop, not a line. You don't ship a model and walk away; you ship it, watch it, and feed what you learn back into the next training run. Interviewers love to see candidates describe this loop explicitly — problem framing, data collection, training, evaluation, deployment, monitoring, and back to retraining — because it shows you understand that the work doesn't end at deployment. It begins there.

Here's the failure mode a feature store prevents. During training, you compute features in a batch job over historical data — say, a user's average order value over the last 30 days. At serving time, you need that same feature computed live, on the fly, for a single user. If the two code paths differ even slightly — a different rounding rule, a different time window, a timezone bug — the model sees different inputs in production than it saw in training. The model didn't change; the inputs did. This is training-serving skew, and it's one of the most common silent killers in production ML.

A feature store gives you a single definition of each feature, materialized into two synchronized stores: an offline store (a data warehouse holding historical feature values for training, with point-in-time correctness) and an online store (a low-latency key-value store like Redis or DynamoDB for serving). You define the feature once; the store guarantees both paths use the same logic. It also enables feature reuse across teams and point-in-time joins that prevent label leakage — fetching feature values as they were at prediction time, not as they are now.

There are three serving modes, and choosing the right one is the first decision. Batch (offline) inference scores a large set of records on a schedule and writes predictions to a table — perfect when predictions don't need to be fresh-to-the-second (nightly churn scores, weekly recommendations). It's the simplest and cheapest to operate. Online (real-time) inference serves predictions synchronously behind an API, on the order of milliseconds, when the input only exists at request time (fraud check on a transaction, ranking a feed on page load). Streaming inference scores events continuously off a message bus (Kafka, Kinesis) when you need near-real-time reactions to a flow of events without a blocking request.

The second decision is how to roll out a new version safely. You almost never flip 100% of traffic to a fresh model. Interviewers expect you to name the de-risking patterns: shadow deployment (the new model receives real traffic but its predictions are logged, not served — pure observation, zero user risk) and canary release (send a small slice of traffic, say 5%, to the new model, watch the metrics, then ramp up gradually). Blue-green is the related infra pattern: two identical environments, switch traffic over, keep the old one warm for instant rollback.

There are two triggers for retraining, and the right choice depends on how predictable your drift is. Scheduled retraining runs on a fixed cadence — nightly, weekly, monthly — and is simple and predictable. It fits domains where drift is gradual and steady. Triggered retraining fires when monitoring detects a problem: drift crosses a threshold, or performance drops below an SLA. It's more responsive and avoids retraining when nothing has changed, but it requires the monitoring infrastructure from the previous section to exist. The most mature setups combine both — a regular cadence as a baseline, plus a trigger for sudden shifts.

The trap interviewers probe is treating retraining as a no-op. It isn't. A retrained model is a new model and must go through the same gate as any deployment: train on fresh data, evaluate against a held-out set and against the current production model, shadow or canary test it, and only promote if it actually beats what's live. Blindly auto-deploying every retrain is how teams ship regressions. And retraining can't fix everything — if your labels are drifting or your feature pipeline is broken, a fresh model trained on bad data just relearns the problem.

The MLOps community talks about CI/CD/CT: continuous integration, continuous delivery, and continuous training. CI for ML doesn't just run unit tests on code — it also validates data (schema checks, distribution checks, null-rate thresholds) and validates the model (does it clear a minimum metric bar? does it beat the current production model on a held-out set?). CD automates the promotion-and-deploy path with the safe-rollout patterns from Section 5. CT — continuous training — is the automated pipeline that retrains, re-validates, and re-registers on the schedule or trigger from Section 7. Naming all three, and noting that ML adds data and model tests on top of normal code tests, is the clean way to answer "what does CI/CD look like for ML?"

The other thing interviewers probe is cost and latency trade-offs, because a model that's accurate but too slow or too expensive doesn't ship. The levers worth knowing: model compression (quantization, pruning, distillation to a smaller student model) to cut latency and serving cost; batching requests to raise GPU throughput at the cost of a little latency; caching predictions for repeated inputs; and hardware choice (CPU vs GPU vs accelerator) matched to the latency budget. The framing that lands: serving cost and latency are first-class design constraints, not afterthoughts — sometimes the right answer is a slightly less accurate model that's 10× cheaper to serve.