Platform engineer interview questions and answers

The platform was excellent. Templated services, a paved deployment path, policy enforcement, sensible defaults, all of it genuinely well built. Eighteen months in, four teams used it and nine did not, and the nine had each built their own thing quietly, which meant the platform team had accidentally increased the number of deployment systems at the company from one to five.

That story is the centre of platform engineer interview questions. Platform engineering is DevOps with a product problem attached: your users are other engineers, they are opinionated, and they can always route around you. The interview reflects that — real systems depth, plus a design round where the graded skill is whether you think about adoption at all. This guide covers the loop and the answers that land.

The platform engineer interview loop

• Coding round — real code, usually Go or Python: a CLI tool, a parser, a small controller or service. Not usually hard algorithms, but genuine code.
• Systems and Kubernetes round — containers, networking, scheduling, storage, and debugging.
• Platform design round — design an internal developer platform, a deployment system, or a multi-tenant service.
• Operations and incident round — on-call, blast radius, and a change of yours that affected other teams.
• Stakeholder round — adoption, migration and saying no.

Our DevOps engineer interview questions guide covers the adjacent role and SRE interview questions covers the reliability-focused sibling.

What platform engineering is, and how it differs

Asked early, and a vague answer costs you. The framing that works:

DevOps is a set of practices for how teams build and run software. SRE is a discipline focused on reliability, error budgets and toil reduction. Platform engineering builds an internal product — a paved road that makes the right thing the easy thing — and is measured on adoption and developer productivity rather than on uptime alone.

Then add the honest part: these overlap enormously and titles vary by company. What is consistent is that a platform engineer has internal users and is expected to think about their experience.

Kubernetes and systems depth

Expect genuine debugging rather than definitions:

• "A pod is stuck in Pending. Walk me through it." Insufficient resources on any node, an unschedulable taint, a PVC that cannot bind, node selectors or affinity rules that match nothing. Say you would start with describe and read the events, because the answer is almost always in the events.
• CrashLoopBackOff versus ImagePullBackOff versus OOMKilled — three completely different causes, and knowing which logs to read for each.
• Requests versus limits, and the consequences: requests drive scheduling, limits drive throttling and OOM kills, and a limit with no request is a common misconfiguration.
• Networking. Services, ingress, DNS resolution inside the cluster, and how you debug a connection that hangs rather than refuses.
• Operators and CRDs. Platform teams write these; be able to explain the reconciliation loop — observe current state, compare with desired state, act, repeat — which is the whole idea.
• Storage and statefulness. StatefulSets, PVCs, and why running a database in Kubernetes is a decision rather than a default.

Our Kubernetes interview questions and Docker interview questions guides cover the fundamentals.

Infrastructure as code

• State management. Where Terraform state lives, why it must be remote and locked, and what happens when two pipelines apply simultaneously.
• Drift. How you detect infrastructure that was changed by hand, and what your policy is — usually reconcile and remove the console access that allowed it.
• Module design. Reusable modules with sensible defaults, versioned, so teams consume rather than copy. This is the platform version of the question.
• Blast radius. Splitting state so one apply cannot take down everything, and why a single monolithic state file is a liability.
• Policy as code. OPA, Sentinel or equivalent, to enforce guardrails at plan time rather than in review comments.
• GitOps. Argo CD or Flux, the pull model, and why declarative desired state in git makes rollback trivial.

Our Terraform interview questions guide covers this in depth.

The platform design round

The prompt is something like: "Design an internal developer platform for 200 engineers across 40 services."

• Start with the users, not the technology. What do developers do today, what takes them longest, and what are they most frustrated by. A platform designed without that is a solution looking for a problem.
• Golden paths, not mandates. A well-supported default that covers 80% of cases, with a documented escape hatch. Teams that need something different should be able to leave without becoming outlaws.
• Self-service with guardrails. Provisioning a database or a service should take minutes without a ticket, while policy is enforced automatically rather than by review.
• The service template. New service scaffolding with logging, metrics, tracing, CI, deployment and health checks already wired. This alone is often the highest-value thing a platform ships.
• Abstraction level. How much Kubernetes do developers see? Too much and it is not a platform; too little and every unusual requirement becomes a support ticket. Have a position and defend it.
• Multi-tenancy. Namespace isolation, resource quotas, network policy, and noisy-neighbour protection.
• Measurement. Adoption rate, time to first deploy for a new service, deployment frequency, and change failure rate. Naming concrete metrics is a strong signal.
• Migration. How existing services move over. The honest answer includes doing the migration for teams rather than asking them to, because their incentive to migrate is usually zero.

Operations, blast radius and incidents

• Your changes affect everyone. A bad platform release breaks many teams at once, so progressive rollout applies to infrastructure too — canary clusters, staged rollouts, and a fast revert.
• On-call. What you page on, what waits until morning, and how you avoid becoming the on-call for every team's application bugs. That last boundary problem is real and interviewers like hearing it.
• The incident question. Have a specific one: a change you shipped that broke other teams, how you found out, how long recovery took, and the structural fix. Our CI/CD interview questions guide covers rollback mechanics.
• Toil. What you automated away, with the hours saved. Platform interviews respond well to numbers.

The stakeholder round

Distinctive to this role, and it is where product thinking gets tested:

• "A team refuses to migrate. What do you do?" Understand the actual blocker rather than assuming resistance — it is usually a genuine missing capability or a bad time in their roadmap. Then either build the capability, do the migration for them, or accept the exception and document it.
• "A team wants an exception to a policy." Ask what they are trying to achieve, decide whether the policy or the request is wrong, and be willing to change the policy. Rigid platform teams get routed around.
• "How do you prioritise the platform roadmap?" Developer pain, measured — surveys plus real data on where time goes — rather than what the platform team finds interesting to build.
• "How do you measure success?" Adoption and developer productivity, not the number of features shipped.

Where each prep option actually helps

• Team Topologies — the source of most of the vocabulary senior platform interviewers use, including platform-as-a-product and cognitive load.
• The Kubernetes documentation, plus real debugging — break a cluster on purpose and fix it. Nothing else prepares the systems round as well.
• Backstage and the CNCF landscape — enough to speak concretely about developer portals and service catalogues.
• The Google SRE book — for error budgets, toil and the operations vocabulary.
• ChatGPT — good for generating debugging scenarios. It will not point out that your platform design has no adoption story.
• Greenroom — the spoken layer. Ari, the AI interviewer runs the design and stakeholder rounds out loud and pushes on the adoption question. Honest tradeoff: Ari will not debug your cluster, so do that yourself.

Frequently asked questions

What is the difference between platform engineering, DevOps and SRE?

DevOps is a set of practices for how teams build and run software, SRE is a discipline focused on reliability, error budgets and reducing toil, and platform engineering builds an internal product — a paved road that makes the right thing the easy thing — measured on adoption and developer productivity rather than uptime alone. The roles overlap heavily and titles vary by company, but a platform engineer consistently has internal users whose experience they are accountable for.

What is asked in a platform engineer design round?

A typical prompt is designing an internal developer platform for a few hundred engineers across dozens of services. Strong answers start from what developers do today and what frustrates them, then cover golden paths with documented escape hatches rather than mandates, self-service provisioning with automatic policy enforcement, a service template that ships logging, metrics, tracing, CI and health checks, a defended position on how much Kubernetes developers should see, multi-tenancy isolation, adoption metrics, and a migration plan that does the work for teams.

How do you debug a pod stuck in Pending in Kubernetes?

Start with kubectl describe and read the events, because the reason is almost always recorded there. The common causes are insufficient CPU or memory on any node, a taint the pod does not tolerate, a persistent volume claim that cannot bind, and node selectors or affinity rules that match no node. Distinguishing Pending from CrashLoopBackOff, ImagePullBackOff and OOMKilled — which have completely different causes and log locations — is usually part of the same question.

How do you get engineering teams to adopt an internal platform?

Treat adoption as the primary success metric and remember that teams can always route around you. Build a golden path that covers most cases well rather than mandating one, keep a documented escape hatch so unusual requirements do not make a team an outlaw, and do migrations for teams rather than asking them, because their incentive to migrate is typically zero. When a team refuses, find the real blocker — usually a missing capability or a bad time in their roadmap — rather than assuming resistance.

What Terraform questions come up in platform engineer interviews?

Remote and locked state and what happens when two pipelines apply at once, drift detection and what your policy is for infrastructure changed by hand, versioned reusable modules with sensible defaults so teams consume rather than copy, splitting state to limit blast radius rather than keeping one monolithic file, policy as code with OPA or Sentinel enforced at plan time, and GitOps with a pull-based reconciler such as Argo CD or Flux.

What metrics do platform engineers get asked about?

Adoption rate across teams, time to first deploy for a brand new service, deployment frequency, change failure rate, and time to restore — the last three being DORA metrics. You may also be asked how you measure developer pain when prioritising the roadmap, where the expected answer combines surveys with real data on where engineering time actually goes rather than what the platform team finds interesting to build.