Yelp Interview Questions (2026)
1 experiences · 1p3a (1)
Top topics
System Design Interview: Proximity Service (Like Yelp) Experience
Interview Experience
Functional Requirements *
Search: Users can search for nearby places (restaurants, gyms, events) or people based on current location. *
Filtering: Support for filters including distance, category, ratings, open status, and personalized recommendations. *
Place Details: Users can view business information, photos, reviews, and ratings. *
Management: Business owners can add, edit, or claim listings; users can add reviews. *
Bookmarks: Users can save favorite locations.
Non-functional Requirements *
Latency: Millisecond-level search responses. *
Scalability: Support for millions of users and tens of millions of locations. *
Availability: High availability (99.99% uptime). *
Consistency: Eventual consistency is acceptable for new locations, updates, and reviews.
Capacity Estimation *
Traffic: 50M MAU, 10M DAU. Average 5 searches/user/day. Peak QPS ~100,000. *
Volume: 5M reviews/day, 100k new places/day. *
Storage: * 100M listings (~200 GB total). * 1B historical reviews (~1 TB total). * Photos (5 per business) (~100 TB total). * 100M favorites (~5 GB total).
API Design * GET /search?lat&lon&radius&category&open_now:
Returns sorted list of nearby locations. * GET /place/:id: Retrieves specific place details. * POST /review/:placeId/add: Submits a new review. * POST /place/add: Business owners list a new location (name, coordinates, category, photos). * PUT /place/:id/edit: Updates listing details. * POST /place/:id/claim: Verifies ownership of an existing listing.
High-Level Architecture *
Client: Mobile/Web interfaces for searching and management. *
API Gateway: Handles auth, routing, throttling, and monitoring. *
Cache: In-memory storage for hot searches and trending zones. *
Load Balancer: Distributes traffic to app servers. *
App Servers: Business logic for listings, reviews, and search coordination. *
Message Queue (Kafka/Redis): Asynchronous processing for search index updates. *
Database: Persistent storage for user profiles and business data. *
Media Storage: Blob storage/CDN for images. *
Segments Producer: Ingests third-party map data (e.g., Google Maps) and divides the world into segments to narrow search scope. *
QuadTree Servers: Stores spatial indexes of places; finds locations within a radius. *
Aggregators: Collects results from QuadTree servers, ranks them, and returns the final list to the user.
Workflows
Flow-1: Business Listing 1. Owner submits details via /place/add. 2. Listing Service validates data and stores geo-indexed location. 3. Media Service links uploaded photos to the place. 4. Admin Service reviews/approves the listing. 5. Listing becomes searchable upon approval.
Flow-2: Proximity Search 1. User requests /search. 2. Gateway routes to Geospatial Search Service. 3. Search Service queries QuadTree servers for places within the radius. 4. QuadTree servers return candidates to Aggregators. 5. Aggregators filter, rank (proximity + popularity), and return results with metadata.
Flow-3: Review Submission 1. User posts to /review/:placeId/add. 2. Review Service validates, stores review, and updates average rating. 3. Review is displayed after moderation (if flagged).
Flow-4: Media Handling 1. Uploads are stored in object storage via Media Service. 2. Read requests fetch media URLs served via CDN.
**Component
Deep Dive Searching Strategy**
SQL Solution * Stores latitude/longitude in indexed columns. * Uses range queries to find points within a coordinate box. *
Limitation: Inefficient at scale (e.g., 500M places). Independent indexes on lat/lon result in large candidate sets requiring costly intersection operations.
Static Grids * Map is divided into fixed-size grids; each place has a GridID. * Queries search the target grid and its 8 neighbors. *
Limitation: Static grid sizes handle uneven data distribution poorly. Dense areas (e.g., NYC) overload a single grid, while sparse areas (e.g., Pacific Ocean) waste resources.
Dynamic Grids (QuadTree) * A tree structure where each node represents a spatial region. * Nodes subdivide into four quadrants when the number of places exceeds a threshold (e.g., 500). *
Mechanism: *
Leaf Nodes: Hold specific lists of places. *
Root: Covers the whole world. *
Traversal: Search navigates down the tree to the leaf node covering the user's location. *
Neighbors: Leaf nodes are connected via a doubly linked list, allowing expansion of the search radius to neighboring grids without re-traversing the root. *
Memory Efficiency: * 500M places * 12 bytes (ID + coords) ≈ 12 GB. * 1M leaf nodes (500 places per leaf) + internal nodes ≈ negligible overhead. * The entire index fits in the RAM of a modern server (~12 GB).
Ranking Search Results *
Popularity Score: Aggregated from ratings (stored in DB and cached in QuadTree nodes). *
Execution: QuadTree leaf nodes return the top 100 places sorted by popularity within the spatial radius. *
Aggregation: The central aggregator merges lists from relevant leaf nodes to form the final result. *
Updates: Popularity scores in the QuadTree are updated via batch processing (off-peak) to prevent locking and performance degradation during high-traffic reads.
Replication and Fault Tolerance *
Master-Slave Architecture: Writes go to the Master; Reads are distributed to Slaves. Eventual consistency applies. *
Failover: If the Master fails, a Slave is promoted. *
Rebuilding (Reverse Index): * If a QuadTree server fails entirely, rebuilding by scanning the whole DB is too slow. *
Solution: A separate "QuadTree Index Server" maintains a reverse index (ServerID -> Set of PlaceIDs). * When a server is replaced, it queries the Index Server to know exactly which places to load from the DB.
Data Partitioning *
Region-Based Sharding: * Places grouped by zip code/geography. * Pros: Preserves spatial locality. * Cons: Hotspots (e.g., downtown areas) cause uneven server load. *
LocationID Sharding (Hash-Based): * Places distributed uniformly based on hash of LocationID. * Pros: Even load distribution. * Cons: Every search query must be broadcast to all shard servers to find nearby places, increasing network traffic and latency. *
Conclusion: Region-based sharding is generally preferred, using consistent hashing or re-partitioning to handle hotspots.
Topics
Related companies
Yelp Interview Process Overview
The Yelp interview process typically includes a recruiter screen, one to two technical phone screens, and a 4-6 round on-site or virtual on-site loop. Each round serves a distinct calibration purpose: coding rounds measure correctness, code quality, and complexity reasoning; system design rounds measure architectural judgment at the appropriate level; behavioral rounds measure ownership, leadership scope, and collaboration. Reports tagged on LeakCode from 2024-2026 show Yelp runs a calibrated process consistent with industry norms for companies of its tier.
Difficulty calibration: Yelp coding rounds typically run medium difficulty with follow-up depth as the senior discriminator. System design rounds expect production-grade trade-off articulation at L4+ levels. Behavioral rounds expect quantified outcomes ("reduced p99 latency from 800ms to 120ms") rather than vague impact claims. The candidates who advance consistently demonstrate clear thinking out loud rather than perfect final answers.
How To Use Yelp Question Reports
Real candidate-reported interview questions are a calibration tool, not a memorization target. Yelp updates its question pool every 2-4 months; memorizing exact problems risks misleading you when the interviewer uses a variant. The high-leverage approach: identify the patterns that appear repeatedly in Yelp reports, practice those patterns on similar (not identical) problems, and use the reports to understand the interviewer's typical follow-up depth.
Filter the questions above by round type, difficulty, and recency. Focus first on reports from the past 6-12 months; older reports may reference questions that have since rotated out of Yelp's pool. Reports tagged with quantified difficulty and explicit round type are higher-signal than reports without those tags. The metadata filters help you build a focused study plan in 1-2 hours rather than 8-10 hours of unstructured browsing.
Common Yelp Interview Mistakes
Reports tagged "no hire" at Yelp consistently surface a few patterns: jumping into code without clarifying requirements, coding silently for extended periods, missing edge cases (empty input, single element, large input, overflow), producing working code the candidate cannot refactor when probed, and behavioral stories that use "we" instead of "I" diluting individual signal. Strong candidates explicitly avoid these patterns by following a consistent round template.
The single most predictive failure mode in recent reports: not asking clarifying questions. Interviewers are explicitly trained to weight this dimension. Strong candidates ask 3-5 clarifying questions even on problems that look obvious; weak candidates dive into implementation immediately. Strong candidates also verbalize their approach before writing code; weak candidates code in silence and lose the communication dimension of the round's calibration.