Design the system that matches a rider request to a nearby driver. What are the hard parts?

What the interviewer is testing

Whether you identify the genuinely difficult parts rather than describing a lookup.

The straightforward part

Drivers report position continuously. Current positions are held in memory, indexed by spatial cell. A request resolves the rider's cell, gathers candidates from that cell and its neighbours, and ranks them.

If the interview stops here it has learned nothing. The hard parts are elsewhere.

The hard parts

Double assignment. Two riders request simultaneously and both are matched to the same driver. This is a global invariant — a driver can accept one trip — so it needs an atomic claim: a conditional write on the driver's state that succeeds for exactly one request. A read-then-write with a check is a race, and at this concurrency it will lose.

Driver rejection and timeout. A driver does not accept. The offer expires, the rider must be rematched, and meanwhile that driver was held unavailable. Every offer is a short-lived reservation with an expiry, not an assignment.

Ranking is not distance. The best match considers estimated time of arrival given traffic and road network — not straight-line distance — plus driver acceptance likelihood, direction of travel, and the effect on remaining supply distribution.

Batching versus immediacy. Assigning greedily as each request arrives is locally optimal and globally poor, because each assignment consumes supply another request needs. Batching over a short window produces better assignments and adds latency for the rider.

Stale positions. A driver's last report may be seconds old, and at speed that is a meaningful distance. Positions carry an age, and confidence decays.

Supply exhaustion. No drivers in range. The system must widen the radius, queue the request, apply pricing pressure, or decline — an explicit policy rather than an empty result.

What a strong answer adds

The failure question: what happens when the matching service is unavailable? The honest answer for this domain is that no fallback produces a good outcome — a rider cannot be matched by a degraded path — so the design effort goes into making it highly available and regionally isolated rather than into a fallback.

That is a legitimate conclusion, and stating it deliberately is better than inventing a fallback that would not work.

Common weak answers

A spatial query over a database with no attention to concurrency. Ignoring rejection and timeout, which is most of the operational complexity.