How to prepare for a product design interview

Every design interview guide tells you the same thing: polish the portfolio and rehearse the case studies so you can show your process. Then you sit down with a head of design who doesn't care about your process at all, wants to know whether the button you shipped moved anything, and spends twenty minutes on one screenshot asking why you made a specific choice. It's the same portfolio, presented the wrong way, and nobody tells you that's what happened.

This article covers what different design leaders are evaluating and where they genuinely disagree, and how to structure a portfolio case. It also covers the whiteboard and app-critique rounds, how to talk about outcomes when you didn't own the metric, and what to ask them back. Read the disagreements section first, because everything else depends on which kind of team you're talking to.

The material comes from Julie Zhuo, who joined Facebook as an intern designer and became its VP of product design over 14 years; Katie Dill, head of design at Stripe and previously head of experience design at Airbnb and head of design at Lyft; Karri Saarinen, co-founder and CEO of Linear and before that a principal designer at Airbnb and the founding designer at Coinbase; Jenny Wen, who leads design for Claude at Anthropic and was director of design at Figma; and Dylan Field, Figma's co-founder and CEO. Every quote below plays the exact moment it was said.

Where design leaders disagree about what they're evaluating

Generic guides flatten all of this into "show your process and prove impact." The people doing the hiring are not that aligned. Some of them are primarily testing your taste and judgment. Some want to see that your work moved the business. At least one thinks the design process you were taught is finished. These lead to different presentations of the same portfolio, so it's worth knowing which one you're walking into.

The one question almost all of them ask

Start with the agreement, because it's unusually strong. When Lenny Rachitsky compiled the favorite interview questions of more than 100 guests, three separate product and design leaders named the same one, independently: what work are you most proud of.

Karri Saarinen answers the same question the same way and says it "gives you a little bit of indication of what the person values and how they think about things." So the piece of work you lead with is doing double duty. It shows what you can build, and it tells them what you think good looks like. Pick the project you're proud of for reasons you can defend, and not the one with the biggest logo attached.

How they probe for taste and judgment

Katie Dill puts taste above almost everything else she could screen for, including experience.

She also names two things alongside it: humility, because it makes you pay attention to what users are telling you, and the nerve to say a design isn't good enough and it should be done again. If you have a story where you threw out your own work and restarted, that's the round to tell it in.

Karri Saarinen probes the same quality through a specific interview move. He asks about a project on your resume, then keeps going deeper on one decision until he finds out whether there's reasoning underneath it.

The questions he uses are worth writing down, because they're the ones candidates freeze on: why was this decision made, do you think it was the right decision, and what would you have done differently. Notice that the second and third ones invite you to disagree with your own shipped work. Saarinen says the strongest candidates "can just talk about it forever and they can go deeper and deeper." So prepare depth on a small number of decisions rather than a tour of everything you've made.

Dylan Field describes taste as something you build by running a loop: notice whether you like something, ask why, then learn the context and the history that produced it and work out where you agree or disagree with it. That's a useful frame for the interview, because it means you can demonstrate taste live by reasoning out loud about a product, even when your portfolio is thin.

Whether your work has to point at a number

Here's the disagreement that will most change how you present. Katie Dill, running design at Stripe, thinks designers should be able to show how quality work moved the business, and treats the belief that it can't be measured as actively dangerous.

Her example is small and specific, which is why it works: support contacts were coming in because a button looked nice but wasn't clear, they fixed the clarity, and the contact volume dropped. She also warns that some quality work pays off over quarters or years, and that a team's rubric should say what impact means so that long-horizon work still counts.

Karri Saarinen runs Linear the opposite way, and he is explicit about it.

Linear has a company-level metric like weekly active users, but no per-feature targets, no experiments, and one product leader. Saarinen calls the mix "magic and science," where the science is everyone in the company talking to customers constantly, and the magic is trusting informed intuition instead of backing every decision with data.

Both of these people hire designers, and neither of them is wrong about their own company. What changes is what a strong answer sounds like in their interview:

Whether the classic design process is still the story

The advice to "show your process" usually means the process every design program teaches: research and discovery, then diverge, converge, diverge, converge, then mocks, then iterate. Jenny Wen, who leads design for Claude at Anthropic and was a director of design at Figma, gave a talk in Berlin arguing that process is finished.

Her argument is that engineering changed first and design got pulled along. When an engineer can spin up a working version of an idea in an afternoon, a designer no longer has time to produce beautiful mocks and hand them over. She splits the job into two kinds of work now: supporting implementation, which often means doing the last-mile detail directly in code alongside engineers, and setting direction, which has shrunk from a five-year vision deck to something closer to a three-to-six-month prototype that points people somewhere.

Be careful about what this does and doesn't mean for your interview. Wen is describing how the work gets done day to day. Saarinen and Dill are describing what they listen for in an interview, which is the reasoning behind decisions. Those aren't in conflict. What is genuinely at risk is the portfolio case built as a ritual walk through the phases, with a research slide and a diverge slide and a personas slide, ending in a hero shot. That structure is what Wen is calling dead, and it also happens to be the structure that buries the judgment Dill and Saarinen are looking for. Nobody in this group is asking you to prove you followed the steps.

How to tell which kind of team you're interviewing with

You can usually work this out before the onsite, and the recruiter will tell you if you ask.

Then present accordingly. You're not changing your story, because you did what you did. You're choosing which parts get the airtime, and if you guess wrong you'll spend the round answering a question they weren't asking. If you want a broader version of this, the positioning playbook covers how to shape your pitch to a specific team.

The portfolio review and how to build one case

Most portfolio reviews give you 45 to 60 minutes, and most candidates try to cover four projects in it. Two or three is plenty, and one of them should go deep enough that the interviewer runs out of follow-up questions before you run out of answers. Remember what Saarinen said about the strongest candidates going deeper and deeper on a single decision.

A structure that holds up with both kinds of interviewer:

Two practical notes. Keep the walkthrough conversational and let them interrupt, because their interruptions tell you what they're evaluating. And rehearse the version that fits in half the time, since panels run late constantly and being cut short is normal.

Most portfolio reviews open with some version of "tell me about yourself" before you share your screen. Keep it to about ninety seconds and use it to set up the work you're about to show, and the playbook on that answer has a structure for it.

The whiteboard round and the app critique

These two rounds test the same thing from opposite directions. The whiteboard asks you to design something new under time pressure. The critique hands you an existing product and asks what's wrong with it. Both are watching how you think when you can't polish anything.

For the critique, Julie Zhuo's advice about giving feedback inside a design critique is the best available guide to sounding senior, and it works because it's what good designers do with each other every week.

Her example of the failure is "why don't we make the logo purple," which skips straight past the reason. In a critique round, "I'd move this button up" tells the interviewer nothing. "A first-time user can't tell which of these three actions is the main one, because they're weighted identically, and here's why that matters for someone in a hurry" tells them how you look at a screen. Zhuo's point is that jumping to a solution takes power away from whoever owns the problem, so it also signals how you'd behave with the designers already on the team.

A workable order for a 30-minute critique:

• Say who the product is for and what job it's doing before you say anything about the interface. Two sentences.
• Pick one flow and walk it as that user would, out loud, calling out the moment things get confusing and why.
• Separate severity from taste. Say which issues block someone from finishing and which are polish, because running them together is the most common way to sound junior.
• Name what's working and why. Interviewers notice candidates who only find faults, and it makes them wonder about your taste rather than your rigor.
• Offer fixes at the end, tied back to the specific problems you named, with a rough sense of what each would cost.

For the whiteboard round, the mechanics overlap heavily with the PM version of this exercise: narrow the prompt, pick a user, find a real problem before proposing anything, sketch, then critique your own sketch. The product sense interview playbook has a full structure with timings you can borrow, and the main difference for designers is that you'll be expected to actually draw and to talk about layout, hierarchy, and states while you do.

How to talk about outcomes when you weren't the PM

The trap in outcome questions is real, and it goes both ways. Claim the metric and a sharp interviewer will ask what you personally decided, then watch you flounder. Refuse to discuss numbers at all and an outcomes-oriented interviewer writes you off as someone who doesn't know what the business does.

The way through is to be specific about the boundary. Say what the team achieved, then say which part of it you owned, at its real size.

If the number genuinely doesn't exist, which happens often at a company that works the way Linear does, use the evidence they'd use: what customers said afterward, what stopped showing up in support, whether the team kept building on it.

What they ask about working with engineers and PMs

Expect at least one round on collaboration, usually run by an engineer or PM rather than a designer. What's changed is that the answer "I hand off high-fidelity mocks and then review the build" now sounds dated at a lot of companies.

Jenny Wen's description of her own week is a useful model for what a strong answer sounds like. When she works with engineers, she explains the thinking behind her feedback so they can extract the principle and apply it without her next time, rather than issuing verdicts on individual screens. She points them at the design system and at code they can reuse. And she does a lot of last-mile implementation herself, putting in the colors and details and prototyping in real code instead of asking an engineer to build the prototype.

Wen also named the three kinds of designer she finds most interesting to hire right now, which is worth knowing because it tells you which story to lead with. Strong generalists who are genuinely good at several things rather than passable at many. Deep specialists whose one skill goes further down than almost anyone's, whether that's engineering depth or visual work or something as narrow as icons. And what she calls the craft new grad: someone early in their career who learns fast and doesn't have a decade of baked-in process to unlearn. Her point about the third one is that most companies only hire senior people, so that candidate is the one being overlooked.

Katie Dill frames the junior-versus-senior question differently, from the hiring side. She thinks an early-stage team probably does need a doer, but also needs someone senior enough to build a user-focused way of working, so pairing a full-time executor with a more senior design advisor can work. If you're early in your career interviewing at a small company, that's the concern to address head on: show you can execute quickly, and separately show you have a point of view about how the team should work.

For the collaboration round itself, come with two stories ready: a time you disagreed with a PM or engineer and how it got resolved, and a time you changed your design because of something an engineer told you about cost or constraints. The behavioral interview playbook covers how to structure those so they don't wander.

What to ask them back

Julie Zhuo tells founders how to make themselves attractive to designers, which is the same list you should be checking them against.

The evidence Zhuo tells founders to produce is the evidence you should go looking for: whether they've invested in design before hiring you, whether the leadership can talk about design in specific terms, and whether the existing product and marketing site suggest anyone cared. Questions that get at it:

If this is your final round, the final-round playbook covers preparing for the rest of the panel around the design-specific interviews.

Frequently asked questions

How many projects should my portfolio presentation cover?

Two or three, with one taken deep. The failure mode is a tour of six projects at a level of detail that never reaches a decision, which leaves the interviewer with nothing to probe. Pick projects that show range across problem type, not across visual style.

Should I show unpolished work?

Yes, and it's often the strongest part. Rejected directions, early sketches, and screenshots you marked up are the evidence that you considered alternatives. Until you show the discards, an interviewer has no way to tell a portfolio of considered choices from a portfolio of first attempts that happened to look good.

What if my last team never measured anything?

Say so plainly and give the evidence you did have, like what customers said, what support saw, and whether the team kept investing in it. Then say what you would measure if you ran it again, which shows you know the gap exists. Karri Saarinen runs a well-loved product without per-feature metric goals, so plenty of interviewers won't blink at this. The ones who do will still respect a candidate who knows what was missing.

How do I prepare for a take-home design exercise?

Timebox it to what they said, and spend a real portion of that time on the writeup rather than the pixels. State your assumptions, show one direction you rejected, and be explicit about what you'd validate next. If the brief is vague, ask a clarifying question by email before you start, because asking is itself a signal.

Is a paid work trial normal?

It's rare but growing. Linear does one with every hire, where candidates work alongside the team for a number of days, join meetings, and get access to Slack and Notion. Saarinen says candidates come out of it with a much better sense of the company, and that they'll schedule around your current job. If you're offered one, treat it as your best chance to evaluate them, because working with a team for a week tells you more than any number of interviews.

Does AI experience matter in design interviews now?

At AI companies and a growing set of others, yes. Jenny Wen looks for resilience and willingness to try new tools, and describes designers prototyping in real code rather than waiting on engineers. Dylan Field's view is that craft is becoming the differentiator precisely because building has gotten easy. Being able to say what you've built with these tools, and what you concluded, is now a reasonable thing to bring up unprompted.

The design interview on one page