Product Designer interview questions and how to answer them

A product designer interview is mostly you explaining your own decisions out loud. The panel already liked your portfolio enough to call, so now they're checking whether the thinking behind it is yours and whether you'd be easy to work with on a hard week. Here's what each round looks for and how to answer the questions that come up again and again.

11 questions7 minute read

Part 1

1.Walk me through a project you're proud of.

Why they ask

This is the portfolio question in its purest form. They want to hear how you frame a problem and how much of the work was actually yours.

How to answer

  • Open with the user problem and the business reason it mattered, in a sentence or two
  • Say exactly what you owned and who else was involved
  • Show two or three directions you explored and why you dropped the others
  • Describe what changed after launch and what you'd do differently now

2.Tell me about a time an engineer pushed back on your design.

Why they ask

Every design gets challenged on build cost. They want to know whether you dig in, cave, or find a third option.

How to answer

  • Name the specific pushback, such as a custom animation or a new component outside the design system
  • Explain how you found out what was actually expensive about it
  • Describe the compromise and what the user still got
  • Mention what you changed in your process so it came up earlier next time

3.How do you decide what to research before you start designing?

Why they ask

Teams rarely have time for a full research phase. They want to see you pick the cheapest way to lower the biggest risk.

How to answer

  • Start from what you'd be most embarrassed to get wrong
  • Mention quick sources first: support tickets, analytics in a tool like Amplitude or Mixpanel, past research in the team's repository
  • Say when a handful of user interviews or a short usability test is worth it
  • Admit when you'd ship and learn instead of researching
4.Design an experience for booking a table at a restaurant.

Why they ask

This is the classic whiteboard prompt. They're watching how you handle ambiguity, not whether you produce a beautiful answer.

How to answer

  • Ask who the user is, what device, and what the business wants before you draw anything
  • State your assumptions out loud and pick one user to design for
  • Sketch the core flow roughly, then go deeper on the riskiest screen
  • Name the edge cases you'd handle next, like a party too big for any open slot, and how you'd measure success
5.How do you work with a design system, and when do you break it?

Why they ask

Consistency speeds up the whole team. They want someone who respects shared components but isn't trapped by them.

How to answer

  • Say you start with existing components and only reach for something new when a real user need isn't covered
  • Give an example of proposing a new pattern and how it went through review
  • Mention documenting variants in Figma and talking to the engineers who maintain the component library
  • Show you know the cost of a one-off: maintenance, accessibility checks, inconsistency

Part 2

6.How do you make sure your designs are accessible?

Why they ask

Accessibility bugs are expensive to fix after launch, and many teams expect designers to catch them early.

How to answer

  • Mention color contrast, focus states, touch target size and readable type as things you check while designing
  • Talk about annotating screen reader order and labels in your handoff
  • Refer to WCAG guidelines as the reference you work from
  • Give one real example where an accessibility check changed your design
7.Tell me about a design that didn't work after it shipped.

Why they ask

They want proof that you look at outcomes and can talk about failure without getting defensive.

How to answer

  • Describe what you expected and what the data or user feedback actually showed
  • Own your part without blaming the PM or the timeline
  • Explain what you changed in the next iteration
  • Say what the miss taught you about your assumptions
8.How do you handle feedback in a design critique that you disagree with?

Why they ask

Critique is a weekly ritual. They want to know if you'll be pleasant to review and still hold a line when you should.

How to answer

  • Say you ask a clarifying question to find the concern behind the comment
  • Separate taste from evidence, and bring evidence when you can
  • Describe one time you changed your mind and one time you didn't, and why
  • Mention following up after the meeting rather than arguing in the room
9.What does a good handoff to engineering look like to you?

Why they ask

Messy handoffs cause rework and resentment. This question shows how much you think about the people who build your work.

How to answer

  • Mention walking engineers through the flow before the file is final
  • Talk about specs, component names that match the code, and states like empty, loading and error
  • Say you stay available during the build and review it before release
  • Name the tools you use, such as Figma Dev Mode and Jira tickets linked to frames
10.How do you prioritize when a product manager and a stakeholder want different things?

Why they ask

Designers often get caught between competing asks. They want to see you steer toward a decision instead of pleasing everyone.

How to answer

  • Bring both back to the user problem and the goal the team agreed on
  • Show a quick side-by-side of both directions so the trade-off is visible
  • Let the PM own the call on scope while you own the quality of the options
  • Give an example of how it resolved

Part 3

11.Why do you want to work on this product?

Why they ask

They want to know you looked at the product and have a real opinion about it.

How to answer

  • Name something specific you used and noticed, good or bad
  • Connect a problem in their product to work you've done before
  • Keep it short and avoid flattery

Questions to ask them

Ask at least two. It shows you're picking them too.

  • How does design work get prioritized against engineering work in a typical sprint?
  • Who does the user research here, and how often do designers talk to users directly?
  • What does a designer's work look like when it's reviewed well, and who reviews it?
  • How mature is the design system, and who maintains it?
  • What's a recent design decision the team disagreed about, and how did it get settled?