Controller Algorithm for a Single-Rider Pandemic Elevator

Quick Overview

Design the dispatch logic for an elevator when a pandemic makes riders avoid shared enclosed space. The question tests whether you can rank competing goals such as safety, fairness and waiting time, then turn them into a concrete controller with edge cases and a multi-car extension.

Controller Algorithm for a Single-Rider Pandemic Elevator

Company: Google

Role: Product Manager

Category: System Design

Difficulty: medium

Interview Round: Other

A building has a bank of elevators, and a respiratory pandemic has made people unwilling to share a small enclosed space with strangers. In a product-manager technical round you are asked to design the **control algorithm** for an elevator in that setting: how the controller decides which request to serve next, how the car moves, and how the health concern changes the rules compared with a normal elevator. The discussion is about the dispatch logic, not about building new hardware or redesigning the buttons. ```hint Pick the property that cannot be traded away Before writing any logic, decide which single property the pandemic makes non-negotiable, and work out what that implies for how many requests the car may hold at one time. ``` ### Constraints and Clarifications - Standard controls: every floor has an up call button and a down call button, and the car has a door-open button, a door-close button and one button per floor. - Normal journey: a rider presses a call button, the car arrives, the rider chooses a destination, the car travels there, the rider leaves, and the car moves on to the next job. Your controller decides the order in which riders are served. - Start with one controller driving one car, then discuss how the design extends to several cars. ### Clarifying Questions - Is the goal to maximize safety (limit riders per trip), to minimize waiting, or to balance the two, and which one wins when they conflict? - How many riders may share the car at once, and is that a fixed rule or a configurable parameter? - Should the caller who pressed first always be served first, or may the car collect someone on the way when that is safe? - Can the car tell how many people are inside it, and with what kind of sensor? ### What a Strong Answer Covers - A clear statement of the objective and its priority order, with the safety versus waiting-time trade-off made explicit. - A concrete controller design: the data it keeps, the states the car moves through, and the rule for choosing the next request. - Handling of awkward inputs such as several people at one floor, a destination that contradicts the pressed direction, or more riders than allowed entering the car. - How the design scales from one car to several without breaking its main rule. - How you would judge the design: the metrics you would measure and the cost you accept. ### Follow-up Questions - If the building wants shorter waits, which rule would you relax first, and what would it cost in rider safety? - A rider presses a call button and then takes the stairs. How does the controller notice and avoid wasting a trip? - How would your design change for a very tall building with a heavy morning arrival rush?

Overview: Design the dispatch logic for an elevator when a pandemic makes riders avoid shared enclosed space. The question tests whether you can rank competing goals such as safety, fairness and waiting time, then turn them into a concrete controller with edge cases and a multi-car extension.

Google logo
Google
Oct 15, 2024
mediumProduct ManagerOtherSystem Design
0
0

A building has a bank of elevators, and a respiratory pandemic has made people unwilling to share a small enclosed space with strangers. In a product-manager technical round you are asked to design the control algorithm for an elevator in that setting: how the controller decides which request to serve next, how the car moves, and how the health concern changes the rules compared with a normal elevator.

The discussion is about the dispatch logic, not about building new hardware or redesigning the buttons.

Constraints and Clarifications

  • Standard controls: every floor has an up call button and a down call button, and the car has a door-open button, a door-close button and one button per floor.
  • Normal journey: a rider presses a call button, the car arrives, the rider chooses a destination, the car travels there, the rider leaves, and the car moves on to the next job. Your controller decides the order in which riders are served.
  • Start with one controller driving one car, then discuss how the design extends to several cars.

Clarifying Questions Guidance

  • Is the goal to maximize safety (limit riders per trip), to minimize waiting, or to balance the two, and which one wins when they conflict?
  • How many riders may share the car at once, and is that a fixed rule or a configurable parameter?
  • Should the caller who pressed first always be served first, or may the car collect someone on the way when that is safe?
  • Can the car tell how many people are inside it, and with what kind of sensor?

What a Strong Answer Covers Guidance

  • A clear statement of the objective and its priority order, with the safety versus waiting-time trade-off made explicit.
  • A concrete controller design: the data it keeps, the states the car moves through, and the rule for choosing the next request.
  • Handling of awkward inputs such as several people at one floor, a destination that contradicts the pressed direction, or more riders than allowed entering the car.
  • How the design scales from one car to several without breaking its main rule.
  • How you would judge the design: the metrics you would measure and the cost you accept.

Follow-up Questions Guidance

  • If the building wants shorter waits, which rule would you relax first, and what would it cost in rider safety?
  • A rider presses a call button and then takes the stairs. How does the controller notice and avoid wasting a trip?
  • How would your design change for a very tall building with a heavy morning arrival rush?