It solves training and serving consistency. The same feature must be computed from batch history for training and from fresh data at low latency for serving, and when those are two separate implementations they drift. A feature store defines a feature once, materializes it to an offline store for point in time training data and an online store for millisecond lookups, and provides point in time correct joins.
Why interviewers ask this
Interviewers ask this to see whether you have felt training serving skew rather than just read about it. Anyone can describe a key value cache; the answer they want names point in time correctness and single definition as the actual value. Being willing to say a feature store is overkill for a single model team also reads well, because it shows judgment about infrastructure cost.
How to structure your answer
- Name training serving skew as the core problem.
- Explain the point in time join requirement for training data.
- Describe the online store's latency role.
- Say honestly when a feature store is not worth the complexity.
Example answer
The problem is that the same feature has two lives. For training I need its value as of some historical timestamp, joined without accidentally including anything that happened afterward. For serving I need it right now, in under ten milliseconds, keyed by entity. If those are two codebases, and they always start as two codebases, they drift. Someone changes a window from thirty days to twenty eight in the training job, nobody touches the serving path, and now the model is scoring against features it was never trained on. That drift is silent, which is what makes it expensive. A feature store gives you one definition that materializes into both an offline table for training and an online key value store for serving, plus point in time joins so the historical query cannot leak the future. That said, I would not stand one up for a team with two models. The overhead is real, and you get most of the benefit from a shared transformation library plus a scheduled job that writes to a cache. I would reach for a managed feature store once several teams share features, because that is when duplicate definitions start multiplying.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How would you implement a point in time correct join yourself?
- What consistency guarantees do you need between the online and offline stores?
- How do you handle a feature whose definition changes after models depend on it?
Related machine learning engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions