The UX Designer Interview: Portfolio And Process

A UX designer interview is built around your portfolio. Most loops run three to five rounds, and the longest one is a 45 to 60 minute case study walkthrough where you present one or two projects to a panel and defend the decisions behind them. The rest of the loop usually adds an app critique, a behavioral round, and either a whiteboard exercise or a take-home design challenge. The screens on your slides matter far less than your reasoning, so the whole interview is really a test of how you think.

If you take one thing from this guide on UX designer interview questions, make it this: hiring managers are not grading the final mockup. They want to see how you framed the problem, what you ruled out, and how you knew your design worked. A product designer who can only narrate the happy path of a finished flow loses to one who can explain the tradeoffs.

The Portfolio Walkthrough

This is the core of the UX design interview, and it is where most candidates underperform. You will not pass by clicking through pretty screens. You pass by telling the story of a decision: here was the problem, here is what users were actually struggling with, here are the options I considered, here is what I shipped, and here is how I knew it worked.

Pick two case studies that show range, ideally three to five in the full portfolio. For each, be ready to answer:

• Walk me through your design process on this project.
• What was the hardest tradeoff, and why did you decide the way you did?
• What would you do differently if you started over?
• How did you measure whether the design actually solved the problem?

Have numbers ready. "We cut the steps in checkout from six to three and drop-off fell" beats "users loved it." When a panelist pushes back on a choice, do not cave instantly and do not get defensive. Explain the constraint you were working under, then say what you would test next.

Showing Your Design Process

Interviewers want a process that bends to the problem, not a rigid five-step recipe you recite for every project. Still, you should be fluent in the phases and able to point to where each one lived in your work: research to understand the user, wireframes and sketches to explore structure cheaply, prototypes to make it real, and testing to check your assumptions before you commit.

Be specific about methods. Name the research you ran, why you chose it, and what it changed. If you skipped a phase, say so and explain the call. A common question: "How do you decide when you have done enough research to start designing?" There is no perfect answer, but a thoughtful one talks about diminishing returns, deadlines, and the risk level of the decision.

The App Critique Round

Here they hand you a real product, often a competitor's or a well-known app, and ask what is wrong with it and how you would fix it. They are watching whether you can evaluate a live interface against user needs instead of just listing personal taste.

Structure beats opinion. Try this:

• State who the app is for and what the user is trying to do.
• Walk a key flow and call out friction, naming the heuristic or principle behind each issue.
• Separate what is broken from what is merely not to your taste.
• Prioritize. Which fix matters most, and why.

Saying "the button color is ugly" is weak. Saying "the primary action is the same weight as three secondary actions, so the user cannot tell what to do next" shows you reason from user goals.

The Whiteboard or Take-Home Challenge

The design challenge gives you an open prompt, something like "design an app that helps people split rent with roommates," and a tight clock. Whiteboard versions are done live and judged on how you think out loud. Take-homes give you a day or two and judge the artifact.

What they actually grade:

• Do you ask clarifying questions before you draw anything?
• Do you define the user and the core problem before jumping to a screen?
• Do you sketch a few directions instead of marrying the first idea?
• Can you explain why this layout, not just what it is?

For the live version, narrate constantly. Silence reads as a stuck candidate. For the take-home, include a short note on your process, your assumptions, and what you would test next. Most teams build in Figma, so know it well enough to move fast without fighting the tool, and be honest about your fluency rather than overstating it.

How To Rehearse

Read your case studies out loud, not in your head, because spoken answers expose the gaps that silent reading hides. A tool like Mythic Intel can research the exact role, ask the portfolio and critique questions a panel would, and grade your spoken answers on accuracy, structure, and whether you backed each claim with proof. Say every walkthrough at least three times before the real thing, until defending a decision feels like a conversation and not a recital.