What do UX designer interviews actually test?

Who you'll actually sit in front of

A UX designer interview is rarely one conversation. It's usually a sequence: a recruiter screen, then a portfolio review with one or two designers, then a design exercise or whiteboard challenge, then a round with the people you'd actually work with — a product manager, an engineer, sometimes a researcher — and often a final chat with the hiring manager or design lead. Smaller companies compress this into two or three sessions; larger ones stretch it across weeks with a formal debrief between rounds where interviewers compare notes on a scorecard.

The portfolio review is the part that carries most of the weight, and it's usually run by a working designer, not HR. That matters because they've built the thing you're describing and they know where the seams are. They're not evaluating your slides. They're listening for whether you can explain a decision under mild pressure, and whether the decision was actually yours.

The portfolio review: what they're really doing

The standard format is "walk me through a project." It sounds like small talk. It isn't. A designer running this review is checking for a few specific things as you talk:

• Where the problem came from. Did a stakeholder hand you a solution disguised as a brief ("we need a dashboard"), or did you get to the underlying need? If you say "the PM asked for X" and then describe building X, that's a flag. If you say "the PM asked for X, but when I looked at support tickets and did three user interviews I found the actual friction was Y," that's the answer they want.
• What you actually did versus what the team did. Case studies written for a portfolio tend to use "we" throughout. A good interviewer will interrupt and ask "what was your specific contribution to that flow?" If you can't separate your work from the team's, they assume you were along for the ride.
• Trade-offs you made and why. Not "we considered a few options and picked the best one" — which option, what would have been lost either way, and what data or constraint tipped it. Engineering timeline, technical debt, brand guidelines, accessibility requirements, a stakeholder who wouldn't move — name the actual constraint.
• What happened after launch. Did you look at the numbers, run a follow-up usability test, get support ticket volume, or did the project end at handoff to engineering? A lot of candidates have no answer here because the org never closed the loop, and a decent interviewer will note that without holding it against you — but they will hold it against you if you claim an outcome you never measured.

A shallow answer in a portfolio review sounds fluent and says nothing checkable: "we redesigned the onboarding flow and it really improved the user experience." No baseline, no metric, no named constraint, no distinction between your input and the team's. Someone who reviews portfolios for a living hears this constantly and stops listening within a sentence.

The design exercise or whiteboard challenge

This is the practical assessment, and its format varies a lot by company, so be specific about which kind you're being asked to do:

• Live whiteboard/Figma exercise. You're given a prompt on the spot — "redesign the checkout flow for a grocery app" or "design a way for two people to split a bill" — and asked to sketch, structure your thinking, and talk through it in real time, often in Figma or FigJam or literally a whiteboard. This is not evaluated on visual polish. It's evaluated on whether you ask clarifying questions before drawing anything (who's the user, what device, what's the business constraint), whether you consider more than one structure, and whether you can defend a decision when the interviewer pushes back — because they will push back, deliberately, to see if you fold or reason.
• Take-home exercise. A brief you work on over a few days and present. Here the thing under test is closer to real work: can you scope a genuinely ambiguous brief, and can you present a rationale to a room, not just hand over screens. If the brief doesn't specify a research method, using one anyway (even a lightweight guerrilla test with five people) and saying so is usually noticed.
• Critique exercise. You're shown an existing screen or flow — sometimes the company's own product — and asked what you'd change. This tests judgement more than execution: can you identify the actual usability problem (a confusing information hierarchy, a violated platform convention, an accessibility failure like insufficient contrast or missing focus states) rather than making cosmetic suggestions about colour and font.

A shallow answer in any of these sounds like design opinion with no user in it: "I'd make the button bigger and change the colour to make it pop." A designer interviewing you wants to hear which specific problem the change solves — discoverability, contrast ratio, touch target size, competing with a stronger visual element nearby — and ideally a way you'd check whether the change worked.

The questions that aren't really about design

A few questions recur precisely because they're hard to fake, and they're worth naming because they don't sound like technical questions on the surface.

"Tell me about a time a stakeholder disagreed with your design." This is a collaboration question wearing a conflict-story costume. A weak answer ends with "and eventually they saw it my way" or, worse, "I just did what they wanted." A strong answer describes a specific disagreement, what evidence or reasoning each side had, and a resolution that involved actually changing something — either your design or your own view, on the basis of something you learned. If nothing ever moves in your stories, that's a signal you don't actually negotiate, you just narrate.

"How do you know when a design is done?" or "How do you handle a feature with no time for research?" These probe whether you have a functioning process under real constraints, not the textbook double-diamond. A shallow answer recites a framework by name — "I always start with empathy mapping, then ideation, then prototyping" — without ever connecting it to a constraint. An experienced designer describes what they cut and why: "there was no time for a full study, so I ran a five-minute unmoderated test on the two riskiest screens and used that to decide between two directions."

"How do you work with engineering?" This is checking whether you understand what you're actually handing off — component states, edge cases, empty states, error states, not just the happy path — and whether you've ever had a design change because of a real technical constraint you didn't anticipate. If your answer implies engineers just build whatever you send them, that reads as inexperience, not confidence.

Metrics and business questions — "how would you measure success for this feature," or "how do you decide what to prioritise" — are checking whether you can connect a design decision to a number a business cares about (conversion, task completion time, support ticket volume, retention) rather than only to aesthetic or usability language. You don't need to be a data analyst, but naming a metric you'd actually track, even roughly, separates you from someone who's never had to justify a roadmap slot.

What to do with this

Before any interview, pick two or three projects and rebuild the story for each one around: the actual problem behind the brief, one hard trade-off, your specific contribution versus the team's, and what happened after launch, even if the answer is "we didn't measure it and here's what I'd track next time." That last honesty lands better than a vague success claim.

If you're doing a live design exercise, practise the first ninety seconds — the clarifying questions — more than the drawing. Most weak performances aren't bad ideas, they're a candidate who starts sketching before they know who the user is or what the constraint is.

And if the problem you're actually facing is earlier than any of this — applications that go nowhere and no interview to prepare for — that's a different problem with a different mechanism, worth solving before you polish interview answers for a call that never comes. jobmarket.pro reads the advert in full, matches it against one profile of your actual experience, and prepares the application from that, without inventing anything you haven't done.