Prompt and scope
Design an internal developer platform for an organization with many services, teams, and deployment environments. The platform should make common delivery tasks easier without becoming a ticket queue or forcing every team into one architecture.
Treat developers as customers with different workloads. Backstage describes a software catalog that tracks entities such as services, libraries, and domains; DORA recommends combining delivery performance with developer experience signals rather than using one productivity number.
What the interviewer is testing
They are testing platform-as-a-product thinking, segmentation, workflow prioritization, change management, governance, and metric design. A strong answer links a platform capability to a developer job and a measurable outcome, while preserving an escape hatch for valid exceptions.
Questions to clarify before answering
- Who is the first target: new teams, on-call engineers, service owners, or security reviewers?
- Which repeated task is most expensive: bootstrapping, deployment, ownership discovery, observability, or compliance evidence?
- How many languages, runtimes, clouds, and maturity levels must be supported?
- What constraints are mandatory, and where can teams opt out?
- Is the goal faster delivery, safer changes, easier onboarding, or lower cognitive load?
A 30-second answer framework
“I would start with teams that repeatedly create services and struggle to find ownership and safe deployment defaults. The MVP is a catalog with clear owners, a self-service service template, one paved deployment path, and searchable runbooks. Teams can leave the path with documented reasons. I would pilot with three representative teams, measure time to first production change, failed deployment recovery, onboarding time, task completion, and developer satisfaction, then expand only where the evidence shows reduced friction.”
Step-by-step deep dive
Step 1: Segment developer jobs
Interview service owners, new hires, on-call engineers, and platform operators separately. Their pain differs: discovering a dependency, creating a repository, shipping safely, or proving a control. Use observed workflows and support tickets, not only feature requests.
Step 2: Map the golden path
Choose one frequent, high-risk journey and define its input, defaults, approvals, and output. A golden path should be the easiest safe route, not a hidden mandate. Document where teams can customize or exit.
Step 3: Build the smallest useful catalog
Start with ownership, lifecycle, critical dependencies, links to deployment and runbooks, and freshness indicators. Backstage’s catalog model uses entities and metadata; require an owner and source file so records do not become an unmaintained directory.
Step 4: Add self-service actions
Offer templates for the next bottleneck: create a service, add standard CI, request an environment, or enable observability. Each action should show prerequisites, estimated time, result, and a recovery path when automation fails.
Step 5: Design governance as guardrails
Automate security and reliability defaults, but separate policy from implementation. A platform can block a risky deployment with an explainable reason and an exception workflow; it should not silently rewrite team code or hide ownership.
Step 6: Plan adoption and migration
Recruit design partners, migrate one real service end to end, publish examples, and provide office hours. Track migration effort and leave legacy paths documented. Adoption earned through lower friction is more durable than a mandate with no support.
Step 7: Define platform reliability
Give the platform its own SLOs: catalog freshness, template success, deployment workflow availability, and incident response. A broken internal platform becomes a production dependency, so provide status, rollback, and support ownership.
Step 8: Measure outcomes and guardrails
Use delivery metrics such as deployment frequency and failed deployment recovery time with task-level measures such as time to create a service, time to first deploy, self-service completion, and support tickets. Add developer surveys and guardrails for change failure, platform incidents, and unequal impact across teams.
Trade-offs and boundaries
Trade-off 1: Standardization or autonomy
Standard defaults reduce cognitive load; autonomy preserves team fit. Standardize interfaces and safety controls first, and allow implementation choices behind them.
Trade-off 2: Build or integrate
Build only the workflow or policy that is differentiating. Integrate existing catalog, CI, secrets, and observability systems when they meet the contract; every integration becomes part of the platform’s reliability surface.
Trade-off 3: More features or better completion
A catalog with twenty half-working plugins creates more friction than a small set of reliable actions. Prioritize end-to-end task completion over feature count.
Failure drills and evolution plan
Drill 1: A template fails halfway
Show the user what was created, how to retry safely, and who owns cleanup. Make actions idempotent where possible and expose logs without requiring platform-admin access.
Drill 2: Teams bypass the golden path
Interview them before labeling it non-compliance. The path may be missing a legitimate use case, have poor defaults, or impose hidden migration cost. Improve the journey and document justified exits.
Drill 3: A platform outage blocks releases
Test degraded operation, status communication, and a manual fallback. The platform must reduce operational risk, not become an opaque single point of failure.
Common mistakes and follow-ups
Mistake 1: Treating the portal as a homepage
Links alone do not remove work. Identify a task and provide a self-service outcome.
Mistake 2: Measuring lines of code or clicks
Those are activity counts, not product outcomes. Pair delivery data with task completion and developer experience signals.
Mistake 3: Mandating one stack
A platform contract can support multiple runtimes. Explain which constraints are about safety and which are merely preferences.
Mistake 4: Ignoring metadata ownership
A stale catalog harms incident response. Require owners, source-controlled metadata, freshness checks, and an escalation path.
Mistake 5: Migrating every team first
Start with design partners and a measurable journey. Broad migration before proof creates resistance and hides usability gaps.
Mistake 6: Forgetting the platform is production software
Set SLOs, incident ownership, release controls, and rollback paths for the platform itself.