This interview question evaluates ML product requirements, data/labeling, modeling, serving architecture, evaluation, monitoring, and trade-offs in a realistic interview setting. A strong answer for Design a recommendation system states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
##### Question
Design a recommendation system for users and items: discuss model choice (e.g., NMF), data fetching with multiple servers and a reverse proxy, and data storage (user, item, and interaction tables).
Quick Answer: This interview question evaluates ML product requirements, data/labeling, modeling, serving architecture, evaluation, monitoring, and trade-offs in a realistic interview setting. A strong answer for Design a recommendation system states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
mediumSoftware EngineerTechnical ScreenML System Design
5
0
Design a recommendation system
Design a User–Item Recommendation System
Context
You are asked to design an end-to-end recommendation service that suggests items to users. The service should include choices for the recommendation model, the serving architecture with multiple application servers behind a reverse proxy, and a storage schema for users, items, and interactions.
Assume: millions of users and items, primarily implicit feedback (views, clicks, purchases), and a p95 online latency target under 150 ms for the recommendation endpoint.
Tasks
Model choice and approach
Explain a reasonable baseline (e.g., NMF/matrix factorization) and alternatives.
Discuss handling implicit vs. explicit feedback, cold start, and ranking.
Describe training cadence and evaluation.
Data fetching and serving architecture
Describe how multiple stateless servers behind a reverse proxy will serve recommendations.
Cover caching, timeouts/retries, fallbacks, and model/feature serving calls.
Data storage design
Propose schemas for user, item, and interaction data.
Include any derived tables (e.g., learned embeddings/factors) and indexing/partitioning choices.
Constraints & Assumptions
Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.
Clarifying Questions to Ask Guidance
Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.
What a Strong Answer Covers Guidance
A scoped requirements summary with concrete non-goals and success metrics.
ML-specific data, model, evaluation, serving, and monitoring choices.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.
Follow-up Questions Guidance
What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?