Articles
Prophet Interview Questions: Changepoints, Holidays, and Future Regressor Leakage
Practice Prophet interview questions with changepoint controls, holiday dates, future regressor leakage, and a time-valid forecast comparison.
A Prophet forecast can look excellent in a notebook and still be impossible to reproduce tomorrow. The notebook may have used actual future weather, revised promotion budgets, or a metric published only after the forecasted day ends.
For Prophet interview questions, the strongest starting point is the forecast issuance time: what information could the system actually have known then? Once that boundary is clear, changepoints, holidays, and additional regressors become modeling choices you can defend with a dated example.
This guide separates official facts from original practice exercises and preparation inferences. It does not use candidate reports or claim that an employer asks these exact questions. Current Prophet documentation also describes newer nested regressor forecasting support; check your installed version before assuming every example uses the same API.
For a related forecasting case, start with Predict Citi Bike Demand at a Specific NYC Station and track the same input-availability boundary.
What should you clarify before fitting Prophet?
Start with the target, sampling frequency, forecast horizon, and decision. Daily completed orders, hourly demand, and weekly revenue are different forecasting contracts. A stockout can suppress completed orders even when demand remains high; a model cannot resolve that target definition by choosing a more flexible trend.
Official fact: Prophet's introductory workflow uses a dataframe with ds for timestamps and y for the target, followed by fitting and prediction. Its component model separates trend, seasonality, and holiday effects. Additional regressors can introduce other explanatory signals. See the quick start and original forecasting paper.
Preparation inference: State the operational contract before discussing hyperparameters. For example: “At midnight, forecast daily orders for the next seven days using the data available at that midnight.” That sentence gives you a test for every proposed input.
Ask whether timestamps represent local business days or UTC aggregation, whether zeros mean no activity or missing ingestion, and how late corrections reach the training table. Define a baseline such as the same weekday last week. If a simple baseline meets the business need, a more complex model needs evidence of better forecasts.
How do changepoint range and prior scale differ?
An interviewer might show a series with a promotion spike and a later persistent growth change, then ask whether both require changepoints.
Official fact: For its usual automatic selection, Prophet places potential changepoints in the first 80% of history by default, with 25 candidates. changepoint_range controls the portion of history searched; changepoint_prior_scale controls the flexibility allowed at candidate changes. The defaults and sparse regularization are explained in trend changepoints.
Explain location and flexibility separately. Increasing the range can let the model consider a recent change. Increasing the prior scale relaxes shrinkage and can make the trend follow more historical variation. Neither operation means a specific date has been proven to cause a permanent business change.
Original practice: A store introduces delivery on August 15 and its daily order growth changes afterward. A three-day September promotion creates a temporary spike. You would investigate the delivery launch as a possible trend change and the promotion as a temporary event. Fitting the promotion with a highly flexible trend can distort the extrapolated slope after it ends.
The answer should include a comparison: hold the holiday specification fixed, vary a small set of range and prior-scale choices, and evaluate at multiple historical issuance dates. Avoid choosing a setting solely because the fitted line hugs the observed history. A cleaner training plot does not establish lower error at the deployment horizon.
For a manual changepoint, explain why that date was available to the modeler at each backtest cutoff. Selecting it after inspecting the entire held-out period introduces a subtler form of hindsight, even if no future target column appears in the training dataframe.
How should holidays and temporary events be represented?
Official fact: Prophet's holiday dataframe names an event and its dates using holiday and ds. Optional lower_window and upper_window extend its effect around the date. Include relevant historical occurrences and the future dates you want modeled. These conventions are documented in holiday effects and regressors.
In an interview, distinguish a calendar fact from a fitted effect. The date of a public holiday can be known in advance; its future sales lift is estimated from history. An announced campaign can be known in advance; its final budget or realized traffic may still be unavailable.
Original practice: A fictional annual sale takes place on November 20. A window from day −1 through day +1 represents November 19, 20, and 21. If the promotion actually lasts five days, ask whether the dates or window should change. Do not silently expand the window until the backtest looks good.
Repeated names pool evidence about the same type of event. Distinct event names may be appropriate when business mechanisms differ, but a one-off event supplies little evidence for estimating a reusable effect. Prophet's handling-shocks guide illustrates treating exceptional periods separately. This is modeling guidance, not proof that every shock belongs in a holiday column.
Aggregation creates another trap. Official fact: In weekly or monthly data, holiday dates need to align with the timestamps representing the aggregated observations; an event on an unrepresented daily date can be missed. See non-daily data. Explain the aggregation convention before moving dates, so a weekly total is not confused with a Sunday-only measurement.
Which future regressors are safe to use?
For the conventional manually supplied regressor workflow, registering a column during training also creates a prediction-time input contract. make_future_dataframe creates dates; it does not invent an approved business plan or retrieve a weather forecast for you.
Official fact: The current generated Prophet API reference documents additional regressor registration before fitting, validation of required inputs, and a newer optional regressor predictor. Its public keyword is regressor_predictor; the narrative regressor guide currently uses different names in its examples. Verify the signature in the installed package instead of copying an inconsistent keyword.
The following ledger is original practice. Assume the forecast is issued on October 1 at 00:00 for October 1–7.
| Proposed input | What exists at issuance? | Available across the horizon? | Safe treatment |
|---|---|---|---|
| Weekday and holiday calendar | Calendar dates | Yes | Generate from dates |
| Planned promotion indicator | Approved September 30 schedule | Yes, if the plan covers all seven days | Use that archived plan version |
| Final promotion spend | Finance closes each day afterward | No | Forecast it, use a documented scenario, or omit it |
| Actual temperature | Observed after the relevant day | No | Use the weather forecast issued before cutoff |
| Weather forecast | Archived September 30 forecast | Possibly | Check horizon coverage and issuance timestamp |
| Realized daily orders | Future target observations | No | Keep them out of prediction inputs |
An archived weather forecast can be an admissible input.
That claim needs a boundary: a weather forecast is usable only if its issuance precedes the sales forecast, its dates match the requested horizon, and the same kind of input will exist in production. Replacing it with retrospectively observed weather changes the experiment.
Official version distinction: The regressor guide describes nested forecasting introduced in v1.4.0. That capability can model an otherwise unknown future regressor rather than require manually supplied future values. Inference: It changes how the input is produced, not the rule against future information. The nested model and its preprocessing must use only the history available at each cutoff. Compare the complete two-stage system against omitting the regressor, including the extra input uncertainty and operational dependency.
Can you detect leakage with a small worked example?
Use this original seven-day fixture, with all values invented for explanation. The observed orders are [100, 110, 120, 130, 140, 150, 160].
| Forecast variant | Predictions for the seven days | Mean absolute error |
|---|---|---|
| Seasonal baseline | 90, 100, 110, 120, 130, 140, 150 | 10 |
| Prophet with issuance-time inputs | 96, 114, 116, 134, 136, 154, 156 | 4 |
| Oracle variant using future actual inputs | 100, 110, 120, 130, 140, 150, 160 | 0 |
These are illustrative outputs, not an executed Prophet benchmark. The second row's absolute errors are all four, so its MAE is four. The oracle row has zero error, but is operationally unavailable under the fixture's input rules. Its accuracy cannot justify deployment.
A seven-day-horizon follow-up is: “What would you change if the weather service supplies only three days?” Do not backfill days four through seven with actual observations. Compare a shorter horizon, another issuance-time source, an explicit fallback model, or scenarios labeled with their assumptions.
For a conventional supplied promotion regressor, the contract might look like this:
import pandas as pd
from prophet import Prophet
# train: historical ds, y, and planned_promo_as_known_then
model = Prophet()
model.add_regressor("planned_promo")
model.fit(train[["ds", "y", "planned_promo"]])
future = pd.DataFrame({"ds": forecast_dates})
# plan_at_issue must contain one row per requested date.
future = future.merge(
plan_at_issue[["ds", "planned_promo"]],
on="ds", how="left", validate="one_to_one"
)
if future["planned_promo"].isna().any():
raise ValueError("Issuance-time promotion plan is incomplete")
forecast = model.predict(future)
This is a contract sketch; the three input objects must be provided. Missing values should not be silently replaced with zero unless zero actually means “no scheduled promotion.” Duplicate dates should fail validation rather than multiply prediction rows. A complete input table is necessary; its source and issuance timestamp determine whether it is legitimate.
What makes the comparison time-valid?
Official fact: Prophet diagnostics provide simulated historical forecast cutoffs and evaluate predictions over a specified horizon. The initial training period should cover the components being modeled. See diagnostics.
Preparation inference: For each cutoff, rebuild the entire information state: target history, archived plans, weather issuance, preprocessing, and any nested regressor model. A time-ordered target split alone does not repair a feature table assembled using future revisions.
Report errors by horizon and by relevant business segment. An average can hide failures on promotion days or the last days of the horizon. Keep model selection cutoffs separate from the final untouched evaluation period. If you repeatedly tune on the same final week, it is no longer a final test.
Do not treat intervals as a guaranteed coverage statement. Official fact: Prophet's uncertainty guidance explains assumptions about future trend changes. Inference: Check empirical interval coverage at the deployment horizon, especially when a future regressor is itself predicted. A nominal interval does not certify the availability or correctness of upstream data.