Once you've listed a model's features in a machine learning (ML) design interview, the interviewer usually follows up with "How is each of these computed, and how fresh is it?" and then "How do you make sure the model sees the same values in serving as it did in training?"

Both questions are about the feature pipeline: the jobs that compute feature values from raw data, store them, and hand the same values to training as historical rows and to serving as fresh lookups. A model can only be as good as that hand-off. If training saw one number and serving sees another, the model makes confident predictions from inputs it never learned from. Not every model needs heavy machinery for this.

One model with a few slow-moving features needs only a nightly batch job and a log of what serving used. Streaming jobs earn their cost when a value changes within minutes and that change moves the prediction, and a dedicated feature store earns its cost when several models or teams share features.

We'll use one example throughout: a food-delivery app that predicts, at checkout, how many minutes an order will take to arrive. It uses three features, each computed differently: a restaurant's 30-day average prep time, the number of orders that restaurant received in the last 10 minutes, and the courier's distance to the restaurant. Which features to build in the first place belongs to Feature engineering. Here the features are given, and the question is how their values get made, stored, and kept consistent.

This topic rarely fills a whole round, but it typically takes 5-10 minutes of the data stage. A mid-level answer assigns each feature a compute path and explains why training reads historical values while serving reads the latest ones. A senior-level answer also covers point-in-time correctness, backfills, and a concrete plan to prevent training-serving skew.