Sample report
This is the whole thing. Nothing held back.
Most assessment tools show you a score and ask you to trust it. Below is a complete report from one session, exactly as a hiring team receives it. The candidate passed, and there is still something in here you would want to ask them about in the next round. That is the point.
- Scenario
- broken-etcd · variant 02 (corrupted member)
- Time box
- 45 minutes
- Finished in
- 22m 36s
- Commands run
- 214 · 3 non-zero exits
- Graded
- outside the sandbox, against the live cluster
The recommendation, and why
They fixed it, but the fix is not reproducible from the declared configuration — the next apply or rollout reverts it. Worth one targeted question.
That sentence is not an opinion about the candidate. It is a published rule applied to three things this session produced: the graders passed, one major blast-radius finding stands, and the fix was verified before they declared done. You can read all three below, and you can disagree with the rule.
At 14:02 they edited a live Deployment to quieten a restart loop while they worked. That is a reasonable debugging move and an unreasonable way to leave production, because the cluster and the manifests now disagree. It is not a reason to reject them. It is a very good ten-minute conversation in the next round, and you now know to have it.
What the grader verified
Run outside the candidate's environment, against the live cluster. A fake kubectl cannot reach this. Checks are weighted, so “made it Ready but it does not survive a restart” is a reportable outcome rather than a flat pass.
- cluster healthy, writes succeeding
- all three etcd members healthy
- no other workload in the namespace was left unhealthy
- the fix survives a control-plane restart
How they diagnosed it
How they worked, as countable facts read off the recording.
- Time to root cause04:12
The first command that touched the faulted object.
- Commands that changed state6
Against 208 that only read. Reading before writing is the habit you want.
- Verified before declaring doneyes
Read the system back after their last change, rather than declaring done.
- Blast radius2 / 4
Questionable. One major finding — see below.
Blast radius
What it cost to get the system back. Detected by code — a command scan and a diff of the files they changed — not by asking a model what it thinks. This is the section no other assessment tool produces.
The cluster and the manifests now disagree. The next apply, sync or rollout silently reverts the fix.
14:02 · $ kubectl edit deploy/payments-api · detected by command scan
no NetworkPolicy, resource limit, probe or quota deleted
no namespace, PVC or deployment removed · no privilege widened
The command timeline
Every command is timestamped and kept. These are the moments that decided the session — milestones, failures and blast-radius findings, all detected from the recording. The full 214-command log is in the report below this.
- 00:00First thing they ran.
$ kubectl get nodes; kubectl get pods -n kube-system - 01:40
$ kubectl logs -n kube-system kube-apiserver-cp-0 | tail -50 - 04:12First command that touched the faulted object. Returned exit 1 — the command failed.
$ etcdctl endpoint health --cluster - 07:553m passed since the previous command.
$ openssl x509 -in peer.crt -noout -dates - 14:02Changed a live object imperatively — this is the blast-radius finding.
$ kubectl edit deploy/payments-api - 18:47Changed the state of the system.
$ etcdctl member remove 8e9e05c52164694d - 21:10The last change they made to the system.
$ etcdctl put smoke test && etcdctl get smoke - 22:36Read the system back after their last change.
$ etcdctl endpoint health --cluster
What you do with this
A recommendation to advance is not an offer. It is a defensible reason to spend an hour of your senior engineer's time on this person rather than the next one, and a specific thing to ask them about.
Notice what the report never does. It does not rank the candidate against a percentile you cannot inspect. It does not decide anything — the recommendation is a published rule over the outcome, the blast findings and how they worked, and you can disagree with the rule. Every claim above points at a timestamp in the command log you can read yourself.
Everything on this page is produced by code running outside the candidate's environment: the graders against the live cluster, the blast findings from the command scan and the file diff, and the timeline from the session recording. The hiring decision is yours, and it is not recorded here unless you record it.