In this article
Before you start
This page is one step of the recommendation system design guide.
Why interviewers ask this
The question separates candidates who can sequence work from candidates who recite architectures. A team with a small staff cannot build every model at once, so the interviewer wants to hear which model comes first, what it costs and what evidence moves you to the next one.
A weak answer lists names: "matrix factorization, a two-tower model, a transformer." A strong answer orders the models by cost and by the data each one needs, and says how each will be compared. A Staff-level answer adds the system view: large recommenders split the work into stages, so "the model" is really several models with different jobs. This opening is reported in interviews at AI labs and large tech companies, and it tends to come before the questions on cold start and on ranking.
Recommender models from first principles
- Popularity baseline
- A popularity baseline is a recommender that shows every user the items with the most past interactions, minus those the user has already seen, with no personalisation, and it sets the score every later model must beat.
- Content-based filtering
- Content-based filtering is a recommendation method that uses the similarity between items, measured on their features, to suggest items like those a user already liked, so it needs item descriptions but not other users' behaviour.
In plain words
Think of a new bookshop. On day one you put the bestsellers at the front. Next you group books by subject, so a reader of one cookbook is shown other cookbooks. Later, once many readers have bought things, you notice that people who bought book A also bought book B, even when the two look unrelated. The analogy breaks at scale. A shop has hundreds of books; a large recommender has far too many items to check one by one.
In one precise sentence, each model on the ladder uses more information than the one before it. The order is counts, then item features, then the behaviour of all users, then a split into fast and precise stages.
Step 1: Start with a popularity baseline
A popularity baseline counts how often each item was used and recommends the top items the user has not yet seen. The input is the interaction log. The output is one ranked list, the same for everyone except for the removal of seen items.
It is worth building first for three reasons. It ships quickly, it works for a user you know nothing about, and it gives every later model a score to beat. If a personalised model cannot beat it on held-out data, the problem is in the data or the evaluation, not in the model size. Adding a recency window, so that only recent interactions count, is a cheap improvement. The ladder starts with a popularity baseline. You now have a floor; the next step adds item features.
Step 2: Add a content-based model
Content-based filtering suggests items that resemble what the user already liked. Google's course puts it as using similarity between items to recommend items similar to what the user likes, such as more cute animal videos after two cat videos.
The input is an item feature table, such as genre, text or price band, and the user's own history. The model builds a profile from the items the user touched and scores unseen items against it. The similarity can be cosine, dot product or Euclidean distance, the same measures the Google course lists for embeddings.
Its strength is that a brand-new item with features can be scored on day one. Its weakness is that it only finds more of the same, and it cannot use what other users did. The cold start problem page covers how this helps with new items.
Step 3: Add collaborative filtering and matrix factorization
Collaborative filtering uses many users' behaviour together. The Google course describes it as using similarities between queries and items simultaneously: if user A is similar to user B, and B likes video one, the system can recommend video one to A even though A has seen nothing similar.
Two common forms exist. Item-item collaborative filtering scores an item by how often it appears with the items the user already used. Matrix factorization learns one embedding per user and one per item, so the score of a pair is their dot product. Both need enough interaction history, and neither can score an item that nobody has used yet. The course also notes that deep neural networks can overcome some limitations of matrix factorization, which is why they come later, not first.
Step 4: Measure each model on held-out data
Held-out evaluation is how the ladder is climbed: build a model, test it on interactions it has not seen, and keep it only if it wins. The test below is a toy, and every number is illustrative. It has 60 simulated profiles, 30 items in three genres and 420 training interactions, and the last interaction of each user is held out.1
Hit rate is the share of profiles whose held-out item appears in the model's top five. The popularity baseline scores 0.1667 (10 of 60 profiles), the item-item collaborative model scores 0.6 (36 profiles) and the content-based model scores 0.7333 (44 profiles).1 The content-based model wins here only because the toy data is built so that genre fully reveals taste; on real data the order depends on how informative the features are and how much history exists. The content-based model also breaks ties by popularity, so it is really a genre-plus-popularity hybrid.
Here the collaborative model does not beat the content-based one, so content-based stays in production. An offline win is a gate, not the launch decision: a model that passes is then confirmed in an online A/B test, because offline hit rate and online results can disagree.
| Model | Users hit (of 60) | Hit rate at five |
|---|---|---|
| Popularity baseline | 10 | 0.1667 |
| Item-item collaborative | 36 | 0.6 |
| Content-based | 44 | 0.7333 |
Text description of the diagram
- The popularity baseline has a hit rate of 0.1667.
- The item-item collaborative model has a hit rate of 0.6.
- The content-based model has a hit rate of 0.7333.
Step 5: Split into retrieval and ranking when the catalogue is large
A large recommender is several models in stages. Google's overview describes a three-stage architecture: candidate generation, scoring and re-ranking. Candidate generation is the first stage, also called retrieval, that narrows a huge pool to a small set; the same page says it reduces YouTube's billions of videos to hundreds or thousands.
The models for each stage differ. Retrieval needs speed, so it uses embedding models such as matrix factorization or a two-tower model. Scoring takes the survivors and, because it sees few items, can use a more precise model that picks on the order of ten to show; a logistic-regression or gradient-boosted-tree ranker is a common cheap first choice before a deep one; multi-task ranking is one form. Re-ranking then applies rules such as removing disliked items or boosting fresher content. A cross-encoder reranker is one precise scorer for the short list.
Step-by-step description
- Popularity sets the score to beat.
- Item features score new items.
- User behaviour is added.
- Each model is compared on unseen data.
- A large catalogue needs stages.
- The ladder starts with a popularity baseline.
- Each model is measured on held-out data.
- Large catalogues split into retrieval and ranking models.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
What are the models we can start building?
I would build in order of cost and evidence. First a popularity baseline with a recency window, because every later model has to beat it on held-out data. Second a content-based model on item features, which also scores new items. Third collaborative filtering, such as matrix factorization, which learns user and item embeddings from behaviour but needs interaction history. Once the catalogue is too large to score in full, I split into a fast retrieval model, for example a two-tower model, and a slower ranking model on the survivors, then a re-ranking step for freshness and diversity. I gate each one on held-out hit rate with a time-based split, then confirm it in an online A/B test.
What makes it Staff-level is the ordering rule, the evaluation habit and the split into stages, rather than a list of model names.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Correctness | Names one fancy model | Names baseline, content-based and collaborative models | Adds retrieval, scoring and re-ranking roles |
| Depth | Names models without definitions | Says what data each model uses | Explains why each model is built when it is |
| Trade-offs | None | Mentions cold start | Matches model to data volume and catalogue size |
| Evaluation | Not mentioned | Tests on held-out data | Time-based offline gate, then an online A/B test. |
| Communication | Rambling list | Ordered, spoken in a minute | Gives a decision rule for moving up |
Three variants of this question
Which model should we build first for a recommender system?
Build the popularity baseline first, with a recency window. It ships quickly, serves users you know nothing about, and gives the later models a number to beat.
What models can we build if we have no user history yet?
Use a popularity or editorial baseline and a content-based model on item features. Collaborative models need interactions, so they wait until logs exist; the cold start problem page covers the options.
What models can we start building if the catalogue is huge?
Split the system: a fast embedding model for retrieval, a more precise model to score the shortlist, then a re-ranking step. Scoring every item with a precise model does not fit a latency budget.
Common mistakes
- "I would start with a transformer." (wrong) It gives no baseline and needs the most data. (right) "I start with a popularity baseline, then add models only when they win on held-out data."
- "Collaborative filtering is always better than content-based." (wrong) It cannot score items with no interactions. (right) "Collaborative needs history; content-based works on day one for items with features."
- "One model does everything." (wrong) Retrieval and ranking have different jobs and budgets. (right) "A fast model narrows the catalogue and a precise model orders the shortlist."
- "We can judge by training accuracy." (wrong) It rewards memorising. (right) "I test on held-out interactions, ideally split by time."
Follow-up questions
How do you know a new model is better than the current one?
Run an offline held-out gate first, then an online A/B test on engagement or conversion metrics. Both are needed because offline hit rate and online results can disagree.
Is collaborative filtering better than content-based filtering?
Neither wins everywhere. Collaborative filtering uses what many users did and can surface surprising items, but it needs history; content-based filtering scores new items from their features but tends to return more of the same. Many systems use both.
Do you need deep learning to build a recommender?
Not to start. Google's course frames deep neural networks as a way past some limits of matrix factorization, so they are a later step once simpler models have been measured.
How do you mix new items into an established catalogue?
Score them with the content-based model from their features, and reserve a small share of slots for them so they can gather interactions that the collaborative model can later use. The cold start problem page goes deeper.
What does the ranking model add after retrieval?
It scores the shortlist with richer features, often for several outcomes at once, as in multi-task ranking. The wider design is in the recommendation system design guide.
- Build in order: popularity baseline, content-based, collaborative, then retrieval and ranking stages.
- A new model replaces the current one only if it wins on held-out data; otherwise keep the better one or combine them.
- Content-based models need item features; collaborative models need interaction history.
- Large systems split into candidate generation, scoring and re-ranking, each with its own model.
Sources
- Recommendation systems overview | Machine Learning | Google for Developers — Google for Developers (undated page; accessed 2026-10-26), 26 Oct 2026
- Candidate generation overview | Machine Learning | Google for Developers — Google for Developers (undated page; accessed 2026-10-26), 26 Oct 2026
- Course summary | Machine Learning | Google for Developers — Google for Developers (last updated 2025-08-25; accessed 2026-10-26), 25 Aug 2025
