Interviews on real, broken infrastructure.
Send your candidate a link. They land in a live Kubernetes, Docker, Linux or Terraform environment that is genuinely broken, with a time box to bring it back. You get a plain-English report on how they did it and a replay of every command. You do not need to be a DevOps engineer to read either one.
In private beta · Built by an engineer who carries the pager · No terminal needed on your side
Every infra loop is testing the wrong thing
A production incident is diagnosis under time pressure with incomplete information. Almost nothing in a standard hiring loop looks like that.
Resume and a chat
Reads well, tells you nothing about behaviour under pressure. Everyone has run Kubernetes on their CV.
LeetCode-style screen
Tests an algorithm skill your infra hire will use approximately never. Strong engineers refuse it and you lose them at the top of the funnel.
Take-home project
A week of unpaid work, high drop-off, and in 2026 you cannot tell how much of it a model wrote.
Trivia quiz
Measures recall of flags and defaults. The job is diagnosis, and diagnosis is not recall.
The cost of getting this wrong is not the interview time. It is the first real incident, six weeks in, when you find out.
How it works on your side
Pick a lab, or upload the JD
Browse 120+ ready-made labs and filter by tool and difficulty, or upload the job description and let the AI engine suggest the ones that test it. You do not need to know Kubernetes to choose well.
Send a link
The candidate opens a browser terminal into a live environment with a genuine fault injected, booted in under 5 seconds. Nothing to install, no scheduling call. You are charged only when they actually start.
They troubleshoot like it is the job
Googling allowed, AI allowed, panic optional. A deterministic grader checks whether the system genuinely recovered while an AI evaluator watches every command, exit code, approach and dead end.
You read a report, not a number
Plain English: what they thought was wrong, how fast they got there, what they broke on the way, and how well they drove their AI. No terminal required on your side.
What your candidate actually opens
No question text, no title telling them what broke. A symptom and a system that is genuinely down. Six of the labs in the library, and what each one is really testing:
CrashLoop in payments
30mA pod restarts every 90 seconds. The logs it prints look fine.
tests
Whether they read the previous container log instead of the current one, and whether they check the probe before blaming the app.
Broken etcd cluster
45mThe API server is up but every write times out.
tests
Working from a symptom to a control-plane dependency nobody mentioned, under pressure, without a rollback button.
Disk full, inodes gone
30mdf says there is space. The service still cannot write.
tests
Whether they know df and du disagree for a reason, and whether they find the deleted-but-open file holding it.
Terraform state drift
45mPlan wants to destroy production. Someone changed it in the console.
tests
Judgement, mostly. The wrong fix here is fast and catastrophic, which is exactly what a blast-radius score catches.
The lying dashboard
30mEvery panel is green. Users say the site is down. Both are true.
tests
Whether they trust instrumentation over reality, which is the single most expensive habit in an on-call engineer.
Image that lies
30mThe tag says v2.1. The behaviour says otherwise.
tests
Digests over tags, and whether they verify what is actually running before changing anything.
Every scenario ships with many randomized fault variants, so two candidates sent the same lab are not debugging the same thing.
Anyone can tell you whether the cluster came back up.
Faultybox tells you how.
Not "can they code?" but "can they fix it when nobody told them what broke?"
What lands in your inbox
Not a percentile. A description of how someone thought, written for a human who has to make a decision about them.
Diagnosis, not just outcome
Time to first correct hypothesis, how many wrong ones came first, and whether they recovered from their own dead ends. Two candidates can both pass and be nothing alike.
Blast radius
What it cost to get the system back: safety checks disabled, resources deleted to make a symptom disappear, shortcuts that page you next week. Nobody else scores this.
AI usage, graded
Your engineers will use AI on the job, so the interview should measure it. Did they give it the right context, catch the wrong suggestion, verify before applying?
A replay you can forward
Hiring managers do not trust assessment scores, they trust watching the fix happen. Every report links to a scrubbable terminal recording your whole panel can read.
candidate: #4-217 scenario: broken-etcd PASS in 22m ────────────────────────────────────────────────────── diagnosis strong first hypothesis correct in 4m 12s recovery restarted etcd with correct flags, verified before declaring done blast radius ⚠ 1 finding └ disabled liveness probe at 09:14, never re-enabled ai usage effective pasted the right logs, rejected one wrong suggestion (kubectl delete ns) replay 22m 36s of terminal, 214 commands
Who you can screen with it
Any role where the real work is keeping something alive that you did not write and cannot restart casually.
SRE and on-call
The job is diagnosis at 3 AM with partial information. That is what the labs are.
Platform and infrastructure
Terraform drift, broken control planes, the cluster nobody wants to touch. Judgement matters more than recall.
DevOps and build engineers
Container images that lie, pipelines that pass while shipping the wrong artifact, monitoring that agrees with everyone.
Backend engineers going on-call
Strong developer, first pager. Find out how they behave when the system is theirs before you hand it over.
What changes in your loop
This replaces one stage, usually the take-home or the first technical screen. Everything else about how you hire stays yours.
Today
- 1Screen a resume that says "Kubernetes" and hope
- 2Book 45 minutes of an engineer to ask trivia
- 3Send a take-home, lose a third of candidates to it
- 4Argue in a debrief about whether the answer was good
- 5Find out for real during the first incident, six weeks in
With Faultybox
- 1Send a link, no scheduling call, no engineer time
- 2Candidate fixes a real fault in a browser, time-boxed
- 3Report arrives in plain English with a command timeline
- 4Debrief on evidence, with the replay open
- 5Find out before the offer, not after
$ cat /etc/faultybox/ai-policy ai_allowed: true ai_detected: irrelevant ai_graded: true ai_evaluator: watching # every command, every approach proctoring: disabled # replay beats surveillance
AI allowed. Graded, not policed.
Your engineers use AI on the job. An interview that bans it tests a job that doesn't exist, and proctoring is an arms race you're funding, not winning. Faultybox inverts it: the candidate can use AI, and the transcript shows you whether they drove it or it drove them.
You pay per interview, not per seat
Hiring is bursty. Per-seat pricing charges you for the quiet months, so we do not do it. Nothing expires.
Candidates can practise on these labs in their own time on a separate plan. It gives no one an advantage in your loop.
The questions buyers actually ask
- Nobody on my side is a DevOps engineer. Can we still run this?
- That is the case we designed for. Upload the job description and the AI engine picks the labs. The report comes back in plain English with the technical judgement already made, so a recruiter or a hiring manager can read it without a terminal.
- Will candidates refuse to do it?
- It is time-boxed, runs in a browser tab, and it is visibly about the actual job rather than a puzzle. Engineers who would walk away from a take-home tend to take this one, and the ones who enjoy it are usually the ones you want.
- What stops them cheating?
- Three things, none of which is surveillance. AI is allowed and graded, so there is nothing to hide. Every scenario has many randomized fault variants, so a leaked walkthrough is worthless. And the replay shows the whole session, which is where a ghost-written fix looks obviously wrong.
- Do you record the candidate?
- No camera, no microphone, no screen capture, ever. The replay is the terminal session: commands, exit codes and file diffs. It is text, it is searchable, and it is the only thing we keep.
- How much does it cost to try?
- Nothing. The free tier is a set of sessions you can run yourself plus candidate invites, on the full lab library, with no card. After that you buy interview credits, which never expire and are charged only when a candidate starts.
- Can you build a scenario on our stack?
- Yes. Custom labs are hand-built on your services and your failure modes, available on Starter and up. Email us and we will scope it.
Latest from the blog
All posts →SRE interview prep: a 4-week plan built on practice, not flashcards
SRE interview preparation as a 4-week training plan: Linux fundamentals, Kubernetes debugging, incident scenarios, and communication - with drills for each.
CreateContainerConfigError: the ConfigMap/Secret mistakes behind it
CreateContainerConfigError decoded: every ConfigMap and Secret mistake that causes it, the exact describe events, and the fastest fix for each.
High load average: what it actually measures and how to debug it
High load average on Linux doesn't always mean busy CPUs. What load really counts, how to split CPU from I/O wait, and a vmstat/pidstat/iostat path.
Run one yourself first. It takes 20 minutes.
Break something on purpose, read the report it produces, then decide whether you want a candidate in there.
Private beta, limited seats. Hiring teams get white-glove setup and one scenario hand-built on your stack.