Platform engineer interview questions

As asked

Your company has 80 engineering teams and every team deploys services differently. How would you design a self-service platform that standardises the paved road?

Sample answer outline

Start with the most common service path: repository template, CI pipeline, container build, deployment, secrets, observability, and rollback. The platform should expose simple self-service APIs or portals while hiding Kubernetes, cloud IAM, and network details where possible. Strong answers balance golden paths with escape hatches, because forcing every workload into one shape creates shadow platforms. Adoption depends on migration support, clear docs, sensible defaults, and measuring developer lead time, failure rate, and support burden. The common mistake is building a portal before standardising the underlying runtime contracts.

Expect these follow-ups

• What should be configurable and what should be fixed?
• How do you migrate the first 20 teams?
• What metric proves the platform is helping rather than adding process?

As asked

You inherit a cloud estate where every team uses admin-like roles in a shared account. How would you redesign access without blocking delivery?

Sample answer outline

Start by separating environments and blast radii: production from non-production, shared platform from application accounts, and human access from workload identity. Define roles around actions people actually need, then enforce least privilege with permission boundaries, short-lived credentials, and break-glass access that is audited. Use infrastructure-as-code and policy-as-code so access changes are reviewed, repeatable, and testable. Strong answers mention migration sequencing because cutting everyone over in one move usually breaks deployments. Candidates often trip up by describing perfect IAM theory without a path from the current unsafe state.

Expect these follow-ups

• How do you handle a senior engineer who insists they need admin for debugging?
• Where would you use service control policies or organisation policies?
• What audit signals tell you the new model is working?

As asked

Your company has 40 data teams writing Airflow or Dagster jobs in different styles. How would you build a shared orchestration platform without becoming a ticket queue?

Sample answer outline

The platform should provide paved roads: project templates, deployment automation, secrets access, standard retries, alerting, and lineage out of the box. Teams should own their DAG code while the platform owns runtime reliability, conventions, and guardrails. Multi-tenancy needs isolation for dependencies, quotas, credentials, and noisy workloads. Adoption is won by making the easiest path the best path, not by banning all custom jobs on day one. Candidates often miss the product-management side of platform work: documentation, migration support, and measuring whether teams are actually faster.

Expect these follow-ups

• What should be centralised and what should remain team-owned?
• How do you prevent one team's job from starving everyone else?
• What platform metrics would you report after six months?

As asked

Teams keep opening platform tickets for production issues in services they own. How would you clarify service ownership without abandoning teams?

Sample answer outline

Define ownership in operational terms: who is on call, who approves changes, who owns SLOs, and who fixes production bugs. The platform team should own shared tooling, templates, and guardrails, not become the default operations team for every product service. Strong answers include an escalation path, office hours, runbooks, and platform-provided diagnostics so teams can solve common issues themselves. The candidate should recognise that ownership changes require enablement, not a memo. The trap is either accepting every ticket forever or abruptly pushing work back without giving teams the capability to succeed.

Expect these follow-ups

• How do you handle a team that refuses to take on-call?
• What belongs in a service catalogue?
• When should the platform team take direct ownership of an incident?

As asked

Design isolation for an internal developer platform where hundreds of services share Kubernetes clusters and cloud accounts.

Sample answer outline

Use multiple layers of isolation: namespaces, RBAC, network policies, resource quotas, admission controls, workload identity, and separate accounts or clusters for higher-risk environments. A strong answer explains the difference between soft tenancy for ordinary services and hard isolation for regulated, privileged, or noisy workloads. They should discuss blast radius, auditability, cost allocation, and how platform defaults are enforced through policy-as-code. The design should include safe escape hatches because some workloads will not fit the default. A common miss is relying only on Kubernetes namespaces and ignoring cloud IAM or network egress.

Expect these follow-ups

• Which workloads deserve their own cluster?
• How do you prevent one team from exhausting shared cluster capacity?
• What policy would you enforce at admission time?

As asked

Your tracing bill is too high, but engineers rely on traces to debug rare checkout failures. How would you change the sampling strategy?

Sample answer outline

Separate head sampling, which decides early and is cheap, from tail sampling, which can keep traces based on outcome after the request completes. Keep all error traces, slow traces, and traces for important business flows, while sampling routine successful traffic at a lower rate. Propagate sampling decisions consistently across services so one request does not produce broken partial traces. Use attributes with bounded cardinality to drive retention rules, and validate with engineers that rare failure modes remain findable. A weak answer simply lowers the global sampling percentage and loses the exact traces people need during incidents.

Expect these follow-ups

• What metadata must be propagated for tracing to work across services?
• When is tail sampling too expensive or too late?
• How would you prove the new sampling policy is not hiding production bugs?