Top 6 Platform engineering Interview Questions
Browse 6 real-world technical and behavioral interview questions about Platform engineering. Review scenarios, edge cases, and architectural best practices.
Build or buy an internal developer platform: build the total-cost comparison.
Compare total cost of ownership like for like. Buying still needs a platform team, building never ends at launch, and a later launch delays benefit. On illustrative figures for 300 engineers over three years, buying costs 1,595k against 2,775k to build, and building wins at steady state only above about 900 engineers.
Finance asks what the platform team returns for what it costs. How do you show it without inflating the number?
Show platform ROI against a counterfactual cost: what product teams would spend doing the work themselves, measured from non-adopters. Add measured time saved, discounted because hours are capacity not cash, and consolidated licences. Report reliability separately and state the limits.
Six months after launching an internal developer portal, weekly active usage has plateaued at around forty percent of engineering. How would you go about figuring out why, and what would you actually do about it?
Stalled adoption is rarely a UI problem; segment usage by team and task rather than the aggregate number, then match the fix to whichever of three causes shows up - a missing daily task, a faster existing habit, or data nobody trusts.
When you build a golden-path template for scaffolding new services, you're pushing every team toward one way of doing things. What do you gain from that, and what do you have to give up?
A golden path buys consistency, faster onboarding, and cheaper platform support at the cost of teams whose problem genuinely doesn't fit the template; the design answer is an escape hatch that costs something small, not a wall.
How do you get a design system adopted by product teams moving at different speeds, and what do you do about the team that forked your component?
A design system adoption strategy works when the system is cheaper to use than avoid, measured by component coverage and version lag, and backed by migration help. Forked components should be treated as evidence before they are treated as resistance.
You've built a service catalog with an owner field on every entry. A year later, half the owners listed are people who left the company. How would you design the catalog so that doesn't happen?
Treat ownership as a derived, continuously verified fact rather than a manually entered field: source it from an existing system of record, expire it on a schedule, and fail builds or pages loudly when it goes unverified.