Predicting the Next Elevator Call Location

## Predicting the Next Elevator Call Location You are a data scientist for a building-operations company. To cut resident wait times, the operations team wants to **pre-position idle elevators**: when a car is sitting empty, move it to the floor where the *next* elevator call is most likely to originate, so it is already there (or closer) when someone presses the button. Your task: design a model that predicts **where the next elevator call will come from** — i.e., for a given building at a given moment, which floor the next call is most likely to originate on (and optionally the requested direction/destination), so the dispatcher can stage an idle car there proactively. Walk through how you would build this model: how you frame the problem, what data you need, how you train and evaluate it, and how it plugs into the dispatcher. ```hint Problem framing "Predict the next call location" can be framed several ways. Is it a **classification** problem (which floor, out of N floors, will the next call come from) or could you frame it as an **arrival-rate / intensity** problem per floor (a spatio-temporal point process)? Pick a framing whose output the dispatcher can actually consume, and say why. ``` ```hint The features carry the signal Elevator demand is overwhelmingly driven by **time** and **location** structure: time of day, day of week, the lobby at the morning rush, residential floors in the evening, recent call history, and floor-level attributes (how many residents, is it the lobby, is there a popular amenity). List the data you need and which features actually move the prediction. ``` ```hint Evaluation must reflect the real objective Top-1 accuracy on "exact next floor" is a weak proxy. The dispatcher cares about whether staging the car there **reduced wait time**. Think about ranking metrics (is the true floor in the top-k staged candidates) and, ultimately, an online wait-time test. ``` ### Constraints & Assumptions - The building has a fixed, known set of floors (e.g. a lobby plus $N$ residential floors). - Elevator controllers log every call with originating floor, timestamp, requested direction, and (where available) the destination floor selected inside the car. - Demand is strongly periodic: morning departures from residential floors to the lobby, evening returns from the lobby to residential floors, plus meal-time and weekend patterns. - Predictions must be produced fast enough to act on (sub-second), since the goal is to stage an idle car before the next call. - Multiple cars exist; "stage the idle car at the predicted floor" is the action, but you are only asked to model **where the next call originates**, not the full multi-car dispatch policy. ### Clarifying Questions to Ask - What exactly must the model output — only the originating floor of the next call, or also the direction and destination? What does the dispatcher consume? - What is the prediction horizon and cadence — predict the single next call, or the expected call intensity per floor over the next few minutes? - What logs and attributes are available (per-call floor/direction/destination, floor occupancy, amenity locations, building events)? Is destination reliably logged? - How is success ultimately measured for the business — reduced resident wait time? By how much would justify deploying this? - How many calls per day does a typical building generate (i.e., how much training data per building), and do we model each building separately or share a model across buildings? - Are there special events (holidays, package-delivery surges, move-in days) that the model must be robust to? ### What a Strong Answer Covers - **Problem framing**: a clear, justified choice (multiclass "which floor" classifier vs. per-floor arrival-rate / point-process model) and what the output feeds into. - **Data inventory**: the call logs and floor/time features needed, with awareness of what is and isn't reliably logged (e.g. destination). - **Feature engineering**: cyclical time encodings, recent-history/lag features, floor attributes, and building-level features for cross-building generalization. - **Label definition & leakage**: how a training example and its label are constructed from a stream of calls, and how to avoid using future information. - **Model choice & cold start**: a baseline (historical per-floor-per-timeslot frequency) before a learned model; gradient-boosted trees or a sequence model; and how new/low-data buildings are handled (shared model + building features, or hierarchical/empirical-Bayes shrinkage). - **Evaluation**: offline ranking metrics (top-k hit rate, log-loss/calibration) on a **time-based** split, and the online metric that matters (wait-time reduction via A/B test). - **Productionization**: latency budget, retraining cadence, drift monitoring, and how the prediction is translated into a staging action. ### Follow-up Questions - Your top-1 accuracy is mediocre but top-3 hit rate is high. Given there are multiple idle cars, how does that change what "good enough" means and how you'd use the predictions? - A new building just came online with almost no call history. How do you produce useful predictions on day one, and how does the model improve as data accumulates? - The morning rush is highly predictable but mid-day demand is nearly uniform across floors. How would you make the staging policy aware of its own uncertainty so it doesn't make harmful moves when the model is unsure?