Design systems engineer interview questions

As asked

You are adding a Modal component to a shared React design system. How do you design the API so product teams can use it safely without losing flexibility?

Sample answer outline

Start from required behaviour, not props: focus trap, escape handling, backdrop behaviour, labelling, scroll locking, and return focus on close. The API should make the accessible path the default, such as requiring a title or aria label and exposing structured subcomponents for header, body, and footer. Allow controlled and uncontrolled usage where the design system already supports both, but avoid prop combinations that create impossible states. Document examples for destructive confirmation, forms, and simple messages. Candidates often over-focus on visual variants and under-specify lifecycle, accessibility, and composition.

Expect these follow-ups

• How would you prevent nested modals or competing focus traps?
• What props would you refuse to add?
• How do you handle teams that need a custom animation?

As asked

A dashboard card can move from loading, to partial data, to complete, to error. How would you design the motion so users understand the state without being distracted?

Sample answer outline

A strong answer starts with information hierarchy, not animation taste. Loading should set expectation without pretending precision, partial data should reveal structure progressively, complete should settle quickly, and error should draw attention only enough to prompt recovery. The candidate should discuss duration, easing, stagger, interruption, and reduced-motion behaviour. Interviewers look for restraint: motion should clarify continuity and state, not decorate the interface. A common miss is designing one beautiful transition while ignoring rapid state changes, network retries, or users who prefer reduced motion.

Expect these follow-ups

• How would this change for a finance dashboard that updates every second?
• What is your rule of thumb for when motion should be removed?
• How do you hand this off so engineering does not guess timings?

As asked

A product has years of hard-coded colours, spacing, and typography. How would you migrate it to design tokens without freezing feature work?

Sample answer outline

Define token layers clearly: primitive values, semantic tokens, and component-level decisions. Start with high-impact surfaces and introduce tokens alongside linting, codemods, visual regression tests, and documentation. Avoid a single big-bang rewrite; migrate by component or route and keep compatibility aliases during the transition. Partner with design so tokens reflect decisions, not just renamed hex values. The senior answer treats this as a change-management problem with adoption metrics and escape hatches, not merely a CSS refactor.

Expect these follow-ups

• How do you handle a brand refresh during the migration?
• What is the difference between a primitive and semantic token?
• How would you measure adoption and remaining debt?

As asked

A shared Button and Dropdown library is used by 30 teams. How do you prevent accessibility regressions as the library evolves?

Sample answer outline

Bake accessibility into component contracts rather than treating it as after-the-fact QA. Use unit tests for keyboard behaviour and ARIA attributes, Storybook accessibility checks for common states, and end-to-end tests for focus movement in realistic flows. Document expected usage and reject APIs that let consumers remove labels or break semantics too easily. Manual screen reader testing is still needed for complex interactions because automated tools catch only part of the problem. Strong candidates also mention release notes and migration guidance because consumers can create regressions even when the library is sound.

Expect these follow-ups

• Which accessibility issues do automated tools usually miss?
• How do you test keyboard behaviour for a composite widget?
• What do you do when a consuming team misuses the component?

As asked

Your team wants a dramatic parallax onboarding animation. How do you make the motion accessible without stripping all personality from the product?

Sample answer outline

Start by identifying motion risks: vestibular discomfort, attention capture, reduced readability, and delayed task completion. Honour system reduced-motion preferences and provide a lower-motion variant that keeps sequencing and hierarchy through opacity, scale restraint, or instant state changes. Avoid large z-axis movement, endless loops, and motion behind text. Test the experience with real users where possible and with implementation constraints in mind. A senior motion designer frames accessibility as part of the creative brief, not a compliance tax at the end.

Expect these follow-ups

• Which motion patterns are most likely to trigger discomfort?
• How would you document reduced-motion behaviour in a spec?
• What if brand stakeholders insist the full animation is essential?

As asked

Your product uses page transitions, animated charts, skeleton loaders, and celebratory effects. How do you design a reduced-motion strategy that still feels coherent?

Sample answer outline

Reduced motion is not the same as no feedback. Keep semantic state changes but swap spatial movement for opacity, colour, instant layout changes, or shorter fades where appropriate. The answer should reference OS-level prefers-reduced-motion, product settings, QA coverage, and documentation in the motion system. The candidate should separate essential motion that supports comprehension from ornamental motion that can be removed. A weak answer treats accessibility as a final toggle rather than a design constraint from the start.

Expect these follow-ups

• Which animations would you keep even in reduced-motion mode?
• How would you test this with users who experience vestibular discomfort?
• How do you prevent teams from bypassing the motion tokens?