Design Driver Allocation System

Problem Statement: Proactive Driver Positioning

Phase understanding — Ride-sharing marketplaces lose money two ways at once: riders wait (or churn) where there are too few drivers, and drivers burn empty miles cruising where there is no demand. Allocation attacks this proactively — it forecasts demand a few minutes out per geographic cell and nudges idle drivers toward the gaps before requests arrive. That is a distinct problem from dispatch matching, which reactively assigns a specific driver to a specific trip in sub-second time. The interview signal is whether you keep the two separate: allocation shapes supply posture over a 5–15 minute horizon; dispatch optimizes a single trip assignment right now. Conflate them and you get a design that either cannot plan ahead or cannot react fast enough.

Track supply_gap_index_p95, forecast_age_sec, nudge_accept_rate, empty_mile_km_saved, and rider_wait_p90_delta. Page when forecast_age_sec > 180 in a hot cell or when nudge_accept_rate collapses after a model deploy.

Code anchors

Why interviewers care

Allocation is a forecasting-and-incentives problem wearing a distributed-systems costume, and that is what makes it a strong interview: it forces you to reason about stale predictions, driver behavior (nudges are advisory — a driver can ignore one), and the blast radius of a bad model deploy, not just boxes and arrows. Strong candidates name the failure modes (a forecast that lags a sudden surge, a nudge storm that over-corrects a cell) and show how the system degrades safely.

Interview checkpoint

A concrete failure to keep ready: a concert lets out and demand in one H3 cell spikes 5x in two minutes, but the forecast still reflects the pre-surge baseline. Allocation under-nudges, riders wait, surge climbs, and drivers pile in late — overshooting the cell. The fix is a fast-reacting nowcast that blends the model with the last 60–90s of live requests, plus a per-cell nudge cap so the correction does not whipsaw.