Should we ask product designers to do a take-home design exercise?

Be careful. Unpaid design work costs candidates time and can look like free consulting. A portfolio presentation plus a short live critique usually gives enough evidence. If you need a take-home, keep it small, use a fictional problem, say how it will be assessed, and consider paying for it.

What should we look for in a product designer's portfolio?

Reasoning, not polish. Look for the problem, the candidate's own contribution, the options they considered, and the outcome. Go deep on one project rather than skimming five, and ask what they would change now.

How do we assess designers whose best work is under NDA?

Let them present redacted or reconstructed work, or talk through the process at a whiteboard. Assess the reasoning and the trade-offs. Do not penalize a candidate for keeping a confidentiality promise.

Should engineers interview product designers?

Yes, for the collaboration competency. An engineer who will build the designs is well placed to judge how the candidate handles constraints and feedback. Give them the same anchors as the rest of the panel.

Free interview kit

Product Designer interview kit: questions and rubric

For hiring teams interviewing a mid-level product designer who owns end-to-end design for a product area alongside a product manager and engineers. It covers a short screen, five competencies with behavioral, situational and work-sample questions, anchored ratings, the questions never to ask, and a rule for deciding.

5 competencies · 10 questions · anchored 1-to-5 scale · Updated 10 October 2026 · Written by the Itya team

Share this kitLinkedIn X WhatsApp Email

How to use this kit

Agree the competencies with the hiring manager before the job is posted.
Give each interviewer one or two competencies, so nothing is asked twice.
Ask every candidate the same core questions; follow up freely.
Rate each competency against the anchors straight after the interview, alone.
Debrief on quotes, not adjectives, then decide with the rule at the end.

First-round screen

Fifteen to twenty minutes, by phone, video or a disclosed AI screen. The aim is to confirm the basics before the panel spends its time.

What draws you to this role, and what kinds of design problems do you want to work on next?
Pick one project from your portfolio and tell me the problem, your part in it, and what changed for the people who used it.
How do you work with product managers and engineers day to day, and which design tools do you use?
The job description sets out the location, working pattern and start date. Do those work for you, what is your notice period, and what compensation range are you expecting?

Competency 1

Problem framing and user research

Good design starts with the right problem. Designers who frame problems with evidence avoid polishing the wrong solution.

Walk me through a project where research changed your design direction.
Follow up with
- Which method did you use, and why that one?
- Who did you learn from, and how many people?
- What did you drop as a result?
Strong answer
Names a method chosen to fit the question, what they learned, and a specific design change it caused. Separates observed behavior from stated preference.
Weak answer
Research appears only as a step in a process diagram. The findings confirmed the first idea, and nothing changed because of them.
What would you do if you were asked to design a feature with no time or budget for user research?
Follow up with
- What evidence could you still gather in a day?
- How would you lower the risk of being wrong?
Strong answer
Uses fast sources (support tickets, analytics, past research, a few quick usability sessions), writes down the assumptions, and plans to check them after launch.
Weak answer
Designs on instinct with no plan to check, or refuses to start until there is a full research phase.

Rating	What it looks like
5 · Strong	Frames problems with evidence, chooses methods to fit the question and the time available, and can point to where research changed the design.
3 · Mixed	Frames problems clearly and uses research on most projects, but picks standard methods rather than ones chosen for the question.
1 · Weak	Starts from screens, not problems. Cannot describe how evidence shaped a design.

Competency 2

Interaction and visual craft

Craft is what users touch. A mid-level designer should produce clear, consistent and accessible flows without close supervision.

Work sample: here is a screen from our product, or a common one such as a checkout form. Critique it and tell me what you would change first.
Follow up with
- Why that change before the others?
- How would you check it is accessible?
- What would you want to know about the users before changing it?
Strong answer
Ranks issues by user impact, names specific problems (hierarchy, labels, error states, contrast, touch targets), proposes concrete changes, and raises accessibility unprompted.
Weak answer
Comments on taste ('I would make it cleaner'), redesigns everything at once, or ignores states such as errors, loading and empty screens.
Walk me through the detailed design of one flow in your portfolio: its states, edge cases and the decisions behind it.
Follow up with
- What did the error and empty states look like?
- What did you change after engineering feedback?
Strong answer
Shows the full set of states, explains each decision with a reason tied to users or constraints, and describes how they used or extended the design system.
Weak answer
Shows only the happy path in polished mock-ups and cannot explain why the choices were made.

Rating	What it looks like
5 · Strong	Designs every state, ties choices to users and constraints, treats accessibility as a default, and critiques by user impact.
3 · Mixed	Produces clear, consistent flows with the main states covered, but misses some edge cases or accessibility details.
1 · Weak	Designs only the happy path. Critique is about taste, and basic accessibility is missed.

Competency 3

Collaboration with product and engineering

Designs that engineers cannot build, or that product cannot ship, stay in the design file. Designers have to trade ideal against possible with their partners.

Tell me about a time an engineer said your design was too expensive to build. What happened?
Follow up with
- What did you give up, and what did you protect?
- How did you decide?
Strong answer
Understood the constraint, explored alternatives with the engineer, protected what mattered most to users, and shipped a version everyone could stand behind.
Weak answer
Either dropped the design entirely or insisted on it without understanding the cost. Treats engineering input as an obstacle.
What would you do if a product manager asked you to 'just make the screens' for a solution they had already decided on?
Follow up with
- How would you raise your concerns?
- What if the decision stood?
Strong answer
Asks about the problem and evidence behind the solution, offers alternatives quickly where they see risk, and still delivers on time if the decision stands.
Weak answer
Complies silently despite real concerns, or refuses to work until the process is redone.

Rating	What it looks like
5 · Strong	Involves engineering and product early, trades cost against user value in the open, and ships designs the team built together.
3 · Mixed	Works well with product and engineering in the examples given, but brings them in mainly at review points.
1 · Weak	Hands off finished designs with little engineering input, and treats constraints and feedback as obstacles.

Competency 4

Communicating design decisions

Designers must explain why to people who do not share their vocabulary. A clear rationale turns arguments about taste into decisions.

Work sample: present one portfolio project to the panel in ten minutes, as if to a leadership review.
Follow up with
- What was the hardest trade-off?
- What would you do with another month?
Strong answer
Opens with the problem and the outcome, shows only the decisions that mattered, explains trade-offs, keeps to time, and answers questions directly.
Weak answer
Walks through every screen in order, runs over time, and cannot say what the outcome was.
Tell me about a time a stakeholder pushed back hard on your design. How did you respond?
Follow up with
- What evidence did you bring?
- Where did you change your mind?
Strong answer
Listened for the concern behind the feedback, answered with user evidence or a quick test, and changed what deserved changing.
Weak answer
Defended the design by appeal to taste or expertise, or accepted every change to avoid conflict.

Rating	What it looks like
5 · Strong	Leads with the problem and the outcome, explains each key decision with evidence, and handles challenges by testing rather than arguing.
3 · Mixed	Presents clearly and explains most decisions with reasons, but leans on process descriptions rather than outcomes.
1 · Weak	Explains designs by describing screens or by appeal to taste. Gives way or digs in when challenged.

Competency 5

Outcomes and iteration

Shipping is the midpoint. Designers who check whether a design worked improve faster than those who move straight to the next brief.

Tell me about a design you shipped that did not work as intended. How did you find out, and what did you do?
Follow up with
- What signal told you it was not working?
- What did you change in the next version?
Strong answer
Names a specific signal (a metric, support tickets, usability findings), diagnoses the cause, and describes the iteration that followed and what it taught them.
Weak answer
Has never had a design fail, or blames the implementation or the users without investigating.
How did you measure the success of the project you are proudest of?
Follow up with
- Who agreed that measure before launch?
- What would you measure differently now?
Strong answer
Agreed a measure with the product manager before launch, checked it after, and can say honestly whether the design moved it.
Weak answer
Measures success by stakeholder approval or a design award, with no evidence of what changed for users.

Rating	What it looks like
5 · Strong	Agrees measures before launch, checks them after, and iterates on the evidence, including when it shows the design fell short.
3 · Mixed	Checks outcomes on some projects, usually informally, and iterates when problems are reported.
1 · Weak	Considers the work done at handoff. Cannot say whether any shipped design achieved its goal.

Never ask

Don't ask a candidate's age, or their graduation year to work it out. Why: age says nothing about design skill, and age-based decisions are unlawful in many places.
Don't ask about marital status, children, pregnancy or plans to start a family. Why: none of it is job-related, and the question is still put mostly to women, which makes it discriminatory as well as irrelevant.
Don't ask about religion, caste, community or the origin of a surname, directly or by proxy ('What does your father do?'). Why: in India these questions signal caste and religion, which have no bearing on the job.
Don't ask 'Where are you from originally?' or 'What is your native place?'. Why: it invites judgments about region and community. If location matters, ask whether the candidate can work from the job's location.
Don't ask about health conditions, disabilities or past medical leave. Why: the only relevant question is whether the candidate can perform the essential functions of the job, with or without reasonable accommodation.
Don't ask for salary history where the law restricts it, as many US states and cities do. Why: it carries past pay gaps into the new offer. Ask for the expected compensation range instead.
Don't ask a candidate to show confidential work from a current or former employer that they are not allowed to share. Why: it asks them to break an agreement. Accept redacted or reconstructed work and assess the reasoning.

Making the decision

The must-haves are problem framing and research, interaction and visual craft, and collaboration with product and engineering. Any 1 on a must-have is a no, and so is any competency rated 1 by two interviewers. A hire needs an average of 3.5 or higher. The hiring manager decides after the debrief and records the evidence from the critique and the portfolio presentation.

Questions people ask

Should we ask product designers to do a take-home design exercise?: Be careful. Unpaid design work costs candidates time and can look like free consulting. A portfolio presentation plus a short live critique usually gives enough evidence. If you need a take-home, keep it small, use a fictional problem, say how it will be assessed, and consider paying for it.
What should we look for in a product designer's portfolio?: Reasoning, not polish. Look for the problem, the candidate's own contribution, the options they considered, and the outcome. Go deep on one project rather than skimming five, and ask what they would change now.
How do we assess designers whose best work is under NDA?: Let them present redacted or reconstructed work, or talk through the process at a whiteboard. Assess the reasoning and the trade-offs. Do not penalize a candidate for keeping a confidentiality promise.
Should engineers interview product designers?: Yes, for the collaboration competency. An engineer who will build the designs is well placed to judge how the candidate handles constraints and feedback. Give them the same anchors as the rest of the panel.

A kit is step one.

Itya holds every interviewer to the same rubric, records the interview, and drafts the scorecard with the quotes behind each rating. The AI drafts; your team decides. Free plan, unlimited teammates.

Run this kit in Itya All interview kits