What to expect in a junior UX designer interview
UX interviews are unique in one important way: your portfolio does a significant portion of the talking before you've said a word. Most junior UX interviews will include a portfolio review (walk me through a project), a process and methodology round (how do you approach design problems), and a behavioural round (collaboration, feedback, and communication).
Many also include a design challenge — a short brief you're asked to think through on the spot or over 24–48 hours. Treat these as a thinking exercise, not a pixel-perfect deliverable.
The most important thing junior UX candidates get wrong
They focus too much on aesthetics and not enough on process and rationale. Interviewers want to know why you made each decision — not just what it looks like. Every design choice should be traceable to user insight, a constraint, or a hypothesis you were testing.
Design process and methodology
Questions 1–7 · Process & Methodology
Question 01
"Walk me through your design process from brief to final output."
What they're really asking
Do you have a structured, repeatable process — or do you just open Figma and start designing?
How to answer it
Walk through the stages you actually follow: understand the problem (business goals, user goals, constraints), research (existing data, user interviews, competitive analysis), define (problem statement, user personas, jobs to be done), ideate (sketching, divergent thinking before converging), prototype (low-fi to hi-fi depending on what needs testing), test (usability testing with real users), iterate and hand off. The key: show you understand that design starts with understanding, not with screens. Use a real project to illustrate the process as you describe it.
Question 02
"What is user-centred design and why does it matter?"
What they're really asking
Can you articulate the philosophy that underlies good UX?
How to answer it
User-centred design is a design philosophy that puts the needs, goals, and context of real users at the centre of every decision. It matters because products built on assumptions about what users want — rather than actual understanding — consistently fail to solve the right problem. UCD is iterative by nature: you involve users throughout the process, not just at the beginning or end, so you can correct misunderstandings before they're baked into production. The business case is simple: designing the right thing is far cheaper than building the wrong thing beautifully.
Question 03
"What UX research methods have you used? When would you choose each?"
What they're really asking
Do you understand that different research methods answer different types of questions?
How to answer it
Describe methods you've actually used, then explain the logic of when to use each. User interviews: qualitative, exploratory — good for understanding motivations and mental models. Surveys: quantitative, scalable — good for validating hypotheses across a larger sample. Usability testing: observational — good for identifying friction in specific flows. Card sorting: good for information architecture decisions. Analytics review: behavioural data at scale — tells you what users do, not why. The best research mixes methods: use qualitative to generate hypotheses, quantitative to validate them.
Question 04
"What is the difference between UX and UI design?"
What they're really asking
Do you understand the full scope of the discipline and where your role begins and ends?
How to answer it
UX (user experience) design is concerned with the overall experience a person has using a product — the flows, the information architecture, the content strategy, and whether the product actually helps them achieve their goal. It's fundamentally about problem-solving. UI (user interface) design is concerned with the visual and interactive layer — typography, colour, spacing, components, and motion. In practice, many roles overlap both. Good UI without good UX is a beautiful product that doesn't work. Good UX without good UI is a useful product that feels unpleasant to use. You need both.
Question 05
"How do you approach designing for accessibility?"
What they're really asking
Is accessibility an afterthought or a design principle for you?
How to answer it
Accessibility means designing for the full range of human ability — visual, motor, cognitive, and hearing differences. Practical steps: meet WCAG colour contrast requirements, ensure all interactive elements are keyboard-accessible, don't rely on colour alone to convey meaning, provide alt text for images, design for screen reader compatibility. Beyond compliance: accessible design is almost always better design for everyone — clear contrast, large tap targets, and unambiguous labels benefit all users. Build it in from the start rather than retrofitting it.
Question 06
"What tools do you use and how do you decide which to use for a given task?"
What they're really asking
Are you tool-flexible, or dependent on one application?
How to answer it
Name what you've actually used — Figma, Sketch, Adobe XD for design; Maze, UserTesting, Lookback for research; Miro or FigJam for workshops; Notion or Confluence for documentation. Then explain your selection logic: for quick low-fi ideation, paper or whiteboard; for collaborative prototyping, Figma; for moderated usability tests, screen sharing with verbal protocol; for unmoderated tests at scale, a tool like Maze. The answer they want to hear: you pick the tool that serves the task, not the most impressive-sounding one.
Question 07
"How do you know when a design is good enough to ship?"
What they're really asking
Can you balance quality with the realities of shipping software?
How to answer it
A design is ready to ship when it solves the defined problem for users without introducing significant friction, meets the technical and business constraints, and has been validated enough to feel confident in the core flows. Perfect is the enemy of shipped. The goal isn't to eliminate all uncertainty — it's to reduce it to an acceptable level given what's at stake. For low-risk changes, ship and measure. For high-stakes flows (payments, onboarding), invest more in validation first. Knowing where to draw the line is one of the key skills of a mature designer.
Practise explaining your design thinking out loud
UX interviews reward candidates who can articulate their reasoning clearly. InterviewZap helps you practise exactly that — with feedback on your structure, clarity, and confidence.
Start Practising Free →No credit card. Free to start.
Portfolio and critique
Questions 8–13 · Portfolio & Critique
Question 08
"Walk me through a project in your portfolio. What was your specific contribution?"
What they're really asking
This is the centrepiece of most UX interviews. Can you narrate a design story clearly?
How to answer it
Structure your walkthrough: problem (what were you solving and for whom?), constraints (time, team, platform, business requirements), process (what research or discovery did you do?), decisions (what design choices did you make and why?), outcome (what shipped, and how did it perform?), reflection (what would you do differently?). Be explicit about your specific role in team projects. The reflection at the end signals maturity — nobody expects perfection, but they do expect learning.
Question 09
"Tell me about a design decision you made that you later realised was wrong."
What they're really asking
Can you evaluate your own work critically? Are you intellectually honest?
How to answer it
Be genuinely honest here — pick a real example. Describe the decision, why you made it at the time, what you later discovered (through user testing, analytics, or feedback), and what you would do differently. The best answer shows that your mistake led to a better outcome through iteration — not just that you made an error. Designers who can't critique their own work are a liability; those who can are accelerating their growth.
Question 10
"How do you handle it when a stakeholder or developer pushes back on your design?"
What they're really asking
Design is collaborative. Can you advocate for your work without being precious about it?
How to answer it
First, understand the pushback: is it based on a technical constraint, a business concern, or a design preference? Constraints are real and worth accommodating; pure preferences are worth discussing with evidence. Present your reasoning clearly — what user problem does this design solve, and what's the risk of the proposed alternative? If their concern is valid, update the design. If you believe the original is right, propose testing both approaches. The goal is always the best outcome for the user, not winning the argument.
Question 11
"What's a product or interface you think is poorly designed? What would you change?"
What they're really asking
Do you have critical design taste? Can you articulate problems and solutions clearly?
How to answer it
Pick something genuine that you've actually struggled with — not the most obvious example everyone gives. Describe the specific friction you experienced, hypothesise why it might have happened (technical constraint? competing stakeholder interests? poor research?), and propose a concrete change. Be specific and fair — acknowledge the constraints the original team may have been working under. This question is as much about your communication and reasoning as your design taste.
Question 12
"How do you work with engineers during implementation to make sure the design is built correctly?"
What they're really asking
Can you collaborate across disciplines, or do you throw designs over the fence?
How to answer it
The best designers are actively involved during build, not just at handoff. Practical steps: involve engineers early in the design process to surface constraints before they become expensive fixes; produce thorough, annotated handoff files with edge cases and interaction states documented; be available during implementation to answer questions and review work in progress; conduct a design QA before launch to catch visual or interaction deviations. Relationship matters too — engineers who feel respected by a designer are more invested in getting the details right.
Question 13
"How do you incorporate user feedback after a feature has shipped?"
What they're really asking
Do you see shipping as the end of the design process, or the beginning of a feedback loop?
How to answer it
Post-launch, monitor analytics for unexpected user behaviour — drop-off points, low engagement on key features, error rates. Gather qualitative feedback through support tickets, in-app surveys, or follow-up user interviews. Treat post-launch data as a gift — it tells you things no amount of upfront research can. Log insights, prioritise iterations, and feed them into the next design cycle. The best products aren't designed once — they're continuously improved based on real usage.
Behavioural questions
Use the STAR method for these.
Questions 14–20 · Behavioural
Question 14
"Tell me about a time you had to design under significant constraints."
What they're really asking
Constraints are real life. Can you produce good work within them?
How to answer it
Describe the constraint clearly — tight timeline, limited research access, technical limitations, brand restrictions. Walk through how you worked within it: what trade-offs did you make, what did you prioritise, and what was the outcome? Great designers often produce their best work under constraints — they force clarity about what actually matters. Show that constraints sharpen your thinking rather than paralysing you.
Question 15
"Describe a time you had to advocate for the user when business or technical pressure was pushing in a different direction."
What they're really asking
Can you hold the line for user needs without being inflexible?
How to answer it
Describe the tension — a business wanting to add a promotional element that disrupts a critical flow, or an engineer proposing a technical shortcut that would confuse users. Walk through how you made the case: using data, user quotes, or a quick test rather than just opinion. The best answer shows you won through evidence, not stubbornness — and that when you didn't win, you proposed a compromise that preserved the most important user experience principles.
Question 16
"Tell me about a time you received critical feedback on your design work."
What they're really asking
Can you separate your identity from your work and grow from criticism?
How to answer it
Be genuine. Describe the feedback, your initial reaction (it's fine to acknowledge it stung), and how you processed and acted on it. The outcome should show growth — either the work got better because of the feedback, or you learned something that changed how you approach design reviews. Designers who are defensive about their work make every collaboration harder.
Question 17
"Describe a time you had to work on a design problem that was genuinely ambiguous."
What they're really asking
Most real design problems are ambiguous. Can you move forward without perfect clarity?
How to answer it
Describe the ambiguity — unclear requirements, competing stakeholder definitions of success, or a genuinely undefined user problem. Walk through how you created enough structure to move forward: what assumptions did you make explicit, what did you decide to learn first, how did you scope the problem to something actionable? Moving productively through ambiguity is one of the highest-value skills in any design role.
Question 18
"How do you keep your design skills current?"
What they're really asking
Are you genuinely curious about the craft, or just doing the minimum?
How to answer it
Be specific. Name the resources you actually use — design blogs (Nielsen Norman Group, UX Collective), podcasts, communities, courses, or designers whose work you follow and why. Then mention something concrete you've learned recently and how it changed your practice. The specific detail is what makes this answer land — "I follow NNG" is fine; "I read NNG's recent research on mobile form design and changed how I structure multi-step flows based on it" is excellent.
Question 19
"Where do you want to be in your UX career in three years?"
What they're really asking
Do you have a direction — and does this role fit into it?
How to answer it
Be honest about your interests. If you're drawn to the research side, say so; if you're more drawn to systems design or product strategy, own that too. Connect your three-year aspiration back to what this role specifically offers. The answer they're looking for: you're serious about developing as a designer, this role is a meaningful step in that direction, and you've thought about it beyond just "get a job."
Question 20
"Do you have any questions for us?"
What they're really asking
Are you genuinely curious about the role and design culture here?
How to answer it
Strong questions for UX roles: "How close do designers work with engineering and product here — is it collaborative from the start or more of a handoff culture?" / "How does the team approach user research — is there a dedicated research function or do designers own it?" / "What does the design review process look like?" / "What's one design decision the team wishes it had made differently in the last year?"
One more thing: your portfolio is your interview
Before you apply anywhere, make sure every case study in your portfolio explains the problem, your process, the decisions you made, and the outcome. Interviewers skim portfolios that only show screenshots — they stop and read portfolios that tell a story.