[ ]productinterview
Run a free mock

technical · standard

Design an elevator algorithm

How would you design the elevator algorithm for a 40-story office building with an average of 100 people per floor during a standard 9-to-5 workday?

Updated Jun 2026 Calibrated to the strong-hire bar

This is a verified Google PM interview question (Glassdoor QTN_312552), asked at Microsoft as well. It is not a riddle with one correct answer. It is an optimization problem that tests whether you can enumerate trade-offs, define success metrics, and escalate to the harder question (multi-elevator dispatch) that most candidates miss entirely.

The four algorithms you need to know

You do not need to write code. You need to name these clearly, state the failure mode of each, and commit to a recommendation with a reason.

FCFS (First Come, First Served). Serve requests in the order they arrive. Fair and simple, but causes excessive bouncing: the elevator travels from floor 2 to floor 38 and back to floor 3 because those came in sequence. Throughput collapses at peak hour.

SSTF (Shortest Seek Time First). Always go to the nearest waiting floor next. Minimizes per-trip travel, but creates starvation: a floor at the far end of continuous activity may never be served. A ground-floor user calling at 9:02 AM might wait indefinitely while the car services a cluster of mid-floor requests.

SCAN (the elevator algorithm). Sweep in one direction, serving all requests on the way, then reverse at the building boundary and sweep back. Named “the elevator algorithm” because it mirrors how real elevators work. This is the baseline interviewers expect you to name and recommend as a starting point. It eliminates starvation and caps wait time at roughly two full sweeps.

LOOK. A variant of SCAN that reverses at the last pending request rather than the physical building boundary. If the highest call is floor 32 and the building has 40 floors, LOOK reverses at 32 and saves the unnecessary travel to floors 33-40. Strictly better than SCAN for most real scenarios. This is the single-elevator recommendation.

Structure a strong answer

strong

"Before I pick an algorithm, I want to clarify constraints: how many elevators, what's the target average wait time, are there any special floors (lobby-only, executive, loading dock), and what's the peak concurrent demand? For a 40-story building with 100 people per floor and a standard 9-to-5 schedule, I'd estimate roughly 4,000 people generating roughly 8,000 trips per day, concentrated into three traffic bursts: morning upward rush (ground to upper floors, 8:30-9:30), lunch inter-floor, and evening downward rush (upper floors to ground, 5:00-6:00). My baseline algorithm recommendation for a single elevator is LOOK: it sweeps in one direction and reverses at the last request rather than the building boundary, avoiding both FCFS's bouncing and SSTF's starvation of distant floors. Industry target for average wait time is under 30 seconds. LOOK achieves this in most mid-density scenarios. But the harder and more interesting problem is multi-elevator dispatch: given N elevators, which one responds to a hall call? A good heuristic: assign the elevator already traveling toward the requester's floor in the correct direction; if none qualifies, assign the idle elevator nearest the call; as a fallback, queue the call for the next available car. This is where real system design happens. The 2026 layer I'd add: modern systems like Otis ONE and KONE 24/7 Connected use ML to learn occupancy patterns and pre-position elevators before demand spikes. This cuts average wait times by 20-30% in documented deployments. But ML dispatch introduces model drift risk and opaque failure modes. I'd recommend it only for buildings with stable, recurring traffic patterns and a vendor relationship covering model maintenance. For a residential building with irregular occupancy, classical LOOK wins on simplicity and reliability. One edge case worth flagging: fire evacuation mode. SCAN and LOOK both break down here because optimal scheduling under normal conditions is wrong during an emergency. You need a dedicated evac mode: all cars go to ground, call buttons are ignored. Success metrics I'd track: average wait time (target under 30 seconds), average journey time, system throughput at peak hour, energy consumption, and floor fairness defined as a maximum wait ceiling so no floor is ever starved beyond, say, five minutes."

weak

"I'd make the elevator go to the nearest floor first so it's efficient, then serve everyone in order after that." This conflates SSTF (nearest-first) and FCFS (serve-in-order) without naming either or acknowledging they are different algorithms with different trade-offs. It says nothing about starvation, which is SSTF's fatal flaw. It ignores the multi-elevator dispatch question entirely, which is the harder and more consequential problem in any real building. No metrics. No constraints elicited. The interviewer sees a candidate who has one half-remembered heuristic and no structured way to reason about optimization tension between efficiency and equity.

What Google is actually evaluating

The technical content (knowing SCAN vs LOOK) is table stakes. What separates a strong hire is:

  • Constraint elicitation upfront. Asking about number of elevators, building type, and peak demand reframes the question from a riddle into a parameterized optimization problem. This is how PMs think, not engineers.
  • Trade-off specificity. Naming the failure modes (starvation for SSTF, unnecessary travel for SCAN) rather than just the algorithms.
  • Escalation to the harder problem. Multi-elevator dispatch is where real design happens. Most candidates stop at single-elevator scheduling.
  • Metric definition. Stating a concrete target (average wait under 30 seconds, floor fairness ceiling) shows you know how to define done.
  • Failure mode awareness. Mentioning evacuation mode shows you think about what happens when normal assumptions break.

The 2026 question interviewers may add

“How does ML-based dispatch change your answer?”

Classical LOOK is stateless and deterministic, which makes it auditable and failure-safe. ML dispatch (Otis ONE, thyssenkrupp MAX, KONE 24/7 Connected) learns traffic patterns and pre-positions elevators, cutting average wait times by 20-30% in documented deployments. But it requires training data, introduces model drift risk, and fails opaquely. The PM judgment: ML dispatch is lovable (faster, anticipatory) but viable only in buildings with stable recurring traffic and a vendor relationship that covers model maintenance. In a hospital with unpredictable demand, or a residential building with irregular occupancy, classical LOOK wins. That is a viability argument, not a preference.

Asked at

Related