Elevator System – Low Level Design Interview Practice
Practise the Elevator System low level design problem the way an LLD round actually runs. You are asked for requirements first, then a class model, and then to extend the design when a new requirement lands part way through – the follow-up that separates a design that was memorised from one that was understood.
The round checks the things interviewers grade: whether your classes carry single responsibilities, whether you reached for a design pattern or reinvented one, whether the design absorbs a new requirement without rewriting what exists, and whether you can explain a trade-off out loud. Feedback covers class modelling, SOLID principles, use of patterns, extensibility and communication.
What this question is really testing
Scheduling. Anyone can model a Lift class; the round turns on how a request is assigned to a car and on keeping that policy swappable.
Requirements to establish first
- Serve requests from inside a car (a destination) and from a floor (a direction), which are not the same request type.
- Dispatch N cars across M floors, picking the car that answers a hall call best.
- Move a car through its stops in one direction before reversing, rather than in arrival order.
- Expose each car's state: idle, moving up, moving down, doors open, out of service.
- Handle a request arriving for a floor a moving car has not yet passed.
Core classes
- ElevatorCar – Owns one car's current floor, direction and stop set. Knows how to move, not whom to serve.
- Request – Split into InternalRequest (floor) and ExternalRequest (floor plus direction) - they carry different information.
- ElevatorController – Receives every request and hands it to a car. The single place assignment happens.
- DispatchStrategy – The assignment rule itself: nearest car, least busy, or scan/LOOK.
- Display / DoorState – Observers of a car, so the car does not know what is rendering it.
Design patterns that apply
- Strategy – Dispatch policy changes per building - an office tower at 9am wants a different rule than a hospital. Hard-coding "nearest car" is the mistake this pattern exists to prevent.
- State – A car's legal actions depend on what it is doing. Doors cannot open while moving. State makes that a compile-time shape rather than a tree of if-statements.
- Observer – Displays, logs and door controllers all react to a car arriving, and the car should not hold references to any of them.
Follow-up questions to expect
- Add express cars that only serve floors above 20. Does your dispatcher need rewriting, or does it become one more Strategy?
- A car goes out of service mid-journey. What happens to the requests already assigned to it?
- Two cars are equally good for a hall call. How do you break the tie, and is that decision in the controller or the strategy?
Where candidates lose marks
- Putting the dispatch logic inside ElevatorCar, so every car decides for itself and two cars answer the same call.
- Modelling internal and external requests as one class with a nullable direction field.
- Treating the stop set as a queue. A lift serves floors in travel order, not arrival order.