15 minutes, report the moment they finish
Frontend engineer judgment assessment
Twelve written situations, about fifteen minutes, that measure the decisions a coding test can't see: what to build, what to refuse, how to handle a design that won't survive live data, and what to cut when the date moves.
The gap
What you can’t see when you hire a frontend engineer
A coding test shows whether they can write the function. It never shows whether they should have.
The case starts here
The Tech Lead: “Design handed over the new dashboard. It ships in two weeks.”
Every case opens with a request that already contains its own answer, because that’s how requests arrive at work. What we measure starts with whether they notice.
What this case shows you
- Whether they spot the states the design forgot
- How they respond to a spec that breaks at scale
- What they cut first when the release date moves
- How they push back on a design without blocking it
- Whether they name the risk they're shipping with
The kind of call they make
Situations a frontend engineer runs into
Twelve short situations like this one, drawn from the day-to-day work of the role. The live situations are confidential, because an assessment you can rehearse stops measuring anything.
Example situation
Design hands over a new dashboard and it ships in two weeks. Reviewing it, you notice there's no empty state, no error state, and the main table assumes every account has at least one project.
What you get
A recommendation for your frontend engineer role
You mark what this particular job can’t do without. The report opens with a clear call for that job, shows where the candidate stands on each capability you chose, and gives you three questions to ask in the interview.
Marta R. · Frontend Engineer
Leads with both of the things you named
Reaches first for thinks about what breaks, with the rest close behind.
Why these matter for a frontend engineer
- Sweats states and edge cases
- The defining capability of the role. Empty, error, loading, offline, zero results, one result, four hundred results, and the string that's far longer than the mockup allowed for.
- Knows what is cheap to build
- Used here as a communication skill as much as a technical one. Being able to say 'that version is three days, this one is an afternoon and covers the same case' is what turns a blocker into a decision.
- Explains decisions outside the team
- Pushing back on a design without blocking the release. An engineer who is right and unheard has the same effect on the product as one who is wrong.
Against what you already do
What each format sees, and what it misses
| Format | What it shows you | What it misses |
|---|---|---|
| Coding test or live algorithm | Whether they can write correct code under time pressure, and how they reason about a problem with a known answer. | Whether the thing should be built at all. It's a useful filter and worth keeping, but a front-end engineer's expensive mistakes are almost never 'couldn't write the function'. They're 'built the design exactly as drawn, including the part that breaks with real data'. |
| Take-home project | Code quality, structure, and what they consider done when nobody is watching. | How they handle a spec that's wrong. The take-home brief is written to be buildable; the tickets on your board aren't. |
| System design interview | Architectural reasoning at a level most front-end roles rarely exercise. | The daily decisions. Which state the design forgot, what to cut when the date moves, and how to tell a designer their layout won't survive a name with forty characters. |
| This assessment | The judgment a coding test can't reach: what to build, what to refuse, what to cut and which risks they'll name out loud. Twelve identical situations, read against your role. | Whether they can code. Keep the coding test. This is the half of the interview loop that usually goes unmeasured. |
How it works
Three steps,
with no calls and no setup
What must they be good at?
- Spots when the brief is wrong
- Knows what the data supports
- Moves without being told
- Sweats states and edge cases
One credit per candidate, spent only when they start. The first is free (see what the packs cost), and nothing expires, so a role on hold costs nothing.
Questions
Assessing frontend engineers, in practice
No, keep yours. A coding test shows whether they can build it. This shows whether they should, and what they do with a spec that breaks at scale. The two catch different failures, and you need both.
No. It's written situations: a design handed over with states missing, a deadline that halves, a spec that won't survive production data. It's about the decision rather than the syntax, and keeping code out is what makes the answers comparable across candidates.
About fifteen minutes, on any device, whenever suits them. Nothing to install, no scheduling, and the report reaches you the moment they finish.
They can try, and it helps them very little. There's nothing to write or polish, and a model can't know what this particular person would do. Read past the headline.
No. You describe what the role can't do without before sending the link, and the report is read against it. An engineer assessed for a two-person team and for a platform group gets two different recommendations.
One credit per candidate, spent only when they start. The first one is free with no card, and credits don't expire.
Related reading
Read these before you decide
10 min
How to evaluate a UX writer
Evaluate a UX writer on whether they fix the interface or just the sentence: whether they flag the broken flow behind a confusing message, how they handle a destructive action, what they do with a legal constraint they can't remove, and how they decide what not to say. A writing sample shows the final line. It never shows what the screen looked like before, or what they refused to paper over.
Read it9 min
How to hire a product manager
Hiring a product manager well comes down to what they refuse rather than what they shipped: whether they interrogate a request instead of writing the ticket, how they size an opportunity with incomplete data, what they say no to and how, what goes first when the deadline halves, and which single metric they'd move and by how much. A roadmap shows the output of a hundred decisions and none of the decisions.
Read it8 min
Product manager interview questions worth asking
A question discriminates when a strong and a weak candidate give visibly different answers to it. Most standard product manager questions fail that test because the good answer is public and can be rehearsed. The ones that work put the candidate in a situation with no correct option (a request that contains its own answer, a stakeholder who won't move, a deadline that halves) and read what they reach for first.
Read it