An interviewer says - finance needs a twelve-month cloud forecast to size the next commitment, and engineering refuses to give a number because the roadmap is uncertain. Walk me through producing a forecast that is honest and still useful.

What the interviewer is testing

Whether you can convert "we do not know" into something a treasury team can act on. The weak candidate either invents a growth percentage or refuses. The forecast finance actually needs is not a single number; it is the floor they can safely buy against, plus a range above it and the named events that would move it.

The clarifying questions that change the answer

• What is the commitment instrument, and what does breaking it cost? A spend commitment you can grow into differs from a reservation tied to one instance family.
• What is the shape of the current bill: how much is steady floor, how much tracks traffic, and how much is project-driven?
• Which migrations, launches and decommissions are already funded? Those are the step changes, and engineering knows them.
• What is the penalty for under-committing versus over-committing? Under-committing leaves discount on the table; over-committing is payable whether used or not.

A strong answer's arc

Decompose the bill into three populations and forecast each differently.

1. The floor. Take the lowest hour of each month over the last twelve months. That is capacity you are certain to use. It is forecastable to within a few percent because it is what runs in production at 04:00 on a Sunday.
2. The traffic-driven layer. Model it as cost per driver unit times forecast volume: cost per order, per stream-hour, per thousand requests. Carry the forecast as a range from the product team's own low and high cases.
3. The step changes. A list, not a curve: each named change with a date, a direction and a size. "Log pipeline migration lands in Q2 and removes about $40k a month." These are the parts marked uncertain, and the list is short enough to review monthly.

Then commit to the floor, not the forecast. Choose the commitment size from the floor: if the floor is 55% of current average spend, buy a commitment covering roughly that, and buy the next tranche only when the floor itself has risen. A workload with a 2:1 daily peak-to-trough ratio plus growth typically has a trough at 50% to 70% of average, which is why blanket 100% coverage proposals turn into shortfall payments.

Common weak answers

• "Last year grew 30%, so forecast 30%." Growth is the output of a driver model, not an input. Extrapolating a blended total hides a mix shift that is already visible in the per-driver numbers.
• "We cannot forecast, so commit nothing." You forfeit a discount on the one part of the bill that is genuinely predictable.
• A single number with no range. It becomes a target, then a budget, and the first overrun costs the forecaster their credibility for the next three years. This is the failure mode that ends most forecasting practices: not a wrong number, but a number presented without its uncertainty and then treated as a promise.

What a strong answer adds

Two things. State a commitment term no longer than the horizon over which the architecture and the driver are predictable within roughly plus or minus 15% — usually twelve months for a product under active change, and three years only for the boring floor. And publish the forecast error every month: modelled versus actual, per driver. A model nobody back-tests gets quietly ignored, and the next negotiation reverts to a growth percentage invented in a meeting.