Recommendation System System Design Interview: Cold Start

When an interviewer asks you to design a recommendation system and then keeps pushing on cold start, they are testing whether you can scope an ambiguous problem and reason about data. The way out is a fixed opening: pin down requirements out loud, sketch retrieval then ranking, and answer cold start with a specific fallback plan rather than a model name. This walkthrough gives you the scripts for each part, in the order the interview usually runs. It is built for a recommendation system system design interview where the follow-ups matter more than the diagram.

What is the interviewer testing?

They are not checking whether you can name a model. They want to see whether you can turn a vague ask into a scoped problem, talk about data before algorithms, and reason about what happens when there is no data. Seniority shows in how you handle the edges, not in how many techniques you list.

Two failure modes sink candidates. The first is jumping straight to collaborative filtering and never stating requirements, which makes every later decision look arbitrary. The second is treating the whole thing as one ranking problem, with no retrieval stage, which suggests you have not thought about scale.

Say what you are doing as you do it. "Before I draw anything, I want to fix the surface, the objective and the constraints" buys you thirty seconds and tells the interviewer your answer is planned.

The requirements pass: five questions to ask first

Aim to spend the first three minutes here. Ask these five questions in order, and offer a sensible default when the interviewer says "your call".

Who is it for and where does it appear? Home feed, product page, email, or a sidebar all imply different freshness and layout needs.
What is the objective? A click, a watch, a purchase, or long-term retention. The objective decides the label you train on.
What does the user see? Usually a ranked list of N items. Ask whether explanations or diversity are required.
What are the non-functional targets? Read latency for the serving path, how fresh interactions must be, and rough scale in users, items and interactions per day.
What is out of scope? Ads, search, and the UI itself are common exclusions. Naming them keeps you inside the time budget.

For a video app, sample answers might run: home feed for signed-in viewers; objective is watch time, not raw clicks; a ranked list of twenty items with some genre diversity; serving under a couple of hundred milliseconds, with new views reflected within minutes; millions of viewers and a large catalogue. Those answers give you enough to draw. For a deeper treatment of the latency and scale side, see Consistency Models System Design Interview: Pick and Defend.

The architecture: retrieval first, then ranking

One model scoring the whole catalogue does not scale: you cannot run a heavy model over millions of items per request. Split the work. Candidate generation narrows millions of items to a few hundred cheaply, then a heavier ranker scores that shortlist.

Describe this diagram on the whiteboard, labelling each arrow:

Event ingestion at the top left, receiving views, clicks and skips. Arrow to the feature store and to the offline log.
Feature store, holding user and item features. Arrows out to training and to serving.
Offline training pipeline, reading logged events plus features, producing candidate generators and the ranker. Arrow to the model registry.
Candidate generators (several, run in parallel) reading features and the registry, emitting a few hundred item IDs. Arrow to the ranker.
Ranker, scoring the shortlist with the heavier model. Arrow to the serving layer.
Serving layer, blending results, applying filters and diversity, returning the top N. Arrow back to the user, and a dotted arrow from the user's response back to event ingestion, which closes the loop.

The dotted arrow is the part interviewers remember. It shows you know the system feeds on its own output, which sets up the feedback-loop question later.

Cold start: the answer that separates levels

Split the problem out loud into new user, new item and new system. Each has a different fix, and saying so shows you have thought about them separately.

New user. Fall back to popularity, content or context signals, then blend in learned preferences as interactions arrive. State how you would measure when the fallback stops being needed: once the user has enough interactions for personalised candidates to beat the fallback in an A/B test, you reduce the fallback's weight.

New item. Use content and metadata similarity to existing items until interaction data accumulates. A new video with a known genre, creator and tags can borrow from neighbours.

New system. Start with popularity and content-based ranking, and treat early data as biased until you have enough volume.

Here is a spoken script for the follow-up "so what do you show a brand-new user on day one?"

On day one I have no interaction history, so a personalised model has nothing to work with. I would show a popularity-based list, but filtered for diversity so it does not look identical to every other new user's feed. I would add context signals I do have, like time of day, device and any onboarding choices. As the first few views and skips arrive, I blend in a learned model, starting with a small weight and raising it as confidence grows. I would judge the switch by whether personalised candidates beat the fallback on watch time in a held-out test, not by a fixed number of sessions.

That answer works because it names the fallback, the blend, and the exit condition. A weaker version says "just use content-based filtering" and stops, which leaves the interviewer to guess whether you know when to stop using it.

The feedback loop: stopping the system recommending only what it likes

A recommender trained on its own output will keep serving what already gets clicks. Popular items get more exposure, which produces more data, which makes them look even better. That is popularity bias, and it also narrows what users see over time, which is a design concern before it is an ethics one.

Three levers to name:

Exploration slots. Reserve a share of the list for items the model is unsure about, so you collect data on them.
Diversity constraints in the ranker. Penalise near-duplicates so the list is not ten versions of the same item.
A held-back slice of traffic. Keep a small random group to measure true performance without the loop's bias.

Frame the trade-off explicitly: exploration costs short-term engagement but protects long-term catalogue health. Say which you would pick and why. "I would hold a small exploration share even at some cost to clicks, because without it the system slowly starves new items" is a defensible position.

Trade-offs to name out loud

Pick a few and state a decision for each. The table is a prompt for your own words, not a script to read.

Trade-off	Option A	Option B	My call
Latency vs freshness	Precomputed candidates, fast but stale	Real-time features, fresher but costlier	Precompute candidates, add real-time features only in the ranker
Offline vs online metrics	Offline score is cheap and repeatable	Online behaviour is the real test	Trust offline for screening, confirm with an online test
Exploration vs engagement	Exploration protects catalogue health	Engagement looks better short term	Hold a small exploration share and defend it

Skip trade-offs that do not change a decision, such as which specific model family to use. Naming a trade-off you cannot defend is worse than leaving it out.

A 25-minute walkthrough, start to finish

Budget the time and say the transitions out loud so the answer sounds planned.

Minutes 0–3, requirements. "Let me fix the surface, objective and constraints first." Then the five questions.
Minutes 3–8, architecture. "Given that, here is the high-level shape: retrieval then ranking." Draw and label the arrows.
Minutes 8–16, deep dive. "The part I would spend most time on is cold start and ranking." Cover new user, new item, and the blend.
Minutes 16–21, trade-offs. "A few trade-offs worth naming." Use the table above as your mental checklist.
Minutes 21–25, follow-ups. Leave room. When a follow-up comes, extend the answer rather than repeating it; Respond to Follow-Up Questions in an Interview covers that move in detail.

If you run long, cut the offline pipeline detail, not the cold-start section. That is where the interviewer is listening.

Common mistakes and how to practise out loud

Three mistakes to watch for:

No requirements. Fix: say the five questions before drawing anything.
No retrieval/ranking split. Fix: describe candidate generation before the ranker, every time.
Hand-waving cold start. Fix: use the day-one script and name the exit condition.

A 20-minute solo routine:

Sketch the diagram from memory in five minutes, labelling every arrow.
Narrate the whole case aloud for ten minutes and record it.
Re-narrate only the cold-start section for five minutes, tightening the script.

When you review the recording, listen for filler, trade-offs you skipped, and follow-ups you left unanswered. If rambling is your habit, Stop Rambling Interview: A Live Answering Plan gives you a way to cut it mid-answer.

Before you walk in

The cold-start answer is the one that gets followed up, so rehearse it until the fallback, the blend and the exit condition come out in one breath. Everything else in the case supports it. Do one thing next: set a timer for twenty minutes and record yourself narrating the whole walkthrough, then listen back only to the cold-start section.

Frequently asked questions

Do I need to know machine learning algorithms to pass a recommendation system system design interview?

No. You need to reason about data, scale and trade-offs. Knowing a few model families helps you speak precisely, but interviewers usually care more about how you scope the problem and handle cold start than whether you can derive a loss function.

How much detail on the ranking model should I give if I am not an ML engineer?

Enough to show you know what it consumes and what it optimises. Say it takes user and item features from the feature store, scores a shortlist, and is trained on the objective you agreed in requirements. Leave the architecture of the model itself to a specialist unless asked.

What if the interviewer asks me to design the offline training pipeline too?

Treat it as a second case and ask a short requirements pass for it. Cover where training data comes from, how features are built, how often you retrain, and how a new model is validated before it reaches serving. Keep it brief so the main design does not drift.

How is designing a recommendation system different from designing a news feed?

A feed case usually focuses on delivery and fan-out for content that already exists. A recommender case focuses on the decision of what to show and to whom, which puts ranking, cold start and the feedback loop at the centre. The serving layer overlaps, but the reasoning is different.

Should I mention evaluation metrics like precision or NDCG, and at what point?

Mention them when you discuss how you would know the design works, usually after the architecture. Name one or two that fit the objective, say they are offline signals, and note that online behaviour is the real test. Do not open with metrics before requirements.

Practise the cold-start script aloud and review your recording.