We use cookies for site analytics. Accept to help us understand how the site is used. See our Privacy Policy for details.
The offline/online store split, train/serve skew as the core problem it exists to solve, point-in-time-correct joins, materialization and freshness, and a registry that lets teams reuse features instead of re-deriving them badly.
Design the platform that stores, serves, and governs the features that feed a company's ML models. Dozens of teams, hundreds of models, thousands of features. Each feature - "user's 30-day average order value," "merchant's fraud rate last week," "items in cart right now" - must be available two ways: in bulk for training (historical, point-in-time correct) and one-row-at-a-time for serving (fresh, single-digit-millisecond).
This is the infrastructure question behind every production ML system. The naive answer - "teams compute features in their pipelines" - is exactly what produces the industry's most common production ML failure: training/serving skew, where a feature is computed one way in the training job and a subtly different way in the serving path, and the model silently degrades. A strong candidate frames the feature store as the single-source-of-truth machine that makes skew structurally impossible, then designs the offline/online split, point-in-time correctness, and materialization that make that guarantee real.
Asking these before diving into a solution is the difference between a "hire" and a "no signal" rating. Pick the questions whose answers would change your design.
Capacity estimation · architecture with all 8 components explained · 5 deep dives · trade-off analysis · 8 common follow-up questions
Get full access to gitGood.dev with a subscription.
Try everything free for 10 days. Cancel anytime.
10-day trial, then $5/mo - or $40/yr ($3.33/mo, save 33%). Cancel anytime.
Online vs batch inference, GPU utilization tricks, autoscaling for spiky load, A/B testing models, and the feature store that decouples training from serving.
The two-stage candidate-generation-then-ranking architecture, embeddings + ANN retrieval, the batch/real-time feature split, feedback loops, cold start, and why offline NDCG lies until the online A/B disagrees.
Batch vs streaming, lambda vs kappa, the warehouse-vs-lakehouse decision, and dimension modeling that survives schema drift.
Partitions, consumer groups, replication, retention, and the exactly-once myth - the implementation details Kafka users gloss over until they don't.
Reading is the floor. The interview signal is in walking through this live with someone probing follow-ups. Use the AI mock interview to practice talking through requirements, architecture, and trade-offs out loud.
Start an AI mock interview →