Platform engineer behavioural interview questions

As asked

Tell me about a time you built a platform tool or process and a specific team refused to adopt it. What was their objection, what did you do, and what was the outcome?

Sample answer outline

Strong answers use STAR and show empathy: the candidate listened to the team's specific objection (the tool was too slow, had a missing feature, broke their workflow), made a concrete change to address it, and tracked adoption afterward. They demonstrate that platform teams serve developer teams, not the other way around. Forcing adoption without addressing the root objection is a red flag.

Expect these follow-ups

• How do you decide when to make the platform mandatory versus optional? Where do you draw that line?
• What metrics did you use to track adoption progress after addressing their concerns?

As asked

Describe a platform-level incident you were responsible for resolving that affected multiple engineering teams. What caused it, how did you communicate during the incident, and what did you change afterwards to prevent recurrence?

Sample answer outline

Strong STAR answers show clear communication cadence during the incident (status page updates, Slack channels, executive summary), structured incident command (IC, comms, tech lead roles), accurate timeline reconstruction in the post-mortem, and blameless root cause analysis. The prevention work should be concrete: monitoring that did not exist, a circuit breaker, a canary deployment process, or a runbook.

Expect these follow-ups

• How do you write a blameless post-mortem that is actually useful rather than just documenting what happened?
• What was the hardest conversation you had to have after the incident, and how did you approach it?

As asked

Tell me about a significant piece of technical debt in a platform system you worked on. How did you make the case for addressing it when product and feature work were competing for the same time, and what approach did you take to pay it down?

Sample answer outline

Strong candidates quantify the cost of the debt (deployment failures per week, hours spent on workarounds, security risk exposure) and translate it into business terms. They describe a phased approach (strangler fig or incremental refactor) that delivered value at each step rather than a big-bang rewrite. They show they got buy-in from engineering leadership by framing the debt as a risk and cost, not an engineering preference.

Expect these follow-ups

• How do you keep platform tech debt visible over time so it does not get forgotten between planning cycles?
• Have you ever made the case to not fix technical debt because the cost of fixing it exceeded the benefit? Walk me through that decision.

As asked

Walk me through a migration you led or contributed to significantly, like moving services from VMs to containers or from one orchestration system to Kubernetes. What was the biggest risk you identified and how did you mitigate it?

Sample answer outline

Strong answers describe a phased migration with a clear definition of done, a rollback plan, and traffic shifting rather than a hard cutover. The biggest risk is usually stateful services or services with hard dependencies on VM-level networking or filesystem mounts. Mitigation involves running dual-stack (old and new) in parallel with gradual traffic shifting. The candidate demonstrates they ran this alongside existing team commitments without dropping service reliability.

Expect these follow-ups

• How did you handle services that the teams said were 'not ready to containerize'? Did you agree with them?
• What did you learn from the migration that you would do differently next time?

As asked

Tell me about a time you had to enforce a security requirement on the platform that slowed developers down or broke existing workflows. How did you handle the conflict between security requirements and developer productivity?

Sample answer outline

Strong answers show the candidate found a way to enforce the security requirement without completely halting developers: a grace period with warnings before hard enforcement, automated tooling to help teams fix violations, and clear documentation of why the policy exists. They collaborated with the security team to understand the actual risk level and pushed back where a blanket policy was disproportionate.

Expect these follow-ups

• What is your personal framework for deciding when to enforce a security policy strictly versus allowing exceptions?
• How do you prevent security theater, where policies exist on paper but are easily bypassed in practice?

As asked

Describe a situation where your team's on-call rotation was painful: too many alerts, too many false positives, or alerts that did not have runbooks. What did you do to improve it?

Sample answer outline

Strong candidates describe a systematic review of alert signal-to-noise ratio: bucketing alerts into actionable, informational, and noisy, then silencing or deleting the noisy ones, adding runbooks for actionable alerts, and converting informational alerts to dashboards. They drove this as a team initiative rather than a solo project, involving the people who received the pages. Metrics: mean time to acknowledge, percentage of pages outside business hours, alert volume over time.

Expect these follow-ups

• How do you handle a situation where an alert has a high false-positive rate but the one time it fires correctly it is critical?
• What is your philosophy on alert ownership? Should the platform team own alerts for platform components, or should product teams own all their alerts?

As asked

Tell me about a time when a product team's release was blocked by a platform issue or a missing platform capability. How did you prioritize it versus your existing roadmap, and what did you do to unblock them?

Sample answer outline

Strong answers show prioritization judgment: the candidate assessed the business impact of the blocked release, communicated honestly about what could be done and by when, and either found a short-term workaround or reprioritized their work. They did not make promises they could not keep. They followed up after the fix to make sure the team was unblocked and added the capability to the platform roadmap if it would prevent future blocks.

Expect these follow-ups

• How do you track requests from product teams so they do not get lost, and how do you communicate your roadmap back to them?
• What is your process for distinguishing between a 'must fix now' platform gap and a 'nice to have' request?

As asked

Tell me about a time you identified significant cloud cost waste and acted on it. What did you find, how did you prioritize which waste to address first, and what was the outcome?

Sample answer outline

Strong candidates found the waste using cost explorer, Kubecost, or a custom billing analysis (idle RDS instances, oversized nodes, low-utilization PVs). They prioritized by impact versus effort: low-effort, high-impact first. They involved the teams who owned the resources rather than making changes unilaterally. They measured the actual savings and reported back to leadership. Common outcomes: right-sizing compute, enabling spot for non-critical workloads, removing dev resources that ran nights and weekends.

Expect these follow-ups

• How do you handle the situation where a cost-saving measure like right-sizing causes a reliability issue later?
• What process do you put in place so that the cost savings do not regress over the following quarters?

As asked

Tell me about a time you got surprising or difficult feedback about a platform tool or workflow from developers. How did you gather the feedback, what did you learn, and how did it change what you built?

Sample answer outline

Strong answers describe a concrete feedback mechanism (developer survey, embedded sessions watching developers actually use the tool, NPS scores for the deployment pipeline) and specific feedback that changed the design. They show they treated developer feedback as product feedback rather than as complaints, and used it to prioritize features. They distinguish between feedback that points to a real problem versus a preference that would not improve the platform for most users.

Expect these follow-ups

• How do you handle conflicting feedback from two teams who want opposite things from the same platform component?
• What leading indicators do you watch to know a platform tool is struggling before you get explicit complaints?

As asked

Describe a situation where you were asked to build a platform feature with vague or missing requirements. How did you handle the ambiguity, what did you ship first, and how did you validate you were solving the right problem?

Sample answer outline

Strong candidates describe a discovery phase: talking to the stakeholders who made the request to understand the underlying pain, looking at usage data or incident history to quantify the problem, and shipping an MVP or prototype to get real feedback before building the full feature. They distinguish between what was asked for and what was actually needed. They show comfort with iteration over perfection.

Expect these follow-ups

• What is the smallest version of a platform feature you can ship that still delivers meaningful value?
• How do you handle the pressure to ship something complete rather than iterating?

As asked

Walk me through a Kubernetes minor version upgrade you ran on a production cluster. What was your preparation process, how did you handle workloads that needed changes (API removals, deprecated features), and what did you do when the first control plane node upgrade did not go as planned?

Sample answer outline

Strong answers describe a structured process: reading the Kubernetes changelog for API deprecations, using pluto or kubectl-convert to find deprecated API usage in deployed manifests, testing in a staging cluster first, upgrading the control plane first then worker nodes one at a time using node drain, and having a rollback plan (control plane can be rolled back if the data plane has not been upgraded yet). When something goes wrong they show calm debugging: checking kube-apiserver logs, verifying etcd health, and communicating status to affected teams.

Expect these follow-ups

• How do you handle an API removal where a third-party Helm chart you do not own still uses the deprecated API?
• What is the safe skew policy between Kubernetes components (kubelet, kube-proxy, kubectl) and how does it affect your upgrade sequence?

As asked

A cloud region loses a large fraction of your GPU capacity during peak traffic. What do you do in the first hour?

Sample answer outline

A strong answer starts with customer-impact triage: preserve critical inference paths, shed or degrade lower-priority workloads, and communicate current impact. Operational steps include shifting traffic across regions, enabling smaller fallback models, reducing max output tokens, disabling non-essential batch jobs, and checking whether queues are draining. The candidate should discuss pre-agreed degradation modes because inventing them during an incident is risky. Good answers include post-incident capacity planning, provider diversification, and game days. The common trip-up is focusing on cluster mechanics while ignoring product-level priority decisions.

Expect these follow-ups

• Which workloads do you shed first?
• What degradation mode would customers notice least?
• How much spare GPU capacity is worth paying for?

As asked

Tell me about a time you had to decide whether to build or buy internal platform tooling. How did you make the decision?

Sample answer outline

Strong answers frame the decision around product-team outcomes, operational ownership, integration cost, compliance needs, and long-term maintenance. Building may be justified for a differentiating workflow or tight integration with existing systems, while buying is usually better for commoditised capabilities such as secrets, CI, or observability storage. The candidate should describe a real evaluation process with users, proof-of-concept criteria, and exit costs. Good answers include the cost of migration and the team capacity needed to run the tool after launch. The common error is treating internal tools as free because engineers are already on payroll.

Expect these follow-ups

• What signal would make you reverse the decision later?
• How do you avoid vendor lock-in without over-engineering?
• Who gets the final say: platform, security, finance, or product engineering?