Architecture interviews that show their working.
Give a candidate a live system with real users and ten weeks of growth to survive. You get back every decision they made, when they made it, and what was bearing down on them at the time.
Sit the same assessment your candidates will. It takes half an hour.
A whiteboard tells you who interviews well.
Asking someone to design a system on a whiteboard measures recall and composure. It cannot show you how they behave when traffic is climbing, a component is saturating, and shipping the fix carries its own risk — which is the job.
This puts them in that position for thirty minutes and writes down what they did.
How it works
Create an assessment
Pick the scenario and the rules — how long it runs, whether the in-run advisor is available, whether they can see the roadmap of what is coming.
Invite a candidate
They get a private link that works once and expires after three hours. Generate a new one any time; the old one stops working immediately.
Read what they did
Every deploy, the minute it landed, what it changed, and the event it was racing. The grade sits beside it as one input.
The report leads with evidence, not a score.
Two candidates can finish on the same architecture having thought about it completely differently. One prepared ahead of a flagged event; the other shipped in a panic while it was already breaking. That difference is the interview.
What they did — excerpt
- Deployed at 4.5 minhot-swap
added In-Memory Cache · rewired app>cache · on the live path
1.5 min before The Lumen Awards — prepared ahead
- Deployed at 12.5 minrolling
added CDN Edge · rewired cdn>gw
during Breaking news — reacting under load
Alongside it: a Well-Architected grade across six pillars, a requirement-by-requirement explanation of what held and what did not, and what the simulated world did back — peak load, worst latency, users lost.
The result is recomputed, not reported.
Scored on our servers
The candidate’s browser submits only the decisions they made. We replay those against the same fixed starting conditions and compute the outcome ourselves, so a result cannot be edited into existence from a developer console.
Every candidate, same world
An assessment fixes its starting conditions, so two candidates face an identical thirty minutes — the same growth, the same events, at the same moments. That is what makes comparing them fair.
Links that expire
An invitation works once and lapses after three hours. We store only a hash of it, so it cannot be recovered from our database — the same way a password is handled.
Your data stays yours
Candidates, assessments and reports are visible only to your organisation. Deleting a candidate removes their invitations and their run, report included.
What the candidate sits
They inherit a working social feed — a gateway, an application tier, and the stores behind it — used by five thousand people. Over thirty minutes the audience grows to about a million, and flagged events push far more traffic than the headcount suggests: a cup final where everyone reads one thread, an announcement where everyone replies at once.
They can see what is coming, rehearse a change before shipping it, and deploy whenever they like — but every deploy carries a window where capacity dips. Nothing to memorise, nothing to look up.
Stop guessing how they think.
Set up an assessment and send your first link in a couple of minutes.
Sign in to get started