Front-End Craft Deep Dive

Cursor's coding screens let you keep autocomplete and nothing else. For a Design Engineer that means writing React the way a senior teammate would on a whiteboard: from muscle memory, narrating why each hook is the right one.

The company sells the very tool you are not allowed to use here. That is deliberate. The screen is a time-boxed read on raw skill and clarity of thought, so the bar is not just working code but code where you can explain every re-render out loud while you type.

Start with the hooks, because misusing them is the fastest way to look like someone who has only ever generated React. Each hook has a job and a failure mode.

Reconciliation, keys and unstable referenceswhy your component re-rendered

React re-renders a component when its state changes, its parent re-renders or its context value changes. The trap is passing a fresh object, array or function on every render: {} and () => {} are new identities each time, so a memo'd child sees changed props and re-renders anyway.

Keys tell React which list items are the same across renders. A wrong key - index in a reorderable list - makes React reuse the wrong DOM node, so input focus jumps and animations snap. Use a stable id from the data, never the array index when the list can reorder, insert or delete.

// Wrong: index as key in an editable, reorderable list
{rows.map((row, i) => <Row key={i} value={row.value} />)}

// Right: stable identity from the data model
{rows.map((row) => <Row key={row.id} value={row.value} />)}

Controlled inputs and focusthe detail interviewers poke at

A controlled input drives its value from state and updates on every keystroke. An uncontrolled input owns its own value and you read it through a ref. For a polished editor UI you almost always want controlled, but you must handle the focus and caret yourself.

• Controlled: value + onChange - predictable, validatable, but you can fight the caret if you reformat the value mid-type.
• Uncontrolled: defaultValue + ref - simpler, but the value lives in the DOM, so React state and the field can drift.
• Focus management: move focus deliberately on mount, on open and on error - a popover that steals or drops focus reads as broken to keyboard users.

Effect pitfallswhere async bites

Effects are where most bugs live in an interview. The dependency array must list every reactive value the effect reads, async effects need a cancellation guard and anything you subscribe to you must clean up.

useEffect(() => {
  let cancelled = false;
  fetchPreview(query).then((data) => {
    if (!cancelled) setPreview(data); // ignore the late response
  });
  return () => { cancelled = true; }; // runs before the next effect / on unmount
}, [query]);

SolidJS is named in the job description and most candidates skip it. Walking in able to reason about signals - not just recite that they exist - is a cheap, strong differentiator for this role.

Solid's core idea: a component function runs once. There is no re-render. Reactivity lives in signals and only the exact DOM expressions that read a signal re-run when it changes. React re-runs your component and diffs a virtual tree; Solid wires the value straight to the node and skips the diff entirely.

// React: Counter() runs again on every click
function Counter() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(c => c + 1)}>{count}</button>;
}

// Solid: Counter() runs once; only the text node updates
function Counter() {
  const [count, setCount] = createSignal(0);
  return <button onClick={() => setCount(c => c + 1)}>{count()}</button>;
}

Note count() - a signal is a getter you call and that call is what subscribes the surrounding computation. The primitives map roughly onto hooks, but the semantics differ.

Why this matters for an editor UIsurgical updates, dense surfaces

Cursor's interfaces are dense: a file tree, a diff gutter, inline ghost text, an agent panel, all updating as you type. With a re-render model you fight to keep those subtrees from re-rendering on every keystroke. With fine-grained reactivity, a signal change touches one text node, so 60fps in a busy UI is closer to the default than a battle.

The gotchas that catch React devswhere the mental model leaks

• Reading a signal outside a tracking scope (an effect, memo or JSX) gets a value but creates no subscription - it will not update. Read it where reactivity should run.
• Props are not destructurable the React way: const { value } = props snapshots the value and loses reactivity. Read props.value at the point of use or use splitProps / mergeProps.
• Conditionals and loops in JSX use <Show> and <For>, not raw ternaries and .map, so Solid can track and reuse nodes instead of recreating them.
• The setter is the only way to update a signal - there is no mutate-then-rerender; you call setCount(next) and dependents re-run.

// Broken: value is read once and frozen, reactivity lost
function Field({ value }) {
  return <input value={value} />;
}

// Right: read props.value lazily, inside the tracked expression
function Field(props) {
  return <input value={props.value} />;
}

The build round judges polish and polish lives in CSS. You should reach for the right layout primitive without thinking, theme with custom properties and have opinions about the half-pixel.

Flexbox and Grid are not interchangeable. Flexbox lays out along one axis and is content-driven; Grid defines a two-dimensional structure the content slots into. Reach for Flexbox for a toolbar or a row of pills, Grid for a panel layout or anything where rows and columns must align across siblings.

Theming with custom propertiesdark mode and density without duplication

Define semantic tokens as CSS variables and let components consume them. Dark mode then flips a handful of values, not a parallel stylesheet. color-mix() lets you derive hover and border tints from one base color, so a palette change ripples everywhere automatically.

:root {
  --surface: #ffffff;
  --text: #18181b;
  --accent: #14b8a6;
  /* derive a subtle hover from the accent, no second hex to maintain */
  --accent-soft: color-mix(in oklab, var(--accent) 14%, transparent);
}
[data-theme="dark"] {
  --surface: #18181b;
  --text: #fafafa;
}
.btn { background: var(--accent-soft); color: var(--text); }

Stacking contexts and z-index disciplinethe bug behind every broken popover

A popover that renders behind another panel is almost never a z-index number problem - it's a stacking-context problem. transform, opacity below 1, filter and will-change all create a new stacking context, trapping a child's z-index inside its parent.

• A z-index: 9999 child can still sit behind a sibling if its parent forms a stacking context with a lower index - z-index only competes within the same context.
• Render overlays, menus and tooltips in a portal at the document root so they escape ancestor stacking contexts entirely.
• Keep a small set of named layer tokens (base, dropdown, modal, toast) instead of scattering raw numbers - z-index sprawl is a maintainability smell interviewers notice.

The 90 to 100 in spacingoptical, not just metric

A spacing system on a 4px grid gets you to 90. The last 10 is optical: an icon next to text often needs a hair less leading space than the grid says because its glyph has built-in padding; a chevron looks centered when nudged a pixel toward its visual mass, not its bounding box.

The job calls out contributing reusable, maintainable components to the design system. That is systems thinking and it shows in API design long before it shows in pixels.

Two patterns carry most of the load. Compound components let related pieces share implicit state through context, so the consumer composes structure instead of passing a dozen props. Headless components ship behavior and accessibility while leaving every style to the consumer.

type ButtonProps = {
  variant?: "solid" | "ghost" | "outline";
  size?: "sm" | "md" | "lg";
  tone?: "neutral" | "accent" | "danger";
};
// classes derive from the enums - adding a tone never forks the render path
const cls = clsx(base, byVariant[variant], bySize[size], byTone[tone]);

Accessibility is table stakesnot a follow-up ticket

For a Design Engineer, shipping a menu without keyboard support is shipping it broken. Interviewers will ask how a component behaves with no mouse, so build it in from the first commit.

• Roles and state: the right role, plus aria-expanded, aria-selected and aria-controls wired to real ids.
• Keyboard model: Arrow keys move within a widget, Tab moves between widgets, Escape closes, Enter/Space activate.
• Focus trap and restore: a modal traps focus inside and returns it to the trigger on close.
• Labels: every control has an accessible name, via visible text, aria-label or aria-labelledby.
• Respect prefers-reduced-motion: gate non-essential animation behind it.

When to abstract and when not topremature abstraction is a graded mistake

Pulling two similar components into one configurable component too early creates a prop-soup abstraction that nobody can read and every new case bends out of shape. The healthier instinct is to wait for the third real use before generalizing and to prefer composition over a growing options object.

Not breaking your consumersthe part of systems thinking the JD names

• Add, don't mutate: new optional props with safe defaults keep existing call sites working.
• Deprecate with a path: warn in dev, document the replacement, give a migration window before removal.
• Treat the prop API as a contract: renaming or retyping a required prop is a breaking change, even if the visuals are identical.

The interview screens raw React. The job is something else: at Cursor, designers and design engineers prototype directly in the product, against a live design system, and publish finished work back to Figma. Knowing that loop is what separates a Design Engineer from a React generalist.

Start in the Agents window, not the editor. Over the last few releases Cursor shifted its primary surface away from the VS Code-style file tree toward an agent-first view. Reach it with the Agents window button top-right, or Command+Shift+P then "Agents window", and toggle back anytime. For a designer who doesn't want a debugger and a file tree staring back, this is the place to live.

Inbound: pull the design system intokens, type, color — not a guess

Paste a Figma file link straight into the prompt: "use the design system at this link to inform the design of my dashboard, make any relevant color and typography changes." Cursor's Figma MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. reads the tokens, typography, colors and variable definitions, screenshots the frames and applies them to the live code. The point of feeding it the real file is that it stops Cursor from hallucinating its own icons, kerning and padding and quietly rebuilding your design system from scratch.

Prototype by clicking the rendered UIdesign mode + @browser

Type @browser in a prompt and Cursor runs your built app in a pane inside the Agents window. There's a design mode button in that pane: toggle it on, click any div in the running app, and that element plus a screenshot is handed to the agent as context. Then you just describe the change — "make this font 3x as big and bright red" — and Cursor edits the code and re-renders live. Command+L adds an element to context, so you can select several divs at once and describe multiple changes in one prompt; Cursor identifies the distinct components and edits each.

The browser pane isn't just for looking. Ask the agent to take control and test interactions — "test that the category slider works, take control and make sure it works" — and Cursor will scroll, click and drag sliders on its own. That in-browser agent QA is how a lot of folks actually do QA at Cursor.

Outbound: publish the component back to Figmaclose the loop

When something is worth sharing, select the rendered component in design mode, Command+L it into chat, and say "publish this component back to Figma" with the target file link so it knows where to land. Cursor recreates the component in Figma with the same colors, fonts and width, split into proper layers — published-back layers show up in purple. Now a designer can prototype in Cursor and hand a clean, collaborator-friendly Figma file back to the team.

Handoff, sharing and version controlthe parts designers actually ask about

At Cursor, designers feel empowered to do their prototyping inside the product, then publish anything that needs collaboration back to Figma. Once it's in Figma, engineers pick it up and Figma is the source of truth they build from. That round-trip is what makes handoff seamless and cuts iteration time.

Plan mode as your paper traildesign with a frontier model, build with the plan

Flip on the plan pill and run it on a frontier planning model (GPT-5.x) and Cursor writes a document rather than code — a feature roadmap that states the current baseline, then a recommended feature set with realism and intelligence upgrades. The plan is your documentation. Copy a section into chat and say "implement this part of the plan" or "I like this feature, go ahead and build it," and you implement it piece by piece.

Which model for design workexecution vs planning vs adherence

There's no single answer, but there are clear leanings. Cursor's own designers love GPT-5.x and Gemini, with Gemini getting a lot of love for design specifically. ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. — Cursor's in-house code model — is the speed pick for rapid UI iteration and diffs, which is why it's the default reach when you're clicking through changes. The one firm rule: don't plan with Composer. It's built for execution, not prose or roadmaps.

Use that as a decision rule. When Cursor's output drifts from your Figma source, switch up to a more powerful model — stronger models adhere better to a file's exact tokens and spec. When you're just iterating fast on a layout, drop back to ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. for the speed.

Make the design system persistentskills, not vibes

Pointing Cursor at a Figma file once works for one session. To make it stick, put the design context into a skill — a persistent Markdown file that shapes how Cursor behaves and can reference scripts and other MD files. Cursor reads design.md files too, but the guidance is to fold them into a skill so they're reliably visible and used.

• "Every time you make changes, check the Figma design system in this skill and adhere to it."
• "After any design change, use the browser and test it yourself."
• Hand it icons, kerning and padding context so Cursor stops hallucinating its own and remaking your design-system elements.

While we're on primitives: the cleanest plain-language definition of a pluginA Cursor marketplace package that bundles MCP servers and skills (sometimes sub-agents and hooks); one click installs all of it into your Cursor instance. is MCPs and skills packaged together and published on Cursor's platform. Sometimes a plugin also bundles sub-agents and hooks, but for the most part it's MCPs plus skills.

The build round asks for one component or interaction, live or as a short take-home and grades it on correctness and polish. The win is sequencing: get it working end-to-end, then spend your remaining time where craft shows.

The most common failure is polishing before the thing works - animating a dropdown that doesn't yet open with the keyboard. The second is the opposite: a correct component that looks like a wireframe, from a candidate who never budgeted time for the finish.

1. 1Clarify and pick a state strategy. Restate the requirement, then choose where state lives (local state, a ref or lifted) before writing JSX. Say the choice out loud.
2. 2Get it working end-to-end first. Make the happy path real - open, select, close - even if it's unstyled. A working ugly component beats a beautiful broken one.
3. 3Layer in the states that signal craft. Focus rings, hover, active, disabled, plus empty, loading and error. These are where a Design Engineer is judged.
4. 4Add motion last and make it earn its place. Animate transform and opacity for 60fps, keep it under ~200ms and gate it behind prefers-reduced-motion.
5. 5Reserve the last 10 minutes for self-review. Re-read the API like a teammate's PR, tidy names and narrate what you'd do with more time.

Edge cases, said out loudthinking like a feature owner

You will not have time to handle every edge case, so name them as you go. Voicing the case you're deferring shows the ownership instinct Cursor screens for even when the clock beats you to the implementation.

Code they read like a teammate's PRnaming and API are part of the grade

Interviewers read your component the way they'd review a colleague's pull request. Clear prop names, a sensible default and no dead code matter as much as the behavior. Tighten the surface before time runs out.

type ComboboxProps<T> = {
  items: T[];
  value: T | null;
  onChange: (next: T | null) => void;
  getLabel: (item: T) => string;
  placeholder?: string;
  disabled?: boolean;
};
// Generic over T, controlled, one obvious way to render a label.