Your organisation has one supported path for building a backend service and 78% of services use it. The platform group now wants golden paths for data engineering, machine learning and web, each owned by a different team, each with its own templates and its own opinion about CI. Walk me through how you decide whether to do that, and what has to exist before the second path does.

What the interviewer is testing

Whether you treat a golden path as a product with an owner and a cost, or as a document. The naive answer is "yes, more paths means more coverage". The question is whether you can see that the second path is the one that creates the problem the first one solved.

The clarifying questions that change the answer

• What does the 22% who are off the path have in common? If they are mostly data and ML services, the demand is real. If they are mostly old services nobody has touched, the answer is a migration sweep, not a new path.
• What does the path consist of? If it is a wiki page, paths are cheap and useless. If it is a template that generates a working service with pipeline, telemetry, ownership and cost attribution already wired, each path is a maintained product and the marginal cost is a team.
• What is shared between paths and who owns the shared part? Telemetry, identity, deployment and ownership metadata are the same in all four. If each path owns its own copy, you have four implementations of the thing that was supposed to be standard.
• Who adjudicates when two paths disagree? Without an answer, the first conflict - two CI conventions, two service-descriptor schemas - is settled by whoever ships first.

A strong answer's arc

Spotify's published material is useful here because it names both halves. Backstage, created at Spotify and open-sourced in 2020 (now a CNCF project), delivers a golden path as a software template that scaffolds a new component, not as guidance - and the component it produces registers itself in the software catalogue through a descriptor file committed next to its source. Spotify's own onboarding material also names the body that decides which frameworks are used, a Technical Architecture Group, whose stated purpose is reducing fragmentation. The template is the mechanism; the group is the authority. A path with one and not the other drifts.

So: yes to more paths, conditional on three things existing first.

1. A shared layer with a single owner. Telemetry, identity, deploy, ownership descriptor and cost tags are extracted into one set of modules that every path composes. Each path owns its language, framework and test idiom - nothing else.
2. A conformance check the paths cannot opt out of. A generated service either produces the ownership descriptor and the standard telemetry or it fails its own pipeline. This is what stops four paths becoming four standards.
3. A named adjudicator with a published decision log. Four path owners will disagree about four things a quarter. Without a forum the disagreements become per-path exceptions.

Common weak answers

• "Build all four, teams will pick the right one." Teams pick the one whose owner answers fastest, and the shared layer forks.
• "One path to rule them all." A single path for backend and ML forces one of them into the wrong shape. Different disciplines genuinely need different scaffolding; what they do not need is different telemetry.
• "Measure adoption and iterate." Adoption is the right measure and it lags by quarters. You need the structural decision - shared layer or not - before the second path ships, because retrofitting it means rewriting both.

What a strong answer adds

The cost in headcount, stated plainly: a maintained path is roughly 2 to 4 engineers once you count upgrades, support and the migration work it imposes on others. Four paths is a platform group of 12 to 16 before anyone builds anything new. If that is not fundable, the honest answer is two paths and a documented "unsupported, you own it" tier, which is better than four paths nobody keeps current.

And the second-order effect: every path is a migration obligation. When the shared telemetry library has a breaking change, you now owe four migrations. The number of paths is the multiplier on all future platform work, which is the real reason to be stingy with it.