How do you prevent future leakage in time-series preprocessing?

What's really being asked

This question probes whether you treat temporal causality as a hard constraint rather than a formatting issue. The interviewer wants to know if you understand that in production forecasting the model must predict the future using only information available at the moment of prediction, and that violating this rule produces overfit accuracy that collapses once the model is deployed.

The full answer

A strong response walks through four controls in order. First, lag features must pull from strictly earlier timestamps, meaning a lag of one uses the value at time t minus one and no later. Second, rolling aggregates must use backward-looking windows that end at t minus one, not centered windows that reach into the future, and expanding aggregates must accumulate only from the series start up to the current row. Third, validation must follow a rolling-origin or expanding-window scheme where every training set is older than its corresponding validation set, the forecast horizon is held constant, and the model is retrained at each step without shuffling. Fourth, all preprocessing such as scaling, missing-value imputation, or outlier clipping must be fit exclusively on the training fold of each split and then applied to the validation fold, preventing global statistics from leaking future information.

The mistakes people make

The most damaging mistake is proposing random train-test shuffling or standard k-fold cross-validation, because these methods place future observations into training folds and destroy the temporal ordering that defines the problem. Another frequent error is computing rolling means, target encodings, or global normalization over the entire dataset before splitting, which embeds future values into historical rows. A subtler red flag is fitting a scaler or imputation model on the full time range and transforming every row, or using centered rolling windows that peek ahead by design.

What usually comes next

Interviewers often push deeper by asking how to encode multiple seasonalities without lookahead, for example using calendar-derived Fourier terms or lagged seasonal features that respect the same backward-looking rule. They may also ask how you handle irregular sampling or missing timestamps when constructing lag matrices, or whether purging and embargo techniques from financial machine learning are necessary to avoid residual leakage between overlapping windows.

A concrete example

Imagine forecasting daily sales with a seven-day horizon. Your features include a seven-day lag, a thirty-day backward rolling mean computed from day t minus thirty through t minus one, and an expanding mean of all prior days for that store. For validation, you train through January and predict the first week of February, then expand training through February to predict the first week of March, walking forward without shuffling. At each step you fit a robust scaler on the training block and use its parameters to transform the validation block. If you instead used a centered thirty-day window or fit the scaler on the full year, future sales levels would leak into January and inflate your accuracy.