A UX designer loop tests four distinct things, usually one round each: the portfolio walkthrough (can you explain why you made the decisions you made), an app critique or design exercise (can you spot and reason about UX problems live), a whiteboard or take-home challenge (can you structure an open problem and design under constraints), and behavioral (can you collaborate, take feedback, and ship). The portfolio walkthrough is the center of gravity — most loops live or die there. In every round the interviewers are scoring your reasoning, not whether you reach their preferred solution. Prepare by drilling two or three case studies into a tight problem-decision-outcome story, practicing live critique out loud, and stocking a few real collaboration stories.
What UX interviews are actually testing
A UX interview is not a knowledge quiz — it is a thinking and collaboration test. The interviewers have seen the prompts dozens of times and are not waiting for one correct screen; they are watching whether you frame a problem from the user, reason through tradeoffs, take feedback without getting brittle, and communicate clearly under mild pressure. Two designers can reach different solutions and both pass, because the score is on the path, not the destination. Your job in every round is to make your reasoning visible.
Almost every loop maps to four rounds. Knowing which skill each one targets lets you bring the right structure instead of improvising.
| Round | What it tests | How to prepare |
|---|---|---|
| Portfolio walkthrough | Is your design thinking real? The problem you were solving, the decisions and tradeoffs you made, the constraints, and how you knew it worked. | Drill two or three case studies into a tight problem-decision-outcome arc. Lead with the problem and the user, spend most of the time on decisions, and defend every choice without getting defensive. |
| App critique / design exercise | Can you spot and reason about UX problems live? User empathy, flow analysis, and judgment about what to fix first. | Practice critiquing real products out loud: name the user and goal, walk a flow, call out friction with a reason, and prioritize one fix. Critique generously, not as a takedown. |
| Whiteboard / take-home challenge | Can you structure an open problem and design under constraints? Problem framing, prioritization, and a sense of what is worth building. | Drill a structure: clarify the goal and constraints, pick and segment a user, map pains, sketch directions, prioritize with a rule, and state how you would measure and test. |
| Behavioral / collaboration | Can you work on a team? Collaboration with PM and engineering, taking critique, resolving conflict, and shipping under deadlines. | Prepare three or four real stories in problem-decision-outcome form — a resolved disagreement, hard feedback you used, a constraint tradeoff, research that changed a call. |
The portfolio walkthrough
This is the round that decides most loops, so over-prepare it. Pick two or three case studies and present each in a clear arc rather than a tour of screens:
- The problem and the user. What were you actually solving, for whom, and why did it matter to the business? Set this up before any visuals.
- The decisions and tradeoffs. This is where the time goes. What did you choose, what did you reject, what constrained you (deadline, tech, research findings), and why. Show range before you converged.
- The outcome and what you learned. How did you know it worked — task success, conversion, drop-off, a SUS or NPS movement — and what would you do differently?
App critique and design exercises
Representative prompts: "Open this app and tell me what you would improve." "Critique our onboarding flow." "Here is a competitor — what works and what does not?" The trap is jumping to opinions about color and spacing. Instead, make the structure explicit: name the user and their goal, walk a key flow start to finish, call out each friction point with a reason rooted in the user's context, then prioritize the one or two changes with the most impact and say how you would validate them. Critique generously — the goal is to show judgment and user empathy, not to perform cleverness by tearing the product apart.
The whiteboard challenge
Representative prompts: "Design an app to help people split rent." "Improve the experience of returning a package." "Design a feature to help nurses track patient medication." The answer matters far less than the process, so narrate it: clarify the goal and constraints, pick and segment a specific user ("a renter sharing with three roommates, paying on different dates" is designable; "everyone" is not), map their real pains, sketch a couple of directions to show range, then converge on one using a stated rule (impact versus effort, or alignment to the goal). Close on how you would measure success and what you would test next. Saying "I will assume the renters already trust each other — tell me if you want me to design for the opposite" is exactly the behavior they are scoring.
Behavioral and collaboration questions
Representative prompts: "Tell me about a time you disagreed with a PM or engineer." "Describe a project where you got tough feedback." "When did you have to ship something you were not fully happy with?" "Tell me about a time research changed your design."
Use a problem-decision-outcome structure and choose stories that foreground collaboration and feedback, because design never happens alone. Keep the situation brief, spend the bulk of the answer on the decision and how you aligned with PM, engineering, or stakeholders, and close on a measured result and an honest lesson. For the tough-feedback question, do not pretend you were right all along — show that you heard the critique, changed the work, and got a better outcome. Interviewers trust a designer who can take a note far more than one whose every story ended in vindication.
The honest summary
UX interviews are a thinking and collaboration test across four rounds: the portfolio walkthrough, an app critique or exercise, a whiteboard challenge, and behavioral. The walkthrough carries the most weight, so present two or three case studies as tight problem-decision-outcome stories and defend your choices without getting defensive. In every round, make your process visible — name the user and goal, reason out loud, and tie design to a measured result. For the methods behind your critiques and challenges, the Nielsen Norman Group's articles are the standard reference, and Indeed's career advice library is a solid guide for the behavioral rounds. Prepare the structures, drill the stories, and the loop stops feeling like a test and starts feeling like the job.
Common questions
- What is the most important round in a UX interview?
- The portfolio walkthrough, almost always. It is where the team decides whether your design thinking is real, so most loops weight it heaviest. They are not grading the pixels — they are listening for the problem you were solving, the decisions you made and why, the tradeoffs you weighed, and how you knew it worked. Prepare two or three case studies you can present in a tight problem-decision-outcome arc, and be ready to defend every choice without getting defensive.
- How do I prepare for an app critique question?
- Practice critiquing products out loud before the interview. Pick an app, name the user and their goal, walk a key flow, and call out friction with a reason ("this step asks for information the user does not have yet"). Structure beats cleverness: state who the user is, what they are trying to do, where the experience breaks, and what you would change first and why. Critique generously — show judgment, not a takedown.
- What happens in a UX whiteboard challenge?
- You are given an open design prompt ("design an app to help people split rent") and asked to work through it live, usually 30 to 45 minutes. The interviewer is scoring your process, not your art. Clarify the goal and constraints, pick and segment a user, map their pains, sketch a few directions, prioritize one with a stated rule, and say how you would measure success and what you would test next. Narrate your reasoning the whole way.
- How do I answer behavioral questions as a designer?
- Use a problem-decision-outcome structure and pick stories that show collaboration, handling feedback, and shipping with constraints — because design is a team sport. Have three or four real stories ready: a disagreement with a PM or engineer you resolved, harsh critique you incorporated, a tradeoff you made under a deadline, and research that changed a decision. Keep the situation brief, spend most of the answer on what you decided and why, and end on the measured result.
Sources
Keep reading
How to answer "tell me about yourself"
Answer "tell me about yourself" with a 60-90 second present-past-future pitch tailored to the role. The structure, a before/after example, and what not to do.
What questions should I ask the interviewer?
The best questions to ask an interviewer, organized by who you are talking to. Questions that signal seriousness, surface red flags, and the ones to avoid.
How do I prepare for a behavioral interview?
Prepare for a behavioral interview with the STAR method, a bank of 6-8 stories mapped to common competencies, and practicing out loud. Examples included.
Software engineer interview questions
The real software engineer interview loop — phone screen, coding, system design, behavioral — with representative questions per stage and how to prep.