How to Interview a UX Designer: 15 Questions That Reveal Real Skill (With Scorecard)

Most UX hiring in the Gulf goes like this: a founder or product manager looks at a portfolio, likes the screenshots, has a friendly 40-minute chat, and makes an offer. Six months later, the designer is producing beautiful mockups that engineers can’t build and users don’t understand.

The problem isn’t the designer pool. It’s the interview. Portfolios show outcomes, not thinking — and in a market where design agencies often do the heavy lifting on “personal” portfolios, outcomes can be borrowed. What you need is a way to see how someone thinks.

This guide gives you exactly that: 15 questions, organized in four blocks, with a scoring rubric you can copy into a spreadsheet and use in your next interview. It’s the same structure we use when we vet designers for our designers extension engagements.

Why do portfolio reviews fail?

A portfolio tells you three things: the candidate was near a project, someone on that project made good decisions, and the candidate can present work nicely. It does not tell you which decisions were theirs.

In Saudi Arabia and Egypt, where design bootcamps and agencies grew fast after 2020, portfolio inflation is real. We’ve interviewed candidates who presented work from our own client projects — work they touched for two weeks as juniors — as if they’d led it. They’re not always lying. Sometimes they genuinely don’t know where their contribution ended.

The fix is simple: stop reviewing portfolios and start interrogating decisions. Every question below forces the candidate to separate what they did from what the team did.

Block 1: craft questions (can they actually design?)

These test whether the candidate can make and defend specific design decisions.

1. “Pick one screen from your portfolio. Walk me through every decision on it.” Listen for hierarchy logic (“I made the primary action bigger because…”), not taste (“I liked the blue”). Strong candidates explain spacing, contrast, and content priority without prompting.

2. “What’s wrong with this screen?” (show them a real screen from your product) This is the highest-signal question in the whole interview. Give them 5 minutes with an actual screen — ideally one you know has problems. Strong candidates find real issues: unclear hierarchy, missing states, confusing labels. Weak ones say “I’d modernize the visual style.”

3. “Tell me about a time data or research changed your design.” If they’ve never changed a design because of evidence, they design for themselves. The answer should include what the evidence was and what specifically changed.

4. “How do you handle empty states, error states, and loading states?” Juniors design the happy path. Seniors design the whole system. If they look confused by the question, that’s your answer.

Block 2: process questions (how do they work?)

5. “Walk me through one project from brief to launch. What was your role at each step?” The phrase “my role” is doing the work here. Watch for “we” turning into “I” only at the visual design stage — that tells you they were handed the thinking and just executed pixels.

6. “What research did you do, and what did it change?” You want specifics: “We interviewed 8 merchants and learned they reconcile payments at night, so we moved the reconciliation report to the home screen.” Not: “We did user research and it validated our direction.”

7. “Tell me about a design you were wrong about.” Every honest designer has one. A candidate who can’t name a failure either lacks experience or lacks self-awareness. Both are problems.

8. “How do you decide when a design is done?” Good answers mention acceptance criteria, usability thresholds, or engineering handoff quality. Bad answers mention “when the client is happy” or “when it feels right.”

Block 3: collaboration questions (can they survive your team?)

9. “Tell me about a time an engineer told you your design couldn’t be built. What happened?” The correct shape of answer: they asked why, learned the constraint, and redesigned. The wrong shape: they escalated, complained, or shipped it anyway.

10. “How do you handle feedback you disagree with?” Look for a process — asking what problem the feedback is trying to solve — rather than either surrender (“I just make the change”) or war (“I defend my design”).

11. “Have you worked in a design system? What did you contribute to it?” Contributing to a system matters more than using one. Anyone can drag components onto a canvas. Fewer people can document a component’s states and rules.

12. “Describe a project where you worked with a product manager. Who decided what?” This surfaces how they handle ambiguity and power dynamics — the two things that kill designer-product manager relationships.

Block 4: business questions (do they understand why design exists?)

13. “What business metric did one of your designs move? How do you know?” This is the hardest question on the list, and the most revealing. Most designers have never been shown post-launch numbers. If they admit that honestly and tell you how they’d measure it, that’s acceptable. If they invent a number, that’s a red flag — the number will be suspiciously round and suspiciously large.

14. “Why does a company hire a UX designer instead of just hiring a graphic designer?” Tests whether they understand their own discipline. Good answers mention behavior, friction, and outcomes. Bad answers mention “user empathy” as a slogan.

15. “If you joined us, what would you want to learn in your first two weeks?” Strong candidates want to talk to users, read support tickets, and look at analytics. Weak candidates want to audit the visual design.

The scorecard

Score each answer 1–5 immediately after the interview, while memory is fresh:

Advance threshold: 50+ total (out of 75), with no score below 3 on questions 5, 6, or 13. A candidate can be weaker on business questions and still be a great mid-level hire — but a candidate who can’t explain their own decisions (Q5) will not grow.

Two interviewers should score independently, then compare. Where your scores differ by 2+ points, discuss — that gap usually reveals something one interviewer noticed and the other missed.

What should you pay attention to beyond answers?

Three behavioral signals during the interview itself:

• Do they ask about your users? A candidate who spends 30 minutes being interviewed about UX and never asks who the users are has told you everything.

• Do they ask about constraints? Budget, timeline, tech stack, team size. Seniors ask. Juniors assume.

• Can they say “I don’t know”? One honest “I don’t know, here’s how I’d find out” is worth more than ten confident answers.

What about take-home assignments?

Keep them short (2–3 hours of effort, maximum), base them on a fictional problem rather than your actual product, and always pay for anything that takes longer. Unpaid multi-day assignments filter for desperate candidates, not good ones — the best designers in Riyadh and Cairo have options and will simply decline.

A better alternative: a 60-minute live working session. Give them a messy requirement and think out loud together. You’ll learn more about how they work than from any polished deliverable.

Hiring is one way to get design capacity. It’s not the only one — a senior designer embedded through a designers extension model gives you vetted capability in days, with none of the six-month risk. If you’d rather we do the vetting — we interview designers for a living — talk to us.

Interviewing UX designers? Get our hiring support →