Everything in CSS & Design Systems, page 4
Modeling responsive design tokens
Model a token as a breakpoint-to-value map, transform into a base custom property redefined in media queries, components use one var per viewport.
Token architecture for white-label multi-brand
A shared semantic schema, per-brand primitive and mapping overrides, a build step emitting one bundle per brand, components consume stable semantic names.
Light and dark themes with design tokens
A shared primitives file plus per-theme semantic files, transformed into custom properties scoped by selector, components read the semantics.
Architect themes on a token foundation
Separate primitive tokens from semantic alias tokens that themes redefine, emit semantics as custom properties per theme scope, components use only semantics.
Versioning a design system library
Monolithic versioning is simple and coherent but couples unrelated changes; independent versioning gives granular upgrades but adds tooling complexity.
Support a one-off that deviates from the system
Offer sanctioned escape hatches like custom-property overrides, scope the one-off to the app not the library, track it for promotion or removal.
Accessibility built into a Modal component
Trap focus in the modal, return focus on close, escape to dismiss, role dialog with aria-modal and a labelled title, inert background.
Roll out a design system color change
Update the token source, rebuild outputs, version and publish, bump the app's dependency, verify contrast and visual regressions.
Component versus pattern in a design system
A component is a single reusable UI building block; a pattern is a documented way of composing components to solve a recurring problem.
What are design tokens?
Platform-agnostic name-value pairs for design values, transformed into CSS variables or platform code, consumed by components by name.
Purpose of a design system for developers
A single source of truth of reusable components and tokens that ensures consistency, speeds delivery, and centralizes accessibility.
Build a custom PostCSS plugin (px to rem)
Export a plugin returning visitor hooks, walk Declaration nodes, parse and rewrite px values to rem against a base size.
Diagnose and shrink a large CSS bundle
Purge unused selectors, minify and merge with cssnano, split critical CSS and code-split per route.
Build a scalable Sass theming system
Store themes as maps, emit values as CSS custom properties so runtime switching needs no recompile, generate per-theme scopes via mixins.
What does autoprefixer do and why?
Autoprefixer is a PostCSS plugin that adds vendor prefixes to CSS based on a browserslist target using compatibility data, so you write standard CSS and it handles support.
Build a DRY button with Sass maps and mixins
A base mixin for shared button styles, a variants map of name to colors looped to generate modifiers, and a sizes map looped for sizing.
What is PostCSS and how it differs from Sass
PostCSS is a plugin-driven tool that parses CSS into an AST and transforms it; it is not a fixed language like Sass but a platform for plugins like autoprefixer.
Sass @mixin versus @extend
@mixin copies declarations into each caller, accepts arguments, and can duplicate code; @extend groups selectors sharing one rule via a comma list, reducing duplication but coupling selectors.
What is nesting in Sass and its pitfall?
Nesting writes child rules inside parents mirroring structure, but deep nesting generates long descendant selectors with high specificity.
Sass variable versus CSS custom property
Sass $vars resolve at build time and vanish from output; CSS --vars live in the browser, cascade, inherit, and update at runtime. Use Sass for static config, custom properties for theming.
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