Delivery ETAs are computed by a model using live traffic and restaurant load. The model's features are computed in batch overnight. What is wrong?

What the interviewer is testing

Whether you recognise a feature freshness mismatch and the training-serving skew that usually accompanies it.

What is wrong

Features describing current conditions are computed from yesterday's data.

"Restaurant load" computed overnight tells you how busy the restaurant was yesterday, not whether it has a twenty-order backlog right now. "Live traffic" computed in batch is a contradiction. The model is being fed inputs that do not describe the situation it is predicting.

The ETA will be systematically wrong in exactly the conditions where accuracy matters most — a restaurant that is unusually busy, a road that is unusually congested.

The fix

Split features by required freshness, because they are not homogeneous:

Real-time — current restaurant queue depth, current traffic on the route, drivers currently available nearby. Computed in a streaming path with seconds of latency.

Near-real-time — the restaurant's preparation time over the last hour. Micro-batch, minutes.

Batch — the restaurant's historical average preparation time by hour of day and day of week, the route's typical duration. Genuinely stable, overnight is fine.

A serving layer assembles all three at inference time.

The harder problem this exposes

Training-serving skew. Training features are computed in batch over complete history, with the whole timeline available. Serving features are computed incrementally, with only the past available. If the two computations differ in any detail — a window boundary, null handling, a definition — the model sees different distributions in production than in training, and accuracy degrades in a way that is very hard to diagnose because nothing is broken.

The remedy is defining the feature once and computing both paths from that definition, which is what a feature store provides.

What a strong answer adds

Point-in-time correct retrieval for training: a training row must see feature values as they were at the moment of the labelled event, not as they are now. Getting this wrong produces label leakage — the model learns from information that did not exist yet — and it looks superb offline and fails on contact.

Common weak answers

Running the batch job more frequently, which does not make a batch feature real-time. Retraining the model, which does not address the input mismatch.