You run a platform team of twelve serving four hundred engineers. Product teams say the platform is a bottleneck; your team says the requests are unbounded and they cannot do product work. Both are right. What do you change?

What the interviewer is testing

Whether you treat this as a capacity problem or an interface problem. Adding platform engineers to an unbounded request queue is the answer that fails, because the queue is generated by an interface that requires the platform to be in the loop, and a bigger team simply processes the same interface faster while the request rate rises to meet it.

The senior move is to change what reaches the queue, not how fast it drains.

The clarifying questions that change the answer

• What is the request mix? Sort a month of tickets into three piles: self-service gaps (the platform can do it, the team could not work out how), genuine escalations (something broke), and bespoke work (this team wants something no one else wants). The proportions dictate entirely different responses.
• Is the platform a product or a service desk? A product has users who succeed without talking to you. A service desk has tickets. Which one has the organisation actually funded?
• Who decides the platform roadmap today? If it is whoever escalates loudest, the bottleneck is a prioritisation vacuum, not a headcount one.

The arc of a strong answer

1. Classify the queue. In most estates, the largest pile is self-service gaps - typically 50% or more. Every one of those is a documentation, defaults or error-message defect, and each is fixable once for everyone.
2. Publish a contract, not a promise. What the platform supports, its response times, and explicitly what it does not do. An unbounded scope is what makes the queue unbounded; the refusal has to be written down or it gets renegotiated in every conversation.
3. Make the bespoke pile an extension point. If three teams want something the platform does not do, the answer is an interface they can implement themselves, not three tickets.
4. Cap escalation with an on-call rotation and leave the rest of the team uninterrupted. Twelve people all interruptible means zero people building.
5. Change the measure. Choose an outcome measure over an activity one: not tickets closed, but percentage of teams reaching production without contacting the platform, and time-to-first-deploy for a new service. Those numbers falsify the service-desk model.

Common weak answers

• "Hire more platform engineers." Raises throughput of a queue whose arrival rate is set by the interface. Temporary relief, same state in six months, higher fixed cost.
• "Make teams self-sufficient with better documentation." Right direction, but documentation is the cheapest and weakest form of self-service. Defaults that make the correct path the path of least resistance beat documentation every time.
• "Push back on the product teams." Correct in part, indefensible without the contract that says what they are entitled to instead.

What a strong answer adds

That this has an organisational failure mode in the other direction: a platform team that becomes purely a product team stops absorbing the hard, unglamorous work - the migrations, the runtime upgrades, the certificate rotations - and that work does not disappear; it is redistributed to four hundred engineers at worse efficiency. The contract needs a line for it.