How the interviewer opens it
“Design a service that computes driving routes across a large road network. It must support road restrictions, alternative routes, and changes in travel time.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Road network
- Query load and read:write mix
- Latency
- Route choices
- Road restrictions
- Travel cost meaning
- Freshness and availability
- Closure source progress
- Map changes and durability
- Inputs and exclusions
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Find the fastest legal route between two coordinates
- Enforce road directions, turn restrictions, access rules, and closures
- Return up to two useful alternative routes
- Apply travel cost changes without interrupting route queries
Usually out of scope
- Collect traffic data or create road maps
- Predict traffic for future departure times
- Track a vehicle during navigation
- Support public transport or delivery stop order
What interviewers ask about
- Routes across a continent
- A long route can require searches across millions of roads. Query work must remain small enough to meet the latency target at peak demand.
- Legal road routes
- Legal roads do not always form a legal route. Turn restrictions depend on the road that the vehicle used to enter a junction.
- Changes in road conditions
- A request needs one coherent view of road costs. A newer worker version does not make an older request's closure coverage current.
- Useful alternative routes
- Many distinct paths differ by only one short detour. Exhaustive path enumeration costs too much and does not guarantee useful choices.
Common mistakes
- Uses full graph search at peak load without estimating its CPU cost
- Reads each road from a remote database during search
- Ignores the incoming road when enforcing turn restrictions
- Changes segment costs without repairing dependent shortcuts
- Returns nearly identical paths as alternative routes
- Uses closure event times as proof of freshness. Checks the worker's latest version instead of the request's pinned version.
The bar by level
- Senior (L5/E5)
- Separates map preparation from query work. Designs coherent cost versions, shortcut repair, graph replicas, and bounded alternative search. Checks the responding request's pinned closure coverage. Estimates CPU and memory demand.
- Staff (L6+/E6+)
- Defines source coverage contracts and safe behavior during feed failures. Proves that version publication cannot mask stale coverage in an active request. Designs map transitions and recovery. Quantifies freshness limits and their availability cost.