Key takeaways
- Design interviews test three things beyond your portfolio screens: how you think, how you handle disagreement, and how you talk about your own decisions under pressure.
- The 20 questions below cover four categories every serious design interview draws from — portfolio and process, stakeholder and behavioural, design challenges, and craft fundamentals.
- Most candidates over-prepare their portfolio and under-prepare their answers to the questions asked about it. Both matter equally.
- There is no single 'correct' answer to most of these — what interviewers are actually scoring is whether your reasoning holds up when they push back.
- Practising out loud, with a real person pushing back on your answers, closes the gap between knowing what to say and actually saying it clearly under pressure — reading this article is preparation; rehearsing it with feedback is what actually works.
A strong portfolio gets you into the interview room. It does not by itself get you the offer. What happens inside that room — how clearly you can explain your decisions, how you handle a stakeholder pushing back, how you think out loud on an unfamiliar problem — is a separate skill from the design work itself, and it is the skill most candidates under-prepare for.
Below are 20 questions that come up again and again across UI/UX and product design interviews, grouped into the four categories every serious interview process draws from. For each one: what the interviewer is actually testing, and how to structure an answer that holds up when they push back.
Portfolio and process questions
These open most interviews, and they are where strong portfolios most often produce weak interviews — because candidates describe their final screens instead of their reasoning.
1. Walk me through your design process from start to finish
What they're testing: whether you have a repeatable, coherent process, or whether each project happened by accident. How to answer: pick one real project and narrate it in order — the problem you were given, the research you did, two or three directions you considered, why you chose the one you shipped, what you tested, what changed after testing. Avoid a generic textbook answer ("first I empathise, then I define...") with no specific project attached to it.
2. Tell me about your favourite project in your portfolio and why
What they're testing: what you actually value in your own work, and whether you can talk about it with genuine enthusiasm rather than rehearsed neutrality. How to answer: pick the project where you made the hardest trade-off, not necessarily the one that looks best visually. Interviewers remember candidates who clearly cared about a specific decision, not candidates who liked everything equally.
3. What was your biggest constraint?
What they're testing: real-world adaptability. Every product has constraints — technical, timeline, legal, business. How to answer: name a specific constraint (a two-week deadline, an engineering limitation, a stakeholder who wanted something you disagreed with) and walk through the actual trade-off you made, including what you gave up.
4. How do you know when a design is "done"?
What they're testing: whether you understand that design work is a series of trade-offs against time and evidence, not a pursuit of an abstract "perfect." How to answer: talk about specific done-criteria — usability metrics hit, stakeholder sign-off, a test that validated the core flow — rather than "when it feels right."
5. Show me a project that failed or didn't go as planned
What they're testing: honesty and growth, and how you talk about your own mistakes. This is one of the highest-signal questions in the entire interview. How to answer: pick something genuinely imperfect, own your part in it plainly, and end on what you would do differently now — not a story where the failure was really someone else's fault.
Stakeholder and behavioural questions
These test whether you can survive inside a real team, not just produce good screens in isolation.
6. Tell me about a time you disagreed with a PM or engineer
What they're testing: whether you can disagree productively without either caving immediately or becoming difficult to work with. How to answer: describe the disagreement specifically, how you made your case (ideally with evidence — research, data, a prototype test), and how it actually resolved — including if you were the one who ended up wrong.
7. How do you handle negative feedback on your design?
What they're testing: ego management. Design is a critique-heavy discipline; someone who gets defensive in every review is a liability on a team. How to answer: give a specific example of feedback that stung a little, and how you separated the useful signal in it from the delivery, then acted on it.
8. Describe a decision you made with incomplete data
What they're testing: comfort with ambiguity, since almost no real design decision has complete data behind it. How to answer: be honest about what you didn't know, what assumption you made explicitly, and how you planned to validate or revisit that assumption later.
9. How do you prioritise conflicting stakeholders?
What they're testing: whether you can navigate organisational politics without either steamrolling people or being steamrolled. How to answer: talk about how you anchored the conversation to user evidence or business goals rather than personal opinion, and how that reframing helped resolve competing requests.
10. Tell me about a time you had to say no to a stakeholder
What they're testing: backbone, paired with tact. How to answer: describe the request, your reasoning for pushing back, and specifically how you delivered the "no" — most interviewers are listening for whether you did it respectfully and with evidence, not whether you simply refused.
Design challenge and whiteboard questions
These are live, timed exercises — usually 20 to 40 minutes — designed to watch your thinking process directly rather than review finished work.
11. Redesign a familiar app for a specific new use case
What they're testing: whether you ask clarifying questions before designing, or jump straight to screens. How to answer: spend the first few minutes asking who the user is, what problem you're actually solving, and what success looks like — before sketching anything. Interviewers score the questions you ask almost as heavily as the design you produce.
12. How would you improve this checkout or signup flow?
What they're testing: whether you can spot friction and reason about funnel-level thinking, not just visual polish. How to answer: name specific friction points (too many fields, unclear error states, hidden costs) and connect each fix to a plausible metric it would move.
13. Design an onboarding flow for [a specific product]
What they're testing: your ability to balance getting a user to value quickly against not overwhelming them. How to answer: talk explicitly about what the single most important first action is, and how your flow gets a user there with minimal friction, before adding anything else.
14. How would you design this for accessibility?
What they're testing: whether accessibility is a habit for you or an afterthought. How to answer: speak concretely — contrast ratios, screen-reader labelling, keyboard navigation, colour-independent status indicators — rather than a vague "I always keep accessibility in mind."
15. Walk me through how you'd approach a totally unfamiliar domain
What they're testing: your research instinct when you have zero prior context — a realistic simulation of your first weeks on a new job. How to answer: describe a real process — competitive research, talking to actual users or domain experts, identifying your own knowledge gaps before proposing solutions.
Craft and technical questions
These probe the depth behind your visual work — systems thinking, testing discipline, and how you work with the rest of the team.
16. How do you choose between UI patterns?
What they're testing: whether pattern choices are deliberate or just aesthetic preference. How to answer: reference a real trade-off — for example, a modal versus a full page for a given task — and the specific reasoning (interruption cost, mobile constraints, data density) that decided it.
17. What's your approach to building and maintaining a design system?
What they're testing: systems thinking beyond one-off screens. How to answer: talk about tokens versus components, how you handle documentation, and — if you have real experience — a specific moment the system prevented inconsistency or saved real time.
18. How do you run usability testing?
What they're testing: whether research is a genuine habit or a checkbox. How to answer: describe a real test — how many participants, what tasks, what you actually changed afterward. A specific, even small, real study beats a vague description of "the process."
19. How do you collaborate with developers during handoff?
What they're testing: whether you understand that your job doesn't end at the final Figma frame. How to answer: talk about spec clarity, edge-case documentation, and how you handle the inevitable moment a developer flags something as technically infeasible.
20. What metrics do you look at to know if a design succeeded?
What they're testing: whether you think about outcomes, not just outputs. How to answer: name specific metrics relevant to the project — task completion rate, conversion, time on task, support-ticket volume — and be honest if a design you shipped didn't move the number you expected.
How to actually practise this
Reading this list is not preparation — it's the map, not the walk. The gap between understanding a good answer and delivering one fluently, under nerves, with a real follow-up question landing mid-sentence, is exactly what rehearsal closes. Say your answers out loud. Better still, say them to a real person who will push back the way a real interviewer will, not just nod along.
This is exactly why mock interviews with real pushback are built into our placement support — not a formality at the end of a course, but genuine practice against the specific questions above, with a mentor who tells you honestly when an answer isn't landing.
Where to go from here
If you're preparing for interviews right now, the fastest useful next step is rehearsing these 20 questions out loud against your own real portfolio projects — not memorising scripts, but building the muscle of reasoning clearly under a bit of pressure. If you're earlier in the process and still building the portfolio these questions will be asked about, our Professional Certificate in UX/UI Design is built around exactly this kind of live critique and jury defence, so interview-day reasoning is a habit by the time you graduate, not something you're building from scratch the week before an interview.
Two ways to take the next step:
- Book a free 45-minute demo class and see how live critique actually builds this skill. Book your free demo class here.
- See the full curriculum for the Professional Certificate, including how jury defence and mock interviews are built into the final months. View the programme here.
Frequently asked questions
How many of these 20 questions will actually come up in a real interview?
Should I memorise exact answers to these questions?
What is the single biggest mistake candidates make in design interviews?
How is a whiteboard design challenge actually scored?
How should I actually practice for these, beyond reading this list?
Learn this properly, not passively.
Live studios, real users, jury-reviewed portfolios — see how the school behind this article teaches.
Book a Free Demo ClassA live 45-minute session · No pressure, no hard sell