Recommendation System Design Interview: The Funnel, Stage by Stage, from Real Asks

A recommendation system design interview is not a test of whether you can name two-tower networks. It is a test of whether you can take an underspecified prompt — "recommend stores," "recommend lenses," "rank the feed" — and walk it through the same four-stage funnel every production recommender uses: define the objective, generate candidates cheaply, rank them with a heavier model, and serve the result inside a latency budget. Our question bank holds 291 recommendation-related questions, spanning design rounds, coding follow-ups, and analytics asks. This page maps the landscape using the ones that teach the most.

Key Takeaways

• Spend the first ten minutes on the objective and the training label, not the architecture. A common failure is drawing a two-tower diagram before saying what the model predicts.
• Every production recommender is a funnel: millions of items → a few thousand candidates → a few hundred ranked → twenty served. Interviewers expect you to name the stage boundaries and the latency spent at each.
• Cold start is not a bonus question. At Snapchat it was an explicit follow-up, asked separately for new items and new users; prepare a distinct answer for each.
• Offline metrics (recall@K, NDCG, AUC) get you to a launch candidate; only an A/B test on the business metric gets you to a launch. Say both, in that order.
• Know when the fancy option is wrong. A candidate at Intuit proposed an LLM-agent recommender and walked its latency component by component; the interviewer doubted the fit and put the total above 20 seconds, and the candidate still passed. The latency arithmetic is what survived the doubt.

The prompt is underspecified on purpose: pick an objective and defend it

Asked at Google — Design a Product or Video Recommendation System An ML engineer onsite where one round was simply "design a recommendation system for products or videos" — no scale numbers, no metric, no surface specified. The same loop separately hand-checked fundamentals: a from-scratch transformer implementation and a web crawler coding round.

With fundamentals checked elsewhere in the loop, an open prompt like this one is mostly grading judgment, and "products or videos" is doing a lot of work in it. The two surfaces have different objectives, and the interviewer wants to watch you notice. Video platforms optimize for watch time or completion rate because a click is nearly free and clickbait poisons a click-trained model. Commerce platforms optimize for purchase or add-to-cart, which is rare relative to clicks, so you immediately face extreme label sparsity and probably a multi-task setup where clicks provide signal density and purchases provide the target that matters.

So the opening move is a short negotiation: who is the user, what action do we want more of, and what logged event will stand in for it as a training label. Then say the label's failure mode out loud. Click labels reward curiosity-gap thumbnails. Watch-time labels over-reward long videos unless you normalize by duration. Purchase labels are so sparse you will need auxiliary tasks. Naming the corruption your own label invites is worth more than any architecture you draw later, because everything downstream (features, model, evaluation) inherits it.

It is tempting to treat this stage as throat-clearing and rush to the diagram. Resist that: every follow-up about features, metrics, and bias circles back to the label you picked, so a shaky objective keeps costing you for the rest of the hour. Worth knowing, too, that the Google report's author came away feeling the design round went only so-so. An open prompt gives you more room to underwhelm as well as to shine.

Candidate generation: cut millions of items to hundreds, cheaply

Asked at Meta — Design Place Recommendation System An MLE round: design a system that suggests places — restaurants, attractions, things nearby — on a maps-style discovery surface. The constraint worth noticing here is eligibility: geography alone rules out almost the entire catalog for any given user, so the pool that matters is the small slice they could plausibly visit — and that reshapes retrieval before any model runs.

You cannot score ten million items with a ranking model per request. The funnel's first stage exists to make the rest affordable: retrieve roughly 1,000–5,000 candidates in about 10–20ms, out of a total budget near 200ms.

Say "multiple candidate sources" explicitly, because a single source is the classic junior answer. A realistic mix:

• Embedding retrieval. A two-tower model: one tower encodes the user (history, context), one encodes the item, trained so that engaged pairs land close in the embedding space. At serving time the user embedding is computed once and matched against a precomputed item index via approximate nearest neighbor search (HNSW or ScaNN — sublinear lookup, versus a linear scan that would blow the budget at corpus scale).
• Heuristic sources. Trending-now, popular-in-region, new-from-followed-creators. Cheap, interpretable, and your fallback when the model path fails.
• Graph sources. Friends-of-friends, co-engagement ("users who saved this also saved..."). If you want to feel this as a concrete data-structure problem, the OpenAI versioned follow-graph question asks for exactly the storage layer under a friend recommender, follow-up included: top-K recommendations from the follower graph.

For the Meta places prompt, geography reshapes all three. The ANN index can't be one global index you filter afterward — a user in Tokyo would retrieve mostly ineligible candidates. You either shard the index by geohash region or push a location pre-filter into retrieval. That observation, specific to the prompt, is what separates a memorized funnel from an applied one.

The common mistake here is the opposite of the objective-stage mistake: too much machinery. Candidates propose retraining the two-tower model online, or running the ranker over 50,000 candidates. Retrieval is deliberately dumb and fast; resist making it clever.

Ranking: where the heavy model earns its latency

Asked at Uber — Design a feed ranking system An MLE onsite where one round was designing a feed ranking system end to end, and a separate round required hand-writing linear and logistic regression. The pairing is deliberate: the loop wanted proof that the boxes in the design diagram were backed by working knowledge of what's inside them.

The ranker sees a few hundred candidates and can finally afford to be expensive: 50–100ms for a model with cross features — features that combine user and item, like "this user's historical CTR on this creator" — which the two-tower structure cannot express because its towers only meet at a dot product.

For a feed, the standard shape is multi-task: one shared network with separate heads predicting pClick, pLike, pShare, pHide, expected dwell time. The final ordering score is a weighted combination, and the weights are a product decision, not a modeling one. That is exactly why calibration matters: if pShare is systematically overconfident, its weight silently means something different from what the product team tuned. Follow-ups about calibration (Platt scaling, isotonic regression, or just monitoring predicted-vs-actual by bucket) come up in MLE loops precisely because it is the detail that pure-theory preparation skips. The Uber loop hand-writing logistic regression is the same check from the other side.

Two more things belong in this stage of your answer:

Position bias. Your training data comes from your own past rankings, and item #1 gets clicked more just for being first. Log the position, use it as a training feature, then zero or fix it at serving time. Skip this and the model learns "things we ranked first are good" — a self-fulfilling loop.

Re-ranking. After scoring, a light pass applies diversity (don't show four videos from one creator), dedup against recent sessions, and hard business rules. Selecting the final top-20 from a few hundred scored candidates is a textbook heap problem — the same top-K pattern covered in our heap guide, except here the interesting part is the constraint interaction, not the data structure.

The common mistake: naming a model family ("we'll use a DNN") without naming a single feature. Interviewers probe features because features are where domain understanding shows; the model family is a commodity.

Cold start and label weighting: the standard follow-ups

Asked at Snapchat — Design a Lens Recommendation System An MLE round: design the recommender for Snapchat lenses, with follow-ups on cold start for both new lenses and new users, weighted logistic regression across multiple engagement levels, and designing the model-training interface — how features and models get fetched for reuse.

Treat this report as a ready-made follow-up checklist for your prep, because these are the questions that arrive around minute thirty no matter the company.

New-item cold start. A new lens has no engagement history, so collaborative signals are silent. Two levers: content features (the lens's visual embedding, category, creator) let the ranker score it on day zero without engagement counters; and an exploration budget — reserve a small slice of impressions, a few percent, for under-observed items, ideally allocated by a contextual bandit rather than uniformly. Say the trade-off: exploration costs short-term engagement to buy information. Interviewers accept the cost when you show you know you're paying it.

New-user cold start. Fall back through signal tiers: onboarding selections if the product has them, then context (device, region, time), then popularity-in-region. Then say when each tier expires. After a handful of sessions the collaborative path should take over, and a design that never hands off is a design that ignores its best users.

Weighted labels. A lens view, a play, and a share are not equal, and Snapchat asked specifically how to encode that. Two honest answers: weight the positive examples in the logistic loss by engagement depth, or model each engagement level as its own task and blend the heads (which is the multi-task ranker from the previous section, arrived at from a different direction). The first is simpler and one model; the second is more flexible and standard at scale. Offering both with the trade-off beats committing blindly to either.

The training pipeline: recommenders are data products first

Asked at Tubitv — ML System Design: Movie Recommendation Model and Pipeline (AI-Assisted Round) An associate-level loop for the Tubi Builders Program, recommendations end to end: one design round on a movie recommendation model and its pipeline, and another on choosing better thumbnails for a title.

When a recommendation design round is framed as model plus pipeline, as this associate-level one was, the model is maybe a third of the expected answer. The rest is the loop that keeps it alive. (That thumbnail round, incidentally, is a ranking problem wearing a different hat: candidate thumbnails, a scoring model, a click label, position bias and all.)

Three points on this diagram carry most of the interview credit.

Train/serve skew. The feature store feeds both the label join and online serving for a reason: if training computes "user's 7-day watch count" one way and the serving path computes it another way, the model quietly degrades and nothing alerts. Log features at serving time and train on the logged values. This one sentence has rescued more candidates than any architecture flourish.

Negative sampling. You log what users engaged with; you must construct what they saw and skipped. Impressed-but-not-engaged items are your negatives, and getting this join wrong (or sampling random items as negatives for the ranker) is a named failure mode worth naming.

The feedback loop. Tomorrow's training data is filtered through today's recommendations. Without exploration traffic and position-bias handling, the system converges on a narrow read of each user and can't discover it's wrong. This connects back to the exploration budget from the cold-start section — same mechanism, second job.

A schema sketch is worth offering here, because it makes the label join concrete:

-- One row per impression; the unit of training data
CREATE TABLE impressions (
  request_id   TEXT,
  user_id      BIGINT,
  item_id      BIGINT,
  position     SMALLINT,      -- for position-bias correction
  features     JSONB,         -- logged AT SERVING TIME, not recomputed
  served_at    TIMESTAMPTZ
);

-- Engagement events join back by (request_id, item_id)
-- label = 1 if a qualifying event exists within the attribution window

For evaluation, give the two-stage answer: offline metrics on a held-out time slice (recall@K for retrieval, NDCG and per-head AUC for ranking — and split by time, never randomly, or you leak the future) to pick a launch candidate, then an online A/B test on the actual business metric with guardrails on retention and report rates. Tubitv's loops also probe practical tuning: a separate Tubitv round went deep on how the candidate actually tuned recommenders in production, which no amount of paper knowledge fakes.

Serving: the latency budget and the degradation story

Asked at DoorDash — Design a Store Recommendation System and Explain ML Trade-offs An ML system design round on recommending stores to DoorDash users, in a loop that separately probed which ML methods the candidate had personally used at work.

The store domain forces constraints most recsys prompts let you skip — a perfect recommendation for a closed store is a defect, not a near-miss — which makes it the right prompt for the serving stage.

Walk the request path with numbers. A feed request has perhaps 200ms end to end. Retrieval gets 10–20ms, feature-store lookups for a few hundred candidates another 20–30ms (batched — one lookup per candidate is how budgets die), the ranker 50–100ms, re-ranking and assembly the remainder. If any stage misses its budget, you serve anyway: fall back to cached results from the user's last session, or to the popularity source. The degradation story is not optional garnish; "what happens when the ranker times out?" is a stock follow-up, and "the feed is empty" fails it.

Store recommendation adds hard eligibility: open now, delivers to this address, acceptable ETA. Push those into candidate filtering, not post-rank. Otherwise the ranker's top-20 can be eligible-item-poor and your served feed is thin. This mirrors the Meta places geography point: real-world constraints move upstream in the funnel.

Also decide when computation happens. Precomputing recommendations per user (push-style) buys single-digit-millisecond serving but goes stale and wastes compute on inactive users; computing on request (pull-style) is always fresh but pays the full pipeline per request. Most real systems split it: precompute or cache candidates, rank fresh. The same fan-out trade-off shows up across feed architecture, and our push vs pull guide covers it from the infrastructure side.

A lot of otherwise-strong answers thin out here to "and then we deploy the model": one box, no budget, no fallback. The DoorDash round's own title says "explain ML trade-offs"; serving is where you show you can.

The twist prompt: when the standard funnel needs surgery

Asked at Intuit — Design a "Future Best-Sellers" Prediction and Recommendation System A 75-minute staff+ round: design a system that predicts which items in a category will sell best over a user-chosen future window, and recommends them. The interviewer allowed either a traditional ML approach or an LLM-based one; the candidate chose an LLM-agent design, walked through per-component latency estimates, and proposed a caching strategy. Asked for feedback, the interviewer called it a good chat-style design but wasn't sure it fit this scenario, putting the likely latency above 20 seconds. Four days later, the email said the candidate had passed.

Twist prompts graft a second problem onto the recommender — here, time-series forecasting. The move is not to invent a new architecture but to say which funnel stage absorbs the twist: forecast demand per item as an offline batch job, then feed the forecast in as a ranking feature and a candidate source. The funnel survives; one input changed.

The LLM fork deserves a clear-eyed answer. The Intuit interviewer offered either path unprompted, so it is a fork worth preparing for. Where LLMs fit: cold-start enrichment (generating item attributes from descriptions), semantic candidate retrieval over text-heavy catalogs, explanation generation. Where they do not: inline scoring in a 200ms feed path. Per-candidate LLM calls are two orders of magnitude outside budget, plus per-token cost at feed volume. Batch and cache LLM outputs offline; keep the online path on small fast models.

Read the report's outcome carefully. The doubt came from the interviewer, not the candidate: good design, unsure it fits, latency probably 20-plus seconds. What the candidate had already done was walk the latency estimates component by component and propose caching, so when the challenge landed, the conversation stayed quantitative instead of defensive — and the pass came anyway. You cannot control whether an interviewer likes your architecture choice. You can control whether the numbers in it are yours.

Practice these on PracHub

Work these in roughly this order — each one drills a different stage of the funnel:

• Design a Product or Video Recommendation System (Google) — the canonical open prompt; drills objective and label negotiation before any architecture.
• Design Place Recommendation System (Meta) — drills candidate generation under a hard eligibility constraint (geography).
• Design a feed ranking system (Uber) — drills the multi-task ranker, calibration, and position bias.
• Design a Lens Recommendation System (Snapchat) — drills cold start for items and users, plus weighted engagement labels.
• Design a Store Recommendation System and Explain ML Trade-offs (DoorDash) — drills serving budgets, eligibility filtering, and degradation.
• Design a Versioned Social Follow Graph with Friend Recommendations (OpenAI) — the coding-round face of the same domain: the storage layer and top-K under a social recommender.

For more ML system design reports across companies, browse the full bank at prachub.com/interview-questions, and the pattern guides at prachub.com/resources.