Every question below is one that gets asked. What we have added is the part that usually goes unsaid: what a strong answer actually demonstrates. Career1 scores interviews for a living, so this is the difference we see between an answer that lands and one that was rehearsed.
How this interview usually runs
Most companies run some version of these stages. Smaller teams often fold two of them into one conversation.
-
01
Screening call
Your background, the products you have designed for, and the kind of design work you want to do next.
-
02
Portfolio presentation
One or two case studies presented to the team, with questions throughout. Often the longest and most important part of the process.
-
03
Design exercise
A take-home brief or a live whiteboard session. How you frame the problem is assessed as closely as what you produce.
-
04
Cross-functional interviews
Conversations with a product manager, an engineer and sometimes a researcher, about how you work with each of them.
The portfolio walkthrough
-
Take me through this project. What was the constraint?
What a strong answer shows: Whether you designed toward a problem or decorated a requirement. The constraint is the part that cannot be invented afterwards.
-
What did you personally decide here, and what did the team decide?
What a strong answer shows: Honesty about scope. Beautiful case studies routinely come from teams of six, and claiming all of it reads badly.
-
What alternatives did you explore and reject?
What a strong answer shows: That there were alternatives. Showing only the final solution leaves the interviewer unable to judge your thinking; rejected options with reasons show it.
-
What would you change about this now?
What a strong answer shows: Self-criticism. Designers who have shipped always have an answer; people presenting student work often do not.
-
Why did you choose these projects to show us?
What a strong answer shows: Self-awareness about your strengths and about this role. The best answers connect the work shown to problems this team actually has.
Research and evidence
-
How did you know the design was working?
What a strong answer shows: Whether the answer involves evidence or taste. Both are legitimate, but conflating them is not.
-
Tell me about a time research contradicted what you believed.
What a strong answer shows: Whether research is used to learn or to justify. This one is very hard to fake.
-
How do you work when there is no budget for research?
What a strong answer shows: Resourcefulness: support tickets, session recordings, sales calls and talking to five users are all real answers.
-
How do you decide how many people to test with?
What a strong answer shows: Matching method to question: a handful of sessions finds usability problems in a flow, while measuring how common something is needs larger samples or quantitative data. Quoting one rule for both is the weak answer.
-
How do you write a usability test task without leading the participant?
What a strong answer shows: Tasks framed as goals rather than instructions, avoiding the interface's own labels, and ideally a story about a session spoiled by a leading question.
-
How do you use analytics alongside qualitative research?
What a strong answer shows: That analytics show where and how often, and research shows why, with an example of one deciding what to investigate with the other.
Design craft and exercises
-
Walk me through how you would approach this design exercise.
What a strong answer shows: Questions before sketches: who the user is, what the constraint is and what success means. The framing is marked more heavily than the final screens.
-
How do you design for accessibility from the start?
What a strong answer shows: Contrast, visible focus states, text that resizes, touch target size and never relying on colour alone, checked during design rather than left to engineering. Examples, not a mention of WCAG.
-
How do you design empty, error and loading states?
What a strong answer shows: That they are part of the design, not engineering's problem. Strong candidates have them in their files and can say what the user should do next in each.
-
How do you work within a design system, and when do you break from it?
What a strong answer shows: Respect for consistency plus judgement about when a pattern does not fit, and proposing a change to the system rather than quietly making a one-off.
-
How does designing for a phone change your approach?
What a strong answer shows: More than shrinking the layout: reach, what to cut rather than stack, input types, and the situation someone is in when they are using it.
-
How are you using AI tools in your design work?
What a strong answer shows: Specific, honest use, such as synthesising research notes or exploring variations, with judgement about what needs checking. Neither dismissing the tools nor claiming they do the design.
Working with other people
-
What happens when engineering says your design is too expensive to build?
What a strong answer shows: Collaboration versus territory. The best answers involve finding what was expensive and redesigning around it.
-
How do you handle a stakeholder who wants something you think is wrong?
What a strong answer shows: Whether you can disagree with evidence and still ship.
-
How do you hand a design over to engineering?
What a strong answer shows: That handover is a conversation, not a file: states and edge cases specified, questions answered during the build, and reviewing what shipped against what was designed.
-
Tell me about feedback on your work that you disagreed with.
What a strong answer shows: Separating the problem someone raised from the solution they suggested, and changing your mind when the problem was real.
-
How do you present a design to senior stakeholders?
What a strong answer shows: Leading with the problem and the evidence, showing options and trade-offs briefly, and asking for a specific decision rather than general feedback.
Now practise it out loud
Reading questions is the easy half. Career1's AI interviewer asks questions like these by voice and follows up when an answer is thin. It takes about eight minutes and costs nothing.
Practise first, in private: once a week, no video and no score, with written feedback that is never shared with companies. When you are ready, the vetting interview is a separate single attempt, no retakes: it is recorded, scored and becomes a profile companies can find. You can hide that profile at any time.
Practise this interview freeQuestions people ask
What should a UX portfolio show for interviews?
Fewer projects, in more depth. Two or three cases where you can explain the constraint, the alternatives you rejected and what you would change beat a gallery of finished screens every time.
How do I interview well with mostly unshipped work?
Be direct about what shipped and what did not, then spend the time on the reasoning. Interviewers mind an unshipped project far less than they mind discovering later that it never launched.
Do UX interviews include a design exercise?
Often, either as a take-home or a live whiteboard session. The evaluation is usually about how you frame the problem and what questions you ask before drawing anything.
Do UX designers need to know how to code?
It is rarely required. Understanding what is hard to build, how components and states work, and how to discuss both with engineers helps far more in interviews than writing production code.
Other roles
Preparing for the general questions too? Common interview questions and what they test.
Hiring instead of interviewing? See how Career1 vets applicants for you.