Questions to Ask in a UX Interview
For a UX designer, product designer or UX researcher preparing questions to ask the interviewer, whether that is the hiring manager, a designer on the team, or a product or engineering partner. The list runs in six groups: the role and how mature design is at the company, how research is done and what happens to it, the process and handoff, the design system and tools, the team and growth, then the portfolio review, the design exercise and the close. Every question carries a note: what a strong answer or a worrying one sounds like, and often which person on the loop to ask.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Role and maturity
Where does design sit in the company, and who does the most senior designer report to?
Why ask it
A design lead who reports into product or engineering argues for the work from one step down, and one who sits beside those leaders argues as a peer. Either can work, so follow up by asking who speaks for design when the quarter's plan is set. If nobody does, expect the plan to arrive already decided.
How would you describe the design maturity here, and what was the last decision that design changed?
Why ask it
Any company will say it values design, so the second half is the real question. A good answer is a feature that was dropped, reshaped or delayed because of what a designer or researcher found. If every example is about making something look better, the job is likely to be drawing solutions other people chose.
How many designers, researchers, product managers and engineers are there, and how are they split across teams?
Why ask it
The numbers show how thinly you would be spread. One designer serving three product teams has to pick which work gets real thought and which gets a quick pass, so ask who makes that choice. Put the same question to a second interviewer and see whether the counts match.
What does a typical week look like for a designer here, and how much of it is left for design work?
Why ask it
Count the fixed items as they are listed: standups, planning, design reviews, critique, stakeholder check-ins. You are hoping to hear of a few unbroken half days, because a flow or a research plan is hard to work out in the gaps between calls. A designer on the team will give a truer count than the manager, so save a turn for one of them.
What does success look like for a designer here after six months?
Why ask it
Notice whether the answer is about output, such as screens delivered and tickets closed, or about a result for users or the business. Output answers are common where design is judged by how fast it feeds engineering. If you get one, mention a result from your own portfolio and see whether the manager's interest picks up.
What would I be working on in my first three months, and what state is it in today?
Why ask it
You are hoping for a named product area and an honest description: a blank page, a half-built flow, or something live that needs repair. Each asks for different strengths, so say which you do best while the subject is open. 'Whatever comes up' suggests design is run as a request desk.
What is the hardest problem the design team is dealing with right now?
Why ask it
Good answers are specific: a checkout flow nobody wants to touch, three products with three visual languages, a research backlog a year long. Sort what you hear into design problems, which you could help with, and standing problems, such as design having no say in the plan, which one new hire rarely moves. For the second sort, find out who above the team is working on it.
Is this a new role or a replacement, and what do you want from design that you are not getting now?
Why ask it
A first design hire and a fifth walk into different jobs with the same title. If someone left, the second half tells you what the manager felt was missing, which may be a skill or may be something no single designer could supply, such as influence over the roadmap. Ask which they think it was.
Is the role a generalist one, or does it lean toward research, interaction design, visual design or content?
Why ask it
UX designer and product designer mean different things from one company to the next, so ask roughly what share of a week each skill takes. If the answer is mostly polished interface work and you want discovery, or the reverse, it is better heard now than in month two.
At what point does a designer first hear about a new piece of work?
Why ask it
Ask about the most recent project, not the ideal one. Being in the room when the problem was framed is one job, and receiving a ticket with the solution in its title is another. A manager who says 'earlier than we used to' is being honest, so ask what changed.
Research
How is user research done here, and who does it?
Why ask it
The usual setups are dedicated researchers, designers who run their own studies, or very little research at all, and each is workable if they are straight about it. With researchers, ask how a designer gets time with one. Without them, ask how many hours of your own week are meant for it.
When did someone on the team last talk to a user or watch one use the product, and what changed afterwards?
Why ask it
A date in the past few weeks and a specific change mean research is a habit. 'We ran a big study last year' means it is an occasion. Either way you now know how much of what the team believes about its users is recent.
How do designers reach users: a panel, a recruiting budget, or through sales and support?
Why ask it
In business software the customers often belong to account managers, and getting five of them on a call can take weeks of asking. Find out how long it took the last time. Rules on consent and recording differ by company and country, so ask how sessions are handled there.
What happens when research findings contradict something the roadmap has already promised?
Why ask it
This separates research that informs decisions from research that decorates them. Ask for the last time it happened. In the good version a plan moved or a launch was narrowed, and in the worrying one the finding went into a slide deck and the feature shipped as drawn.
Where do research findings live, and could I read some before I start?
Why ask it
A shared, searchable place means the team builds on what it has learned. Studies scattered across personal drives mean each new designer starts from zero and old questions get asked again. Asking to read one report once an offer is made is reasonable, and what they send shows the standard of the work.
How much of the research is discovery, and how much is usability testing of designs that already exist?
Why ask it
Testing a finished design finds flaws in a solution, but it cannot say whether the solution was aimed at the right problem. A team that only tests late has usually decided what to build by other means. If you are interviewing as a researcher, the split is close to a description of the job.
Who decides what gets researched: the researchers, the product teams, or whoever asks first?
Why ask it
For a researcher this is the question of whether you would set an agenda or work through a queue. Designers should ask it too, since a queue means your study waits its turn behind everyone else's. The number of open requests, and how long a typical one sits, says more than the name of the intake process.
What product data can a designer look at, and who helps when a question is too hard for a dashboard?
Why ask it
Direct access to analytics lets you check your own hunches before a design review does it for you. If every number has to be requested from an analyst, ask how long the last request took. 'We go on instinct more than data' is a fair answer too, and it tells you arguments are settled by judgment and seniority.
Process and handoff
What does the design process look like here, and could you take me through it on a recent project?
Why ask it
A described process is the ideal one and a retold project is what happened, which is why the second half matters. Listen for the points where the designer was missing: the kickoff, the scoping, the week before release. Asking a designer and a product manager for the same story and comparing the two is worth one of your turns in each interview.
On your last project together, how did you and the designer divide the work?
Why ask it
One for the product manager on the loop. A PM who describes working out the problem with the designer, sharing the customer calls and arguing over scope, is describing a partner. One who talks about 'getting designs' by a date is describing a supplier, however friendly the tone.
When design and product disagree about what should ship, who makes the call?
Why ask it
Most teams have a real answer, often the product manager or whoever owns the deadline. That can be fine if the designer was heard first. What you want is a recent disagreement in which the designer's objection changed something, even a detail.
How far ahead of engineering does design work?
Why ask it
A designer who is a sprint or two ahead has time to test and think again. One who is designing the ticket being built this week is doing production work under a UX title. The follow-up is what happens when engineering catches up, since testing with users tends to be the first thing dropped.
What does handoff to engineering look like: a written spec, an annotated file, or a conversation?
Why ask it
Best asked of an engineer. Good signs are that engineers saw the design before it was finished and can list what they need from it: error states, empty screens, loading, text that runs long. 'They send us a link' describes a wall with a file thrown over it.
How closely does what ships match what was designed, and who checks before release?
Why ask it
Where nobody compares the build with the design, small differences pile up and designers stop looking. A good sign is that a designer can file a bug for a visual or interaction fault and see it fixed, not parked in a backlog. An engineer who says 'pretty close, and our designer tells us when it is not' is describing a healthy habit.
When time runs short, what gets cut from a design, and who decides?
Why ask it
Something always goes: the edge cases, the empty states, the onboarding, the animation. You are checking that the designer is part of choosing, and that the cut is made on purpose. Then ask how often the promised second version has actually been built.
How much time is there to explore more than one direction before committing?
Why ask it
Days of exploration on a hard problem mean the team is buying thinking. One solution expected by Friday means it is buying screens. If they say there is room, ask a designer what was tried and thrown away on their last project.
How does the team find out whether a design worked once it is live, and does it go back to improve it?
Why ask it
A good answer names what was looked at: task completion, support tickets, a test on the live version, a business number. Teams judged on launches rarely return, and then the designer never learns whether the work did its job. If nobody can recall a feature that got a second pass, treat 'we iterate' as a hope.
Is there a list of known usability problems, and how does anything on it get fixed?
Why ask it
Most teams have the list. What varies is whether there is any route from it to an engineer's week: a share of each sprint, a fix-it week, a designer who lobbies well. If the route is the lobbying designer, that designer would be you.
Who writes the words in the interface?
Why ask it
If there is a content designer or UX writer, ask when they join a project, since late means they are filling boxes someone else drew. If the answer is the designer, or whoever is building it, count the writing as part of your job and say how you feel about that.
System and tools
Is there a design system, and who maintains it?
Why ask it
The answer is usually a dedicated team, a few volunteers in spare hours, or one person who built it and has since moved on. The last two tend to fall behind the product. The date a component was last added or changed tells you whether it is alive.
Does the design library match what is in code?
Why ask it
An engineer will answer this more frankly than a designer. Where the two have drifted apart, every handoff starts with an argument about which one is right, and you would be designing with parts that do not exist. A team that names the mismatches and has a plan is in better shape than one that says they are identical.
How does a designer propose a new component or a change to an existing one?
Why ask it
A known route, such as a request form, a weekly review or a named owner, means the system can grow with the product. If the practical answer is to detach the component and build a one-off, the library is on its way to being ignored. Find out how long the last accepted change took as well, because a route that takes a quarter gets bypassed too.
Which tools does the team use for design, prototyping and research, and can engineers and product managers open the same files?
Why ask it
A new design tool can be learned, so it matters less than who can see the work. Shared access means comments arrive early, from the people who will build it. Listen for whether the list includes anything paid for testing or recruiting participants, because its absence says how much research is really expected.
Who is responsible for accessibility, and at what stage is it checked?
Why ask it
'Everyone' often means nobody, so ask who last caught a problem and when in the project that was. Catching it in design is cheap, an audit before release is expensive, and a customer complaint is worse. Which standards a product has to meet depends on the country and the sector, so ask which apply to this one.
Which platforms would I design for, and do they share one design language?
Why ask it
Web, iOS, Android, a desktop app and internal admin tools each have their own conventions and usually their own engineers. Find out which you would own and which come along as an afterthought. If your portfolio is all web and the role is half mobile, raise it yourself and explain how you would get up to speed.
How are designers here using AI tools, and are there rules about what can be put into them?
Why ask it
Policies on feeding customer data, research recordings or unreleased designs into outside tools differ from employer to employer, so ask before assuming your own habits carry over. The tone of the answer is worth noting too. A team experimenting openly is a different place to work from one waiting for permission.
How do you prototype something too complicated for a click-through mockup?
Why ask it
Products with real data, long tables or live states are hard to test as static screens. Some teams have engineers who build throwaway prototypes, some let designers work in code, and some simply ship and watch. Which one they describe tells you how much risk is settled before launch.
Team and growth
Would my manager be a designer, and how much of their week is still hands-on design?
Why ask it
A manager from the craft can critique your work and argue your promotion in its own terms. Reporting to a product or engineering manager can still go well, but then ask who gives you design feedback. A manager who is also the team's busiest designer may have little time for either.
How often do designers critique each other's work, and what happened at the last session?
Why ask it
The details to listen for are what was shown, how finished it was, and what the designer changed afterwards. Rough work on the screen means people feel safe showing it. Critique held 'when we need it' tends to happen once the design is too far along to change.
Would I be the only designer on my product team, and where would I get feedback from other designers?
Why ask it
Being embedded alone with a PM and engineers is common and can be lonely for the craft. A weekly session with the other designers, a pairing habit or a lead who reviews files fills the gap. If there is nothing, you would be building it yourself, which suits a senior designer better than someone early on.
Who outside the team reviews design work before it ships, and whose objection can stop it?
Why ask it
Founders, brand, legal and sales all sometimes hold a veto, and it is better to learn the list now than in the week of a launch. How the last late objection arrived matters as much as who made it. A designer who was in the room and heard the reason had a very different day from one who got a screenshot back with changes drawn on it.
Is there a written career ladder for designers, and could I see it?
Why ask it
A document they can send you means levels are decided against something other than a manager's impression, and it lets you check where this role sits. Having no ladder is common in small companies and is not a bad sign by itself. In that case the useful fact is how the last raise or title change for a designer was decided.
What does a designer at the next level up do that this role is not yet expected to do?
Why ask it
Good answers describe scope: owning a whole product area, shaping what gets built, raising the standard of other people's work. If the only difference offered is years of experience, promotion may be a matter of waiting. The most recent promotion on the team, and what that person had done to earn it, is the test of whichever answer you get.
Can a designer keep growing here without managing people, and is anyone doing that now?
Why ask it
Many companies say there is a senior path for people who want to stay in the craft. A named principal or staff designer, and what that person works on, is the evidence. Without one, the route exists on paper and you might be the first to try it.
How is a designer's performance reviewed, and who has a say besides my manager?
Why ask it
Product managers and engineers are often asked for input, which means their idea of a good designer counts toward your rating. If they mostly praise speed, quick delivery is what gets rewarded, whatever the ladder says about craft. Review systems differ by employer, so have the manager describe the last cycle instead of the policy.
Who was the last designer to leave the team, and what reason did they give?
Why ask it
Worth putting to both a designer on the loop and the manager. Too little influence, no path upward and being stretched across too many teams are the usual reasons, and each one points back at an earlier question on this page. If the manager answers plainly, without running the person down, and the designer's version matches, you have probably heard the real reason.
Is there time and money for learning: courses, conferences, or days set aside for it?
Why ask it
Budgets vary by employer and often by year, so ask what a designer on the team actually spent in the last twelve months. Time is the scarcer half. A budget nobody has had a free day to spend is not much of a benefit.
Portfolio and close
For the portfolio review, what do you most want to see: the finished work, the process behind it, or the result it had?
Why ask it
Ask the recruiter or the hiring manager before the session, not during it. The answer tells you which case studies to bring and where to spend your minutes. If they say all three, ask which one candidates most often leave out.
Who will be in the portfolio review, and how is the time split between presenting and questions?
Why ask it
A room of designers wants to hear about craft decisions, and a room with product managers and engineers wants trade-offs and what shipped. Knowing the split stops you preparing forty minutes for a slot with twenty. Plan to finish early, because the questions are often where a panel makes up its mind.
Does the process include a design exercise or whiteboard challenge, and what are you looking for in it?
Why ask it
Many teams will say they are watching how you frame the problem and not the screens you end up with. Hearing that in advance lets you spend the time on questions and assumptions without worrying that the sketch is rough. Ask whether you may ask questions during it, and whether the brief is about their own product.
If there is a take-home exercise, how long should it take, is it paid, and who owns what I make?
Why ask it
A stated time limit keeps you from competing with someone who spent a whole weekend. Practice on payment and on who owns the result varies from company to company, so ask instead of assuming. Decide your own limit before you hear the answer.
Having seen my work, where do you think I would need the most support in this role?
Why ask it
It asks for their reservation in a form that is easy to say out loud. If they name research, or systems work, or a platform you have not designed for, you can answer with an example on the spot or send one afterwards. No answer at all usually means the panel has not compared notes yet.
Can designers here publish case studies of their work once it has launched?
Why ask it
Designers change jobs on the strength of case studies, so this is a fair thing to ask. What may be shown is set by each employer's confidentiality terms, so ask what past designers were allowed to publish and when. If nothing can be shown, weigh that against what else the job offers.
What do you wish you had known about designing here before you joined?
Why ask it
Save it for a designer who would be your peer, ideally with no manager in the room. The answer is often the most candid thing you hear all day: the stakeholder to win over, the part of the product nobody wants, the thing that is better than it looked from outside. Thank them and do not push for more.
What happens after this round, and who makes the final decision?
Why ask it
Design loops often end with a debrief where each interviewer gives a view, and then the hiring manager or a panel decides. Ask how the decision is made at this company and when you might hear. Then you know whose doubts counted and when a follow-up note is reasonable.
How to use your questions across a UX interview loop
Practical guidance for the conversation itself
Before the loop
Use the product first
Sign up, finish the main task and note where you got stuck. 'The import step asks for a file before saying which formats it accepts. Has that been looked at?' starts a far better conversation than a general question about process, and it shows the attention you would bring. Keep it to one observation and a question. A list of fixes offered uninvited lands badly with people who built the thing under constraints you cannot see.
Find out who you will meet
Ask the recruiter for names and roles. A loop often has a hiring manager, one or two designers, a product manager and sometimes an engineer or a researcher, though every company arranges it differently. With the list in hand you can give each person the questions only they can answer.
Pick three for each conversation
Time for your questions is short in most interviews. Choose three per person, lead with the one whose answer would most affect your decision, and keep two spare in case a reply is brief.
Know what you need from the job
The first design hire at a small company and a seat on a large design team are both good jobs, for different people. Before the loop, write down the two things you would not give up, whether that is access to users, a manager who is a designer, or time for craft. Those decide which answers count as worrying for you.
Who to ask what
The hiring manager
Role and maturity and Team and growth are mostly theirs. The manager knows why the role exists, what leadership expects from design, how levels and reviews work and what you would work on first. Ask them about maturity too, then check the answer with the people below them.
Designers on the team
They live inside the process the manager describes. Ask about a typical week, the last critique, when they last met a user, the state of the design system and what they wish they had known. If a designer's account of a recent project differs from the manager's, the designer's is closer to the week you would have.
The product manager
Ask how they and their designer divided the last project, who decides when the two disagree, and what happens when research contradicts the roadmap. How a PM talks about their designer, as a partner in the problem or as the person who supplies screens, answers several questions on this page before you ask them.
The engineer
Handoff, whether the library matches the code, and how much of a design survives the build. Engineers tend to answer plainly. Asking what they need from a designer that they do not always get is also a good way to show you would be easy to work with.
The recruiter
Logistics go here: the format of the portfolio review, who attends, whether there is an exercise and on what terms, and the timeline. Those questions sit in the last group on this page but are the first ones to ask. Settle them by email before the day, and your minutes with the team stay free for the team.
Reading the answers
Turn a process into a project
Every team can describe a tidy process. Ask which recent project followed it and which did not. The second story has the deadline, the skipped research and the late stakeholder in it, and that is the one you would be working in.
Ask one question three times
Pick a single question, such as when designers first hear about new work, and put it to the manager, a designer and the product manager. Three matching answers mean it is how the place runs. Three different ones mean the manager is describing a hope, which is still worth knowing.
Listen to the vocabulary
'Users', 'the problem' and 'what we learned' tend to come from teams where design shapes the work. 'Mocks', 'assets', 'tickets' and 'making it pretty' tend to come from teams where design finishes it. One slip means nothing. A whole interview in the second vocabulary means something.
Low maturity is not always a no
A company early in its use of design can be a good move for a senior designer who wants to build the practice and has a manager with the standing to back it. It is a harder place to start a career, because there may be nobody to learn the craft from. Read the answers against where you are.
Mistakes to avoid
Quizzing them on method
Asking a product manager which design framework the team follows sounds like a test, and gets a diagram for an answer. Ask what happened on the last project instead. Plain questions about real work tell you more and leave a better impression.
Asking the wrong person
An engineer cannot tell you how designers are promoted, and a hiring manager may not know how long a pull request with a visual fix waits. A question put to someone who has to guess uses up a turn and returns a guess.
Starting an exercise without its terms
Candidates often accept a take-home task without asking how long it should take or who keeps the result. Ask before you start, politely and in writing. A team that answers clearly is showing you how it treats a designer's time.
Hearing what you hoped for
After a portfolio review that went well, it is tempting to take a vague answer about research or influence as a yes. Write down what was said the same evening, and mark which questions got a story and which got a slogan.