How to assess · For hiring teams
How to Assess Kubernetes Skills When Hiring
The test formats that actually work for Kubernetes, what a strong answer looks like, sample questions and a scoring rubric you can use as-is.
The short answer
Assess Kubernetes with a task, not a conversation: broken-pod troubleshooting, manifest review, ai-scored assessment (e.g. cohesyve) or live cluster exercise. Score it against written criteria you fix before you see any submissions, and weight the criteria that the role actually depends on.
- Debugs a failing pod methodically: describe, events, logs, previous logs, exec — in that order
- Sets resource requests and limits deliberately and can explain what happens when each is wrong
- Distinguishes liveness, readiness and startup probes and knows the damage a wrong one does
- Uses rolling updates with a rollback path and knows how to pause and revert a deployment
Paste a job description; Cohesyve generates a role-specific assessment and rubric. Ten candidates free, no card.
Kubernetes experience is easy to claim and hard to verify. Plenty of engineers have applied a manifest someone else wrote; far fewer can look at a pod stuck in CrashLoopBackOff, read the events and logs, and know whether it is a bad probe, a missing config map, a resource limit or an image problem. That diagnostic skill is what you are hiring for, along with the judgement to run workloads safely: right-sized requests and limits, sensible probes, rollouts that can be reversed, and an honest understanding of what the cluster will and will not do for you. This page covers how to assess Kubernetes as an operator, not as a vocabulary test.
Why Kubernetes is worth testing
Kubernetes misconfigurations are expensive and slow to surface. A missing resource limit takes down a node under load weeks later; a liveness probe that is too aggressive restarts healthy pods during a traffic spike; a deployment with no rollback strategy turns a small bug into an outage. Testing shows whether a candidate has actually operated clusters or only deployed to them, and that difference determines whether the platform is something the team trusts or something it fears.
What strong Kubernetes looks like
- Debugs a failing pod methodically: describe, events, logs, previous logs, exec — in that order
- Sets resource requests and limits deliberately and can explain what happens when each is wrong
- Distinguishes liveness, readiness and startup probes and knows the damage a wrong one does
- Uses rolling updates with a rollback path and knows how to pause and revert a deployment
- Understands what a Service, Ingress and NetworkPolicy each do and where traffic actually flows
- Keeps secrets out of manifests and applies least privilege with RBAC
- Knows the limits of the platform: what it does not schedule well, what it does not protect you from
Ways to assess Kubernetes
Broken-pod troubleshooting
Provide the `describe` output, events and logs for a pod that is failing (a misconfigured probe, an image pull error, an OOMKilled container, a missing secret — pick two). Ask the candidate to diagnose and propose the fix.
Pros
Cons
Best for Any level; the subtlety of the planted fault scales it.
Manifest review
Give a Deployment, Service and Ingress with problems — no resource limits, `latest` image tag, secrets in env, liveness probe hitting a slow endpoint, single replica for a critical service. Ask what they would change and why.
Pros
Cons
Best for Mid and senior platform roles.
AI-scored assessment (e.g. Cohesyve)
Generate a Kubernetes scenario from the job description — a troubleshooting case, a manifest review, a rollout plan — with a rubric. Each candidate receives a different variant; written reasoning is scored.
Pros
Cons
Best for Screening before engineer-led interviews.
Live cluster exercise
Give access to a sandbox cluster with a broken workload and forty-five minutes. Ask them to get it healthy and explain what they found.
Pros
Cons
Best for Final-round for senior operators.
Cohesyve
Run a Kubernetes assessment on your next opening
Cohesyve generates a unique Kubernetes task per candidate from your job description, with the scoring rubric attached. Questions are different for every applicant, so they cannot be shared or looked up.
What to test
Troubleshooting
Whether they can diagnose a failing workload from the evidence the cluster gives.
Workload configuration
Whether their manifests are safe to run.
Rollouts and reliability
Whether changes can be made and reversed safely.
Networking and security
Whether they understand where traffic goes and what is exposed.
Sample Kubernetes questions
A pod is in CrashLoopBackOff. What do you look at, in order?
EntryLook for Describe for events and exit code, current and previous logs, then probes and config. Method over guessing.
What is the difference between a liveness and a readiness probe, and what goes wrong if you swap them?
EntryLook for Liveness restarts, readiness removes from service; a slow endpoint as liveness causes restart storms.
A node keeps running out of memory and evicting pods. What is the likely cause and fix?
MidLook for Missing or wrong requests and limits, overcommit; fix by setting limits, using quotas, and right-sizing.
Design a rollout for a change you are not confident in.
MidLook for Canary or small max-surge, observe metrics, pause, automated rollback trigger, feature flag if possible.
How would you run a stateful database on Kubernetes, and when would you not?
SeniorLook for StatefulSets, storage classes, PDBs, backup and restore; honesty about managed services often being the better choice.
Red flags
- Deploys with no resource limits and cannot say why that matters
- Uses `latest` tags in production manifests
- Cannot describe how to roll back a deployment
- Treats Kubernetes as a black box that "handles scaling"
- Puts secrets in plain environment variables in a manifest
Scoring rubric
| Criterion | Weight | What strong looks like |
|---|---|---|
| Troubleshooting method | 30% | Reads events, logs and state in a sensible order and reaches the real cause. |
| Workload safety | 25% | Resources, probes and replicas are set with reasons. |
| Change management | 20% | Rollouts are reversible and observed. |
| Networking and security | 15% | Traffic flow is understood; secrets and RBAC are handled. |
| Platform judgement | 10% | Knows what Kubernetes is not good at and says so. |
Mistakes hiring teams make
- Asking definitions of objects instead of giving a broken pod
- Accepting a working manifest that has no limits or probes
- Not testing rollback at all
- Confusing certification with operating experience
- Skipping the "when would you not use Kubernetes" question — it reveals judgement
Roles that need Kubernetes
Common questions
Do I need a live cluster to assess Kubernetes?
No. `kubectl describe` output, events and logs on paper test diagnostic skill well, and manifest review tests configuration judgement. Save the live cluster for finalists in senior operator roles.
Is a Kubernetes certification a good signal?
It shows familiarity with the objects and commands. It does not show whether someone has run production workloads through incidents, which is what most roles need. Use it as a prerequisite at most.
How much Kubernetes should a backend developer know?
Enough to read a manifest, understand probes and limits, and debug their own pod from logs and events. Cluster operation is the platform team's job.
What is the best single Kubernetes screening question?
Give them a CrashLoopBackOff with the describe output and logs and ask them to talk through it. Method, vocabulary and experience all show in five minutes.
Cohesyve · Skill assessments for hiring
Test Kubernetes before the first interview
Generate a role-specific Kubernetes assessment from your job description and see who can do the work before you spend interview time on them.
1,500+
assessments completed
50%
faster time-to-hire
90%
completion rate
5 min
from JD to assessment
No credit card · 10 free candidates · Plans sized to your hiring volume
From the blog