Problem background: design a store recommendation system similar to the app's home page.
Interview process & core follow-ups:
Overall architecture and hard constraints
The scenario given right away was home page recommendation. User input is extremely sparse — basically just the User ID and current location. The system has a couple of hard constraints: the stores surfaced must be within delivery range, and they must currently be open.
How to design retrieval
Follow-up questions:
- Geo-location caching: how do you combine caching with location? (We discussed using Geohash or a grid system — pre-computing popularity leaderboards offline for each grid cell, then storing them in a KV database like DynamoDB keyed by coordinates.)
- Extreme performance challenge: if I set an extremely strict timeout for each recall path (say, only 15ms), how would you optimize concurrent fetching?
Ranking layer and feature infrastructure (Ranking & Feature Store)
The last part went very low-level, mostly testing how to build a feature platform.
The interviewer threw out this scenario:
- Storage and read design: how do you split storage for different feature types (embeddings, numerical, categorical) at the database level? How do you use Store ID and User ID as the primary key to get hourly offline refresh while still guaranteeing concurrent read efficiency for online inference?
- Model iteration and A/B testing: say you now want to ship a V2.0 model that adds a few new features on top of V1.1. How does your underlying infrastructure support that kind of change? How do you pull different feature-set config files for different treatment groups?
- Real-time feature trade-offs: we finished by discussing the trade-off between real-time features and offline batch features, focusing on the pitfalls of pushing real-time features in for better accuracy under low-latency requirements — things like timeouts, reduced system stability, and missing feature values.
Discussion
Loading comments…