Elevator System

Phase 1: Requirements & Use Cases

Interviewer: "Design an elevator system for a multi-story building."

Candidate: "Sure. Let me confirm scope. I'm imagining a system with multiple elevators serving multiple floors — handling button presses from inside the cabin and from floor panels, dispatching the right elevator to each request, and tracking state as elevators move. Does that match?"

Interviewer: "Yes. What clarifying questions do you have?"

Candidate: "A few: How many elevators and floors? I'll design for N elevators and M floors, not hardcoded values. Are all elevators identical — same capacity, same speed — or do we have express elevators? For V1, I'll assume identical cars. Do we need to model the physical door and its open/close timing? I'll model it but keep door timing abstract. Finally — is this real-time dispatch or batch? I'll assume real-time."

Interviewer: "What about emergency stop or overweight detection?"

Candidate: "I'll keep those as explicit state transitions — an elevator can enter an OUT_OF_SERVICE state — but I won't model the hardware sensors. The system responds to an event; it doesn't simulate the sensor."

WHY: Modeling hardware sensors pushes us into embedded/IoT territory. The OOD interview is about the software model — states, dispatch, and class responsibilities.

Interviewer: "What actors interact with this system?"

Candidate: "Three actors: a Passenger (presses floor buttons, selects destinations inside the cabin), a Building Controller (orchestrates all elevators — this is the brains of dispatch), and an Admin (takes an elevator out of service, configures floors). The elevators themselves are actors in the sense…