Design elevator system
A scheduling problem wearing an OOP costume. Direction is what everyone forgets.
hard · 60 minutes · 7 classes
Requirements
- Several lifts serving a building of N floors.
- Hall calls specify a floor and a direction; car calls specify a destination.
- Dispatch a hall call to one lift under a stated policy.
- Each lift serves requests in a sensible order rather than strictly first-come.
- Model doors, and the states where a lift will and won't accept new stops.
Say these are out of scope
- Weight limits and overload sensors.
- Fire and maintenance modes — mention them, then set them aside.
- Physical acceleration curves; assume constant travel time per floor.
A shape that works
One reasonable decomposition, not the only one. What matters in the round is that you can defend the boundaries you drew.
What they'll push on
Why does a hall call carry a direction?
Because a lift travelling down past floor 5 should not stop for someone who wants to go up — they'd ride the wrong way. Direction is what makes the scheduling non-trivial, and candidates who model a call as just a floor number produce a lift that behaves nothing like a real one.
In what order does one lift serve its stops?
Sweep, not FIFO: continue in the current direction serving every stop on the way, then reverse. It's the disk-scheduling elevator algorithm, which is where the name came from. Strict first-come makes a lift oscillate between the top and bottom of the building.
How do you keep this testable?
Make time a step() you call rather than real elapsed time. The whole system becomes a deterministic simulation you can drive one tick at a time, and the alternative — threads and sleeps — is untestable and will deadlock in front of the interviewer.