An interviewer says - a central quality team of 12 owns the end-to-end suite the three shared test environments and the release sign-off while 25 feature teams write unit tests only. Where would you start? Treat this as the interview prompt it is.

What the interviewer is testing

Whether you reach for structure or for tooling. The weak version of this answer is a test-pyramid lecture. The strong version notices that the described arrangement is an organisational design, and its defect is a feedback loop, not a test distribution. The pyramid shape is a symptom of who owns what.

The clarifying questions that change the answer

• How long between a feature team's merge and a signal from the suite that blocks it? Under 2 hours and the structure is survivable; 3 days and it is the dominant problem.
• Where are escapes actually caught - the suite, the central team's manual pass, or in production? If the suite catches few, you are debating the cost of something that is not working.
• Can a feature team run the end-to-end suite against its own change without asking anyone? This one question usually decides the engagement.
• Who is on call for the service when it breaks at 3am? If the feature team is, and the quality team owns the verification, accountability and capability sit in different places.
• Is the quality team's work queue bounded by its own capacity or by requests from 25 teams?

A strong answer's arc

With 12 people serving 25 teams, each team's share is about half a person, so the quality team is a queue and its length sets the delivery rate of the whole organisation - a fact no amount of test authoring changes. Worse, the signal arrives where the change was not made: a red suite run tells 25 teams that one of them broke something, and the diagnostic work of finding which is paid by the central team, who did not write the change.

The move is to transfer the signal to where the change is made and keep the central team for what only it can do:

1. Feature teams own the tests that block feature teams, including the end-to-end tests for their own journeys, running on demand against an environment they can create.
2. The central team becomes a platform team: the environment service, the test-data service, the shared harness, the flake detection, and the handful of genuinely cross-team journeys nobody owns. This is a product with users, and it should have a roadmap rather than a ticket queue.
3. The sign-off is replaced rather than deleted. Someone is accountable for the release; make it an automated evidence record that the accountable owner reads, not a person re-doing the checks.

Common weak answers

• "Delete the end-to-end suite and push everything down the pyramid." Fast, confident and wrong on its own: those tests encode years of production incidents and deleting the only cross-service verification raises escape rate immediately.
• "Give every team access to staging." Nine teams in one mutable environment produces contention, not autonomy. The access was never the constraint.
• "Hire more quality engineers." Scales the queue linearly while the number of teams grows faster, and entrenches the structure that caused the problem.

What a strong answer adds

Say the uncomfortable part: escape rate usually rises in the first quarter after transfer, because feature teams inherit tests they did not write and the central team's tacit knowledge goes with the reorganisation. Name it in advance, measure it, and transfer one team at a time so the instrument is still readable. The promotion rule is concrete: hand a team its journey tests only if it can create its own environment and run them unaided, otherwise you have moved the blame and not the capability. And note what you would not change: if the regulator requires a named human signatory, that person stays - what changes is that they sign an evidence record rather than re-running the tests.