Ride-Sharing Service — OOD Interview Walkthrough

Tier: 4 — Hard Domain: Mobility / On-Demand Transportation Core Patterns: Strategy (pricing), State (trip lifecycle), Observer (notifications), Factory Method (ride types)

---

Phase 1: Requirements & Use Cases

Interviewer: "Design the object-oriented model for a ride-sharing service like Uber or Lyft."

Candidate: "Before I start designing, let me restate the problem to make sure we're aligned. We're building the class-level model for a ride-sharing system — specifically the core domain objects, their responsibilities, and how they interact to fulfill the lifecycle of a ride from request to payment. We're not building infrastructure, not designing APIs, not covering distributed concerns. Does that match your intent?"

Interviewer: "Yes, exactly. Class-level OOD. Go ahead."

Candidate: "Great. Let me identify the actors and use cases first.

Primary Actors:

• Rider — a registered user who requests rides
• Driver — a registered user who accepts and fulfills rides
• System — the dispatcher coordinating matching and lifecycle

Core Use Cases:

1. Rider requests a ride — specifying pickup location, drop-off location, and ride type
2. System matches the request to an available driver
3. Driver accepts or declines the matched request
4. Trip executes — tracking state transitions (en route, picked up, in progress, completed)
5. Fare is calculated and applied to the rider's account at trip completion
6. Riders and drivers receive notifications at key state transitions

I'd also note two out-of-scope items: real-time geolocation matching (requires spatial indexing, not OOD), and payment gateway integration (external service boundary, not domain logic)."

WHY: Geolocation matching is an algorithmic/infrastructure concern. The OOD question is about the…