Product designer interview questions that surface the decisions a portfolio hides
A portfolio shows outcomes and hides decisions. It can't tell you what the designer argued for and lost, what they cut, what the constraint was, or how much of the work was theirs. Those are the things that predict how someone will perform on your problems, and they're all conversational. Which makes a designer interview unusual in this family: the recorded round has real signal, and the portfolio it accompanies has less than people assume.
What the job actually involves
A product designer turns a problem into an interface: research, flows, interaction, visual design, and the negotiation with engineering about what's actually buildable this quarter. In smaller teams they also do research and front-end work, and the constraint is almost always time over ideas.
The work is collaborative in a way portfolios obscure. Almost every screen is the product of arguments with product managers about scope, with engineers about feasibility, and with the evidence when it disagrees with the designer's taste. How someone handles those is the job.
The questions, and what a good answer sounds like
Ask these as written. Each one is paired with what a strong answer sounds like, so two people rating the same candidate reach the same conclusion for the same reason.
1. Take a piece of work from your portfolio and tell me what you argued for and lost.
A good answer: A specific disagreement, the reasoning on both sides, and what they did after losing. This is the single most useful design interview question there is, because portfolios systematically remove exactly this information.
2. What did you cut, and why?
A good answer: Names a real cut and the trade-off. Designers who can't describe what came out of a project are describing work they didn't scope.
3. Research contradicts a design you're confident about.
A good answer: Interrogates the research, and if it holds, changes the design. Strong answers do both, accepting evidence uncritically is as weak as dismissing it.
4. Engineering says your design is too expensive to build.
A good answer: Asks what specifically, then finds the cheaper version that keeps the essential thing. Weak answers either capitulate entirely or insist on pixel fidelity.
5. How do you know a design worked after it shipped?
A good answer: Names what they measured and what they would have accepted as failure. Many designers never look after launch, and this question separates them fast.
6. How do you design for a user you can't talk to?
A good answer: Proxies (support tickets, sales calls, analytics, adjacent research) and explicit assumptions marked as assumptions. Common constraint, rarely asked about.
7. Show me something of yours that didn't work.
A good answer: Something real with a diagnosis. Portfolios are curated to a fault, and this question is where practice instead of presentation shows.
8. What was your actual contribution on the work you just showed me?
A good answer: Specific and honest about the team. Team credit inflation is common in design portfolios and asking plainly resolves most of it.
A scorecard you can rate against
Rate every candidate 1 to 4 on each row, and write the rating down before you watch the next one. Ratings drift badly when they're relative to whoever you just saw.
| Criterion | What a 4 looks like |
|---|---|
| Losing an argument well | Names a specific disagreement and what they did after. A 2 has never lost one. |
| Scoping | Describes a real cut and its trade-off. A 2 can't name anything removed. |
| Evidence over taste | Interrogates research and then changes the design. A 2 dismisses or capitulates. |
| Working with constraints | Finds the cheaper version that keeps the essential thing; a 2 insists on fidelity or folds. |
| Honesty about credit | States their specific contribution. A 2 uses 'we' throughout. |
How to run the screen
- Send the questions with the portfolio request. Asking what they argued for and lost in advance produces far better portfolio conversations than asking live.
- Use the recorded round to hear how they narrate decisions. This is one of the roles where speech genuinely carries the signal, because design work is defended verbally every week.
- Don't ask for spec work. A paid exercise on a real problem is defensible. Unpaid speculative work isn't, and the best candidates decline it.
- Ask the contribution question every time. It is a small question that resolves most portfolio ambiguity and it is uncomfortable to ask live.
- Keep a working session for the shortlist — a real problem, an hour, together. How someone thinks with you is the thing that finally decides it.
Running this on a large applicant pool is where it gets expensive. VoxScreen sends these questions as a single link, transcribes and scores every answer against criteria you set, and hands back a ranked list. Free for 50 candidates a month, no card.
Common hiring mistakes for this role
- Judging the portfolio as a visual artefact. It shows outcomes and hides constraints, team size and what was overruled.
- Not asking about lost arguments. It is the highest-signal question available and it is almost never asked.
- Requesting spec work. It filters for candidates with free time instead of candidates who are good, and it costs you the strongest ones.
- Skipping the contribution question. Portfolio credit inflation is common and one direct question resolves most of it.
- Treating a recorded round as sufficient. Design is collaborative and a working session shows what no recording can.
Common questions
What should I ask a product designer in an interview?
Ask what they argued for and lost, what they cut and why, what their actual contribution was, and how they knew the design worked after it shipped. Those four extract precisely the information a portfolio removes. Constraints, disagreements, scoping decisions and outcomes.
Is a portfolio enough to hire a designer?
No, and it is less informative than most teams assume. It shows finished outcomes without showing team size, constraints, what was overruled or which parts the candidate actually did. The interview's job is to recover that context, which is why the questions above are mostly about decisions rather than about the work itself.
Should I ask designers for a design exercise?
A paid exercise on a real problem is reasonable. Unpaid speculative work isn't. It filters for candidates with spare time over candidates who are good, and strong designers with other options routinely decline. A one-hour paid working session on a live problem gives you more signal for less imposition.
Does a recorded interview work for designers?
Better than for most technical roles. Designers defend decisions verbally every week, so how someone narrates a trade-off is close to a work sample. Send the questions alongside the portfolio request. Asking what they argued for and lost in advance produces far more useful answers than springing it live.