How the interviewer opens it
“Design a system that recommends relevant products from a store's catalog. Use browsing behavior, purchase history, and product attributes. The system must respond quickly for both new and returning users.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Recommendation surfaces
- Scale
- Traffic and read:write mix
- Latency
- Freshness
- Consistency and availability
- Durability and retention
- New users and products
- Success
- Scope and data sources
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Recommend products on the home page and a product page
- Use browsing behavior, purchase history, and product attributes
- Support users without history and products without interactions
- Meet latency targets and exclude products that are not eligible
Usually out of scope
- Build the checkout, inventory, or payment service
- Set prices or select advertisements
- Invent new model algorithms
- Track users across other websites
What interviewers ask about
- New users and products
- Behavior signals do not exist for new users or products. Popularity alone can prevent new products from gaining useful feedback.
- Behavior freshness
- A fast event stream and slower model jobs can disagree. Duplicate events and delayed purchases can corrupt user interests.
- Response time and product availability
- The service cannot score the full catalog per request. Cached recommendations can contain products that recently became unavailable.
- Recommendation quality
- Users interact only with products they see. Historical data can reward position and popularity instead of relevance.
Common mistakes
- Describe model algorithms without a complete request path.
- Score the full catalog on every request.
- Treat new users and new products as the same problem.
- Use daily jobs alone despite minute-level freshness targets.
- Trust old recommendation lists for current product eligibility.
- Optimize clicks without exposure data or purchase measures.
The bar by level
- Senior (L5/E5)
- Meet freshness and latency targets with explicit budgets. Handle duplicate events, new products, eligibility changes, and dependency failures. Define useful experiments and fallback behavior.
- Staff (L6+/E6+)
- Set clear contracts across catalog, orders, features, and model releases. Address feedback bias, recovery, privacy, and cost. Explain when added model complexity earns its operational cost.