Use these questions to interview Product Designer candidates at {{Company name}}. Anchor as many as possible to the candidate's portfolio on screen — the same question asked against real work produces far better signal than asked in the abstract. Assign groups to different interviewers, and reserve the product thinking and craft groups for your strongest design evaluators.

Product thinking

• Pick your favorite portfolio project. What user problem was it solving, and how do you know that was the right problem?
• Tell me about a time you pushed back on the brief because the framing was wrong.
• How did you decide what success looked like for your last shipped feature? What did the metrics show after launch?
• Walk me through a design where business goals and user needs were in tension. How did you resolve it?
• What is a product you use daily whose design you would change, and what exactly would you change?
• Tell me about a solution you shipped that was deliberately less ambitious than your best concept. Why?

What good looks like: strong candidates trace a line from user evidence to design decision to measured outcome — and they can name what they deliberately traded away. Weak candidates present outcomes as inevitable and describe problems in the language of solutions they already wanted to build. The push-back question separates designers from ticket-takers.

Interaction and visual craft

• Zoom into one screen of your portfolio. Defend every element on it — or tell me what you would remove now.
• How do you design empty states, loading states, and error states? Show me a real example.
• Tell me about a complex flow you simplified. What was the step count before and after?
• How do you use motion and micro-interaction — and when do you deliberately not?
• What are the accessibility issues you check for in your own work before anyone reviews it?
• Show me the most technically constrained design you shipped. What did the constraints force you to invent?

What good looks like: the best candidates can defend or critique their own screens at the element level — hierarchy, spacing rhythm, state coverage — and they treat edge states as the design, not an afterthought. Candidates who cannot find anything to improve in their own work stopped growing a while ago.

Research and validation

• Walk me through the last time user research changed your design direction. What did you hear?
• How do you validate a design when there is no research team and no budget?
• Tell me about a usability test that went badly. What did you change?
• What do you do when user feedback and stakeholder opinion point in opposite directions?
• How do you decide between shipping to learn versus testing before shipping?

Collaboration with engineering and product

• How do you work with engineers during build — cadence, tools, and what you do when the build diverges from the design?
• Tell me about a disagreement with a PM over scope. How was it resolved, and what shipped?
• Describe the best handoff process you have worked in. What made it work?
• How do you respond when an engineer proposes a simpler version of your design?
• Tell me about advocating for design quality when the team wanted to ship faster.

Design systems and quality at scale

• What was your relationship with the design system in your last role — consumer, contributor, or maintainer?
• Tell me about a component you contributed to a system. What edge cases did you have to document?
• When is it right to break from the design system?
• How do you keep quality consistent across a product surface designed by several people?
• What does design debt look like, and how did your team manage it?