TL;DR: Build a golden path, not a gate. Measure task completion, developer satisfaction and adoption, and the failure mode is a platform team that becomes a ticket queue. Identify an expensive recurring workflow through user research and improve it.
How to approach it
Frame it as a product with users before describing components. The interviewer is checking whether you would build for developers or at them, which is the actual difference between platform engineering and a rebranded ops team.
A strong answer
The goal is that a developer can go from nothing to a running, observable, secured service in production without filing a ticket or learning Kubernetes. Everything follows from that sentence.
Start with a golden path, not a catalogue. Identify the most valuable workflow to improve, such as deploying a service or diagnosing a failed build, and make it excellent for one opinionated stack. A template that scaffolds the repository, the pipeline, the infrastructure definition, the dashboards, the alerts and the on-call registration in one action. Breadth comes later; a platform that supports everything badly gets adopted by nobody.
Components. A portal for discovery and ownership (Backstage is one option; its service catalogue can connect services to ownership metadata). Templates for scaffolding. An infrastructure abstraction so a team declares "I need a Postgres" rather than writing Terraform, implemented with Crossplane or with modules behind a thin interface. A paved pipeline. And observability provisioned by default, so teams can inspect the service from its first deployment.
The abstraction level is the hard design decision. Too thin and you have documentation over raw tools, so teams still need Kubernetes expertise and you have added a layer without removing a burden. Too thick and the first non-standard requirement forces an escape hatch, and if the escape hatch is a ticket to your team you have rebuilt the wall you were removing. Document which customization is self-service and which change needs a risk review. An escape hatch still needs an owner, support boundary and required security controls. The CNCF platforms white paper supports optional, composable capabilities; it does not make organizational controls optional.
Now the measurement, which is the question's real content. Vanity metrics are services onboarded and tickets closed. The ones that mean something:
- Voluntary adoption rate. What fraction of new services use the golden path when they are not required to? If use is mandatory, voluntary adoption is unavailable, but completion rates, satisfaction, retention of optional features and workarounds still provide evidence.
- Time from empty repository to production, measured end to end. This is the number the platform exists to reduce.
- Frequency of escape hatches, because each one names a gap in the abstraction.
- DORA metrics for teams on the platform versus off it. Compare similar workloads and track changes within teams; migration stage, team maturity and release constraints confound an on/off comparison.
- A periodic developer survey. Qualitative, and the only thing that catches "it works but everyone hates it".
The honest failure mode to name unprompted: platform teams drift into being a ticket queue because it feels helpful and produces immediate gratitude. Every ticket you accept that should have been self-service is a feature you did not build, and the queue grows faster than the team.
What interviewers probe next
"How do you handle the team that wants something different?" Establish the unsupported requirement and agree who operates the exception, including upgrades and incident response. Repeated requests are evidence for the roadmap, but even one critical workload may justify a supported capability.
"Would you mandate the platform?" Not early. A mandate removes voluntary choice as a measurement. Evaluate task success and developer feedback independently, and explain any security or operational requirement for standardization.
"Who is on-call for the platform?" The platform team, with an SLO, because it is now production infrastructure for every other team.
Common mistakes
Listing tools instead of describing users and workflows.
No measurement, or measuring throughput of the platform team rather than outcomes for developers.
Building a gate. If the platform is the only way and it is worse than what it replaced, adoption is compliance and you will not hear the complaints until people route around you.