How the interviewer opens it
“Design the ETA service and live location sharing for a ride hailing app. A rider should be able to see where their driver is and when the driver will arrive.”
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
- Product scope
- Scale
- Update frequency and read:write mix
- Location inputs
- Latency
- ETA accuracy
- Routing and traffic inputs
- Consistency versus availability
- Authorization and lifecycle
- Durability and retention
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Receive driver location updates during an assigned pickup
- Show the assigned driver's latest location to the rider
- Provide and refresh a traffic-aware pickup ETA
- Handle stale locations, reconnects, reassignment, and the end of sharing
Usually out of scope
- Driver matching and dispatch
- Pricing and payments
- Turn-by-turn navigation
- Building map data or collecting traffic observations
- Training a large ETA prediction model from scratch
What interviewers probe
- Turning imperfect GPS into trustworthy progress
- The newest received packet is not necessarily the newest observation, and snapping to the wrong parallel road can make both the map and ETA confidently wrong.
- Fresh, accurate ETA without a route search per fix
- ETA depends on the remaining road path and changing conditions, but route computation at GPS frequency is expensive. A fast response can still be a stale or systematically biased prediction.
- Snapshot-to-stream delivery under reconnects and backpressure
- A rider needs current state, not a reliable replay of every coordinate. Reconnect races and slow sockets can otherwise create gaps, stale playback, and unbounded memory.
- Assignment changes and bounded location access
- Location is sensitive, and permission follows a changing trip assignment. Closing one socket is insufficient when caches, delayed events, and reconnect tokens still contain the old relationship.
Common mistakes
- Spending the interview on driver dispatch instead of the assigned driver's tracking and ETA.
- Treating straight-line distance divided by current speed as an accurate pickup ETA.
- Running full routing on every location sample without estimating the load.
- Ignoring out-of-order data, app restarts, GPS uncertainty, or old samples uploaded after reconnect.
- Conflating client animation and a ticking countdown with fresh measured location and ETA.
- Authorizing only at connection setup and forgetting reassignment, cancellation, cached snapshots, or token reuse.
The bar by level
- Senior (L5/E5)
- Quantifies ingest, connection, and ETA load; separates delivery from routing work; handles ordering across device restarts, map-matching uncertainty, cached-route progress, reconnect races, backpressure, and assignment-version fencing. Gives explicit stale-state and dependency-failure behavior.
- Staff (L6+/E6+)
- Sets measurable freshness, accuracy, and revocation contracts and shows how the design enforces them during partitions. Explains regional ownership and failover fencing, controls routing cost through reuse and coalescing, evaluates ETA quality by cohort and prediction horizon, and makes privacy retention and degraded behavior operationally concrete.