Why this matters: the elevator problem punishes assumption-holders. Everyone has ridden an elevator, so everyone thinks they know the requirements — and skips the conversation that would have revealed the two facts the whole design hangs on: there are two different kinds of button press, and you don't control the hardware. Candidates who surface both in the first five minutes design a controller; candidates who don't design a simulation of the wrong thing.

The prompt, as given

Design the control software for a bank of elevators in one building.

You own the brains, not the machinery: deciding which car answers which call, and what each car does next. Doors, motors, and sensors belong to another team — assume you receive events from the hardware and issue commands back to it.

People press buttons in hallways and inside cars all day, and the building expects the system to feel fast and fair.

Denser than most prompts — it already gives you the software/hardware split — but the load-bearing details are still missing: what a "call" even is, how many cars, and what "fast and fair" means as an objective you can design against.

The questions, and why each one matters

"What kinds of requests exist?" This is the question. Press a button in the hallway and you've said "floor 7, going down" — a floor plus a direction, with no car chosen yet. Press a button inside a car and you've said "take this car to floor 2" — a destination bound to one specific car. Two request types, with different information and different natural owners. Everything in lesson 02 flows from noticing that; a design that models them as one "request" type has already merged two things the scheduler needs to treat differently.

"How many cars and floors?" Not because the number changes the model, but because it calibrates the engineering. Four cars and twenty floors means a scan over cars is nothing, and pretending otherwise reads as invented sophistication.

"What are we optimizing for?" Don't wait to be told — propose a metric. Average passenger wait time is the natural candidate; a good interviewer will accept it and add a constraint like fairness — no floor waits forever just because it's far from the action. Proposing the metric yourself is a scored signal: schedulers exist to optimize something, and a candidate who doesn't ask what is designing blind.

"Where exactly is the hardware boundary?" The prompt says events in, commands out — pin what that means. In: car arrived at a floor, doors closed, button pressed. Out: move up, move down, stop at next floor, open doors. No physics, no door timing, no acceleration curves. This boundary is a gift; take it explicitly so you never model what you don't own.

"Capacity? Overload sensors? Failures?" Out of scope in the representative set below — but asking draws the boundary consciously, and out-loud scope-setting is exactly the habit the foundations module drilled.

"Is this real-time, or can I drive everything from events?" You want the answer to be events — a discrete stream you can inject in tests, with no wall clock. If the interviewer leaves it open, choose event-driven and say why: a controller you can't unit-test without a real elevator shaft is a controller you can't demo in an interview either.

The requirement set this chapter builds against

Scale         4 cars, 20 floors, one building
Requests      hall call: (floor, direction) — pressed in the hallway
              car call:  (car, destination) — pressed inside a car
Objective     minimize average wait; fairness — no floor starved
Hardware      events in: arrived(car, floor), doorsClosed(car),
                         buttonPressed(...)
              commands out: moveUp / moveDown / stopNext / openDoors
Time          discrete event stream; no wall-clock simulation
Out of scope  capacity & overload, failure handling, door timing

As always: a live interviewer's answers may differ — more cars, a hotel tower with basement levels, an objective that weights energy. The conversation is the skill; a different answer sheet steers the same method to a slightly different controller.