Interview Drills — Behavioral (Collaboration & Feedback)

Open-ended interview questions. Each has a Framework (the structure a strong answer follows), a Model answer (a concise example), and a Rubric (what an interviewer listens for). Behavioral rounds for designers screen for one thing above all: can you work with a team and take feedback without ego? Tell real stories, structured as STAR — Situation, Task, Action, Result — and always show what you learned. The app can role-play these as mock interviews (see mock-interview.md).

The universal behavioral structure (STAR): Situation (set the scene briefly) → Task (your specific responsibility) → Action (what you did — the bulk of the answer) → Result (the outcome, ideally with a number or a clear before/after) → close with the lesson. Keep the Situation short and spend your words on Action and Result.

D1

difficulty: easy
concept: design-roles-collaboration Tell me about a time you collaborated closely with people outside design — like a PM or an engineer — to ship something.
Framework: Situation (the project and who was involved) → Task (your design responsibility) → Action (how you communicated, shared work early, and adapted to their constraints) → Result (what shipped) → close with what made the collaboration work.
Model answer: "On a booking feature, I worked daily with a PM and one engineer. My task was the flow and screens. Instead of designing in a silo, I shared rough wireframes in our standup on day two so the engineer could flag what was cheap vs. expensive to build, and the PM could confirm scope. When the engineer said a custom calendar would take two weeks, I switched to a native date picker — same user outcome, a fraction of the cost. We shipped on time, and the engineer told me handoff was the smoothest he'd had because nothing was a surprise."
Rubric: Strong answers show the designer treating PM/eng as partners early, not handing off finished art at the end; they adapt to real constraints and name a concrete result. Weak answers describe the designer working alone, "throwing designs over the wall," or framing other functions as obstacles.

D2

difficulty: easy
concept: receiving-critique Tell me about a piece of harsh or critical feedback you received on your design. How did you handle it?
Framework: Situation (the design and the critique) → Task (your job to respond well) → Action (how you listened without getting defensive, asked clarifying questions, and what you changed) → Result (the improved design) → close with the mindset you bring to critique.
Model answer: "In a design review, a senior designer said my onboarding screen was 'cluttered and trying to do too much.' My first instinct was to defend it, but I asked, 'Which part felt like too much?' She pointed to three competing calls-to-action. She was right — I'd been too close to it to see it. I cut it to one primary action and moved the rest to later steps. The revised flow tested cleaner, and I started actively asking for critique earlier rather than waiting until I was attached to my work."
Rubric: Strong answers separate the work from the self, get curious about the critique rather than defensive, make a concrete change, and show the designer values feedback. Weak answers reveal a thin skin, explain why the critic was wrong, or describe accepting feedback passively without acting on it.

D3

difficulty: medium
concept: disagreement-with-pm Describe a time you disagreed with a PM or stakeholder about a design decision. What did you do?
Framework: Situation (the disagreement) → Task (your responsibility to advocate for the user while staying collaborative) → Action (how you made the case with evidence — research, testing, or principles — not opinion, and stayed open) → Result (the resolution, even if you didn't fully "win") → close with how you balance advocacy and disagreeing-and-committing.
Model answer: "A PM wanted to add a promo banner to the top of the checkout screen. I worried it would distract from completing the purchase. Rather than argue taste, I proposed a quick test: we ran both versions with five users. Three of them tapped the banner and lost their place in checkout. I shared the recordings. The PM agreed to move the promo to the confirmation screen instead. The lesson: I disagree with data and user evidence, not just my opinion — and when I'm overruled on something low-stakes, I commit and move on."
Rubric: Strong answers advocate for the user with evidence (testing, research, heuristics) rather than personal preference, stay collaborative, and accept that they won't always win. Weak answers describe digging in on opinion, going over someone's head, caving instantly with no advocacy, or framing the PM as the enemy.

D4

difficulty: medium
concept: disagreement-with-eng Tell me about a time an engineer pushed back that your design was too hard or too expensive to build. How did you respond?
Framework: Situation (the design and the pushback) → Task (your job to protect the user experience within real constraints) → Action (how you understood the why behind the cost, separated the user need from your specific solution, and found a buildable alternative) → Result (what shipped) → close with how you think about feasibility.
Model answer: "I'd designed a drag-and-drop reordering interaction for a list. The engineer said it would take a sprint and break on mobile. Instead of insisting, I asked what the constraint was — touch targets and gesture conflicts. The real user need was just 'move an item up or down,' not drag-and-drop specifically. So I redesigned it as simple up/down arrows, which took a day to build and actually tested better for our older users. I learned to hold the user problem firmly but my specific solution loosely, and to bring engineers in before I fall in love with an interaction."
Rubric: Strong answers distinguish the underlying user need from one particular solution, treat feasibility as a real design input, and involve engineers early. Weak answers insist on the original design regardless of cost, blame the engineer, or abandon the user need entirely just to avoid conflict.

D5

difficulty: medium
concept: career-changer-empathy You don't have a traditional design background. Why should we hire you over someone who does?
Framework: Acknowledge the background honestly (don't hide it) → reframe it as a source of user empathy and communication → give a concrete example of how that past experience makes you a better designer → connect to the role → close with the proof (portfolio / how you've closed the craft gap).
Model answer: "I spent five years as a nurse, which means I've spent thousands of hours watching real people struggle with confusing systems under stress — that's user empathy I didn't have to learn from a book. When I design, I instinctively ask 'who's using this on their worst day?' For my portfolio I redesigned a clinic check-in app, grounded in that lived experience, and tested it with five users to validate it. I've put in the craft work too — Figma, design systems, visual fundamentals — but the empathy and the ability to talk to non-designers came with me. That's a combination a fresh grad often has to develop for years."
Rubric: Strong answers own the non-design background confidently and reframe it as genuine user empathy with a specific example, while showing they've closed the craft gap (portfolio, tools, process). Weak answers are apologetic, hide the background, claim empathy without evidence, or ignore that craft still matters.

D6

difficulty: hard
concept: critique-and-iteration Tell me about a design you were proud of that failed in testing or with users. What happened next?
Framework: Situation (the design and your confidence in it) → Task (facing the evidence honestly) → Action (how you accepted you can't judge your own design's usability, what you learned from watching users, and how you iterated) → Result (the improved outcome) → close with what it taught you about ego and evidence.
Model answer: "I designed a clever gesture-based navigation I was sure was elegant. In usability testing, four of five users never discovered it — they just sat stuck on the home screen. It stung, but their struggle was the data: I'd designed something obvious to me and invisible to everyone else. I added a visible, conventional nav bar and kept the gesture as a power-user shortcut. Task completion went from 40% to 90% in the next round. It cemented a rule I now live by: I can't judge my own design's usability, so I test early and let real users — not my pride — decide what ships."
Rubric: Strong answers show genuine humility, treat user evidence as the authority over personal taste, iterate based on observation, and quantify the improvement. Weak answers blame the users ("they didn't get it"), avoid admitting the design failed, or describe no real change resulting from the test.