A design engineer interview isn’t a LeetCode grind, and it isn’t a pure design crit. It’s someone watching how you turn a vague request into a real, accessible component in forty-five minutes. Three things decide the outcome, and none of them is memorized syntax.
Build something live
You’ll get a prompt like “build a button with a loading state” and an empty file. They aren’t looking for clever code. They want a component that handles the states real buttons actually have: default, disabled, loading, and focus.
type Props = React.ComponentProps<'button'> & { loading?: boolean };
export function Button({ loading, disabled, children, ...props }: Props) {
return (
<button
disabled={disabled || loading}
aria-busy={loading}
{...props}
>
{loading ? <Spinner /> : null}
{children}
</button>
);
}The detail that lands: disabling on loading, an aria-busy flag, and spreading the native props so the thing stays a drop-in. That small stuff is the entire signal.
Narrate your tradeoffs
Silence reads as luck. Say the why out loud as you type: “I’m spreading props so this stays a drop-in for a native button.” “I’d reach for cva here if we had five variants, but that’s overkill for one.” Naming the option you didn’t take is what separates senior from mid-level, more than the code itself.
Bring a details portfolio
Skip the case-study novels nobody reads. Bring three interactions you can open in a browser right there: a menu that traps focus, a form that validates on blur, a transition that respects prefers-reduced-motion. Talk about the bug you fought and fixed, not the Figma file you were handed.
Practice this week
Set a timer for forty-five minutes and build one component from a one-line prompt, out loud, into an empty file. Record your screen and voice. Watch it back once. You’ll hear every place you went quiet or skipped a state, and that’s your prep list for the real thing.