How would you handle a feature that is cheap in batch but too slow to compute per request?
PICTURE THIS: DATABASE INDEX
Simple meaning
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.
WHY — Feature Store instead of guessing?
Why interviewers care about Feature Store:
question about Feature Store.
trade-offs, and what you would actually do on a MLOps project - not buzzwords.
Name the idea, why it exists, then one short example.
End with when you use it and one common pitfall.
STEPS — What happens step by step?
Before you speak the answer, walk the interviewer through these steps:
- 1Precompute 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.
- 2If neither works, change
the product to tolerate batch decisions.
- 3I would not compute
heavy Spark SQL inside the request path.
- 4Give an example
One tiny concrete case you can say aloud.
- 5Common mistake
What juniors usually get wrong.
- 6Close
When you pick this over the alternative.
EXAMPLE — See it in action
Here's a short line you can speak, broken into clear beats:
Note: Adapt this scaffold to your own project — keep it under 60–90 seconds.
Key takeaway
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. If neither works, change the product to tolerate batch decisions.