How do you design a places / POI recommender?

In this article

1. Before you start
2. Why interviewers ask this
3. Places recommender design from first principles
4. Worked example
5. Trade-offs and edge cases
6. How to answer it in an interview
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

This page is one part of the recommendation system design guide.

Why interviewers ask this

The prompt appears in several wordings, reported by candidates: a feed of locations, a venue homepage like a review app's landing page, a places-to-visit tool with a category filter, and a version for a user who arrives in a new city. The consequence of a weak answer is a flat one: "train a model on past clicks and sort by distance" misses that a city holds far more places than any model can score per request.

The question separates three things. A weak answer names one model. A strong answer names stages, says what each stage sees, and picks a metric. A Staff-level answer adds what is special about places: location changes by the minute, opening hours change the right answer, and a user in a new city has no history there. Those three points are the ones this page builds toward.

Places recommender design from first principles

POI recommender

A POI recommender is a recommendation system that chooses a short ordered list of real-world places, such as restaurants or museums, for one user at one location and time, using the user's context and history as well as the places' own features.

Candidate generator

A candidate generator is a fast, simple component that nominates a small subset of the full catalogue, such as the places near the user, so that later and slower models only score that subset.

Distance decay

Distance decay is a rule or learned effect that lowers a place's score as its distance from the user grows, so a far place needs much higher relevance than a near one to rank equally.

In plain words

Think of a good local friend asked "where should we eat?" The friend does not weigh every restaurant in the country. They first think of places within walking distance and drop the closed ones. Then they pick the few that suit you. Last, they make sure the suggestions are not three identical pizza shops. The analogy breaks in one place: the friend knows you, while a new app user has left no history, so the system must start from location, time and popularity.

In one precise sentence, a POI recommender narrows a catalogue in stages, so that cheap rules cut the number of places and a more careful model orders the few that remain.

Google's recommendation course describes the general pattern: "One common architecture for recommendation systems consists of the following components: candidate generation, scoring, re-ranking" (Google for Developers, updated 2025-08-25). The same two-stage idea, retrieval then ranking, is described for YouTube by Covington et al. (2016).

Step 1: Nearby is a filter, and relevance does the ranking

Candidate generation starts from a huge corpus and, according to the Google course, "generates a much smaller subset of candidates"; for YouTube it reduces billions of videos to hundreds or thousands. For places, the first cut is geographic: take the user's location, use a grid whose cells are at least as wide as the search radius, take the user's cell plus its eight neighbours, then check the exact distance and keep the places inside the radius. A geohash or S2 cell index does this lookup quickly, and a quadtree adapts the cell size to density (design reasoning, not a sourced figure).

Sorting that set by distance is the common error. Distance answers "can the user reach it?", not "will the user like it?". A tiny shop next door should not beat a loved restaurant a few minutes further. So distance is a hard filter plus one feature for later stages, never the final order.

One generator is not enough. The same course notes that a model may use "multiple candidate generators, each nominating a different subset of candidates" . For places the natural generators are nearby, same category as a requested filter, similar to past visits and popular in the area (this mapping is design reasoning). You now know which places may compete; the next step decides which ones should win.

Step 2: A scoring model ranks the short list for one user

The scoring model sees only the candidate list, so it can afford many features. According to the Google course, it scores and ranks candidates to choose the set, on the order of ten, to display to the user.

Input: one user, one context and about a thousand places. Output: one score per place.

Useful features for places are the user's past visits and clicks, the place's category, rating and review count, its distance from the user now, the time of day and weekday, whether it is open, and how the user's friends or similar users reacted. A pointwise model estimates the chance of a good outcome for each pair; a pairwise or listwise model compares places directly. Because a feed serves several goals, such as clicks, saves and visits, one shared model with several outputs is common; see multi-task ranking.

Distance decay belongs here as a learned feature. A fixed formula such as exponential decay is a good starting point, but a user in a dense city accepts a short walk while a driver in a suburb accepts a trip. Let the model learn that from data. You now have a score for each place.

Step 3: Re-ranking applies the rules a score cannot

Re-ranking is the final pass that reorders or removes scored items using constraints that a single relevance score does not capture. The Google course says it can help ensure diversity and freshness, for example by removing items the user explicitly disliked or boosting fresher content.

For places, the equivalent rules are design choices rather than sourced facts:

• remove places that are closed now or about to close before the user could arrive;
• merge duplicate listings and limit repeats of one chain;
• mix categories so the top ten is not ten coffee shops;
• boost new places so they can collect their first reviews;
• drop places the user already visited recently, unless they are favourites.

Input: ranked list with scores. Output: the final feed. This stage is cheap, easy to change without retraining, and where product rules live. A heavier model that reads the user and the place together can also act here on the short list, see the reranker page for that kind of model.

Step 4: Logged feedback closes the loop

Every shown list is logged with what was shown, in which position, and what the user did. Those logs train the next scoring model and let you evaluate changes. Without the shown list you cannot tell "not clicked" from "never seen".

Two traps follow. First, position bias: a place shown first gets more clicks because it is first, so the position becomes a feature during training and is neutralised at serving. Second, popularity bias: popular places appear in the logs far more often and the model learns to favour them, which starves new places. Popularity also skews the in-batch negatives used to train a retrieval model: popular items are drawn as negatives more often and get over-penalised, and Yi et al. (2019) estimate item frequency from streaming data to correct it; the two-tower model page covers training such a model. For the bias in the logs, reserve a small share of impressions for exploration so new places get seen.

1 · Generate2 · Score3 · Re-rank4 · LogReplay

Step-by-step description

1. Generators nominate nearby candidates.
2. A model ranks the short list.
3. Rules fix variety and opening hours.
4. Impressions and clicks train the next model.

• Candidate generators cut a whole city of places to a short candidate list.
• A scoring model ranks only the candidate list for one user.
• Re-ranking removes closed and duplicate places and mixes categories before the feed.
• Logged impressions and clicks train the next scoring model.

Worked example

Take an illustrative city of 500,000 places over 600 square kilometres, so the average density is 833.3 places per square kilometre.¹ A user searches within 2 kilometres. The circle covers 12.566 square kilometres, so it holds about 10,472 places if they were spread evenly, which real cities are not.¹ A grid needs cells at least as wide as the radius.

With 1 kilometre cells, the user's cell and its eight neighbours reach only 1 kilometre beyond the cell edge, so they would miss part of the circle. With 2 kilometre cells, the 3 by 3 block covers 36 square kilometres and about 30,000 places, and an exact distance check then keeps the 10,472 inside the circle; a 5 by 5 block of 1 kilometre cells covers 25 square kilometres and about 20,833 places.¹

Now apply cheap filters, each with an illustrative pass rate. If 25% of nearby places match the requested category and 60% of those are open, a category filter leaves 2,618 of the 10,472 places and an open-now filter leaves 1,571.¹ The generators and a quota per generator then keep a union of about 1,000 candidates (an illustrative target), and the model shows 10. That is a cut by a factor of 50,000 from corpus to screen.¹

Text description of the diagram

• About 10,472 places lie within 2 km in the illustrative city.
• A category filter leaves 2,618 places and an open-now filter leaves 1,571.

Two more computed examples help the answer. First, distance decay with a scale of 2 kilometres (illustrative) multiplies a score by 0.7788 at 0.5 kilometres, 0.3679 at 2 kilometres and 0.0821 at 5 kilometres.¹ Second, the metric: with 10,000 shown lists (illustrative), design A has a click-through rate (CTR) of 20% and a bounce rate of 50%, giving 1,000 good clicks; design B has a CTR of 12% and a bounce rate of 10%, giving 1,080.¹ Design B wins on good clicks despite fewer clicks, which is why click-through rate paired with bounce rate beats clicks alone.

For ranking quality, normalised discounted cumulative gain (NDCG) is a score from 0 to 1 that rewards putting highly relevant items near the top: it is the discounted cumulative gain (DCG) of the list divided by the DCG of the ideal ordering. The DCG of a list of 10 items is:

Here rᵢ is the graded relevance of the item at position i. A list with graded relevance 3, 2, 3, 0, 1, 2, 0, 0, 1, 0 (illustrative) has a DCG of 14.149, the ideal ordering has 14.952, and the NDCG is 0.9463.¹ Some texts use the linear gain rᵢ instead of 2 to the power rᵢ, minus 1.

Trade-offs and edge cases

Every choice trades coverage against cost. A larger radius or more generators raises the chance that the best place is in the list, but the scoring model scores more places and each request takes longer. A long list helps recall; a short list protects latency. Split a request budget across stages and measure each: an assumed budget of 300 milliseconds might give 50 to retrieval, 120 to scoring, 30 to re-ranking and 100 to everything else (an assumption, not a measured figure).¹

• New city or new user. A visitor has no history in the area. Lean on context (location, time, weekday), popularity within the area, and categories the user liked at home, and learn quickly from the first clicks. See the cold start page for the general methods.
• New place. Content features (category, photos, text) and an exploration quota give it a first chance.
• Density differences. A 2 kilometre radius holds thousands of places downtown and a handful in a village, so use an adaptive radius or cell size that widens until enough candidates are found.
• Time. A place open at noon may be closed at the time the user arrives; filter on arrival time.
• Fresh signals. Open now and the user's current location change by the minute, so read them at request time from a low-latency store instead of baking them into nightly features.
• Traffic and travel time. Real travel time, not straight-line distance, can be a feature. A traffic-data prompt is reported by candidates; treat it as a separate problem unless the interviewer links it to places.

Large language models can also be added to a recommender, for example to describe places or explain a choice; the page on designing large language models (LLMs) inside a recommender covers where they fit.

Four candidate generators cover different gaps, so the union is more reliable than any one of them: nearby, category, similar to past visits and popular in the area. Similar to past visits fails for a new user, so popularity covers that case.

Text description of the diagram

• Nearby, category, similar to past visits and popular in the area are four candidate generators.
• Similar to past visits fails for a new user, so popularity covers that case.

For the full interview frame, see the machine learning system design guide.

How to answer it in an interview

The spoken structure: name the three stages, say what each one sees, then give the cold-start plan and the metric.

Common mistakes

• "I would sort places by distance." (wrong) Distance is a filter and a feature, not a goal. (right) "Distance picks who can compete; a model ranks them by relevance."
• "One model scores every place in the city." (wrong) Scoring the full catalogue per request is too slow; the staged design exists because the scorer only evaluates a small subset. (right) "Cheap generators cut the city to about a thousand, then the model scores those."
• "I will optimise clicks." (wrong) Clickbait raises clicks and bounces. (right) "I pair click-through with bounce rate and add conversion, such as a booking or a visit, as the business metric."
• "Cold start means we cannot recommend." (wrong) Context and popularity still work. (right) "I use location, time and area popularity first, then personalise as signals arrive."
• "Ranking by relevance is enough." (wrong) Closed or duplicate places hurt trust. (right) "Re-ranking handles open hours, diversity and freshness."

Follow-up questions

How would you design the recommendation system for locations in a feed?

Use the same three stages, but the candidate generators also include the user's social and interest signals, since a feed is not a search. Log what was shown, rank for good clicks and save rates, and re-rank for variety and for places that are open.

How do you design a recommender for a user who arrives in a new city?

Drop personal history in that city as a primary signal. Use the user's categories from home, local popularity, time and weekday, and a short exploration phase. The first few clicks give strong signal, so update quickly.

What are we trying to optimise in a venue recommender?

Pick a business outcome, such as bookings or visits, and a user-quality guard, such as click-through paired with bounce rate, so clickbait loses. Then add long-term value, meaning whether the user returns. Before launch, check ranking with NDCG on held-out sessions; after launch, run an experiment.

How would you design the homepage that shows personalised venue suggestions?

Treat the homepage as the feed above, but assume cold start for new users and rank for the opening context (location and time). Fill the slots with session context (the time, the location and what the user just searched), lay out rows by intent such as nearby now and picked for you, and fall back to area popularity until the first clicks arrive.

Is a traffic-data system the same problem as a places recommender?

Not necessarily. Traffic data is mostly a prediction or routing problem; in a places recommender it enters as a travel-time feature. Ask the interviewer what the output is before choosing a design.

Sources

1. Recommendation systems overview: types of recommendation systems — Google for Developers (Machine Learning course), 25 Aug 2025
2. Deep Neural Networks for YouTube Recommendations — Google Research (Covington et al., RecSys 2016), 15 Sep 2016
3. Sampling-Bias-Corrected Neural Modeling for Large Corpus Item Recommendations — Google Research (Yi et al., RecSys 2019), 16 Sep 2019