How the interviewer opens it
“Design surge pricing for a ride-hailing app like Uber. Use live rider demand and driver supply to update local prices, and make sure riders see a consistent price when they request a ride.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- geography and scale
- traffic and read:write mix
- what counts as demand and supply
- pricing geography and product
- latency and freshness
- pricing policy
- consistent price
- availability versus consistency
- durability and retention
- scope boundaries
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Maintain local demand and available-driver supply from live events
- Continuously publish bounded surge multipliers for pickup areas
- Create a fare quote using the current local multiplier
- Honor an unexpired quote when the rider requests the ride
Usually out of scope
- Building dispatch, matching, routing, or the base-fare estimator
- Learning the economically optimal pricing formula
- Payments, billing, and post-trip fare adjustments
- Full-region disaster recovery
What interviewers probe
- Counting people and drivers, not messages
- Heartbeats, movement, retries, and status changes can all corrupt a naive demand/supply counter. A driver crossing an area boundary must stop contributing to the old area without being counted twice in the new one.
- Stable prices from sparse, spatially uneven signals
- A raw demand/supply ratio is unstable with small counts and undefined at zero supply. Sharp area boundaries and feedback from rider or driver behavior can make prices oscillate even when the overall market barely changes.
- A binding quote while the market keeps changing
- The price map is intentionally changing and eventually consistent, but a rider's accepted price must not change. Retries, quote expiry, and the handoff to booking create correctness requirements that the live map cannot satisfy by itself.
- Freshness and failure policy for the published price map
- A price service can remain fast while quietly serving decisions based on stale supply. Recomputing or republishing old inputs makes ordinary cache timestamps look healthy, and out-of-order publications can roll a city back to an older price.
Common mistakes
- Treating telemetry event rates as driver supply or quote refresh rates as independent rider demand.
- Recalculating price at acceptance and silently replacing the fare the rider saw.
- Using a raw demand/supply ratio without handling zero supply, sparse areas, boundaries, or oscillation.
- Confusing processing time with input freshness and serving stale surge indefinitely.
- Focusing on an elaborate pricing model while leaving deduplication, quote expiry, and booking handoff undefined.
- Requiring every quote to synchronously query live driver locations or coordinate across all cities.
The bar by level
- Senior (L5/E5)
- Independently defines signal semantics, entity expiry, area transitions, and replay-safe aggregation. Separates the eventually consistent price map from durable quote acceptance, covers idempotency and booking handoff, and proposes concrete spatial/temporal stabilization and stale-feed behavior.
- Staff (L6+/E6+)
- Establishes explicit invariants and freshness budgets across the full pipeline. Handles partial-feed failures, fenced publisher failover, and quote acceptance races without imposing global coordination. Explains the market-feedback consequences of counting and smoothing choices, distinguishes hard quote guarantees from softer map consistency, and chooses operationally simple regional ownership with clear failure boundaries.