Design systems engineer domain knowledge interview questions

As asked

How would you explain the difference between a design system and a component library to a skeptical engineering manager who thinks a component library is sufficient?

Sample answer outline

A component library is the code artifact: reusable UI components with defined APIs. A design system is the broader framework that includes the component library, the design token layer, documentation, contribution guidelines, governance processes, and the design-to-engineering handoff workflow. The engineering manager analogy: a component library is like a function library; a design system is like an internal platform team. Without the surrounding system, the component library tends to diverge from design intent over time and lacks the governance to stay coherent.

Expect these follow-ups

• At what company size does it make sense to invest in a design system versus just using a third-party component library?
• What is the one thing most organizations get wrong when starting a design system?

As asked

Define what major, minor, and patch versions mean in Semantic Versioning and give one concrete example of each from a component library perspective. What is a pre-release version and when should a design system use one?

Sample answer outline

Major: breaking changes that require consumer code changes (removing a prop, renaming a component). Minor: backward-compatible new features (adding an optional prop with a default, adding a new component). Patch: backward-compatible bug fixes (fixing a visual regression, correcting an aria attribute). Pre-release versions like 3.0.0-alpha.1 or 3.0.0-rc.2 signal instability and allow early adopters to test without blocking stable consumers. Design systems should use alpha for work-in-progress APIs that may still change and RC for feature-complete code under final review.

Expect these follow-ups

• What does it mean when an npm package has a ^ in front of the version in package.json, and why might that be dangerous for a component library dependency?
• How do you communicate in release notes that a change is technically a patch but has a meaningful visual impact?

As asked

What is the WAI-ARIA Authoring Practices Guide, how is it different from the WCAG spec itself, and are there any common patterns in the APG that you would implement differently in practice?

Sample answer outline

WCAG defines the success criteria (the what). The APG provides design patterns (the how) for specific interactive widget patterns like combobox, listbox, dialog, and menu. A strong answer notes that the APG is a best-practices guide, not a normative requirement. Common patterns where practice diverges: the APG combobox pattern uses aria-activedescendant for managing virtual focus, but many production implementations use real focus because screen reader support for activedescendant is inconsistent. The APG also recommends Escape to close all menus in a menu bar, which users rarely expect on the web. The candidate should show they test with actual assistive technology, not just follow the spec.

Expect these follow-ups

• Which screen reader and browser combination do you consider the most important to test and why?
• How do you stay current with changes in screen reader behavior that might make a previously correct implementation incorrect?

As asked

Walk me through how CSS specificity is calculated. Then explain why high-specificity selectors in a component library stylesheet create problems for consumers trying to customize components.

Sample answer outline

Specificity is a four-part weight: inline styles (1,0,0,0), IDs (0,1,0,0), classes and pseudo-classes (0,0,1,0), elements and pseudo-elements (0,0,0,1). The cascade applies the highest-specificity rule for each property. Component libraries that use ID selectors or long compound class selectors create a high specificity floor that consumers cannot override with a single utility class without resorting to !important. Best practice for component library stylesheets is to use single-class selectors at most (.button), keeping specificity low enough for consumers to override with their own single-class rules.

Expect these follow-ups

• How does :where() change the specificity calculation and how is it useful in a component library?
• How do CSS @layer rules interact with specificity?

As asked

Explain the distinction between ARIA roles, states, and properties. Give an example of each from a real component implementation, and explain which of these can be changed dynamically at runtime.

Sample answer outline

Roles define what a widget is semantically (role=button, role=dialog, role=listbox). Properties describe static characteristics (aria-labelledby, aria-controls, aria-required). States reflect dynamic, changeable conditions (aria-expanded, aria-selected, aria-disabled, aria-checked). Roles generally should not change after initial render because assistive technology caches the role. States must change dynamically to reflect UI changes (an accordion panel sets aria-expanded=true when open). The candidate should give a concrete example like a toggle button: role=button (static), aria-pressed (state that changes on click), aria-label (property that stays constant).

Expect these follow-ups

• What happens if you change an element's role at runtime? How do assistive technologies handle that?
• When should you use aria-hidden versus display:none to hide content from screen readers?

As asked

Someone on your team uses 'Web Components' and 'Custom Elements' interchangeably. Clarify the difference between the two and explain which specifications together make up what is commonly called 'Web Components'.

Sample answer outline

Web Components is an umbrella term for a set of browser specifications: Custom Elements (define new HTML element types), Shadow DOM (encapsulated DOM subtree with scoped styling), HTML Templates (inert markup cloned at runtime), and CSS Custom Properties (technically separate but foundational to Web Component theming). Custom Elements is just one spec within Web Components. It is entirely possible to write a Custom Element without Shadow DOM, which trades style encapsulation for easier external styling. Lit is the most widely used library for building Web Components, adding template syntax and reactive state on top of the native specs.

Expect these follow-ups

• Why would you choose to use Light DOM (no Shadow DOM) for a Web Component?
• How does the Declarative Shadow DOM specification change SSR support for Web Components?

As asked

What is the Component Story Format (CSF) in Storybook, how does it differ from the older storiesOf API, and what advantages does it provide for a design system's tooling ecosystem?

Sample answer outline

CSF is a module-based format where each story is a named export from a .stories.tsx file, and the default export is component metadata. The older storiesOf API used a method chain that was harder to statically analyze. CSF enables tools to extract story data without executing JavaScript (via static AST analysis), which powers the documentation site, visual regression tools like Chromatic, and testing integrations. CSF 3 (Storybook 6.4+) further simplifies the format by allowing object stories without needing a render function for simple cases. The candidate should know that play functions in CSF 3 enable interaction testing directly in story files.

Expect these follow-ups

• How does Storybook use the CSF args convention and how do args differ from decorators for providing context to stories?
• How would you write a CSF story that tests a component's error state without mocking at the module level?

As asked

Your design system ships both an ESM and a CommonJS build. A consumer reports that importing a single Icon from the ESM build still pulls in the full icon set. Explain why static ES module imports enable tree-shaking while CommonJS require calls do not, and what additional conditions must be met in the package for tree-shaking to actually work.

Sample answer outline

ESM imports are static declarations evaluated before code runs (import { Button } from './components'), so bundlers can build a complete dependency graph at compile time and remove unused exports. CommonJS require() calls are dynamic and can appear anywhere in the code (conditionally, inside loops), so bundlers cannot statically determine which exports are used without runtime analysis. This means a barrel file using CommonJS will always include all exports even if the consumer only imports one. The candidate should also note that even with ESM, tree-shaking can be defeated by side effects in module scope and that the sideEffects field in package.json is the author's signal that module execution is safe to skip.

Expect these follow-ups

• Can you tree-shake a CommonJS package if the bundler has special mode enabled?
• Why might a dual ESM/CJS package still not tree-shake correctly in some consumer environments?

As asked

What are HSL and OKLCH color models and when does the choice between them matter for a design system's token authoring workflow?

Sample answer outline

HSL represents color as hue (0-360), saturation (0-100%), and lightness (0-100%). It is intuitive but perceptually non-uniform: two colors with the same HSL lightness value can look very different in perceived brightness (yellow vs. blue at 50% lightness). OKLCH is a perceptually uniform model where equal steps in lightness correspond to equal perceived brightness differences. This matters for design systems when generating color scales because an HSL-based scale will have jarring jumps in perceived lightness. OKLCH also separates chroma (colorfulness) from lightness cleanly, making it better for generating accessible color pairs. Browser support for oklch() is now excellent across all modern browsers.

Expect these follow-ups

• Why does OKLCH produce more predictable results when generating tints and shades of a saturated color?
• How do you handle colors defined in OKLCH in a token system that also needs to output hex values for older platform consumers?

As asked

Explain CSS containment, the contain property, and the newer content-visibility property. How might a design system use these to improve rendering performance for large lists or complex component trees?

Sample answer outline

CSS containment tells the browser that a subtree's layout, paint, or style is independent from the rest of the document, allowing the browser to skip recalculating outside the boundary when changes occur inside. contain: layout prevents layout changes inside from affecting outside elements. contain: paint clips visual overflow and signals the element is an independent stacking context. content-visibility: auto goes further, allowing the browser to skip rendering off-screen elements entirely until they scroll into view, with intrinsic-size used to reserve space. Design systems can apply this to complex Card components or list items that appear in long feeds, potentially saving significant render time on initial load.

Expect these follow-ups

• What are the risks of applying content-visibility: auto to a component that contains form inputs or interactive elements?
• How does CSS containment interact with position: sticky or overflow: hidden on a parent element?