Roles
We assess the people who build the product
Six roles, one rubric. We only cover work where the job is deciding under ambiguity and the brief always arrives wrong — so backend, data and infrastructure are deliberately out of scope.
That limit is the point. A library of four hundred shallow tests is a different product, and it already exists.
Request access to the betaThe same instrument, six times
Every role gets 12 written situations in about 15 minutes, across 4 short parts. What changes between them is the situations themselves — a product manager is asked about a deal lost to a missing feature, a UX writer about an error message that is covering for a broken flow. The rubric, the scoring and the report are identical.
That is what makes two candidates for the same job comparable, and it is the reason we do not add roles quickly.
Why these six and not four hundred
A role belongs here when the person builds the product experience and the job is deciding under ambiguity. Backend, data and infrastructure are out on purpose: their hard part is verifiable in other ways, and a wide catalogue would make us one more test library.
You pick which capabilities can veto a hire when you set the role up, so the same answers read differently for two different jobs. How the scoring works, and what it costs.
Product Designer
15 min
A portfolio shows the final screens. It never shows what the brief said before they fixed it, what they argued for and lost, or what they cut when the deadline moved.
See the assessment →Product Manager
15 min
A CV lists shipped features. It never shows which ones they argued against, what they killed, or whether the roadmap was theirs or handed to them.
See the assessment →UX Researcher
15 min
A research portfolio shows tidy findings. It never shows the studies that were badly framed, or whether the recommendation survived contact with the business.
See the assessment →Frontend Engineer
15 min
A coding test shows whether they can write the function. It never shows whether they should have.
See the assessment →Design Engineer
15 min
A GitHub profile shows what they merged. It never shows what they talked the team out of.
See the assessment →UX Writer
15 min
A writing sample shows the final sentence. It never shows what the screen looked like before, or what they refused to paper over.
See the assessment →
Before you pick one
No, and it is deliberate rather than a roadmap item. Each role has its own bank of situations written for the decisions that job actually makes — a product manager is asked about a deal lost to a missing feature, a UX writer about an error message covering for a broken flow. Running someone through another role's situations would produce a number, and the number would not mean anything.
Pick by what the person will decide, not by what the title says. If they own what gets built and why, that is the product manager assessment even if you call it something else. If they live between design and engineering deciding when a component should exist, that is design engineer. Titles vary by company; the decisions do not.
Only where the job is deciding under ambiguity with a brief that arrives wrong — that is the limit, not a stage we are passing through. Backend, data and infrastructure stay out because their hard part can be verified other ways. If a role you hire for belongs inside that limit and is not here, tell us: the pages for roles we have not built yet carry a direct line for exactly that.
You have an open role right now.
Invite one candidate and read their report the moment they finish.