Elevator System Design: How to Answer It in an Interview

"Design an elevator system" looks like the easiest question on the list. Everyone has used an elevator. There is no database to shard, no billion users, no CDN.

That is exactly why candidates do badly on it. They draw a box labelled "Elevator", a box labelled "Controller", an arrow between them, and run out of things to say after ten minutes. The interesting part of this problem is not the infrastructure. It is scheduling under constraints: deciding which car answers which call, in what order, while keeping everyone's wait short and never doing anything unsafe.

This guide walks through a complete answer, in the order you would give it in an interview.

1. Figure out which interview you are in

The elevator question is asked in two different rounds, and the expected answer is different in each.

• Object-oriented design (low level design): the interviewer wants classes, interfaces, a state machine and probably some code. Scale is irrelevant. Clean responsibilities and extensibility matter.
• System design (high level design): the interviewer wants the control architecture: how a building's cars are coordinated, how dispatch decisions are made, what happens when a component fails. Sometimes it grows into a fleet problem: thousands of buildings sending telemetry to the cloud.

Ask in the first minute: "Should I focus on the object model and scheduling logic, or on the overall control system architecture?" Most interviewers want a bit of both, with emphasis on one. This guide covers both, so you can pick.

2. Requirements

Functional requirements

Pin these down with the interviewer:

• A building with N floors and M elevator cars. Use concrete numbers: say 40 floors and 6 cars, an office building.
• Hall calls: a person on a floor presses Up or Down.
• Car calls: a person inside a car presses a destination floor.
• The system assigns each hall call to a car and moves cars to serve all calls.
• Each car reports its position, direction and door state to floor displays and the car's own panel.
• Operating modes: normal, maintenance (car out of service), and emergency (fire recall, power failure).
• Safety: doors never open while moving, a car never exceeds rated load, an obstructed door reopens.

Good to ask about but usually out of scope: destination dispatch keypads in the lobby, VIP or freight priority, access control (badge required for some floors), and energy optimisation.

Non-functional requirements

• Safety above everything. A slow elevator is a bad experience. An unsafe one is a lawsuit. Safety logic must work even if every other component fails.
• Low average and tail wait time. Elevator engineers measure average waiting time and the share of waits over 60 seconds. A reasonable target for an office is under 30 seconds average.
• Fast decisions. Assigning a hall call should take milliseconds. People notice when the button lights up but nothing happens.
• High availability. If the central dispatcher fails, cars should still move people, just less efficiently.

Rough numbers

You do not need big numbers here, but a quick estimate shows you understand the load:

• 40 floors, about 100 people per floor, so about 4,000 occupants.
• Elevator engineers size offices by five minute handling capacity: the percentage of the population the system can carry in the busiest five minutes. Office buildings typically target around 12 to 15%.
• 13% of 4,000 is 520 people in 5 minutes, about 1.7 people per second arriving at the lobby in the morning peak.
• That is a few hall calls per second at most. This system is not throughput bound. It is latency and correctness bound, which tells the interviewer you will spend your time on scheduling, not on scaling.

3. Core entities

Whatever round you are in, sketch the model early. It anchors the rest of the discussion.

The most important design decision in this table is the split between CarController and Dispatcher. A car controller owns everything about one car, including all of its safety logic. The dispatcher only decides which car should take a hall call. It never moves a motor or opens a door. That split is what lets the building keep working when the dispatcher fails.

4. The car state machine

Every car is a state machine. Drawing it is the fastest way to show the interviewer you have thought about safety.

States:

• Idle: stopped, doors closed, no pending stops.
• Moving up / Moving down: doors locked closed.
• Doors opening, Doors open, Doors closing: only reachable when the car is stopped level with a floor.
• Out of service: maintenance or a fault. Hall calls are never assigned to it.
• Emergency recall: fire service mode, described below.

The invariants worth saying out loud:

1. The motor can only be commanded when the doors are confirmed closed and locked.
2. The doors can only open when the car is stopped and level with a floor.
3. If the door obstruction sensor fires while closing, go back to Doors opening.
4. If the load sensor reports overload, the doors stay open and the car does not leave.

In code, the transitions are a small table, and the safety checks live in the car controller, not the dispatcher:

1from enum import Enum, auto
2
3class State(Enum):
4    IDLE = auto()
5    MOVING_UP = auto()
6    MOVING_DOWN = auto()
7    DOORS_OPENING = auto()
8    DOORS_OPEN = auto()
9    DOORS_CLOSING = auto()
10    OUT_OF_SERVICE = auto()
11
12class CarController:
13    def __init__(self, car):
14        self.car = car
15        self.state = State.IDLE
16
17    def start_moving(self, direction):
18        if self.state not in (State.IDLE, State.DOORS_CLOSING):
19            raise IllegalTransition(self.state, direction)
20        if not self.car.door.locked_closed():
21            raise SafetyInterlock("doors not locked")
22        if self.car.load_kg > self.car.rated_load_kg:
23            raise SafetyInterlock("overload")
24        self.state = State.MOVING_UP if direction > 0 else State.MOVING_DOWN
25        self.car.motor.run(direction)
26
27    def on_door_obstructed(self):
28        if self.state == State.DOORS_CLOSING:
29            self.state = State.DOORS_OPENING
30            self.car.door.open()

In a real elevator these interlocks are also enforced in hardware, below the software, by the safety circuit. Mentioning that the software is not the last line of defence is a good senior signal.

5. Scheduling one car: SCAN and LOOK

Start with one car before you add more. Given a set of pending stops, in what order should the car visit them?

First come, first served visits stops in the order they were pressed. It is simple and terrible: a car at floor 10 with requests for 30, 11 and 29 goes 10, 30, 11, 29, crossing the building three times.

Shortest seek first always goes to the nearest stop. It is efficient on average but can starve someone: if people keep calling from floors 5 to 8, a person waiting on floor 35 may never be served.

SCAN, which disk schedulers literally call "the elevator algorithm", keeps moving in one direction, serving every stop on the way, until it reaches the end of the building, then reverses. No starvation, and the number of reversals is minimal.

LOOK is SCAN with one fix: reverse when there are no more stops ahead, rather than travelling all the way to the top or bottom floor. This is what real elevators do and the answer you want to give.

1def next_stop(car):
2    ahead = [f for f in car.stops if (f - car.floor) * car.direction > 0]
3    if ahead:
4        # keep going in the current direction, nearest stop first
5        return min(ahead, key=lambda f: abs(f - car.floor))
6    if car.stops:
7        # nothing ahead: reverse (LOOK)
8        car.direction = -car.direction
9        return min(car.stops, key=lambda f: abs(f - car.floor))
10    car.direction = 0
11    return None  # idle

One subtlety interviewers like: a hall call has a direction. A car moving up past floor 12 should stop for an Up call on 12, but not for a Down call on 12. That Down caller would ride up to the top and back. The car should only take it on the way down. So pending stops are really (floor, direction) pairs for hall calls and plain floors for car calls.

6. Scheduling many cars: the dispatcher

With six cars, every hall call raises a new question: which car?

Nearest car (the naive answer)

Assign the call to the car physically closest to the floor. This fails in obvious ways. The closest car may be moving away, full, or already carrying ten stops. Say this, then improve it.

Cost-based assignment (the answer to give)

For each candidate car, estimate the cost of adding this call, and pick the cheapest. A good cost estimate is the time until the car would reach the caller, accounting for everything it has already promised to do:

1FLOOR_TIME_S = 1.5   # time to travel one floor at speed
2STOP_TIME_S = 10.0   # decelerate, doors open, people move, doors close, accelerate
3
4def estimated_time_to_arrival(car, call):
5    stops_before = car.stops_on_route_to(call.floor, call.direction)
6    floors = car.route_distance_to(call.floor, call.direction)
7    return floors * FLOOR_TIME_S + len(stops_before) * STOP_TIME_S
8
9def cost(car, call):
10    if car.state == State.OUT_OF_SERVICE or car.is_full():
11        return float("inf")
12    eta = estimated_time_to_arrival(car, call)
13    # penalise delay added to people already riding or already assigned
14    added_delay = car.extra_delay_if_stopping_at(call.floor)
15    return eta + 0.5 * added_delay

route_distance_to is where LOOK matters. A car heading away from the caller has to finish its run and reverse first, so its distance is longer than the raw floor difference.

The second term is the one candidates forget. Stopping a full express run at floor 7 to pick up one person costs everyone already inside. Weighting existing passengers' extra delay is how real group controllers avoid making one person's wait shorter by making ten people's rides longer.

Reassignment

Conditions change after assignment. A car gets stuck behind a held door, a closer car becomes idle. The dispatcher should re-run the assignment periodically for calls that have not been served yet, and move a call when another car becomes clearly cheaper. Keep a hysteresis margin (switch only if the new car is several seconds better) so calls do not flip between cars every second.

Traffic patterns

A strong answer notices that the best strategy depends on the time of day:

• Morning up peak: almost everyone starts at the lobby. Send idle cars back to the lobby, and consider zoning: cars 1 to 3 serve floors 2 to 20, cars 4 to 6 serve floors 21 to 40. Fewer stops per trip means more round trips per hour.
• Evening down peak: the reverse. Park idle cars higher up.
• Midday interfloor traffic: spread idle cars across the building.

The dispatcher can detect the pattern from recent call history and switch strategy.

Destination dispatch

Many modern buildings replace Up and Down buttons with a keypad in the lobby where you enter your floor, and the screen tells you which car to take. Because the dispatcher knows destinations before people board, it can group people going to nearby floors into the same car. Each car makes fewer stops, and handling capacity rises substantially during peaks.

This is a good extension to mention if you have time: it changes the input from (floor, direction) to (floor, destination), and the cost function now optimises groups instead of single calls.

7. Architecture

Here is how the pieces fit together in one building.

• Hall call panels on each floor publish calls to the dispatcher and light the button when the call is accepted.
• The dispatcher keeps the set of unserved hall calls and each car's reported state, computes costs, and sends an assignment to one car.
• Each car controller runs LOOK over its own stops (assigned hall calls plus car calls from its own panel), drives the motor and doors, and enforces safety.
• Cars publish state (floor, direction, doors, load, stops) a few times per second. The dispatcher and the floor displays subscribe.
• A monitoring service records events for maintenance and analytics. It is never in the control path.

Concurrency

Calls arrive concurrently from many floors and cars, so be explicit about where the races are:

• Two cars answering one hall call. Prevent it by making the dispatcher the single writer of assignments. One call has exactly one owner car at a time, and reassignment is an explicit handover.
• State updates racing with decisions. Each car controller processes its events (sensor readings, new stops, assignments) on a single-threaded event loop. No locks around car state, no partial updates.
• A car call for a floor the car just passed. It is just another stop. LOOK serves it on the way back.

8. Failure handling and special modes

This section is where senior candidates separate themselves.

Dispatcher failure. Run a standby dispatcher with the same input stream. If both fail, car controllers fall back to local collective mode: every car answers hall calls on its own using LOOK. Service gets worse (cars may duplicate effort), but people still move. The safety logic is local to each car, so it is unaffected.

Car fault. A car that detects a fault (door will not lock, motor current out of range, levelling error) moves to Out of service, reports it, and the dispatcher reassigns its pending hall calls. Passengers inside get taken to the nearest floor if it is safe to move.

Lost connection between a car and the dispatcher. The car keeps serving the stops it already has. The dispatcher marks it stale after a few missed heartbeats and stops assigning new calls to it.

Fire recall. When the fire alarm triggers, all cars cancel their stops, return to a designated recall floor (usually the lobby, or an alternate floor if the fire is on the lobby), open their doors and stop responding to normal calls. Firefighters then operate cars manually with a key. This is a regulated behaviour in most countries, and mentioning it shows domain awareness.

Power failure. Emergency power usually lets cars move one at a time to the nearest floor and open their doors. The controller needs a plan for which car goes first.

Door obstruction and overload. Covered by the state machine: reopen on obstruction, refuse to depart on overload.

9. The fleet version

Some interviewers turn this into a distributed systems question halfway through: "Now your company runs elevators in 50,000 buildings. Design the system that monitors them."

The control loop stays local in every building. Never put the cloud in the path of opening a door. What moves to the cloud is telemetry:

• Each building's gateway batches events (trips, door cycles, faults, motor readings) and sends them upstream, buffering locally when offline.
• Rough numbers: 50,000 buildings times 6 cars times one event every few seconds is in the order of 100,000 events per second. That is a job for a partitioned log such as Kafka, keyed by building, feeding a time series store.
• On top of that: dashboards per building, alerting on faults, and predictive maintenance models (for example, door motors whose closing time is drifting upward).

This is the same shape as a metrics monitoring system, which is a separate classic interview question.

10. What the interviewer is listening for

11. Common mistakes

• Treating it as a scaling problem. Load balancers and sharded databases have no place in a single building's control loop. Say early that the load is tiny and the hard part is scheduling.
• One giant controller class. Mixing dispatch, motor control and door safety in one class makes the failure story impossible to tell.
• Ignoring hall call direction. Picking up a Down caller on the way up is the most common logic bug.
• No time estimates. "Closest car" without a notion of stop time and current direction gives poor assignments.
• Forgetting the people already inside. Minimising the caller's wait at any cost makes everyone else's ride longer.

Practise it

Reading a full answer makes the problem feel easy. Writing one under a timer is a different experience. Try both versions on Codemia:

• Design an Elevator System (system design): the control architecture, dispatch and failure handling. Your answer gets AI feedback against the problem's rubric.
• Design an Elevator System (object-oriented design): classes, the state machine and scheduling logic.

If you want more problems in the same family, try designing a parking lot or a vending machine, both of which reward the same habits: a clear state machine and clean ownership of responsibilities.