Guides to hiring product people

Skills-based hiring means the hiring decision rests on evidence of what someone can do, rather than on proxies for it such as a degree, a former employer, a job title or years served. The practical test is simple: if you removed the CV from your process entirely, could you still decide? If not, you aren't hiring on skills, whatever the policy says.

Traditional hiring sorts candidates on proxies (degree, employer, title, tenure), which is fast, cheap and works as long as the proxies stay correlated with ability. Skills-based hiring sorts on demonstrated ability, which is slower and more expensive up front and produces fewer wrong hires. The trade is a small fixed cost per role against a large variable cost per mistake.

Start with one role, not a programme. Write down the three capabilities that role can't do without before you post it, give every candidate the identical exercise, and score independently against a written rubric before anyone discusses. Everything else (platforms, policies, dropping degree requirements) refines those three steps, and none of it works without them.

The choice is decided by two numbers before any feature list matters: how many different roles you hire for, and what a wrong hire costs you. Wide and cheap points to a test library; narrow and expensive points to a purpose-built instrument. Everything vendors compete on (question formats, integrations, dashboards) only starts to matter once those two numbers have eliminated most of the market.

No large assessment platform is built for design hiring, and you should know that before you shop. Broad libraries such as TestGorilla and Testlify cover design thinly because their value is breadth. Technical platforms such as Adaface go deep where answers are verifiable, which design mostly isn't. Work-sample tools such as Vervoe fit roles whose output can be produced and graded in a sitting, which favours spreadsheets and code over interface work. Psychometric tools such as Alva Labs and Bryq measure traits that stay the same whichever role you're filling. For design, the practical shortlist is a portfolio review for craft plus one instrument for judgment, and most teams struggle because nobody sells them the second half.

Product management is the hardest role on this list to assess with a standard tool, because almost nothing a PM does has a verifiable answer. Skills libraries such as TestGorilla and Testlify test adjacent things (analytics, tools, cognitive ability), and psychometric platforms such as Alva Labs, Bryq and Criteria measure traits that apply to any role. Neither reaches the decisions the job is made of: separating a request from a problem, sizing an opportunity on incomplete data, and saying no in a way that keeps the person. Most teams substitute the case study interview. That's the right instinct, with one weakness: the formats are public, the frameworks are memorised, and a small industry teaches people to perform that hour.

A situational judgement test presents realistic work scenarios and asks what the candidate would do, looking at which action they reach for rather than what they know. It sits between a skills test, which needs a verifiable answer, and a personality questionnaire, which asks people to describe themselves. It's used when the decisions that matter in a role have no correct answer. The format has a long history in selection research, and it's also easy to build badly. The common failure is a scenario with one obviously right option, which measures only whether the candidate can spot what the employer wants to hear.

Evaluate a UX researcher on what they refuse to conclude: whether they reframe a question that can't be answered, whether the method follows the decision rather than the budget, how they spot a flawed study and say so, and how they deliver a finding nobody wants. A portfolio shows conclusions that survived. It never shows the studies that shouldn't have been run.

A coding test answers whether someone can build it. It doesn't answer whether they should have. That comes down to whether they spot the states a design forgot, how they respond to a spec that breaks at scale, what they cut when the date moves, and whether they name the risk they're shipping with. Those decisions make a frontend hire expensive or excellent, and none of them appear in an algorithm exercise.

Evaluate a design engineer on the decisions nobody logs: when a component should be new, a variant, or shouldn't exist at all; how they trade system consistency against shipping this week; what they do with a design that ignores the system; and which debt they choose to take on. A GitHub profile shows what they merged. Most of this role's value sits in what never got built.

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.

Hiring a product designer well comes down to assessing decisions rather than screens: whether they reframe a badly posed brief, what they ask before designing, what they cut when resources disappear, how they respond when a constraint changes, and whether they can name the weakest part of their own proposal. Visual craft is necessary, but it's the easiest thing to verify and the least predictive of seniority.

Most design interview questions fail because a well-prepared candidate can answer them from their portfolio. Questions that discriminate share one property: they need information the candidate could only have if they were actually in the room, such as a decision that went wrong, a constraint they lost to, or a thing they'd cut.

Self-report personality instruments measure what a candidate believes about themselves, or what they think you want to hear, which in a hiring context comes to the same thing. They predict job performance far more weakly than work samples, create legal exposure when used as a selection gate, and are visibly resented by experienced candidates.

Start by deciding whether you need a UX designer or a product designer, because in most companies today the two titles describe the same job and in a few they don't. Then assess the three things a portfolio structurally can't show: what they questioned in the brief, what they cut when the date wouldn't move, and what they refused to ship. Everything else (visual craft, tool fluency, case study narrative) is either visible in the work or no longer reliable evidence of anything.

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.

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.

A product case interview measures structured thinking, communication under mild pressure and comfort with ambiguity. It doesn't measure what someone refuses, what they kill, how they behave when a plan breaks, or how they hold a position with an executive. Run as a take-home, it also ranks how much unpaid time a candidate had available that week.

You usually can't tell from the artefact itself, and detection tools don't work reliably. What you can do is look for missing specifics (real constraints, abandoned directions, disagreements, numbers that are inconveniently precise) and then ask one interview question that only someone who was in the room could answer.

Generative AI collapsed the cost of producing the artefacts hiring used as proxies: screens, case studies, cover letters, application volume. It didn't change what makes someone good at the job. The practical response is to stop assessing artefacts produced in private and start observing reasoning under conditions you control.

A take-home assignment measures how much unpaid time a candidate is willing and able to spend. It produces work you can't compare between candidates, and it can't show how someone reacts when a constraint changes, because in a take-home nothing changes. It's fixable: cap it hard, give every candidate the identical scope, and score against a written rubric.

Score a design exercise against written anchors rather than impressions. Define three to five criteria, describe what each score level looks like in observable behaviour, fix the weights before you read anything, and require a quote from the candidate's work to justify every score. Then calibrate on people whose ability you already know.