Interview Drills — Design Exercise (Whiteboard / Take-home)

Open-ended interview challenges. Each has a Framework (the structure a strong answer follows), a Model answer (a concise example), and a Rubric (what an interviewer listens for). The live whiteboard or take-home "design an app/flow for X" challenge tests your process, not a pixel-perfect result. Think aloud, narrate your reasoning, and treat it as a collaboration. The app can role-play these as mock interviews (see mock-interview.md).

The universal design-exercise loop (the design-thinking loop under time pressure): Clarify the problem and goal → pick one specific user → state the problem in their words → sketch 2–3 rough options → pick one and justify the trade-off → walk the user flow → name how you'd test it. Use it on almost any "design X" prompt. Diverge before you converge — never fall in love with your first idea.

D1

difficulty: easy
concept: design-process-and-thinking Walk me through how you'd approach a "design an app for X" whiteboard challenge — what's your process?
Framework: Name the loop you'll follow → clarify goal and constraints → pick a specific user → define the problem → diverge (sketch options) → converge (pick one, justify) → flow → test. Emphasize that you'll think aloud and check in along the way.
Model answer: "Before sketching anything, I'd clarify the goal and who it's for, because the most expensive mistake is solving the wrong problem beautifully. Then I'd pick one specific user and write the problem in their words. I'd sketch two or three rough options instead of committing to my first idea, pick one with a clear trade-off, walk the main user flow, and say how I'd test it. I'll think out loud and check in with you so this is a collaboration, not a guessing game."
Rubric: Strong answers lead with clarify and define before designing, explicitly diverge then converge, and frame the session as thinking-aloud collaboration. Weak answers jump straight to drawing screens, skip the user, or treat it as a solo performance with no check-ins.

D2

difficulty: easy
concept: user-research-basics You're given the prompt "Design an app to help people drink more water." Before you draw anything, what do you ask?
Framework: State why you're clarifying first → ask scope questions (who, what success looks like, constraints, platform) → narrow to one user → restate the problem you'll solve out loud.
Model answer: "I'd clarify before drawing, since the prompt is wide open. Who's the user — busy office workers, athletes, older adults, kids? What does success look like to the business — habit formation, daily active use? Any constraints — phone only, do we assume a smart bottle? I'll assume busy desk workers who simply forget during the day, and the goal is building a reliable daily habit. Does that framing work, or would you steer me elsewhere?"
Rubric: Strong answers ask a few sharp scope questions (user, success, constraints), then commit to one clear framing rather than asking endlessly. Weak answers either skip clarification and dive into features, or ask vague questions and never land on a specific user and goal.

D3

difficulty: medium
concept: information-architecture-and-flows Design the flow for booking a doctor's appointment in a health app. Walk me through it on the whiteboard.
Framework: Clarify (new vs. returning patient? goal?) → pick the user → map the flow as boxes-and-arrows to the goal → call out where friction or drop-off lives → name what you'd cut → state a success metric for the flow.
Model answer: "I'll focus on a returning patient who wants the soonest available slot. Flow: open app → 'Book' → pick specialty or 'my doctor' → see soonest times first → confirm → confirmation with calendar add. The risky steps are choosing a provider and finding a time, so I'd default to their usual doctor and surface the earliest slots up front to cut steps. I'd avoid a long intake form here — collect that after booking. Success metric: booking completion rate and time-to-book."
Rubric: Strong answers map an explicit step-by-step flow, point to the high-friction steps, cut or defer steps deliberately, and name a metric. Weak answers list disconnected screens, never show the path to the goal, or pile on steps without noticing the friction they create.

D4

difficulty: medium
concept: design-process-and-thinking Sketch two or three different directions for a "report a pothole to the city" app, then pick one. Why that one?
Framework: Diverge first — describe 2–3 genuinely different options → compare them on a clear axis (speed vs. richness, effort vs. data quality) → converge on one with an explicit trade-off → tie the choice back to the user and goal.
Model answer: "I'd diverge before committing. Option A: a one-tap 'report here' using GPS plus a photo — fastest, least friction. Option B: a guided form with category, severity, and notes — richer data for the city, but slower. Option C: a map where you drop a pin on the exact spot — precise, but more interaction. For a casual resident who reports once, friction kills completion, so I'd pick A and let the city enrich data later. The trade-off is less structured input up front in exchange for far more reports actually submitted."
Rubric: Strong answers generate genuinely distinct options, evaluate them on an explicit trade-off, and justify the pick by the user and goal. Weak answers show one idea dressed up as three, never compare, or pick without naming what they're trading away.

D5

difficulty: hard
concept: wireframing-and-prototyping Take-home: "Design an onboarding flow for a budgeting app for first-time users." Walk me through your deliverable and your thinking.
Framework: State the goal of onboarding (activation, not feature tour) → pick the user and their first-session anxiety → define the one "aha" moment to reach fast → wireframe the key screens at low fidelity → justify what you cut → say how you'd test it and what you'd measure.
Model answer: "Goal: get a first-timer to their first 'aha' — seeing where their money goes — not touring every feature. User: someone anxious about money who's bounced off spreadsheets. The fast win is connecting one account and seeing an auto-categorized spending breakdown. I'd wireframe three screens: a one-line value promise, connect-an-account (with a 'try with sample data' escape hatch), and the spending snapshot. I deliberately cut budget-setup to later — too much commitment up front. I'd prototype it and run five usability tests, watching for where people hesitate, and measure activation: reached the snapshot in the first session."
Rubric: Strong answers anchor onboarding to a fast activation moment, keep fidelity low and screens few, cut commitment-heavy steps, and name a test plan plus an activation metric. Weak answers build a long feature tour, over-polish visuals instead of structure, or never say how they'd know it worked.

D6

difficulty: hard
concept: usability-and-testing Mid-whiteboard, the interviewer says: "A user test shows people abandon your checkout at the shipping step." How do you respond, live?
Framework: Don't defend — treat it as the loop sending you back → ask what specifically they saw (where, what they said) → form a hypothesis for the root cause → propose 1–2 targeted changes → say how you'd re-test to confirm → keep thinking aloud.
Model answer: "Good — testing sending me back to refine is the process working, not a failure. What did people actually do at that step: hesitate, hit a surprise, or quit? My hypothesis is unexpected shipping cost or too many fields. I'd try showing the shipping cost earlier so there's no surprise, and cut the form to the essential fields with a guest-checkout option. Then I'd re-test that one change with five users and watch the abandon point. I'd want the data before assuming I'm right."
Rubric: Strong answers welcome the feedback as part of the iterative loop, diagnose root cause before fixing, propose targeted changes, and commit to re-testing rather than declaring victory. Weak answers get defensive, guess a fix with no hypothesis, or treat their first design as final and untestable.