5 exercises — covering Internal Developer Platform design, golden path definition, platform adoption strategy, platform metrics, and staff-level influence.
Structure for Staff Platform Engineer answers
IDP philosophy: reduce cognitive load on product engineers, not centralise control — the platform is a product
Golden paths: opinionated defaults that are easy to follow; escape hatches for valid exceptions
Adoption: measure time-to-production for new services; treat adoption rate as a product metric
Staff influence: RFC → prototype → pilot team → measure → scale; never mandate without demonstrated value
0 / 5 completed
1 / 5
The interviewer asks: "What is an Internal Developer Platform and what problem does it solve?" Which answer is most complete?
Option B is strongest. It defines IDP in terms of the problem it solves (cognitive load, duplicated infrastructure effort), names the components of an IDP (service catalogue, deployment workflows, environment provisioning, observability), makes the critical distinction between IDP as a control plane vs IDP as a product teams choose to use (the single most important philosophical point), and names the right success metric (time-to-production for a new service). Option A conflates IDP with Kubernetes. Option C conflates IDP with a developer portal (Backstage is a component of an IDP, not the IDP itself). Option D conflates IDP with CI/CD — CI/CD is one component.
2 / 5
The interviewer asks: "Define a golden path. How do you decide what goes into a golden path and what remains an escape hatch?" Which answer shows the clearest thinking?
Option C is the strongest. It defines a golden path by its design intent (opinionated, end-to-end, common case), states two decision criteria (frequency and leverage), makes the critical point that golden paths are opt-in with first-class escape hatches, and includes a review process (annual, using adoption rate, support tickets, and satisfaction). Option A defines by majority usage — frequency is one criterion, not the only one. Option B turns golden paths into mandates — this is the most common failure mode; mandated paths without escape hatches lead to secret workarounds. Option D describes a template repo — this is an implementation detail, not a definition.
3 / 5
The interviewer asks: "How do you measure whether your platform is delivering value?" Which answer shows the most product-minded thinking?
Option B is strongest. It defines four metric categories (developer experience, reliability, adoption/retention, product team outcomes), names specific metrics in each (time-to-production, self-service success rate, DORA metrics, churn), uses DORA metrics as outcome evidence, includes a churn metric (teams leaving = signal of platform failure), and frames the presentation to leadership. Option A counts services — an output, not an outcome. Option C uses a single annual survey — too infrequent and too aggregated to be actionable. Option D uses deployment frequency alone — correlates with platform quality but cannot isolate platform contribution from other factors.
4 / 5
The interviewer asks: "As a Staff Platform Engineer, how do you drive adoption of a new platform capability without mandating it?" Which answer shows the most mature influence approach?
Option C is strongest. It describes a six-step graduated adoption model that builds credibility (RFC → pilot → measure), reduces friction (guides, office hours, pairing), progressively normalises the capability (default for new services), and includes a diagnostic framework for adoption stalls (discovery vs trust vs fit). Option A uses managerial mandate — effective short-term but builds resentment and reduces platform team credibility. Option B relies on the RFC alone — RFCs build consensus but do not drive adoption by themselves. Option D relies on passive availability — good capabilities are discovered slowly without active enablement.
5 / 5
The interviewer asks: "How do you handle a situation where a product team has strong objections to a platform decision that affects them?" Which answer shows the right balance of influence and respect?
Option B is strongest. It triages the type of objection (decision vs implementation vs communication — each needs a different response), names the responses for each type (review decision, add to backlog, acknowledge trade-off), insists on documented rationale for overrides, and explains the long-term risk of overriding without explanation (advocates against the platform). Option A escalates immediately — this damages the platform team's relationship with product teams. Option C is bureaucratic — putting the burden of RFCs on the product team creates friction and resentment. Option D uses majority vote — objections from a minority can still be valid; majority view is not a substitute for technical reasoning.