Location System Design at Uber, DoorDash, Meta and Amazon

As of 2026-10-18, TrueInterview's bank holds 32 candidate-reported location and ride-hailing design questions from 11 big-tech companies, led by Uber with 8, Amazon and Meta with 7 each, and DoorDash with 6. The four companies do not share one canonical Design Uber prompt: Amazon files 6 of its 7 under maps, ride-hailing and delivery, while DoorDash files only 3 of its 6 there. In one candidate's Uber write-up, the interviewer pushed past the diagram into crash recovery and per-region rules. Our view is that senior rounds turn on those follow-ups, plus stale location handling, more than on the geo-index you pick.

Disclosure: TrueInterview is an interview-preparation product and publishes this article. Facts about other products come from their public pages on the dates listed under Sources.

How do Uber, Amazon, Meta and DoorDash frame location questions differently?

Each company wraps the same geospatial core in a different product. In the bank, the classic family covers prompts such as a driver heatmap, Design Uber and driver pay aggregation, while the minority variants are nearby recommendation and ranking designs and prediction models for delivery risk, courier allocation and dispatch ETAs. Which minority variant appears depends on the company.

Read the table by column; the Best for row is our inference from the reported titles. The location slice is small next to each company's full list, so treat it as one design round you can prepare precisely, not as the whole loop.

• Uber: rehearse the driver heatmap first, then the dispatch core behind Design Uber.
• Amazon: rehearse a tracking pipeline end to end, because the classic family dominates its column.
• Meta: split your time between the ride-sharing design and a nearby ranking design.
• DoorDash: expect the least classic framing of the four, and prepare a recommendation or risk-model variant alongside dispatch.

The same prompts also travel between companies. Design Uber is filed under Uber, DoorDash, Lyft and Snapchat, and Design Driver Location Heatmap under Uber, Amazon and Lyft. Design a ride-sharing system (Uber) was linked from write-ups at Oracle and Meta.

Our take: the ride-hailing template is the floor at all four companies, so learn it once and well. What separates the loops is the second design you rehearse, and the column for your target company tells you which one it should be.

Which location questions do candidates write up most?

Four titles have the most write-up links. Design A Nearby Restaurant Recommendation System and Design Driver Location Heatmap are each linked from 7 candidate write-ups, Design Uber from 6, and Nearby Place Recommendation from 5. Two of those four are recommendation designs, so the classic dispatch prompt is only part of what candidates report.

Write-up links count candidate write-ups that point to a question. They measure what candidates reported, not how often a company asks it. For each of the four, here is where we would expect the push, as our view rather than a reported pattern:

• Design A Nearby Restaurant Recommendation System was linked from DoorDash and Uber write-ups. Treat it as two stages: retrieve candidates by location cell and delivery radius, then rank them. In our view, expect a push on freshness, such as a restaurant that closes or a delivery zone that shrinks after the candidate set is cached.
• Design Driver Location Heatmap is worked through in full below. In our view, the deciding questions are windowed aggregation per cell and what happens to the counts when the stream job fails.
• Design Uber was linked from Uber and Snapchat write-ups. Hello Interview's guide lists strong consistency so that no driver is assigned multiple rides simultaneously, so expect to show how one driver holds one active ride while requests race for the same supply.
• Nearby Place Recommendation was linked from Meta write-ups. Answer it as an ML design: candidate generation by location, a ranking model, and the offline and online metrics you would trust.

Two less-linked titles deserve a look if they match your loop. Design Real-Time Driver Pay Aggregation was linked from 3 DoorDash write-ups, and Uber Eats Search from 2 Uber write-ups.

Which round will you see these in, and how recent are the reports?

Mostly onsite, but not only. Candidates reported 23 of these questions in onsite rounds, 8 in phone screens and 1 in an online assessment, and a question can be reported in more than one round. Of the 23 onsite questions, 18 sit in the maps, ride-hailing and delivery family. The classic design is the onsite default.

Two phone-screen reports show how varied that round can be. Amazon's Perishable-Goods Tracking & Location System was reported in a phone screen last reported in 2026-06. ByteDance's Plan DS approach for biker delivery project was reported in a phone screen in 2025-11. If your recruiter schedules a design phone screen, prepare a compressed version of your tracking design that reaches the data model and one failure mode quickly.

The reports are current. 27 of the 32 questions were last reported within the 12 months before 2026-10-18. Outside the big four, Stripe's Design a Superhero Dispatch System was reported onsite in 2026-06, and OpenAI's Design A Nearby POI Service onsite in 2026-02. Stripe and OpenAI have 3 location questions each in the bank, so treat these as proof that the dispatch core travels, not as a reason to reorganise your plan.

How much time should the geo-index get?

In our view, about five minutes, not twenty. Uber's H3 blog post says the company developed H3 as its grid system for optimizing ride pricing and dispatch. That makes a hierarchical hex grid a sensible default to name, but the index only narrows candidates. In the one detailed Uber write-up cited below, the follow-ups went to failure and regional rules instead.

Know enough to answer two follow-ups on cell size and neighbours. Uber's H3 blog post says H3 supports sixteen resolutions, each finer cell having one seventh the area of the coarser one, and converts a latitude and longitude into a 64-bit cell index. The same Uber post says hexagons have one distance from a cell's centre to every neighbour and minimise quantization error as users move through a city.

The alternatives are square grids. The H3 documentation describes Geohash as a string encoding that forms a hierarchical square grid, a quadtree, and S2 as an open-source hierarchical grid with square cells. The H3 documentation also says its hierarchy gives exact logical containment but only approximate geometric containment, so a parent cell is not a perfect union of its children. If you store points in a relational database, the PostGIS documentation shows the pattern to name: ST_DWithin uses indexes to limit the search list before the exact distance is computed.

Our take: pick one grid, explain cell size, neighbour lookup and why you filter by cell before computing exact distance, then move on. A candidate who spends twenty minutes comparing grids has spent the time the interviewer wanted for failure handling.

Why is ride-hailing matching more than a nearest-driver lookup?

Because the hard requirement is consistency, not proximity. Hello Interview's Uber walkthrough lists strong consistency in ride matching so that no driver is assigned multiple rides at once, next to a target of matching or failing in under a minute. Finding nearby drivers is the easy half.

Hello Interview's guide frames the core as fare estimates, ride requests and matching riders "with a driver who is nearby and available". The same guide lists bursts such as 100k requests from the same location among its non-functional requirements. Uber's H3 blog post says Uber calculates surge pricing by measuring supply and demand in hexagons in each city it serves, which is why surge and heatmap prompts sit next to dispatch.

The decisions we would expect to be pressed on, as our view:

• Single active assignment. Make the driver's state change from available to offered a conditional write that only one matcher can win, with an expiry so a declined or ignored offer releases the driver.
• Hot cells. A stadium or airport puts thousands of requests into one cell. Say how you split that cell's work, or queue requests per cell, rather than letting one partition absorb it.
• Stale location. A driver's position from several seconds ago can put them on the wrong side of a river. Say how old a ping can be before the driver drops out of the candidate set.

Our take: draw the matcher as a small state machine around each driver before you draw a single index. Interviewers can see a geo-index in any walkthrough; they cannot see your concurrency reasoning unless you put it on the board.

How is delivery design different at DoorDash and Amazon?

Delivery adds an order that must stay correct while couriers and estimates move. PracHub's food delivery guide says a strong answer separates durable order state, fast-changing marketplace state and predictive estimates, and it calls aligning several timelines without losing order correctness the hardest part. In ride-hailing the rider waits on one match; in delivery the order, the kitchen and the courier each run on their own clock.

PracHub's guide lists the invariants worth stating aloud: an order has at most one active courier assignment, a courier cannot exceed capacity, and a stale GPS ping or delayed event cannot overwrite newer state. On matching, PracHub's guide is blunt: "The nearest idle courier is not always the best courier." The same guide recommends starting with a weighted score or greedy matcher and discussing bipartite or mixed-integer optimization only after the basic flow works.

Cost control is the other theme. PracHub's guide advises against calling a road-routing service for every restaurant or courier, and recommends recomputing ETA at state changes, route deviation or bounded intervals rather than on every raw ping. Before drawing anything, PracHub's guide suggests asking about scheduled orders, stacked deliveries, substitutions, delivery polygons and courier capacity.

The bank's titles show where the two companies differ. DoorDash's reported prompts include Design Real-Time Driver Pay Aggregation, which sits on the courier side of the marketplace. Amazon's include Perishable-Goods Tracking & Location System, which is a tracking problem first. Each company also has a prediction variant, covered in the ML section below.

Our take: the order-state advice above is general food delivery guidance, not drawn from DoorDash reports. For DoorDash, practise the reported prompts first: aggregating courier pay from a stream of trip events, and retrieving and ranking nearby restaurants, then use the order-state model as background. For Amazon, the reported prompts lean toward tracking and courier allocation, so spend more time on the location event pipeline and less on restaurant-side flows.

Do these companies ask ML versions of location questions?

Yes, often enough to plan for if your role touches ML. Of the 32 questions, 20 are distributed-systems designs, 7 are ML system design, 3 are experiment design and 2 are low-level design. If you interview for an ML-adjacent role, one of your location rehearsals should be an ML design.

The ML titles stay close to the product. The bank's prediction family includes Build a late-delivery risk model at DoorDash, Build a package-allocation model for couriers at Amazon and Design airport dispatch with ETA uncertainty at Uber. The recommendation family includes the nearby restaurant and nearby place prompts covered above.

For any of these, prepare two decisions: how you define the label (late by how much, measured against which promised time) and how the model is served inside a dispatch loop that cannot wait for it. Have a fallback ready for when the model is unavailable, such as a rule-based estimate, because that is the failure question in ML clothing.

What do interviewers push on at senior level?

The detailed evidence here is one Uber report, and the bank does not show company-specific senior follow-ups for DoorDash, Meta or Amazon. One candidate's Medium write-up of a Senior SDE onsite at Uber reports a real-time surge pricing prompt and an interviewer who "didn't let me stay at the high level". Treat it as one person's report; in our view its follow-ups, plus stale location handling, are the ones to rehearse at any of the four companies.

The same candidate's write-up lists the follow-ups in order. The interviewer asked, "What happens if the Flink job crashes mid-calculation?" The candidate reported a follow-up on surge across city boundaries where hexagonal zones overlap different regulatory regions. The candidate reported being pushed further: "How does it know which regulatory rules to apply per hex?" The write-up says the answer, a config per city, was vague, and the candidate felt that was where the round was lost.

The write-up also reports that asking about fallback behaviour on failure drew praise from the interviewer as a good question, and the candidate concludes that "one strong behavioral round can't save a wobbly system design." PracHub's Uber system design page says interviewers evaluate scoping, service decomposition, data models and APIs, scaling and failure modes, and trade-offs such as consistency versus availability.

Build a one-page follow-up sheet for each design you rehearse:

• Crash mid-computation. Checkpoint stream state and make the output idempotent, keyed by cell and time window, so a replay overwrites instead of double counting.
• Late or out-of-order pings. Carry a per-device sequence number or event time, and apply a location update only if it is newer than what is stored.
• Regional rules. Keep a versioned mapping from cell to jurisdiction, decide how a cell on a boundary is assigned, and look up policy from that mapping rather than from a per-city config file.
• Double assignment. Name the single write that makes a driver or courier unavailable, and what happens when two matchers attempt it at once.

What changes at senior and staff level?

The reports skew senior. Write-ups link these questions 34 times from candidates who reported a senior, staff-plus or manager level and 13 times from candidates who reported junior, new-grad or intern levels. Levels are self-reported in the write-ups, so read this as who writes about these prompts.

The most-linked titles skew further. Design Driver Location Heatmap has 6 senior-or-above links out of 7, Design A Nearby Restaurant Recommendation System 6 of 7, and Nearby Place Recommendation all 5. Design Uber has 5 senior-or-above links and 1 junior link.

Our take: at senior level, the expectation shifts from drawing a working system to defending it. Expect to own the scope cut, name the invariant that must never break, and explain why your design degrades the way it does. At staff level, add the organisational view: which team owns the regional policy mapping, and how a change to it reaches the stream job safely.

Down-leveling note: the same Uber candidate's Medium write-up says the design round is where senior candidates are made or broken. In our view, that makes design depth the round to protect if you are worried about level, so spend at least a third of every mock on follow-ups rather than on the first sketch.

Worked example: Design Driver Location Heatmap

Design Driver Location Heatmap was reported at Uber in an onsite, last reported in 2026-05, and is linked from 7 write-ups, 6 of them by senior-or-above candidates. It is a compact way to rehearse the whole geospatial core, because it forces you through ingestion, cell mapping, windowed aggregation and failure in one prompt.

1. Scope it. Ask who reads the heatmap, how fresh it must be and which zoom levels it serves. Put trip history and pricing below the line.
2. Ingest pings. Drivers push location on a timer; the server stamps the time and identity from the session rather than trusting the client.
3. Map each ping to a cell. Uber's H3 blog post describes the mapping from a latitude and longitude to a 64-bit cell index, which gives you a stable partition key.
4. Aggregate per cell and window. Keep each driver's latest cell, so a driver who crosses a boundary moves from one count to the other instead of appearing in both.
5. Serve from aggregates. Precompute counts at the few resolutions the map needs, and say how you roll children up to parents given that the H3 documentation describes geometric containment as approximate.
6. Defend it. Answer the crash, late-ping and boundary questions from the follow-up sheet above. The answer one candidate reported losing on, a config per city, is the one to replace with a cell-to-region mapping.

Practise it at Design Driver Location Heatmap with a timer, and ask a partner to refuse to let you stay high level after the first third of the session.

Common mistakes in ride-hailing and delivery rounds

In our view, most of these mistakes are habits rather than missing components. Hello Interview's Uber walkthrough calls passing userId, timestamps or fare estimates from the client "a red flag" for security understanding, and says timestamps should be generated by the server. The rest are habits you can fix in a week.

• Too many features. Hello Interview's walkthrough advises prioritising the top 3 functional requirements and marking the rest below the line, and says to move on if extra features are not coming quickly.
• Staying at the box level. The Medium candidate's interviewer pushed for depth, and a vague answer is what the candidate reported losing on.
• Nearest equals best. Proximity is a filter, not a dispatch policy, at both ride-hailing and delivery companies.
• Last write wins on location. Without ordering, a delayed ping can move a driver backwards and corrupt every count built on it.

How we counted

We counted questions in TrueInterview's bank that are filed under location, ride-hailing and delivery design, grouped by company, round, design family and the reporting candidate's self-reported level. These are candidate-reported questions reconstructed for practice, not any company's official question list. Counts reflect what candidates reported and wrote up, not how often a company asks a question, and a write-up link is a link from one write-up to one question, not a count of distinct interviews.

FAQ

Is Design Uber still asked?

Yes. Design Uber is linked from candidate write-ups at Uber and Snapchat, and Design a ride-sharing system (Uber) was reported onsite at Oracle in 2026-05. The bank also holds company-specific variants such as a heatmap, a nearby recommendation and a delivery prediction model, so prepare Design Uber first and then add the variant that matches your target company's column in the table above.

How long is the Uber onsite?

One candidate's Medium write-up reports Uber's onsite as 4 to 5 rounds of 60 minutes each, usually spread across two days. That is one person's report, so confirm the structure with your recruiter. For a design round of that length, plan to finish requirements and the high-level design early, because the depth questions on failure and regional rules need the second half of the hour.

How should I design Uber Eats or a food delivery system?

Start from the order state machine, not the map. PracHub's Uber page lists a question on the data flow behind the restaurant list in a food delivery app such as Uber Eats. In TrueInterview's bank, Uber Eats Search is linked from Uber write-ups. Combine the delivery invariants from the section above with location-based restaurant retrieval and ranking, and keep ETA as a separate, frequently wrong estimate rather than part of the order record.

Which geo-index should I use in the interview?

Use the one you can explain under pressure. A hexagonal grid is a natural choice at Uber, a square grid such as geohash works as well if you know it better, and a spatial database index works when the data already lives there. What matters is that you filter by cell or index first and compute exact distance only for survivors. In the detailed Uber write-up discussed above, the follow-ups went to failure and regional policy rather than to the index choice, so do not let the comparison eat your time.

How difficult is the Uber system design interview?

PracHub's Uber page says its system design questions probe real-world, large-scale trade-offs rather than tiny implementation details. In TrueInterview's data, 6 of the 7 write-up links to Design Driver Location Heatmap come from candidates who reported senior or above levels. In our view, the difficulty sits in the follow-ups on crash recovery, ordering of location updates and regional rules, rather than in the first diagram.

Your practice plan

A plan for three weeks while working full time:

1. Week one, two evenings. Learn one hierarchical grid well enough to explain cell size, neighbours and the filter-then-measure pattern, then stop.
2. Week one, weekend. Run Design Uber end to end, with the single-assignment write and the stale-ping rule drawn on the board.
3. Week two, by target company. For Uber or Amazon, do Design Driver Location Heatmap and Perishable-Goods Tracking & Location System. For Meta, add Nearby Place Recommendation. For DoorDash, add Design A Nearby Restaurant Recommendation System and Design Real-Time Driver Pay Aggregation.
4. Week two, one evening. Write the follow-up sheet for each design: crash recovery, late pings, double assignment and regional policy per cell.
5. Week three. Run two timed mocks where your partner refuses to let you stay high level after the first third, and spends the rest on the follow-up sheet.
6. Week three, last evening. If your role touches ML, rehearse one prediction or ranking variant, then browse the candidate interview write-ups for your target company to check the most recent framing.

Sources

• TrueInterview question bank — location and ride-hailing design at big-tech companies — counted 2026-10-18
• Medium — checked 2026-10-18
• Real FAANG Interview Questions by Company · TrueInterview — checked 2026-10-18
• Design a Ride-Sharing Service Like Uber | Hello Interview System Design in a Hurry — checked 2026-10-18
• H3: Uber’s Hexagonal Hierarchical Spatial Index — checked 2026-10-18
• Introduction | H3 — checked 2026-10-18
• ST_DWithin — checked 2026-10-18
• Food Delivery System Design Interview Guide: Dispatch, Geospatial Search, ETAs, and Order State | PracHub Knowledge Hub — checked 2026-10-18
• Uber System Design Questions (Updated 2026) | PracHub — checked 2026-10-18

Last reviewed: 2026-10-18.