Section 1: Near Is a Number You Have to Choose - Problem Understanding & Clarifications

Executive Summary: This section covers the opening minutes of a Staff/Principal interview on a Yelp-style proximity service. We break the prompt into what, who, why and how. We then run a short clarifying exchange in which every answer settles a design decision: near me versus near a named place, list versus map, filters, multi-factor ranking, who owns reviews, freshness, global reach, location privacy, and what is out of scope. Last, we commit the assumptions and meet Sam, whose lunch search runs through the lesson. The lesson to take away: "near" is not a fact about the world. It is a parameter you choose, and much of the design follows from how you choose it.

The interviewer reads you one sentence:

"Design a proximity service like Yelp's nearby search. A user opens the app, types 'ramen' or nothing at all, and sees the best places near them — on a list and on a map — in well under a second, anywhere in the world."

The tempting answer is "store latitude and longitude, find the closest ones, sort by distance." Every word of it breaks at scale. "Closest" ignores that a 5-star place with three reviews should not beat a 4.6-star place with nine hundred. "Find" ignores that a database index on latitude cannot answer a two-dimensional question. And "near" never says how near. So your first move is not a box on the whiteboard.

Decomposing the Prompt

Before asking anything, sort the prompt into four buckets out loud:

• What it does: Turn a location plus optional text and filters into a ranked, paginated list of places, and show the details of any one place. Two read paths, plus a quiet write path: places change, and search must notice.
• Who uses it: People on phones standing somewhere, people on a desktop panning a map of a city they're visiting, business owners editing their hours, and data providers sending bulk feeds. The searchers are many and anonymous. The writers are few and trusted.
• Why it exists: To help someone decide where to go right now. So relevance and "open now" matter as much as distance, and sending someone to a closed restaurant hurts more than a slow page.
• How it's used: Short, bursty sessions with lunch and dinner peaks per time zone. The user's location arrives on every request, and it is sensitive data.

Key Insight: The decomposition already shows you the system's shape. It reads heavily and writes rarely, and the hard part is correctness under geometry: every result really inside the circle, really open, really ranked well. Raw request volume is not the hard part.