Interview questions in Design Systems, page 5
Delivering one color token to three platforms
One JSON source, generated CSS variable for web, color resource XML for Android, and Swift/asset for iOS.
Pixel-identical modals across platforms
Raise back-button and gesture behavior, safe areas and keyboard insets, native dismiss patterns, and accessibility differences.
Versioning and distributing multi-platform tokens
JSON source, Style Dictionary transforms per platform, semantic versioning, and per-platform package registries in CI.
Sharing logic, native UI across platforms
Shared module (e.g. Kotlin Multiplatform) for state/business rules, platform-native UI consuming it, and a clean interface boundary.
Responsive Tabs with one consistent API
One stable public API (items, value, onChange), internal swap of presentation by breakpoint, and shared selection state.
Modeling a confirmation action for voice
Model confirmation as a modality-agnostic intent, add voice tokens (prompts, accepted phrases, reprompts, timeouts), and map intent to each modality.
Performance trade-offs of abstracting native UI
Bridge/serialization overhead, JS-thread bottlenecks for lists, and mitigations like virtualization, native modules, and profiling both threads.
Governance to keep platforms from diverging
A federated model with central stewards plus platform reps, an RFC process, and contribution rules.
Token architecture for multi-modal alerts
A semantic alert concept with per-modality token groups (visual, voice, haptic) under one name, single source of truth, and platform transforms.
Challenges of breaking changes in a design system
Technical (semver, codemods, coexistence) and organizational (comms, migration support, timelines) challenges.
Versioning and shipping design tokens via NPM
Semver, deprecate-before-delete with aliases, codemods and migration guides.
Rolling out a breaking change to a shared Button
Major semver bump, deprecation period, codemod and migration guide, staged comms.
Composite components versus layout primitives
Primitives give flexibility and composition, composites enforce consistency, choose by reuse and variation.
Documenting accessibility per component
Per-component a11y sections, keyboard tables, ARIA roles and states, live examples.
Architecting a federated documentation site
Docs-as-code with a manifest, CI publishing artifacts, a build that pulls and merges, unified deploy.
Automated a11y testing in CI and its limits
Axe-core in unit and story tests, fail the build on violations, plus manual screen-reader and keyboard testing.
Governance for accessibility regressions
Detection via audits and monitoring, triage with severity and ownership, remediation SLAs, prevention feedback.
Design systems across micro-frontends
Shared singletons and version alignment, token-based theming, distribution via shared scopes, stronger governance.
Critical a11y fix requiring a breaking API change
Ship a safe interim fix, plan the breaking API as a major with deprecation and codemod, communicate urgency.
Technical and comms plan for a Button break
Additive-first then deprecate, major semver, codemod and guide, multi-channel early comms with adoption tracking.
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