Amazon 26NG OOD Interview: Design a Multi-Elevator Dispatch System

Overview

Sharing a July 2026 new-grad OOD round.

Behavioral

• How do you handle an urgent request that jumps the queue?
• Team task allocation and keeping progress aligned.

OOD: multi-elevator dispatch system

The interviewer gave a short description that boiled down to designing a multi-elevator dispatch system supporting:

• Floor requests
• Up / down scheduling
• Stopping at floors
• Overload checks
• Request queue management
• A dispatch-strategy abstraction
• Coordination across multiple elevators

Core classes

Class	Responsibility
Request	One call: floor, direction, whether it's VIP
Elevator	State of one elevator: current floor, direction, load, pending stops
DispatchStrategy	Strategy interface that decides which elevator gets a request
ElevatorController	Manages all elevators and the request queue; dispatching and mode switches

Reference skeleton

import heapq
from abc import ABC, abstractmethod
from dataclasses import dataclass, field
from enum import Enum

class Direction(Enum):
    UP = 1
    DOWN = -1
    IDLE = 0

@dataclass(order=True)
class Request:
    priority: int                     # VIP = 0, normal = 1; lower is served first
    floor: int = field(compare=False)
    direction: Direction = field(compare=False)

class Elevator:
    def __init__(self, eid, capacity_kg):
        self.id, self.capacity_kg = eid, capacity_kg
        self.floor, self.load_kg = 0, 0
        self.direction = Direction.IDLE
        self.stops = set()

    def is_overloaded(self):
        return self.load_kg > self.capacity_kg

    def add_stop(self, floor):
        self.stops.add(floor)

    def step(self):
        """Move one floor per time unit; open the doors when reaching a stop"""
        if self.is_overloaded():
            return                    # overloaded: keep doors open, don't move
        if not self.stops:
            self.direction = Direction.IDLE
            return
        target = min(self.stops, key=lambda f: abs(f - self.floor))
        if target != self.floor:
            self.direction = Direction.UP if target > self.floor else Direction.DOWN
            self.floor += self.direction.value
        self.stops.discard(self.floor)

class DispatchStrategy(ABC):
    @abstractmethod
    def choose(self, elevators, request): ...

class NearestCarStrategy(DispatchStrategy):
    """Pick the closest elevator that is idle or already heading the same way"""
    def choose(self, elevators, request):
        def cost(e):
            on_the_way = e.direction in (Direction.IDLE, request.direction)
            return abs(e.floor - request.floor) + (0 if on_the_way else 100)
        candidates = [e for e in elevators if not e.is_overloaded()]
        return min(candidates, key=cost) if candidates else None

class ElevatorController:
    def __init__(self, elevators, strategy: DispatchStrategy):
        self.elevators, self.strategy = elevators, strategy
        self.pending = []             # priority queue: VIPs dispatched first
        self.fire_mode = False

    def request(self, req: Request):
        if not self.fire_mode:
            heapq.heappush(self.pending, req)

    def set_strategy(self, strategy: DispatchStrategy):
        self.strategy = strategy      # swap strategies for peak hours, etc.

    def enter_fire_mode(self):
        self.fire_mode, self.pending = True, []
        for e in self.elevators:
            e.stops = {0}             # everyone returns to the ground floor; stop taking requests

    def tick(self):
        while self.pending:
            req = self.pending[0]
            car = self.strategy.choose(self.elevators, req)
            if car is None:
                break                 # no elevator available right now; retry next tick
            heapq.heappop(self.pending)
            car.add_stop(req.floor)
        for e in self.elevators:
            e.step()

Design highlights

• Strategy pattern: dispatch algorithms implement DispatchStrategy, so adding a new one doesn't touch the controller.
• Priority queue: requests are dequeued by priority, which naturally supports VIPs.
• Mode switching: fire mode is handled in the controller — clear the queue and send every elevator to the ground floor.

Follow-ups

How would you support these scenarios?

Scenario	Design idea
Peak hours	Add a PeakHourStrategy (e.g. send idle elevators back to the lobby during the morning rush) and switch with set_strategy by time of day
VIP priority	Give Request.priority a higher priority so it's dispatched first; optionally reserve a dedicated elevator for VIPs
Fire mode	Use the State pattern for Normal / Fire modes: on entering fire mode, clear requests, return all elevators to the ground floor, and only accept firefighter commands