MLOps interview questions and answers

I would register one model family but two serving paths: an online path with an in-memory or Redis feature store, HPA, and a strict timeout plus heuristic fallback.

I would extract feature definitions into a single source, compile or execute them in both engines, and add a skew job that computes features both ways on a sampled log and diffs them.

Each team gets a namespaced registry, required metadata, and automated gates on frozen eval sets plus slice metrics.

Prevention is immutability, object lock, and tying registry GC to a retention policy that never deletes a version still aliased.

Offline jobs would compute aggregations with event-time windows and point-in-time joins against label timestamps.

Precompute it on a stream or micro-batch into the online store with a freshness SLA, or approximate it with a cheaper online proxy and keep the expensive version for training if you can prove low skew.

Treat the feature as a versioned contract: user_spend_30d_v3 with a changelog, dual-write during migration, and a sunset date.

I would compare against last Monday and a seasonal baseline, not only versus the training month.

Track vector norms, cosine distance of daily centroids to a reference, and ANN recall on a labeled query set.

I would freeze the score distribution, check whether business thresholds or coverage changed, and look at precision at the operating point on delayed labels.

Combine scheduled retrains with gates: drift plus a statistically significant drop on a delayed metric, plus a minimum data volume.

PR CI would unit-test features, validate schemas, and run a tiny train.

Fix seeds where possible, compare metrics with tolerances, and assert ranking or calibration bands rather than exact floats.

Keep CPU unit tests in PR CI and submit GPU jobs to a cluster with a queue, using smaller smoke configs on a single GPU for merge gates.

A rarely changing base with CUDA and system libs, a mid layer with pinned Python deps, and a thin top layer with app code and the model.

I would compare memory requests, model load plus thread pools, and whether local used a smaller weights file.

I would scale on a custom metric such as concurrent inflight requests, keep a small warm pool, and use a queue to absorb spikes.

Namespaces with resource quotas, separate node pools for GPU versus CPU, network policies, and per-model HPA.

Set a startup or readiness probe delay beyond 90 seconds, maxSurge so old Pods keep traffic, and maxUnavailable of 0 if capacity is tight.

Separate tracking server, backend SQL, and artifact bucket with IAM, SSO, and per-experiment permissions.