July 24, 2026·3 min read
Ask a platform engineer to "explain how a Kubernetes pod gets scheduled" and you will get a clean, confident answer from someone who has never once fixed a pod stuck in Pending. The words are memorizable. The job is not.
Platform work is diagnosis under uncertainty. A deploy is failing, the on-call is paging, and the person has to read the cluster's actual state and act. That is the thing you want to measure, and a verbal walkthrough measures none of it.
The alternative is simple: give the candidate a real cluster that is already broken, and watch them fix it.
A whiteboard Kubernetes question rewards vocabulary. It tells you the candidate has read about controllers, services, and ingress. It does not tell you whether they can find why a rollout is wedged at 3 replicas of 5.
The gap shows up fast in real work. We have watched engineers who could recite the reconciliation loop freeze the moment kubectl get events scrolled past. And we have watched quieter candidates who fumbled the theory question calmly walk a CrashLoopBackOff back to a missing config key in under ten minutes.
Recall and operation are different skills. Only one of them is the job.
The cleanest platform interview is a running cluster with a real, reproducible fault, plus kubectl access and a short brief: "the checkout service should be serving traffic and it is not. Find out why and fix it."
Good broken scenarios share the traits of any good debugging task (we cover the general version in how to assess debugging skill):
Scenarios that discriminate well:
Pending because of an unschedulable resource request or a missing node selector. Tests whether they read kubectl describe before guessing.CrashLoopBackOff driven by a bad env var or a missing secret. Tests whether they read logs and reason about the container lifecycle.Each one has a clean answer and a messy path to it. The path is what you are buying.
The fix matters less than how they get there. Strong platform engineers show a recognizable pattern:
kubectl get, describe, events, logs, in that rough order. They build a picture of current state before changing anything.describe output. Weak candidates scroll past it; strong ones stop and read the Events block.delete or apply, do they consider what else it touches? That instinct is the difference between a safe operator and an incident.Watch for the anti-patterns too: reaching for kubectl delete pod as a first move (restarting to make a symptom disappear without understanding it), editing live resources with no record of what changed, or narrating the textbook while ignoring what the cluster is actually reporting.
Turn the behaviors above into a short rubric so two interviewers reach the same verdict (more on that in how to write a technical interview rubric). Score the observable process, not just the outcome:
A candidate can fail to fully fix the cluster and still score well if the reasoning is sound and time simply ran out. A candidate who fixes it by luck, with no explanation and a trail of unrelated edits, is not the operator you want on call.
You cannot fake a Kubernetes cluster on a shared document. The interesting signal is the sequence of commands and how the cluster responded, and that only exists if there is a real cluster.
EasyEnv gives the candidate a live environment (we call it a workspace) with a genuinely broken cluster inside it, and records the session. You see the terminal, every command, and the order they ran, so a fuzzy "they seemed to know their way around" becomes a concrete record you can review with the rest of the panel. For a role where the cost of a wrong hire shows up at 2am, that record is worth more than any answer to "explain a pod."
Reciting Kubernetes concepts is a baseline. Restoring a broken cluster under mild pressure is the job. Hand the candidate something broken, watch how they narrow it down, and score the path, not just the fix.
Interview for the on-call, not the exam.
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
Calm under fire is the SRE trait you can't ask about and can't fake. Run a short simulated outage in a real environment and watch how a candidate triages. Here is how to set it up and what to score.
Most interviews test whether a candidate can write code from scratch. Real engineering is mostly reading, diagnosing, and fixing code you did not write. Here is how to interview for that.
Read more
Reviewing a take-home is easy to do badly. Some things that look like problems are noise, and some real warning signs are quiet. Here is how to tell them apart.
Read more
