Interview questions in CSS & Design Systems, page 5
Shadow DOM encapsulation vs CSS Modules
Shadow DOM creates a separate tree blocking selectors both ways, CSS Modules only rename classes, and global styles need explicit bridges.
Associating a label with a form input
Explicit association via for and id, implicit by wrapping the input, and why this gives screen readers an accessible name and larger click target.
Managing focus in an accessible modal dialog
Move focus in on open, trap Tab within the dialog, close on Escape, and restore focus to the trigger on close.
ARIA roles for an accessible tab interface
Tablist contains tabs, each tab uses aria-selected and aria-controls, panels use role tabpanel with aria-labelledby, and arrow keys move between tabs.
Announcing status messages with ARIA live regions
Use a live region with aria-live polite or role status, ensure it exists in the DOM beforehand, and insert text to trigger announcement.
Building an accessible combobox with ARIA
Input has role combobox with aria-expanded and aria-controls, listbox holds options, and choose aria-activedescendant to keep focus in the input versus roving DOM focus.
Respecting prefers-reduced-motion in a design system
Gate CSS animations behind the media query, read the same preference in JS via matchMedia, and centralize motion tokens.
Why design systems use Sass or PostCSS
Sass adds variables, nesting, mixins, and functions for reuse; PostCSS transforms CSS via plugins like autoprefixer.
Packaging a design system as an npm dependency
Publish to an npm registry, with package.json holding the version, entry points, and dependencies, and version it via SemVer.
Automated visual regression testing for components
Render components in known states, capture screenshots, diff against approved baselines in CI, and require human review of differences.
Releasing a breaking Button change with SemVer
Bump the major version, write a changelog and migration guide, deprecate before removing where possible, and communicate clearly.
Bundling a component library for tree-shaking
Ship ES modules, mark sideEffects false, preserve named exports, and externalize peers so consumers tree-shake and code-split.
CI/CD pipeline for a design system monorepo
Install and cache, then parallel lint, type-check, unit and visual tests, then build, and on main a release job bumps versions and publishes.
Documenting a single UI component
Purpose and when to use, a props API table, live examples of variants and states, accessibility notes, and do and don't guidance.
Classifying a Card change under SemVer
Removing a prop is breaking so the whole release is major, document and migrate, and release the highest applicable level.
Governance for design system contributions
A clear intake and proposal step, review by core maintainers plus design, and criteria covering accessibility, API consistency, tokens, tests, and docs.
Driving and measuring design system adoption
Lower friction with migration paths and great docs, incentivize over mandate, and measure adoption via package usage, component coverage, and code analysis.
A federated design system governance model
Let the product team own the component as maintainers, with the core team setting standards, reviewing against a checklist, and owning the platform and tokens.
Declaring and scoping CSS custom properties
Declare with --name, read with var(), :root makes it global while a class scopes it locally.
CSS logical properties versus physical properties
Logical properties map to flow direction not fixed sides, padding-inline-start follows text direction, benefit is automatic RTL and vertical support.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles