How the interviewer opens it
“Design a car rental platform. Customers search across rental locations and reserve vehicles for a pickup and return 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
- Fleet and locations
- Traffic and read-to-write ratio
- Vehicle selection
- Rental duration and locations
- Hold deadline
- Vehicle operations and readiness
- Latency
- Consistency and availability
- Durability and history
- Scope limits
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
- Search for available vehicles by location, vehicle class, and rental interval.
- Hold and confirm a reservation without conflicting reservations.
- Cancel a reservation and release its vehicle.
- Account for preparation, maintenance, pickup, and actual return.
Usually out of scope
- Payments, insurance, and dynamic prices.
- One-way rentals and vehicle transfers.
- Vehicle telemetry and repair work.
What interviewers ask about
- Reservation conflicts and durability
- One vehicle can support many future reservations. Concurrent requests and database failures must not create overlapping commitments or erase acknowledged confirmations.
- Hold deadlines
- Expiry, delayed requests, and retries can race. The service needs one acceptance boundary and one durable result.
- Vehicles that are not ready
- A valid schedule does not prove physical readiness. Delays and safety faults can affect both new requests and existing commitments.
- What an available search result means
- Search must remain fast and at most 30 seconds stale. Even a fresh result cannot promise that a later hold will succeed.
Common mistakes
- The design checks only pickup time and ignores the full rental interval plus preparation.
- The design treats search as a reservation or ignores the age of its source data.
- The design protects existing reservations but leaves a vehicle with no reservations open to a race.
- The design uses different expiry rules for confirmation and release.
- The design acknowledges confirmations that one database node failure can erase.
- The design flags delays or faults but still accepts new holds for unavailable vehicles.
The bar by level
- Senior (L5/E5)
- The candidate defines atomic changes across holds, confirmation, expiry, and staff events. They handle duplicate commands, uncertain outcomes, and bounded search freshness. They preserve acknowledged confirmations.
- Staff (L6+/E6+)
- The candidate proves safety across failover and partitions. They order delayed vehicle events correctly. They quantify query cost and contention. They define recovery when physical capacity cannot meet confirmed commitments.