Phase 1: Requirements & Use Cases
Interviewer: "Design a car rental system. Walk me through your approach."
Candidate: "Sure. Let me restate the problem to confirm scope. I'm thinking of a system like Enterprise or Hertz — one that manages a fleet of vehicles across branch locations, allows customers to make reservations, handles pickup and return, assesses damage, and generates an invoice. I'm designing the object model and core domain logic, not a web API or database schema. Does that match your intent?"
Interviewer: "Yes. Who are the actors?"
Candidate: "I see three actors: a Customer who searches for vehicles, makes reservations, picks up and returns cars; a Rental Agent at a branch who processes physical pickup, inspects returned vehicles, and records damage; and an Admin who manages fleet inventory — adding vehicles, retiring them, setting base rates. The vehicles and branches are domain entities, not actors.
The core use cases I want to cover are:
- Customer searches for available vehicles by location, date range, and vehicle type
- Customer makes a reservation for a vehicle
- Customer picks up a vehicle (rental begins)
- Customer returns a vehicle
- Agent assesses damage and records it
- System generates an invoice with itemized charges
- Admin adds or removes vehicles from a branch"
Interviewer: "What about loyalty points, or cross-branch returns where you pick up in Los Angeles and drop off in San Francisco?"
Candidate: "Good probes. Loyalty points are a rewards subsystem — they'd sit as a separate concern on top of…
In the full tutorial
- Phase 2: Object Modeling
- Phase 3: Class Design & Relationships
- Phase 4: Design Patterns Application
- Phase 5: Key Implementation
- Phase 6: Extensibility & Trade-offs