Assess the work
Platform engineer interview scorecard: rollout and recovery
Assess whether a candidate can investigate a failed rollout while protecting the running service. Use fixed evidence and recovery prompts, and keep operational authority and irreversible actions explicit.
Run a bounded 60-minute platform discussion
This exercise evaluates discussion about a service delivery platform and operational decisions. It does not test live infrastructure operation or prove implementation ability. Share the packet, time, format and adjustment contact in advance. Use one interviewer to facilitate and one to take evidence when possible; rate independently before debrief.
| Minutes | Stage | Fixed prompt | Stop rule |
|---|---|---|---|
| 0–6 | Orient | Read the scenario and ask: “What fact would you clarify before choosing a release action?” | Answer only scenario questions. Do not coach toward a design. |
| 6–17 | Ownership and service design | “Who owns the service, delivery path and release decision? What would you make visible before changing this service?” | Capture one ownership map and one health or rollout signal; move on at minute 17. |
| 17–29 | Readiness failure | Reveal the failed readiness check. “What do you inspect first, and how do you decide whether traffic should continue?” | Do not ask for commands or vendor syntax. Move on after the candidate names an owner and a safe next check. |
| 29–41 | Capacity and alert inject | Reveal rising CPU throttling and an alert firing on every restart. “What changes in your diagnosis and what action would you take now?” | Ask the fixed follow-up: “What evidence would make you stop the rollout?” Then stop diagnosis. |
| 41–51 | Recovery and authority | “Would you roll back, pause or continue? Who authorizes it, what might a deployment rollback leave behind, and how do you protect data?” | Record a choice, owner and limitation. Do not add a second incident. |
| 51–57 | Least privilege and developer path | “A developer asks for cluster-admin to debug this. What safer path do you offer, and how should the paved path remain usable?” | Score access boundary and usability evidence only. Do not debate tool preference. |
| 57–60 | Close | “What assumption would you verify first after this discussion?” | Clarify process and close. No new scored prompt. |
Global stop rule: end a scenario at its listed minute even if the discussion is unfinished. Do not recover time by shortening later prompts for one candidate. Optional probes about Terraform syntax, autoscaling policy or a second failure are unscored and should be scheduled separately for all candidates in that stage.
Kubernetes documents readiness as controlling whether a Pod receives Service traffic, while liveness can restart a container; badly designed checks can contribute to cascading failure. Its resource guidance explains CPU throttling under limits. The exercise uses those behaviors without requiring a specific configuration: probe guidance and resource management.
Give the candidate only the scenario
The printable candidate packet contains the prompt, supplied facts and instructions. It does not include interviewer notes or expected answers.
The packet below is the candidate-facing material.
Scenario: a service rollout is not ready
You have joined a small product team that runs a customer API through an internal deployment path. A new version is being released to a small share of capacity. The service owner says the change contains no planned database migration. A platform engineer can pause the rollout; the service owner decides whether the release is safe for the application. The incident lead coordinates customer-impacting response.
At the start, the only new fact is that the new instances are failing a readiness check. The team has not yet established whether existing instances or customers are affected.
During the discussion you will receive two additional facts: resource throttling is rising, and an alert fires for every restart. You may ask the interviewer to repeat a fact or clarify the stated ownership. You do not need to name a cloud, Kubernetes command, monitoring vendor or infrastructure language.
Talk through what you would check, what decision you would make at each stage, who should be involved and what evidence would change your mind. This is a discussion only. Do not access a live system or provide credentials. There is no single prescribed architecture.
Score ownership and delivery design
Fixed prompt, 6–17: “Who owns the service, delivery path and release decision? What would you make visible before changing this service?”
Look for a separation between shared platform responsibilities and application ownership, a named decision path, and a small set of useful signals before release. Strong discussion recognizes that a platform should make the safe path easy to understand and operate. Do not credit a list of products without a reason tied to this service.
Fixed follow-up: “What do you need from the service owner before you can define readiness?” Record whether the candidate asks about traffic eligibility or user behavior rather than deciding service semantics alone.
Stop at minute 17. A platform engineer may propose a default template, but the role brief must say who reviews exceptions and owns service-specific health behavior.
Probe least privilege and the internal customer boundary
This competency is about safe operational authority and developer self-service, not multi-tenant application authorization.
Fixed prompt, 51–57: “A developer asks for cluster-admin to debug this. What safer path do you offer, and how should the paved path remain usable?”
Seek a scoped alternative that lets the developer inspect the relevant service, an approval or time boundary when elevated access is needed, and an owner for policy and audit. Also ask how routine diagnosis stays self-service so least privilege does not become a ticket queue for every read-only question.
Fixed follow-up: “If the safe path is unavailable during an incident, who can grant temporary access and how is it reviewed afterward?” Do not expect one particular identity provider or cloud feature.
NIST defines least privilege as granting only the access necessary for assigned tasks. This principle informs the prompt; the exact control depends on the organization's system: NIST least-privilege definition.
Stage the failure and decide when to stop
Stage 1, readiness: “The new instances fail readiness. What do you inspect first, and how do you decide whether traffic should continue?” The candidate should ask what the check represents, whether existing capacity serves users and what changed. Do not accept a guessed probe threshold as proof.
Stage 2, minute 29: “CPU throttling is rising, and the alert fires on every restart. What changes in your diagnosis and what action would you take now?” Then ask the fixed follow-up: “What evidence would make you stop the rollout?” A useful answer makes impact, capacity, alert signal and stop authority explicit.
Stage 3, minute 41: “Would you roll back, pause or continue? Who authorizes it, what might a deployment rollback leave behind, and how do you protect data?” The supplied service owner says no database migration is planned, but the candidate should still identify compatibility and external side-effect assumptions rather than treat that statement as a guarantee about every dependency.
Stopping rules: do not add a second incident; do not demand a command; move on when the candidate names an owner and a safe next check; stop each stage on time. Optional discussion of progressive delivery, autoscaling or capacity modeling is unscored.
Google SRE guidance distinguishes alerting on symptoms that need action from monitoring used for diagnosis, and describes incident roles and on-call practices. These concepts support the exercise, but do not validate a particular alert policy: Monitoring distributed systems and Being on-call.
Rate evidence, not confidence
Write the observed decision or stated assumption before selecting a rating. The rating describes evidence from this discussion at the brief's stated scope. It is not an overall judgment of the person and should not be summed into an automatic decision.
Worked calibration: borderline and strong
Hypothetical borderline evidence: After the capacity inject, the candidate asks for current throttling and shared cluster headroom, pauses the rollout, and proposes adding one replica only if the observed headroom allows it. They do not connect throttling to current workload or customer impact, and after the fixed follow-up they cannot name a service-impact signal that would stop the rollout. For capacity and failure diagnosis, 2 fits: the candidate checks one real constraint and proposes a bounded action, but leaves a meaningful diagnosis and verification gap. This is partial evidence, not the blind scaling response described by level 1.
Hypothetical strong evidence: The candidate says the rollout should pause while the service owner and incident lead establish impact; compares old and new instance health; checks throttling against workload and shared headroom; replaces the restart-count alert with a signal tied to service impact while retaining diagnostic detail; and states what evidence would authorize rollback. For release, capacity and operations, 4 may fit where each point is actually discussed. Record the separate evidence per dimension.
NO example: If time ends before the least-privilege prompt, mark that competency NO with “not asked, agenda over.” Do not infer access judgment from another answer.
Scale: 1 = material gap remains after the fixed follow-up; 2 = partial evidence with a meaningful gap; 3 = workable evidence at this role's stated scope; 4 = level 3 plus independent handling of an important interaction; NO = not enough fair evidence. Record the reason for NO. Do not turn it into a 1 or a zero.
| Competency | 1 · Gap | 3 · Meets this role | 4 · Strong evidence |
|---|---|---|---|
| Release and health reasoning | Treats readiness and liveness as interchangeable or recommends continuing without checking service impact. | Uses readiness to reason about traffic eligibility, checks recent change and service impact, and names a safe stop condition. | Connects probe behavior, rollout progression and blast radius; proposes a bounded observation or staged change another owner can verify. |
| Capacity and failure diagnosis | Responds to throttling or restarts by raising limits blindly or adding replicas without checking demand, saturation or shared headroom. | Checks workload and relevant resource signals, distinguishes symptom from cause, and identifies a service-owner decision or safe capacity action. | Separates per-instance and shared constraints, calls out uncertainty and proposes a reversible measurement/action sequence with explicit stop criteria. |
| Alert triage and operations | Accepts a noisy restart alert as actionable without identifying user impact, owner or response. | Finds the signal tied to service impact, suppresses or changes noisy diagnosis only with a replacement signal, and names who responds. | Explains how alerting, incident lead and runbook connect; reduces noise without hiding the failure and makes follow-up ownership clear. |
| Recovery and data safety | Calls deployment rollback a complete reversal, ignoring schema or external side effects. | Chooses pause/rollback/continue from evidence, identifies the release authority and checks whether data changes remain compatible. | Explains a concrete recovery boundary, sequencing or reconciliation step, including what cannot safely be undone. |
| Least privilege and developer experience | Grants broad standing access or makes the paved path an opaque mandatory gate without an alternative. | Offers a scoped, reviewed access path and explains how developers get enough visibility to diagnose routine problems. | Balances time-bound or task-scoped access, audit and emergency needs with a usable self-service path and named policy owner. |
For every dimension, 2 means part of the relevant reasoning is present but a significant issue remains or the candidate needs substantial prompting. NO means a fair rating was not possible because a prompt was skipped, time ended, the interviewer interrupted, the scenario was unclear or an adjustment changed what evidence was elicited. Record why and arrange the same follow-up for candidates in the same stage.
Have interviewers score independently before discussion. Resolve a disagreement by checking the prompt asked, the candidate's exact evidence and the anchor. If a prompt was administered differently, record the process gap and arrange a consistent follow-up rather than averaging impressions.
Print a self-contained interviewer packet
Use this packet for interviewer notes. Keep records under the organization's candidate-data access and retention rules. Write job-related evidence only.
The packet repeats its agenda, prompts and anchors so it remains usable when printed by itself.
Platform interview: fixed 60-minute agenda
| Minutes | Stage | Fixed prompt | Stop rule |
|---|---|---|---|
| 0–6 | Orient | Read the scenario and ask: “What fact would you clarify before choosing a release action?” | Answer only scenario questions. Do not coach toward a design. |
| 6–17 | Ownership and service design | “Who owns the service, delivery path and release decision? What would you make visible before changing this service?” | Capture one ownership map and one health or rollout signal; move on at minute 17. |
| 17–29 | Readiness failure | Reveal the failed readiness check. “What do you inspect first, and how do you decide whether traffic should continue?” | Do not ask for commands or vendor syntax. Move on after the candidate names an owner and a safe next check. |
| 29–41 | Capacity and alert inject | Reveal rising CPU throttling and an alert firing on every restart. “What changes in your diagnosis and what action would you take now?” | Ask the fixed follow-up: “What evidence would make you stop the rollout?” Then stop diagnosis. |
| 41–51 | Recovery and authority | “Would you roll back, pause or continue? Who authorizes it, what might a deployment rollback leave behind, and how do you protect data?” | Record a choice, owner and limitation. Do not add a second incident. |
| 51–57 | Least privilege and developer path | “A developer asks for cluster-admin to debug this. What safer path do you offer, and how should the paved path remain usable?” | Score access boundary and usability evidence only. Do not debate tool preference. |
| 57–60 | Close | “What assumption would you verify first after this discussion?” | Clarify process and close. No new scored prompt. |
Fixed prompts and evidence notes
- Ownership/design: “Who owns the service, delivery path and release decision? What would you make visible before changing this service?” Follow-up: “What do you need from the service owner before you can define readiness?”
- Readiness: “The new instances fail readiness. What do you inspect first, and how do you decide whether traffic should continue?”
- Capacity/alert: “CPU throttling is rising, and the alert fires on every restart. What changes in your diagnosis and what action would you take now?” Follow-up: “What evidence would make you stop the rollout?”
- Recovery: “Would you roll back, pause or continue? Who authorizes it, what might a deployment rollback leave behind, and how do you protect data?”
- Least privilege/experience: “A developer asks for cluster-admin to debug this. What safer path do you offer, and how should the paved path remain usable?” Follow-up: “If the safe path is unavailable during an incident, who can grant temporary access and how is it reviewed afterward?”
Scale: 1 = material gap remains after the fixed follow-up; 2 = partial evidence with a meaningful gap; 3 = workable evidence at this role's stated scope; 4 = level 3 plus independent handling of an important interaction; NO = not enough fair evidence. Record the reason for NO. Do not turn it into a 1 or a zero.
| Competency | 1 · Gap | 3 · Meets this role | 4 · Strong evidence |
|---|---|---|---|
| Release and health reasoning | Treats readiness and liveness as interchangeable or recommends continuing without checking service impact. | Uses readiness to reason about traffic eligibility, checks recent change and service impact, and names a safe stop condition. | Connects probe behavior, rollout progression and blast radius; proposes a bounded observation or staged change another owner can verify. |
| Capacity and failure diagnosis | Responds to throttling or restarts by raising limits blindly or adding replicas without checking demand, saturation or shared headroom. | Checks workload and relevant resource signals, distinguishes symptom from cause, and identifies a service-owner decision or safe capacity action. | Separates per-instance and shared constraints, calls out uncertainty and proposes a reversible measurement/action sequence with explicit stop criteria. |
| Alert triage and operations | Accepts a noisy restart alert as actionable without identifying user impact, owner or response. | Finds the signal tied to service impact, suppresses or changes noisy diagnosis only with a replacement signal, and names who responds. | Explains how alerting, incident lead and runbook connect; reduces noise without hiding the failure and makes follow-up ownership clear. |
| Recovery and data safety | Calls deployment rollback a complete reversal, ignoring schema or external side effects. | Chooses pause/rollback/continue from evidence, identifies the release authority and checks whether data changes remain compatible. | Explains a concrete recovery boundary, sequencing or reconciliation step, including what cannot safely be undone. |
| Least privilege and developer experience | Grants broad standing access or makes the paved path an opaque mandatory gate without an alternative. | Offers a scoped, reviewed access path and explains how developers get enough visibility to diagnose routine problems. | Balances time-bound or task-scoped access, audit and emergency needs with a usable self-service path and named policy owner. |
For every dimension, 2 means part of the relevant reasoning is present but a significant issue remains or the candidate needs substantial prompting. NO means a fair rating was not possible because a prompt was skipped, time ended, the interviewer interrupted, the scenario was unclear or an adjustment changed what evidence was elicited. Record why and arrange the same follow-up for candidates in the same stage.
Optional unscored extensions: infrastructure-as-code implementation, autoscaling policy, progressive delivery or a second failure. Schedule separately and offer consistently; do not alter this core's ratings.
Role / level: ____________________________________ Date: ______________
Candidate identifier: __________________________ Interviewer: __________________
Evidence sheet
| Competency | Observed words, choices and assumptions | Rating | Missing evidence / consistent follow-up |
|---|---|---|---|
| Release and health reasoning | 1 / 2 / 3 / 4 / NO | ||
| Capacity and failure diagnosis | 1 / 2 / 3 / 4 / NO | ||
| Alert triage and operations | 1 / 2 / 3 / 4 / NO | ||
| Recovery and data safety | 1 / 2 / 3 / 4 / NO | ||
| Least privilege and developer experience | 1 / 2 / 3 / 4 / NO |
Independent debrief notes
Evidence that matched the role outcome:
______________________________________________________________
Different readings of an answer and the relevant anchor:
______________________________________________________________
What was not observed, and the same follow-up to use:
______________________________________________________________
Support, authority or staffing gap in the role brief:
______________________________________________________________
Before using it
- Confirm the role actually includes the authority and operational scope in this scenario.
- Have platform and service owners review the facts and anchors.
- Dry-run the timing and wording; no human pilot is claimed here.
- Tell candidates the format and duration in advance and offer an adjustment path.
- Use a separate implementation exercise if implementation skill is a job requirement.
This is a discussion aid, not a validated selection instrument, an incident simulation or legal advice. People remain responsible for fair administration and the final decision.