How the interviewer opens it
“Design a service that finds journeys across buses, trains, and walks. The service must combine published schedules with service disruptions and live vehicle updates.”
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
- Coverage and schedule size
- Search traffic
- Live updates and read:write mix
- Journey choices
- Source data
- Latency and update delay
- Availability and correctness
- Durability
- Walks and transfers
- Scope 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 journeys between two locations for a requested departure time
- Return useful choices across buses, trains, and walks
- Apply live delays, cancellations, and closures
- Show journey times, transfer details, and data freshness
Usually out of scope
- Fare calculation and ticket sales
- Vehicle dispatch and schedule creation
- Arrival predictions from raw GPS data
- A new pedestrian map service
What interviewers ask about
- Journey choices and search time
- The best journey depends on departure time and user preferences. Many possible transfers can make a general search too expensive.
- Service changes during a search
- A delay can remove one connection and create another. Updates can arrive late, conflict, or refer to a different schedule version.
- Walks and transfers
- Nearby stops can lack a legal pedestrian path. Valid transfers depend on station layout, access rules, and the time between vehicles.
Common mistakes
- Candidates use static shortest paths without departure times or service calendars.
- Candidates apply delays only after the service selects a journey.
- Candidates treat nearby coordinates as proof of a valid pedestrian connection.
- Candidates ignore service dates, times beyond midnight, or agency time zones.
- Candidates let older updates restore cancelled trips.
- Candidates return cached journeys without checking cancellations and transfer feasibility.
The bar by level
- Senior (L5/E5)
- The candidate selects a timetable algorithm and bounds its cost. The design handles service dates, update order, stale predictions, and coherent versions. The candidate explains pedestrian transfer checks.
- Staff (L6+/E6+)
- The candidate defines feed contracts and publication boundaries. The design isolates agency failures and supports restart recovery. The candidate quantifies memory, CPU, and update delay. The candidate explains correctness limits when agencies supply stale data.