Cohesyve · Practice for candidates
Preparing for a UI Designer role? Start by finding out where you stand.
Import the actual job you're going for, run a simulation built from it, and get a scored report showing which of these areas you're weakest in — before you spend weeks studying the wrong thing.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
Overview
UI designer interviews weigh interface craft, systems thinking and the ability to explain a decision to engineers and product people. Most processes include a portfolio presentation, a scoped design task with a written rationale, and a conversation about design systems and handover. Interviewers are assessing whether your screens hold up beyond the first look — states, edge cases, accessibility and consistency. This page covers each stage and the preparation that matters.
The hiring process, stage by stage
Portfolio screen
Reviewed asynchronously. The reviewer looks for interface craft, evidence of systems thinking, and whether you present product context or only polished shots.
How to prepare: Show real product work over concept pieces where possible. Include the problem, the constraint, and at least one flow rather than isolated screens. Make sure the portfolio loads quickly and does not require narration to make sense.
Hiring manager conversation
Covers how you work with product and engineering, how you handle design systems, and your understanding of the product domain.
How to prepare: Prepare an account of a feature you designed end to end, including what changed after engineering feedback and what you compromised on. Read the product properly before this call.
Portfolio presentation
A live session, usually 45 minutes, presenting one or two projects in depth to designers, product managers and often an engineer.
How to prepare: Structure as problem, constraint, exploration, decision, outcome. Include states and edge cases, not just the happy path — an engineer in the room will ask about them.
Scoped design task
A defined brief — design a flow, redesign a screen, extend a component — usually take-home over a few days, with a short rationale required.
How to prepare: Practise scoping to the time given, covering the primary flow with its empty, loading and error states, and writing a rationale that names the trade-offs. Breadth of states beats polish on one screen.
Craft and collaboration interview
A working session or critique with the design team, plus conversations with engineers about handover, specification and design system contribution.
How to prepare: Practise critiquing an interface against a user goal rather than against taste, and be ready to discuss how you specify a component so an engineer can build it without guessing.
What to study
Interface craft and visual hierarchy
Reviewers form a judgement about craft level within seconds, and it is largely typographic and spatial rather than decorative.
Design systems and components
Most product teams need someone who extends a system rather than producing bespoke screens. This is asked about in nearly every process.
States, edge cases and interaction
The most common gap in a UI portfolio is that only the ideal path is designed. Engineers on the panel notice immediately.
Accessibility
Increasingly a scored criterion rather than a nice-to-have, and easy to demonstrate concretely if you have prepared.
Working with engineering and product
UI designers are judged partly on whether what they design gets built as intended. Handover practice is a direct interview topic.
Cohesyve for candidates
Practise a UI Designer assessment before the real one
Run the same AI job simulations companies use to evaluate applicants. You get a scored report showing where you're strong and where you're not, plus what to work on.
Your preparation plan
Four weeks out
Rebuild the portfolio around product reasoning and completeness.
- •Choose two projects to present in depth and cut the rest to short summaries
- •Add the states and edge cases you designed, or design them now if they are missing
- •Write the problem and constraint for each project in two sentences
- •Use the target organisation's product and note three specific interface observations
Two weeks out
Practise the presentation and the scoped task.
- •Present one project aloud to time, ideally to an engineer or product person
- •Complete a scoped design task in four hours covering a full flow with its states
- •Write the accompanying rationale, naming at least two trade-offs you made
- •Audit a component in a public design system and note how you would improve it
The final week
Close the specific gaps and prepare for critique.
- •Rehearse answers on accessibility and on handover, which candidates most often improvise badly
- •Trim the presentation so the strongest project is covered thoroughly within the time
- •Prepare your questions about the design system, team structure and how work gets shipped
- •Confirm the design task scope, deadline and expected format
The day before and the day of
Remove technical risk and arrive with clear judgement.
- •Test screen sharing, prototype links and file loading on the setup you will use
- •Export a PDF fallback of the presentation and have the prototype pre-loaded
- •Reread your project notes once and then stop
- •Decide the two things you want the panel to conclude about how you work
Questions to expect
“Walk us through this feature from problem to shipped design.”
What they're really asking: Whether you designed against a real constraint or produced screens in isolation.
How to answer: Open with the problem and who had it, state the constraints including engineering ones, show one or two explorations you rejected, then the final flow with its states, then what happened after release. Keep the happy path brief and dwell on the difficult decisions.
“How do you decide when to add a new component to the design system?”
What they're really asking: Whether you extend a system responsibly or create one-off solutions that fragment it.
How to answer: Describe checking whether an existing component can be varied, weighing the maintenance cost, and involving whoever owns the system. Give an example where you chose not to add one and worked within the constraint instead.
“An engineer says your design is too expensive to build. What do you do?”
What they're really asking: Whether you can negotiate rather than either capitulating or digging in.
How to answer: Ask which part is expensive and why, identify the part of the design carrying the user value, and propose a simpler version that keeps it. Give a real example including what you accepted losing.
“How do you handle accessibility in your work?”
What they're really asking: Whether it is built into your process or something you mention because you know it is expected.
How to answer: Name the checks you run as a matter of course — contrast, focus order, target size, text scaling — and give one example of a design you changed as a result. Specific examples land far better than a general commitment.
“Show us a design you would do differently now.”
What they're really asking: Whether you evaluate your own work and have improved measurably.
How to answer: Choose a genuine example, name the specific decision that was wrong and what it caused, and describe the alternative. Avoid superficial answers about visual style.
“How do you make sure what ships matches what you designed?”
What they're really asking: Whether you follow work through implementation or hand off and move on.
How to answer: Describe your specification practice, reviewing built work in a real environment, and how you raise discrepancies proportionately — distinguishing what matters from what does not. Give an example of a compromise you accepted deliberately.
What to bring as evidence
A portfolio with one or two projects presented in depth, each showing a full flow rather than isolated screens
Evidence of states and edge cases: empty, loading, error and permission variants
A design system or component contribution, with the usage documentation you wrote
A prototype demonstrating an interaction you designed, ready to run live
A handover or specification example showing how an engineer received your work
A short written rationale from a past project, showing how you argue a trade-off
Common mistakes
Presenting only the happy path, so the first engineering question exposes the gap
Showing polished screens with no product problem stated
Producing bespoke patterns that ignore the existing design system
Treating accessibility as a general commitment with no concrete example behind it
Overrunning the presentation and never reaching the interesting decisions
Submitting a task that exceeds the scope in polish while leaving states undesigned
Questions to ask them
- ?
Who has final say on design decisions when product, design and engineering disagree?
- ?
How mature is the design system, and who maintains it?
- ?
How is design work measured here — shipped features, usability outcomes, or something else?
- ?
How early is design involved in a piece of work, and how often does that hold?
- ?
What is the ratio of designers to engineers, and how are designers allocated?
- ?
What currently stops good design work from shipping as intended?
Frequently Asked Questions
Should my portfolio show UI or full product case studies?
Show interface craft with enough product context to make the decisions legible. Pure visual galleries fail on reasoning and long research-heavy case studies bury the craft. One or two projects with a clear problem, a flow and its states is the balance most panels want.
How much research am I expected to have done?
For a UI role, enough to explain who you designed for and why the decisions follow, rather than owning discovery. If the role expects research, the advert usually says so, and it is worth asking at the screening call.
Is a multi-day take-home task acceptable?
A scoped task of a few hours is normal; several days of work is not, and it is reasonable to ask what the expected effort is. Deliver the flow with its states within the stated scope and note what you would have added with more time.
What if I have never worked on a design system?
Say so and show that you understand the principles — components, variants, tokens, consistency — and how you have kept work consistent without one. Claiming system experience you lack becomes obvious in the craft interview.
How should I rehearse the design task?
Work to a real time limit on an unfamiliar brief and force yourself to cover states rather than polish one screen, since scope discipline is what is actually being marked. Cohesyve can create a UI design simulation from the job advert, score the submission and show where your rationale and coverage were thin. Your first three assessments are free, no card required.
Practice
What a UI Designer assessment tests, and how it's scored →
Career guide
What a UI Designer actually does, and where the path leads →
Prepare for another role
Cohesyve · Practice for candidates
Don't walk in guessing. Find out where you stand first.
Three free scored practice runs, a full report on every one, and a learning pathway built from what you actually got wrong. No card required.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
For hiring teams
Hiring for a UI Designer role? See how your applicants perform before you spend interview time.