Hire a frontend engineer who fits your team
Fifteen minutes of real work situations, with no right or wrong answers. You see the decisions a coding test can’t: what they’d build, what they’d push back on and what they’d cut when the date moves, next to how your team works.
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 with a request
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.
The Tech Lead: “Design handed over the new dashboard. It ships in two weeks.”
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
Situations a frontend engineer runs into
Twelve short situations like this one, drawn from the day-to-day work of the role. The live ones 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.
A recommendation for your frontend engineer role
You mark what this job can’t do without. The report opens with a clear call for it, shows where the candidate stands on each capability you chose, and gives you three questions for the interview.
Marta R. · Frontend Engineer
Leads with both of the things you named
Of what 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.
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. |
From open role to shortlist
Choose the role, what it should lead with and how your team works. It takes about ninety seconds.
Send it to each candidate or paste it in your job ad. There’s nothing to install and nothing to schedule.
Short, varied situations from the day-to-day of the role. No right or wrong answers, about fifteen minutes, on any device.
The report is ready when they finish: how close each person is to your profile, and questions for the interview.
New link
Other product roles
One credit per candidate, spent only when they start. The first is free (see what the packs cost), and nothing expires.
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. The same engineer can fit a two-person team and not a platform group, or the other way round.
One credit per candidate, spent only when they start. The first one is free with no card, and credits don't expire.
Read these before you decide
10 min read
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 read
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 read
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
Hiring a frontend engineer right now?
Invite one candidate and read their report the moment they finish. The first one is free, with no card.