An interviewer gives you this. "We have 400 engineers and 9 on the platform team. The CTO just approved 20 more platform engineers for next year. Tell me how you would spend them and how you would know in twelve months whether it worked."

What the interviewer is testing

Whether you treat headcount as capacity or as a commitment. Twenty engineers is not twenty units of output: it is twenty engineers' worth of new surface that will need on-call, upgrades and deprecation work for as long as the company exists. The answer they are listening for starts with what the current nine are actually doing, not with a roadmap.

The clarifying questions that change the answer

• What share of the nine is consumed by interrupts and upgrades? If it is above half, the first hires buy back existing capacity rather than building anything, and saying so is the strongest move available.
• How many supported paths exist today? Each path is a recurring maintenance load against every component beneath it, so the count caps what a team can keep current.
• Who carries the pager today, and at what floor? A 24/7 rota needs roughly six qualified responders to be humane. If the nine are split across three capabilities, none of them has a staffable rota and the first structural fix is fewer capabilities, not more people.
• What is adoption of the last two things we shipped? If it is low, more engineers will produce more unused capability faster.

A strong answer's arc

9 to 400 is about 1 platform engineer per 44 product engineers, which is thin against the band most organisations settle into, commonly somewhere between 1 in 20 and 1 in 40. 29 to 400 is about 1 in 14, which is above it. The risk flips from under-capacity to building what nobody asked for, and the answer should say that out loud.

Spend the first six on removing the interrupt load - self-service for the three request types that make up most of the queue - because that converts the existing nine back into project capacity and is measurable within a quarter. Split the rest into capability-owning teams of five or six, each with its own consumers, its own rota and a published contract, plus one enabling team that works inside product teams temporarily and owns no component. Leave two unallocated for the second half of the year; committing all twenty in January means committing to a roadmap written before you had the evidence.

Common weak answers

• "Build a developer portal." A portal is a view over capabilities. It is what you build after the capabilities exist and teams can already find them.
• "Split into infrastructure, tooling and enablement layers." Horizontal layers mean every user-visible change needs three teams, which lengthens exactly the lead time the platform was funded to shorten.
• "Hire all twenty into one team." Past roughly eight to ten people a platform team stops having one set of consumers and starts needing an internal roadmap conversation of its own.

What a strong answer adds

Exit criteria, stated in advance. Each new capability gets a date by which voluntary adoption must reach a stated level, and a team whose capability misses it is redeployed rather than given another two quarters. Report time to first success for a new team, the share of changes shipped without a platform ticket, and the platform's own change-failure rate. Report cost too: 29 engineers is on the order of $5M a year fully loaded, and a platform group that cannot name what that bought is one budget cycle from being cut back to nine.