In this article
Before you start
This page is one design in the recommendation system design guide, and it assumes only the ideas below.
Why interviewers ask this
A next-page prompt tests whether you can turn a vague product wish into stages with a clear job each. Candidates report prompts of this family: recommend the next Confluence pages a user should view, recommend articles in Confluence, recommend Jira issues, suggest files in Dropbox, and find the top pages by likes, shares and views, including a variation that hides pages the user has already viewed. These are candidate reports, not public statements by any company.
A weak answer says "train a model on clicks." A strong answer names the query, separates retrieval from ranking, adds filters for access and for pages already seen, and says how it would judge success. A Staff-level answer also knows that the similarity score itself can favor popular pages, and chooses on purpose whether to keep, damp or remove that effect.
Next-page recommendation from first principles
- Next-page recommender
- A next-page recommender is a system that takes a user and the page or issue open right now and returns a short, ordered list of other pages or issues worth opening next, drawn from a catalog far too large to score one by one.
- Seen-page filter
- A seen-page filter is a step that removes from a candidate list every page the current user has already viewed, so the final list shows only new items; it only works if retrieval returns more than the number finally shown.
- Embedding norm
- The embedding norm is the length of an item's embedding vector. In a dot-product score a larger norm raises the score for every query, and items that appear often in training data tend to get large norms, so the norm acts like a hidden popularity bonus.
In plain words
Think of a good librarian. You hold one book. The librarian pulls twenty similar books, puts back any you have read or may not borrow, then picks the best few. Each move is a stage of the system. The analogy breaks in one place: a librarian knows every book personally, while a recommender knows items only through numbers learned from behavior.
In one precise sentence, a next-page recommender maps the user and the open page to a query, retrieves nearby items by similarity, filters them, and ranks the survivors.
Everything below is a proposed design for an interview, not a description of how Atlassian or Dropbox build their features.
Step 1: The query is the user plus the open page
The query of a next-page recommender is built from who is reading and what is open now. Useful inputs are the text and space of the current Confluence page, the user's recent views and edits, and for Jira the project, issue type, labels and linked issues.
Input: user id and current item. Output: one query vector, plus a list of access rules that apply to this user. Items are mapped to vectors in the same space, because Google's course describes mapping both items and queries into a shared low-dimensional embedding space. You now know what is being asked of the system; the next step turns the query into candidates.
Step 2: Candidate generation scores by similarity, and the norm adds popularity
Candidate generation is the first stage of recommendation: given a query, the system produces a set of relevant candidates (Google for Developers, updated August 2025). The same page describes two families: content-based filtering (items similar to what the user likes) and collaborative filtering (similarities between queries and items, learned from other users).
For a next-page task you can combine both: item-to-item similarity for "pages like this one", and user-to-item similarity for "pages people like you opened." Each is a similarity score between a query vector and an item vector, using cosine, dot product or Euclidean distance. If the vectors are normalized, dot product and cosine coincide, according to the same Google page.
The catch is the embedding norm. The Google page notes that items appearing very often in training, such as popular videos, tend to get large norms, so popular items can dominate the recommendations. Cosine ignores the norm.
Keep the dot product when popularity helps the product, such as a team's hot pages; use cosine when relevance to the open page matters most; damp the norm (raise it to a power between 0 and 1) when both matter. Yi et al. (2019) keep dot-product retrieval and correct the frequency bias in training instead.
Text description of the diagram
- Keep the dot product when popularity helps the product.
- Use cosine when relevance to the open page matters most.
- Damp the norm when both matter.
Step 3: Filters run on a longer list than the one you show
The filter stage removes candidates the user must not or need not see, and it must run on a longer list than the one finally displayed. Two filters matter here. An access filter drops pages and issues the user has no permission to open. A seen-page filter drops what the user has already viewed.
Filtering after a short retrieval can empty the list. If you retrieve exactly k items and the user has seen some, fewer than k remain. The fix is to retrieve k plus the seen pages that fall inside the retrieved list, or a safe margin above that, then cut to k after filtering. The worked example below shows the effect in numbers.
Access checks also belong before display, never only in the ranker, because a leaked page title is a data leak even when it ranks last. Archived or duplicate pages are filtered here too. You now have a clean, allowed list ready to be ordered.
Top-k heavy hitters, with seen pages removed
A top-k heavy hitter list holds the k pages with the highest counts in a stream of view events, and a shared feed built on likes, shares and views is one. Count events in a recent window and let older ones decay, so stale pages leave the list. On each shard, keep approximate counts with a Count-Min sketch (Cormode and Muthukrishnan, 2005) plus a min-heap of the best pages, or use the Space-Saving algorithm (Metwally et al., 2005). A central job merges the shard lists into one global list.
Then handle seen pages per user. Over-fetch from the global list by k plus the seen pages inside the retrieved list, not the user's total seen count. Drop the seen ones, and if fewer than k remain, page further down until k unseen pages remain. Hold the seen set as a per-user set or a Bloom filter, a compact structure that can wrongly say "seen" but never wrongly says "new".
Step 4: A ranker orders the survivors and the system serves them
The ranker is a slower, richer model that orders the few hundred filtered candidates for one user. Because only hundreds of items reach it, it can use features retrieval cannot afford: page freshness, how often the page was opened after similar pages, author, and the user's role. A ranker can predict several outcomes at once, such as an open and a long read, which is called multi-task ranking. Covington et al. (2016) describe this two-stage split of candidate generation and ranking for YouTube.
Input: the filtered candidates and the user context. Output: an ordered list, cut to k and served. New pages with no history rely on content similarity until behavior accrues, which is the cold start problem. Judge the system with recall at k (do pages the user later opened appear in the list?), click-through rate and a ranking metric such as normalized discounted cumulative gain, first on held-out history in batch evaluation and then in a live experiment.
Step-by-step description
- The query is the user plus the open page.
- Similar pages are retrieved.
- Restricted and seen pages are dropped.
- The survivors are ordered and served.
- The query is the user plus the open page.
- Candidate generation retrieves similar pages.
- Filters remove pages the user cannot open or has seen.
- A ranker orders the survivors.
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 →Worked example
A toy with three pages shows how the score changes the answer. The query vector is (1.0, 0.0). Page A is (4.0, 3.0), page B is (1.2, 0.5) and page C is (2.0, 0.4); all values are illustrative.1 The dot products are 4.0, 1.2 and 2.0, the cosines are 0.8, 0.923 and 0.981, and the Euclidean distances are 4.243, 0.539 and 1.077.1
| Score | Order, best first | Top page |
|---|---|---|
| Dot product | A, C, B | A |
| Cosine similarity | C, B, A | C |
| Euclidean distance | B, C, A | B |
| Damped dot product (exponent 0.5, illustrative) | A, C, B | A |
Page A has norm 5.0, against 1.3 for B, so it wins the dot product on length rather than direction.1 The damped score with exponent 0.5 lowers A's lead: C scores 1.4 against A's 1.789, a gap of about 1.28 times, where the plain dot product gave 2 times.1 Damping narrows the popularity bonus but here does not reorder the pages.
Now the seen-page filter. Take a popularity list of twelve pages (illustrative), and a user who has viewed the first, second and fourth. A plain top 3 leaves 1 page after filtering, P03.1 Retrieving 6, which is k plus the 3 seen pages inside the list, leaves P03, P05 and P06, a full list of 3.1
Text description of the diagram
- A plain top 3 leaves 1 page after the seen-page filter.
- Retrieving 6 pages leaves a full list of 3.
For scale, assume 2,000,000 daily active users with 10 page views each (illustrative). That is 20,000,000 requests a day, about 231.5 queries per second on average and about 694.4 at three times the average for the peak.1 Storing 5,000,000 page vectors of 64 numbers at 4 bytes each takes 1,280 megabytes before any index overhead.1 Those figures show that scoring every page per request is wasteful, which is why retrieval is a separate stage.
Trade-offs and edge cases
Retrieval choices trade personalization against simplicity and safety. The table lists the main options; the two similarity families come from Google's course, and the remaining judgments are design opinions.
| Option | Strength | Weakness |
|---|---|---|
| Popularity top-k | simple, strong fallback | same list for everyone; needs a seen-page filter |
| Content-based | works for new pages | only finds look-alikes |
| Collaborative | learns what users open together | weak for new pages and users |
| Hybrid | covers both gaps | more parts to maintain |
Edge cases to name. Popularity can dominate unless the score is norm-damped or cosine is used. Permissions change, so cache recommendations briefly and re-check access at display. Jira issues differ from pages: a closed or duplicate issue is rarely a good "next" item, so status becomes a filter or a feature. A new space has no behavior, so lean on content similarity.
Finally, the "next page" can be a loop: recommending only what the user already reads narrows their view, so add some diversity in the ranker. Because recommendations shape later training data, see how recommender feedback loops work. Yi et al. (2019) correct the popularity bias of sampled training batches in retrieval. The same stages appear in a places recommender, People You May Know and food-delivery and e-commerce recommendations.
How to answer it in an interview
Design a system that recommends the next Confluence page a user should view.
I would build three stages. The query is the user plus the open page. Candidate generation retrieves a few hundred pages by embedding similarity, mixing page-to-page and user-to-page scores, and I choose cosine or a damped norm when relevance to the open page should beat popularity. Then filters drop pages the user cannot access or has already seen, so I retrieve more than k first. A ranker orders what is left. I would measure recall at k in batch evaluation, then click-through rate in an experiment, and use content similarity for brand-new pages.
The spoken structure: name the query, retrieve, filter, rank, then say how you measure and what breaks.
Common mistakes
- "Dot product is just similarity." (wrong) The dot product also rewards norm, which tracks popularity. (right) "Dot product also rewards norm, which tracks popularity, so I choose cosine, damping or bias correction on purpose."
- "I return the top k most viewed pages." (wrong) That is the same non-personalized list for everyone, and viewed pages reappear. (right) "Popularity is my fallback, personalized retrieval is the main path."
- "I filter after retrieving exactly k." (wrong) Filters can leave fewer than k results. (right) "I retrieve k plus the seen pages inside the retrieved list, page further if needed, filter, then cut to k."
- "Access control happens in the ranker." (wrong) A page title can leak before ranking matters. (right) "I enforce permissions before anything is shown."
Follow-up questions
How would you design the top Confluence feed from likes, shares and views?
Keep a counter per page for each signal over a recent window, combine them into one score with tuned weights, and let older events decay so stale pages leave the list. The approach is in the top-k heavy hitters section above: approximate counters per shard, merged centrally, then the seen-page filter per user.
How do you keep a top-k heavy hitter list from showing pages the user already viewed?
Keep the global top list shared, but store a small per-user seen set and filter at request time. Take a longer global list than k, as in the worked example, so the filtered list still has k pages.
How would you recommend Jira issues instead of Confluence pages?
The stages stay the same. The query adds project, issue type and links, and status becomes a filter or ranker feature, since closed or duplicate issues are rarely useful. For the wider design see the recommendation system design guide.
What do you do with a brand-new page that has no views yet?
Use its text and space to place it near similar pages and give it a small exploration slot in the ranker. The cold start problem page covers the options.
How would you suggest files to users in a file-storage product?
Reuse the same stages: query from the user and the folder or file open now, retrieval from file similarity and co-use, an access filter, then a ranker. This is a design answer, since candidates report this prompt but no public source describes any company's version.
How do you measure whether the recommendations help?
Check recall at k and a ranking metric on held-out history in batch evaluation, then run a live experiment on click-through rate and on whether users reach what they needed. Optimizing clicks alone can reward clickbait titles, so add a longer-read signal; multi-task ranking, which predicts several outcomes at once, shows how.
- A next-page recommender is retrieval, filters and a ranker, each narrowing the list.
- A dot product also rewards embedding norm, which tracks popularity; keep, damp or remove that effect on purpose.
- Retrieve more than k before the seen-page filter so the final list stays full.
- Enforce access permissions before display, not only in the ranker.
- Treat popularity top-k as a fallback, and use content similarity for new pages.
Sources
- Candidate generation overview (Machine Learning Recommendation course) — Google for Developers, 25 Aug 2025
- Deep Neural Networks for YouTube Recommendations — Google Research (Covington et al., RecSys 2016), 15 Sep 2016
- Sampling-Bias-Corrected Neural Modeling for Large Corpus Item Recommendations — Google Research (Yi et al., RecSys 2019), 16 Sep 2019
- Efficient Computation of Frequent and Top-k Elements in Data Streams (Space-Saving) — Springer, ICDT 2005 (Metwally, Agrawal, El Abbadi), 1 Jan 2005
- An improved data stream summary: the count-min sketch and its applications — Journal of Algorithms (Cormode and Muthukrishnan), 1 Apr 2005
