One-way interview questions for designers (graphic and UX), with model answers

A graphic or UX designer one-way interview is an early screening step where you record answers to set questions on your own time, instead of meeting a live interviewer. It is also called a one-way video interview or pre-recorded interview. A design lead or recruiter reviews your recordings later, usually before a portfolio call or a panel.

For design roles the questions blend two things: behavioral prompts you would get in any interview, and portfolio prompts that ask you to talk about your work. The twist that catches designers off guard is that you usually cannot share your screen. You get “walk me through a project you are proud of” pointed at a camera, with your portfolio sitting in another tab you are not allowed to show.

Design teams reach for this format when they hire in volume. One recruiter on Reddit described a client “hiring 30-40 senior level UX designers in a couple months” and said that while they “hated the concept of the recorded interview” at first, in the end they “appreciated the step” for that kind of volume. That is the reality you are recording into: a fair, consistent first pass that buys you a real conversation later.

This page covers the questions designers actually get, how to walk a reviewer through a portfolio you cannot display, three model answers in the STAR format, and the traps specific to creative roles.

The questions you should expect

Designer one-way interviews pull from a stable set. You will not get all of these, but if you can speak to each one you are covered. They fall into four groups.

Motivation and fit

• Why do you want this role, and why this team or product specifically?
• What kind of design problems do you most want to work on?
• How would you describe your design style or strengths in a sentence?

Portfolio and process

• Walk us through a project you are proud of, from brief to outcome.
• Describe your process when you get a vague or incomplete brief.
• Tell us about a design decision you made that you would defend, and one you would now change.

Collaboration and feedback

• Tell us about a time you got tough feedback on your work. What did you do with it?
• Describe a time you disagreed with a stakeholder, a PM, or an engineer about a design choice.
• How do you work with developers to make sure the build matches the design?

Judgment under constraints

• Tell us about a time you had to ship something good enough under a tight deadline.
• Describe a project where the data or user research contradicted your instinct.
• How do you balance brand consistency or a design system against a one-off creative request?

Most of the portfolio prompts are really behavioral questions in disguise. They want the story behind the work, not a tour of the pixels. That is what the STAR method is for.

How to walk through a portfolio you cannot show

This is the part that trips designers up, so it gets its own section. On most one-way tools there is no screen-share. You are describing visual work with only your voice. The instinct is to narrate every screen, and it falls flat without the visual.

Treat it as a verbal case study instead. The structure that works:

• The problem in one sentence. What was broken, missing, or unclear for the user or the business.
• Your specific role. What you owned versus what the team owned. Reviewers want to know what you did, especially on team projects.
• The two or three decisions that mattered. Not every choice. The handful where you can say “I chose X over Y, and here is why.” That is where your judgment shows.
• The outcome. A number if you have one. A signup lift, a drop in support tickets, a faster task completion, a stakeholder who signed off. If there is no metric, describe the result you can see.

Describe the work in plain, concrete language so it lands without the picture. “A four-step checkout collapsed into one screen with a progress bar” paints something. “A clean, modern, user-centric flow” paints nothing.

Then close the loop on the visual. Reviewers will open your portfolio link from your application anyway, so say so: “You can see the before and after in my portfolio under the checkout case study.” You are not hiding the work. You are giving them the reasoning the link cannot, and pointing them to the link for the pixels.

If the tool happens to allow an upload or a shared link in your answer, use it. But assume it does not, and prepare to carry the project with words.

Three model answers in STAR

STAR is four beats: Situation (one sentence of context), Task (the problem in front of you), Action (what you specifically did), Result (how it turned out, with a number where you have one). On a recorded interview there is no one to nudge you back on track, so the structure does the work.

These are templates to adapt to your own projects, not lines to recite.

”Walk us through a project you are proud of.”

Situation. At a B2B SaaS company, our onboarding had a 40 percent drop-off on the second step, and support was fielding the same setup questions every week.

Task. I owned the redesign of the onboarding flow. The goal was to get more new accounts to their first real action without adding engineering scope we did not have.

Action. I mapped where people stalled, then made two decisions that mattered. First, I cut the flow from five steps to three by deferring everything that was not needed on day one. Second, I replaced an empty dashboard with a single guided task, because a blank screen was where most people gave up. I prototyped both in Figma, tested with five users, and worked with one engineer to keep the build inside the sprint.

Result. Drop-off on that step fell to about 18 percent over the next month, and the repeat support questions dropped noticeably. The before and after is the onboarding case study in my portfolio.

Why it works: it names a real problem, shows two specific decisions instead of a feature list, lands on a number, and points to the link for the visuals. It makes the candidate’s own role clear on a team project.

”Tell us about a time you got tough feedback on your work.”

Situation. I presented a homepage redesign I was attached to, and the head of product said the hero section was beautiful but did not tell anyone what we actually sold.

Task. He was right, and I had to separate my pride in the craft from whether it did the job.

Action. Instead of defending it, I asked what he wanted a first-time visitor to understand in five seconds. We agreed on the one message that mattered. I reworked the hero around that line, kept the visual direction I believed in, and brought back two options the next day so the decision was concrete rather than abstract.

Result. We shipped the clearer version, and the bounce rate on the homepage improved. The lesson stuck: I am designing for the person who has five seconds, not for the portfolio shot.

Why it works: design reviewers are screening for whether you can take feedback without ego. It shows you heard a hard note, acted on it, and kept the parts worth keeping. It never makes the stakeholder the villain.

”How do you handle a vague brief?”

Situation. A founder asked me to “make the app feel more premium” with no other direction and a launch in two weeks.

Task. I had to turn a feeling into something specific enough to design and ship on time.

Action. I did not start in Figma. I asked three questions: who is the user we are trying to impress, what does premium mean to them, and what is the one screen they see most. We landed on a cleaner typographic system, more generous spacing, and a slower, more deliberate set of transitions, rather than a full visual overhaul I could not finish in two weeks. I scoped it to the three highest-traffic screens.

Result. We shipped the refresh on time, the founder felt it matched the brand he wanted, and we rolled the system out to the rest of the app the following month.

Why it works: a vague brief is a judgment test. It shows you interrogate the ask before you open the tool, you scope to the deadline, and you make a defensible call instead of waiting for perfect direction.

Role-specific traps

General interview advice misses the things that specifically trip up designers on camera.

Narrating screens instead of telling a story. Without the visual, “and then this screen, and then this one” is noise. Lead with the problem and the decisions. The screens are in the link.

Talking about the team’s work as if it were all yours, or burying your role entirely. Reviewers need to know what you owned. On a group project, say plainly which parts were yours. Overclaiming reads as dishonest; underclaiming reads as a junior who only executed.

Defending a decision with taste alone. “It just looked better” is weak. Tie choices to the user, the brief, the brand, or a result. You can absolutely have a point of view, but anchor it in something beyond preference.

Vague aesthetic language. “Clean,” “modern,” “intuitive,” and “user-centric” describe almost any design and stick to none. Be concrete. What did you cut, combine, simplify, or rework, and what changed because of it.

Forgetting the portfolio link does the visual work. You are not on this recording to recreate your portfolio out loud. You are there to give the reasoning a portfolio cannot, and to make them want to open the link. Reference it, then let it carry the pixels.

Reading a script. Designers often over-prepare the portfolio walkthrough and end up reading it. Reviewers can see it. As one interviewer put it on Reddit, “you can literally tell if someone is reading an answer to you.” Use three or four bullet points off to the side, not a paragraph, and look at the lens. More on that in can you use notes in a one-way video interview.

Ignoring the timer. Many one-way tools give you a short prep window, then record for a fixed length with no pause. One candidate described having “30 seconds to prepare for a two minute answer,” which is jarring the first time. Read the first screen for the prep time, the answer length, and whether retakes are on, before you hit start. There is a full breakdown of how many retakes you get.

The AI-scoring reality, stated plainly

If your recorded interview is scored by AI, the honest version is reassuring. AI tools mostly transcribe what you say and check your answers against the role’s criteria, then surface that to a human who makes the actual call. The major vendors have stepped back from scoring candidates’ faces, and HireVue, the most cited example, said it dropped facial analysis around 2021. So answer the question on its merits, speak clearly so the transcript is clean, and do not perform for a camera you imagine is reading your expressions. For a creative role, the human reviewer and your portfolio still carry the decision. The recording is the first filter, not the judge.

Before you record

Set your portfolio open in another tab so the case studies are fresh in your mind, and make sure the link in your application actually works. Light your face from the front, put the camera at eye level, and silence your phone. For each answer, lead with the problem and your role, give two or three real decisions, land on an outcome, and stop. Describe visual work in concrete language, and point reviewers to the link for the pixels.

For the full mechanics of recording well under a timer, read how to pass a one-way video interview. To structure your project stories cleanly, the STAR method on a one-way video interview breaks it down beat by beat. And if you want the questions for a different role, the virtual interview questions by role index has the full set.