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 — a degree, a former employer, a job title, years served. The practical test is simple: if you removed the CV from your process entirely, would you still be able to decide? If not, you are not 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 not accuracy against speed in general; it 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 cannot 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 — is a refinement of 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 already eliminated most of the market.

Evaluate a UX researcher on what they refuse to conclude: whether they reframe a question that cannot 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 should not have been run.

A coding test answers whether someone can build it. It does not answer whether they should have — 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 are shipping with. Those are the decisions that 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 should not 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 take on purpose. A GitHub profile shows what they merged. The value of this role is largely 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 cannot 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 is 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 require information the candidate could only have if they were actually in the room — a decision that went wrong, a constraint they lost to, a thing they would 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 is 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 actually need a UX designer or a product designer, because in most companies today the title is the same job and in a few it genuinely is not. Then assess the three things a portfolio structurally cannot show: what they questioned in the brief, what they cut when the date would not 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 would 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 rehearsable. The ones that work put the candidate in a situation with no correct option — a request that contains its own answer, a stakeholder who will not 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 does not measure what someone refuses, what they kill, how they behave when a plan breaks, or how they hold a position with an executive — and if it runs as a take-home, it also ranks how much unpaid time a candidate had available that week.

You usually cannot tell from the artefact itself, and detection tools do not work reliably. What you can do is look for the absence of specifics — real constraints, abandoned directions, disagreements, numbers that are inconveniently precise — and then ask one question in the interview that requires knowledge only someone who was in the room could have.

Generative AI collapsed the cost of producing the artefacts hiring used as proxies — screens, case studies, cover letters, application volume. It did not change what makes someone good at the job. The practical response is to stop assessing artefacts produced privately 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, produces work that cannot be compared between candidates, and cannot show how someone reacts when a constraint changes — because in a take-home nothing changes. It is fixable: cap it hard, make every candidate answer the identical scope, and score against a written rubric.

Score a design exercise against written anchors, not 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.