Design systems engineer at AMD

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 behavior. 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

Walk me through how you would architect a three-tier design token system, from primitive tokens through semantic tokens to component tokens. What naming conventions do you enforce, and how do you decide which layer a given value lives in?

Sample answer outline

Strong answers distinguish primitives (raw values like color-blue-500), semantics (purpose-bound aliases like color-action-primary), and component tokens (component-button-background-default). The candidate should explain that consumers should almost never reference primitives directly, that semantic aliases allow theming without touching component definitions, and that component tokens give component authors an escape hatch for exceptions.

Expect these follow-ups

• How do you enforce that engineers don't bypass semantic tokens and reach for primitives?
• How would you structure tokens for a dark-mode theme alongside a high-contrast accessibility theme without duplicating your entire token set?

As asked

Your design system uses CSS custom properties for all semantic tokens. A component deep in the tree needs to render in a different theme from its parent. Explain exactly how CSS custom property inheritance works in this case, what the :root strategy gets wrong, and how you would scope tokens to subtrees correctly.

Sample answer outline

CSS custom properties inherit down the cascade like any other inherited property. Setting --color-background on a scoped class or data attribute creates a new value for that subtree without affecting siblings. The :root-only approach fails for embedded third-party widgets and multi-theme pages. A strong answer mentions that @layer can affect specificity, that properties with initial keyword break inheritance deliberately, and that JavaScript can override via element.style.setProperty for runtime switching.

Expect these follow-ups

• How do you handle components that intentionally need to opt out of the inherited theme, like a modal that must always appear in light mode?
• What are the performance implications of deeply nested custom property lookups in a large component tree?

As asked

You're designing the API for a Card component. A product engineer wants a single component that accepts props for header, footer, image, actions, and variant. Another engineer wants Card, CardHeader, CardBody, CardFooter as composable primitives. Walk me through how you evaluate the tradeoffs and what signals in a component tell you which model to use.

Sample answer outline

A strong answer argues that configuration APIs are faster to use for uniform repeated patterns but box out unforeseen variations, while composition forces more code but is extensible without API surface changes. Key signals favoring composition: content is variable or slot-based, order matters, the component wraps markup with semantic structure (li, section). Signals favoring configuration: the component has a fixed, well-understood layout with a small variation space. The candidate should mention Radix UI or Headless UI as examples of composition done well.

Expect these follow-ups

• How would you handle a consumer who needs to insert a custom element between CardHeader and CardBody in the composable model?
• How does your choice affect accessibility, specifically aria relationships between subcomponents?

As asked

Walk me through the complete focus management behavior a modal dialog must implement to be WCAG 2.1 compliant. Include: when focus moves into the modal, how focus is trapped, what happens on close, and how you handle the case where the trigger element is removed from the DOM while the modal is open.

Sample answer outline

Focus moves to the modal container or its first focusable element on open. A focus trap intercepts Tab and Shift+Tab so they cycle only within the dialog. Escape closes and returns focus to the trigger. If the trigger is gone, focus falls to the nearest logical ancestor or document.body. The candidate should mention aria-modal=true, role=dialog, aria-labelledby pointing to the dialog heading, and that inert attribute on the background is now preferred over aria-hidden for modern focus trap implementations.

Expect these follow-ups

• How does your focus trap handle nested modals or a date picker that opens inside the dialog?
• How would you implement the same behavior as a headless hook in React so consumers can bring their own markup?