The single most useful fact about this discipline, and the one a good candidate will volunteer: on a great many real forecasting problems, a well-configured classical method beats a machine learning model. Not occasionally — routinely, and the result has held up across large public forecasting competitions for years.

An engineer who knows that will save you a quarter. One who arrives intending to apply a neural network to eighteen months of weekly sales data will spend it.

Ask what their baseline was

This is the question, and it is almost diagnostic on its own. Every forecasting problem has a trivial baseline: last period’s value, the same period last year, or a simple average. A serious practitioner establishes that first and reports everything relative to it.

The reason matters. Forecast error is not interpretable in isolation — an error of twelve per cent is excellent for some series and terrible for others — so the only meaningful claim is improvement over the naive answer. A candidate who quotes an accuracy figure without a baseline either does not know this or is hoping you do not.

Follow up by asking how often the fancy approach lost to the baseline. The honest answer is “more often than I expected”, and hearing it is a strong positive signal.

Validation here has a trap that catches clever people

You cannot randomly split time series data. Doing so lets the model learn from the future to predict the past, which produces a wonderful score and a worthless model.

The correct approach is rolling-origin validation: train on everything up to a point, forecast forward, move the point, repeat. Ask them to describe it, and ask how many folds and what horizon. The horizon question is the revealing one, because accuracy at one step ahead and accuracy at twelve steps ahead are different problems, and a model tuned for one is frequently poor at the other.

Then ask what they did about the gap between when data arrives and when the forecast is needed. Real operational forecasting has a lag — you do not have last week’s actuals when you need next month’s plan — and a validation scheme that ignores it is optimistic in a way that only shows up in production.

The parts of the problem that are not modelling at all

  • Hierarchies that must add up. Forecasts by product, by region and in total need to reconcile, because a plan whose parts contradict the whole is unusable to the people receiving it. Ask whether they have done reconciliation; in retail and supply chain it is unavoidable.
  • Intermittent demand. Series that are mostly zeros with occasional spikes break most standard methods, and they are extremely common in spare parts and long-tail inventory. A candidate who has met them will say so.
  • Calendars and events. Holidays, promotions, paydays, school terms, and whatever happened last March. Encoding these well frequently improves a forecast more than changing the model does.
  • Prediction intervals. A point forecast without an uncertainty range is nearly useless for a stocking or staffing decision, because the decision depends on the downside. Anybody who has supplied forecasts to an operational team will raise this unprompted.

Many forecasts, or one? It changes the hire

Ask how many series they have forecast at once, because the engineering differs completely.

A handful of important series — company revenue, headline demand — rewards careful individual attention, domain knowledge and hand-tuning. Fifty thousand series, one per product per store, is an automation problem: you need something that fits acceptably without supervision, fails safely on the weird ones, and can be retrained on a schedule nobody watches.

Those are different jobs. The second is where the global-model approaches earn their keep, because one model trained across many series can borrow strength from the ones with sparse history, and it is also where the ML pipeline engineer skill set starts to matter as much as the statistics.

The conversation with the business, which is half the role

Forecasts are consumed by people making commitments — ordering stock, rostering staff, setting budgets — and they will mostly remember the times the forecast was wrong.

So screen for how they have handled that. Good answers involve communicating uncertainty honestly upfront, agreeing in advance what accuracy is achievable, and resisting pressure to present a single confident number where a range is the truthful answer. Somebody who has been blamed for a forecast will have thought hard about this, and the ability to hold that line is worth more than a small accuracy improvement.

If the role is mostly this conversation, with modelling as support, the data scientist guide describes the hire better.

The question that decides whether a model is worth building

Ask what decision the forecast will change. It sounds like a business question and it is the most technical one available, because it determines the horizon, the granularity and the accuracy that would count as success — and those three settle the whole approach.

A forecast used to place a factory order twelve weeks out needs a twelve-week horizon and does not care about next Tuesday. A forecast used to roster staff needs daily granularity and a fortnight of lead time. A forecast that nobody acts on needs nothing, and should not be built. Candidates who ask this before discussing methods are the ones who will produce something used rather than something admired, and it is a reliable filter in a first conversation.

What it pays, and where the deepest expertise hides

Indicatively £65,000 to £100,000 permanent, with day rates from about £500 and the upper end in energy, retail and financial planning where forecast error has a directly calculable cost.

A note on sourcing: the deepest expertise frequently sits with people from operational research, econometrics or supply chain analytics rather than from a machine learning background. They will not describe themselves in current vocabulary and they will often be better at this than somebody who arrived via deep learning, because the discipline is older than the current toolkit and most of its hard-won lessons predate it.