Product Designer Interview Questions: Portfolio, Whiteboard & More

Product and UX designer interviews test how you think about problems, not just how polished your final screens look. Most loops combine a portfolio review, a live design exercise, and a behavioral round — and interviewers at every stage are listening for your reasoning, not just the outcome.

The Interview Rounds

Portfolio review. You walk through 1-2 projects in depth. The interviewer is evaluating your process and decision-making, not grading the visuals like a design-school critique.

Whiteboard / design exercise. A live, timed prompt ("design a bike-sharing app") where you think out loud through user needs, constraints, and trade-offs — usually on a literal whiteboard, not in a design tool.

Behavioral. Stories about working with engineers and PMs, handling design feedback or pushback, and a project that didn't go as planned.

Technical (role-dependent). Some companies ask basic front-end/prototyping questions for roles that expect designers to work close to implementation.

A Framework for Walking Through Your Portfolio

For each project, structure your walkthrough in four parts rather than narrating chronologically from the first sketch:

1. Problem. What was broken or missing, and for whom — be specific about the user and the constraint, not just "we wanted to improve engagement."

2. Process. How you got from problem to solution — key research findings, the options you considered, and why you picked one over another. This is the part interviewers care about most.

3. Outcome. What actually happened after launch — a metric, qualitative feedback, or an honest "we didn't measure this well" if that's the truth.

4. Reflection. What you'd do differently now. This signals growth and self-awareness more than any other part of the walkthrough.

Worked Example: "Design a Bike-Sharing App"

A classic whiteboard prompt, worked through at interview depth:

Clarify: Ask about the platform (app vs. kiosk), the city context (dense urban vs. suburban), and whether this is a new product or redesigning an existing one. Assume a new mobile app for a dense city.

Identify the core user need: Find an available bike nearby and unlock it quickly — everything else (payment, route history) is secondary to this core loop.

Sketch the primary flow: Map view showing nearby bikes with availability → tap a bike → scan a QR code or enter a code to unlock → ride → end ride by locking at a station.

Name the trade-offs: A map-first home screen is fast for finding a bike but buries account/payment info; a list view is more accessible but slower to scan. State which you'd pick and why — for a task this location-dependent, map-first wins.

Discuss an edge case: What happens if a bike shown as available is actually broken or gone? Naming this (and a fix, like real-time status plus an in-app "report an issue" action) shows you're thinking beyond the happy path.

How to Practice

Talking through design decisions clearly, under time pressure, in front of someone evaluating you is a different skill from designing alone. Practice explaining your reasoning out loud in a live-scored AI Mock Interview, or build the daily habit of structuring answers with Flash Practice.

Frequently Asked Questions

What should I include in a portfolio walkthrough? The problem you were solving and why it mattered, your process (research, iterations, key decisions and trade-offs), the final outcome, and what you'd do differently now. Interviewers care more about your reasoning than the final visuals.

What is a whiteboard design exercise? A live, timed exercise where you're asked to design a solution to a prompt (e.g. "design a bike-sharing app") in front of the interviewer, thinking out loud through constraints, user needs, and trade-offs rather than presenting a polished screen.

Do I need to know Figma or specific tools for design interviews? Rarely tested directly — interviewers care about your design thinking, not your tool proficiency. Some whiteboard exercises are literally done on a whiteboard or paper for exactly this reason.

How do I talk about a project that didn't go well? Be honest about the outcome, focus on what you learned and what you'd change, and avoid blaming stakeholders — interviewers are specifically listening for self-awareness and growth, not a flawless track record.