You have 14 weeks to replace 132 CSS-in-JS components across 4 React storefronts while weekly releases continue; what would your migration RFC require?

I would sequence the replacement by dependency risk and keep both styling paths interoperable until each storefront proves parity. - The RFC would map shared primitives, theme providers, SSR style injection, and the 23 components that sit on checkout-critical paths. - A compatibility layer would translate existing theme props to CSS variables while a codemod handles only imports and mechanically safe declarations. - Each cohort would need zero severe Chromatic diffs, no p75 LCP regression above 100 ms, and a feature-flag rollback tested in staging.

A design system has 168 components in 6 applications, but 41 primitives are forked; how would you design a 2-quarter consolidation plan and its dependency map?

I would consolidate from low-level behavior upward, because replacing a forked primitive after its composites creates the same work twice. - The dependency map would combine static imports with Storybook composition and production telemetry so unused forks do not dictate the plan. - I would pilot Button, Field, and Dialog families in one lower-risk app, then migrate composites only after their primitive contracts stabilize. - Quarter 1 exits with every fork assigned an owner and target; quarter 2 exits only when new fork imports are blocked and shared adoption exceeds 90%.

You must move 104 components from a monorepo into versioned packages used by 9 independently deployed surfaces; what release-train architecture prevents lockstep deployment?

I would separate stable public contracts from package internals and let consumers advance through explicit compatibility ranges. - An RFC would define package boundaries around tokens, primitives, composites, and framework adapters, with forbidden dependency directions checked by CI. - Changes would ship through canary, next, and stable channels; each surface records its tested package set in a compatibility manifest. - Removal waits until all 9 surfaces report zero legacy imports for 30 days; rollback restores an immutable previous deployment artifact or switches the runtime import map or manifest to its prior package set without rebuilding.

After a brand acquisition, 127 components must support 3 brands and 2 density modes within 10 weeks; what architecture decision record would you write?

I would add brand and density as orthogonal token dimensions, not clone the component library six times. - The decision record would define which differences belong to semantic tokens, which require component variants, and which brand requests are explicitly unsupported. - A generated theme matrix would catch missing combinations, while product shells select brand and density at a single root boundary. - The first gate covers the 18 highest-traffic components across all six combinations; full rollout requires no raw brand values in component source.

A portal migration touches 119 components across 5 microfrontends owned by separate teams, and duplicate React copies already add 74 KB; how would you frame the integration RFC?

I would make runtime ownership and singleton dependencies explicit before moving any visual component. - The RFC would assign React, overlay roots, theme context, and event transport to the host, while remotes expose versioned UI entry points. - Module Federation shared settings would be verified with a runtime probe because configuration alone does not prove one React instance. - A canary microfrontend advances only if hydration errors stay at zero, shared JavaScript drops by at least 60 KB, and host rollback works without rebuilding remotes.

You are replacing 143 physical-direction CSS components for RTL across 7 locales in 12 weeks; what should the migration ledger and gate contain?

I would migrate layout semantics by component family and treat bidirectional screenshots as required evidence, not final QA. - The ledger would classify each usage as logical property, mirrored asset, directional data, or intentionally fixed content such as a media timeline. - A PostCSS report can locate left and right declarations, but human review decides whether an icon, chart axis, or gesture should mirror. - A family closes only after keyboard order, Arabic text expansion, and snapshots at 320 px and 1440 px pass in both directions.

A legacy admin suite has 151 components and 38 global Sass entry points; teams demand zero selector breakage during a 16-week move to scoped styles. What is your strangler plan?

I would introduce real style encapsulation at new ownership boundaries, then shrink the global cascade instead of attempting a one-day stylesheet cutover. - A selector census would record specificity, cascade layer, affected routes, and whether each rule is an actual contract or accidental coupling. - New components would use CSS Modules or Shadow DOM; where neither fits, every selector would be prefixed by a route-owned root, because containment and cascade layers control layout or ordering but do not isolate global selectors. - Weekly deletion targets matter only if contract tests cover the 27 selectors used by third-party extensions and production override volume trends toward zero.

A new accessibility primitive must replace 116 home-grown dialogs on 22 routes without changing analytics events; how would you prove the migration is behaviorally compatible?

I would define compatibility from observable dialog behavior, not from matching the old component props. - The contract fixture would cover focus entry and return, Escape, nested overlays, scroll locking, accessible naming, and the 6 analytics payload shapes. - An adapter would preserve event names while translating legacy callbacks to the new primitive, with duplicate-event detection in telemetry. - Route cohorts ship at 5%, 25%, and 100% only when completion and abandonment rates each stay within 1 percentage point of the control baseline and no focus blocker appears.

You need to retire 109 deprecated components across 11 repositories, but 17 cannot be found by static imports because they are loaded from JSON; what migration control plane do you build?

I would combine source analysis with runtime registration so dynamically selected components cannot disappear from the inventory. - Every deprecated component would emit a development warning, a sampled diagnostic event with repository and route, and an unsampled aggregate usage counter at dynamic registry resolution. - The control plane would join codemod coverage, dynamic registry keys, package versions, and owner acknowledgements into one retirement ledger. - Sampled telemetry showing no events is not proof of zero use; deletion requires migration fixtures for all 17 dynamic keys and zero unsampled registry counters for two full release cycles.

A typography change affects 126 components on 8 surfaces and could shift checkout layouts; what 6-week rollout architecture would you choose for the new variable font?

I would ship font metrics and component adoption separately so loading risk is not coupled to visual migration risk. - The RFC would pin fallback ascent-override, descent-override, line-gap-override, and size-adjust descriptors before any component switches families. - A route-level font flag would preload the required font asset, with Unicode subsets and bounded variable-axis ranges produced at build time, while old and new typography tokens coexist for measured cohorts. - Promotion requires CLS below 0.05, no checkout line-wrap regressions in 12 locales, and a kill switch that restores the previous font files.

A pipeline exports 842 tokens to Figma Variables, CSS, Swift, and Kotlin, and 29 aliases broke last release; what belongs in token schema version 3?

I would make version 3 a typed source contract with target capabilities, rather than another naming convention document. - Each token would declare type, semantic path, value or alias, mode scope, deprecation state, and permitted platform transforms. - JSON Schema would reject invalid shapes and units, while a graph validator rejects cycles, missing references, and primitive or semantic tokens that reference component tokens against the permitted dependency direction. - The release manifest would include source hash, generated artifact hashes, schema version, and a machine-readable diff for all 842 tokens.

Tokens Studio contains 615 tokens, but Figma and code disagree on 46 mode mappings; how would you define a bidirectional ownership contract without creating 2 sources of truth?

I would keep one canonical token graph and treat both Figma and code as validated projections with different editing permissions. - The ownership table would allow semantic intent and mode assignment in Tokens Studio, while platform transforms remain review-only code. - Every export carries stable token IDs so renames are distinguishable from delete-and-create operations in the Figma diff. - CI blocks a merge when the round-trip report finds an unknown ID, changed type, or any of the 46 unresolved mode mappings.

You must add a 4th brand to 1,180 tokens without allowing brand aliases to reference component tokens; how would your schema enforce the dependency direction?

I would encode token layers as a directed graph and make illegal edges impossible at validation time. - Primitive nodes may feed semantic nodes, semantic nodes may feed component nodes, and brand modes may override values only at approved primitive or semantic paths. - A graph walk would report the complete alias chain and shortest offending edge, rather than a generic unresolved-reference error. - The fourth brand can publish only after 100% path coverage, zero cycles, and visual fixtures for the 32 semantic roles with brand-specific overrides.

A Style Dictionary build emits 7 target packages from 730 tokens, but nondeterministic ordering changes 300 lines on every run; what pipeline contract fixes review noise?

I would make generation hermetic and compare semantic manifests before formatting target files. - The build would pin Node, transforms, locale, sorting keys, and floating-point serialization, then run twice in CI to prove identical hashes. - A canonical intermediate manifest would sort by stable ID and record resolved values plus alias provenance before target-specific output. - Reviewers see added, removed, renamed, and value-changed tokens; any generated diff without a source diff fails the reproducibility gate.

A token release changed 34 foreground-background pairs and caused 12 WCAG failures; how would you add contrast semantics to a 560-token contract?

I would validate declared color relationships, because isolated color tokens cannot prove contrast by themselves. - The schema would define usage pairs such as text.primary on surface.default, including required ratio, text size class, and supported modes. - Validation would resolve aliases per brand and mode, then report the semantic pair and consuming components for each failed ratio. - Release requires all 34 changed pairs to pass their thresholds and snapshots of the 12 previously failing states to be attached to the manifest.

Web accepts rem while iOS requires points and Android uses dp; 96 of 480 dimension tokens currently diverge. What unit-normalization contract would you approve?

I would preserve semantic design intent without pretending rem, points, and dp are physically interchangeable. - Spacing and radius would use canonical semantic steps with explicit, reviewed values per target; typography would keep target-specific font-size and line-height values rather than apply one global multiplier. - The schema would reject mixed-unit arithmetic and require a unit, rounding policy, minimum target value, and precision for every platform transform. - A golden fixture of the 96 divergent tokens must produce reviewed CSS, Swift, and Kotlin outputs before the contract becomes stable.

You need to rename 210 semantic tokens consumed by 13 repositories with a 6-week deprecation window; what must the release manifest guarantee?

I would publish identity-preserving aliases and make removal depend on observed consumer migration, not the calendar alone. - The manifest would map old stable IDs to new names, state the semantic reason, identify affected modes, and declare the first removable version. - Generated packages keep old exports as aliases with warnings, while repository scanners report exact files and package versions still using them. - A rename can become deletion only after all 13 repositories pass CI on the new names and production telemetry is clean for one release cycle.

A Figma plugin can write 900 token values directly, while pull requests require review by 2 owners; how would you prevent the plugin from bypassing governance?

I would make the plugin propose signed source changes rather than publish generated artifacts directly. - The plugin would open a branch containing stable IDs, old and new values, Figma node provenance, and the authoring library version. - CI would regenerate all targets, run schema and visual impact checks, and require the same two CODEOWNERS approvals as hand-edited changes. - Production publishing uses a short-lived CI identity tied to the approved commit, so a Figma credential cannot release packages.

A 670-token pipeline must support high-contrast mode, but 58 component tokens have no semantic fallback; what capability matrix would you write?

I would declare high contrast as a target with required semantic capabilities, not append a sparse override file. - The matrix would mark which roles use system colors, which retain brand identity, and which decorations disappear without losing information. - Every component token must resolve through a semantic role in default, dark, and high-contrast modes; missing paths are build errors. - The 58 gaps close only after forced-colors browser fixtures and Windows High Contrast manual checks cover focus, status, and selection states.

Two release trains consume 760 tokens, and the mobile train lags web by 3 versions; how would you stop semantic changes arriving out of order?

I would version the token contract independently from generated packages and declare compatibility against contract ranges. - A semantic change lands as additive first, with old and new roles generated for both trains before any consumer switches meaning. - The manifest records minimum transformer and consumer versions, so mobile cannot accept an artifact it interprets under older semantics. - Removal waits until both trains acknowledge the replacement; CI tests the current web version against mobile lagging by exactly three versions.

Design Engineer interview questions

100 real questions with model answers and explanations for Senior candidates.

See a Design Engineer resume example →

Practice with flashcards

Spaced repetition · Hunter Pass

Questions

cssreactcomponents

I would sequence the replacement by dependency risk and keep both styling paths interoperable until each storefront proves parity.

The RFC would map shared primitives, theme providers, SSR style injection, and the 23 components that sit on checkout-critical paths.
A compatibility layer would translate existing theme props to CSS variables while a codemod handles only imports and mechanically safe declarations.
Each cohort would need zero severe Chromatic diffs, no p75 LCP regression above 100 ms, and a feature-flag rollback tested in staging.

Why interviewers ask this: The interviewer is testing whether a large styling migration is decomposed around runtime dependencies and measurable rollback gates.

componentsdesign-systemsystem-design

I would consolidate from low-level behavior upward, because replacing a forked primitive after its composites creates the same work twice.

The dependency map would combine static imports with Storybook composition and production telemetry so unused forks do not dictate the plan.
I would pilot Button, Field, and Dialog families in one lower-risk app, then migrate composites only after their primitive contracts stabilize.
Quarter 1 exits with every fork assigned an owner and target; quarter 2 exits only when new fork imports are blocked and shared adoption exceeds 90%.

Why interviewers ask this: The interviewer is looking for dependency-aware sequencing rather than a component-count migration calendar.

deploymentmonorepoarchitecture

I would separate stable public contracts from package internals and let consumers advance through explicit compatibility ranges.

An RFC would define package boundaries around tokens, primitives, composites, and framework adapters, with forbidden dependency directions checked by CI.
Changes would ship through canary, next, and stable channels; each surface records its tested package set in a compatibility manifest.
Removal waits until all 9 surfaces report zero legacy imports for 30 days; rollback restores an immutable previous deployment artifact or switches the runtime import map or manifest to its prior package set without rebuilding.

Why interviewers ask this: The interviewer is evaluating package architecture and deprecation discipline for independently released products.

componentsarchitecture

I would add brand and density as orthogonal token dimensions, not clone the component library six times.

The decision record would define which differences belong to semantic tokens, which require component variants, and which brand requests are explicitly unsupported.
A generated theme matrix would catch missing combinations, while product shells select brand and density at a single root boundary.
The first gate covers the 18 highest-traffic components across all six combinations; full rollout requires no raw brand values in component source.

Why interviewers ask this: The interviewer is checking whether variation is modeled without multiplying component ownership costs.

reactcomponentsmigrations

I would make runtime ownership and singleton dependencies explicit before moving any visual component.

The RFC would assign React, overlay roots, theme context, and event transport to the host, while remotes expose versioned UI entry points.
Module Federation shared settings would be verified with a runtime probe because configuration alone does not prove one React instance.
A canary microfrontend advances only if hydration errors stay at zero, shared JavaScript drops by at least 60 KB, and host rollback works without rebuilding remotes.

Why interviewers ask this: The interviewer is testing microfrontend boundaries where visual migration can otherwise conceal runtime duplication.

csscomponentsmigrations

I would migrate layout semantics by component family and treat bidirectional screenshots as required evidence, not final QA.

The ledger would classify each usage as logical property, mirrored asset, directional data, or intentionally fixed content such as a media timeline.
A PostCSS report can locate left and right declarations, but human review decides whether an icon, chart axis, or gesture should mirror.
A family closes only after keyboard order, Arabic text expansion, and snapshots at 320 px and 1440 px pass in both directions.

Why interviewers ask this: The interviewer is assessing whether RTL migration distinguishes mechanical CSS changes from product semantics.

componentsmigration

I would introduce real style encapsulation at new ownership boundaries, then shrink the global cascade instead of attempting a one-day stylesheet cutover.

A selector census would record specificity, cascade layer, affected routes, and whether each rule is an actual contract or accidental coupling.
New components would use CSS Modules or Shadow DOM; where neither fits, every selector would be prefixed by a route-owned root, because containment and cascade layers control layout or ordering but do not isolate global selectors.
Weekly deletion targets matter only if contract tests cover the 27 selectors used by third-party extensions and production override volume trends toward zero.

Why interviewers ask this: The interviewer is probing safe use of the strangler pattern for a cascade with undocumented consumers.

a11ymigrations

I would define compatibility from observable dialog behavior, not from matching the old component props.

The contract fixture would cover focus entry and return, Escape, nested overlays, scroll locking, accessible naming, and the 6 analytics payload shapes.
An adapter would preserve event names while translating legacy callbacks to the new primitive, with duplicate-event detection in telemetry.
Route cohorts ship at 5%, 25%, and 100% only when completion and abandonment rates each stay within 1 percentage point of the control baseline and no focus blocker appears.

Why interviewers ask this: The interviewer is evaluating behavioral migration evidence across accessibility and product instrumentation.

componentsmigrations

I would combine source analysis with runtime registration so dynamically selected components cannot disappear from the inventory.

Every deprecated component would emit a development warning, a sampled diagnostic event with repository and route, and an unsampled aggregate usage counter at dynamic registry resolution.
The control plane would join codemod coverage, dynamic registry keys, package versions, and owner acknowledgements into one retirement ledger.
Sampled telemetry showing no events is not proof of zero use; deletion requires migration fixtures for all 17 dynamic keys and zero unsampled registry counters for two full release cycles.

Why interviewers ask this: The interviewer is checking whether migration discovery covers runtime indirection rather than trusting static tooling alone.

typographyarchitecturecomponents

I would ship font metrics and component adoption separately so loading risk is not coupled to visual migration risk.

The RFC would pin fallback ascent-override, descent-override, line-gap-override, and size-adjust descriptors before any component switches families.
A route-level font flag would preload the required font asset, with Unicode subsets and bounded variable-axis ranges produced at build time, while old and new typography tokens coexist for measured cohorts.
Promotion requires CLS below 0.05, no checkout line-wrap regressions in 12 locales, and a kill switch that restores the previous font files.

Why interviewers ask this: The interviewer is testing whether typography migration treats font loading and geometry as architectural concerns.

cssci-cdfigma

I would make version 3 a typed source contract with target capabilities, rather than another naming convention document.

Each token would declare type, semantic path, value or alias, mode scope, deprecation state, and permitted platform transforms.
JSON Schema would reject invalid shapes and units, while a graph validator rejects cycles, missing references, and primitive or semantic tokens that reference component tokens against the permitted dependency direction.
The release manifest would include source hash, generated artifact hashes, schema version, and a machine-readable diff for all 842 tokens.

Why interviewers ask this: The interviewer is evaluating whether token reliability is encoded in a schema and provenance chain.

conflictownershiptokens

I would keep one canonical token graph and treat both Figma and code as validated projections with different editing permissions.

The ownership table would allow semantic intent and mode assignment in Tokens Studio, while platform transforms remain review-only code.
Every export carries stable token IDs so renames are distinguishable from delete-and-create operations in the Figma diff.
CI blocks a merge when the round-trip report finds an unknown ID, changed type, or any of the 46 unresolved mode mappings.

Why interviewers ask this: The interviewer is testing source-of-truth design when designers and engineers need different authoring surfaces.

tokenscomponentsschema

I would encode token layers as a directed graph and make illegal edges impossible at validation time.

Primitive nodes may feed semantic nodes, semantic nodes may feed component nodes, and brand modes may override values only at approved primitive or semantic paths.
A graph walk would report the complete alias chain and shortest offending edge, rather than a generic unresolved-reference error.
The fourth brand can publish only after 100% path coverage, zero cycles, and visual fixtures for the 32 semantic roles with brand-specific overrides.

Why interviewers ask this: The interviewer is looking for enforceable graph rules rather than relying on token naming discipline.

tokensci-cd

I would make generation hermetic and compare semantic manifests before formatting target files.

The build would pin Node, transforms, locale, sorting keys, and floating-point serialization, then run twice in CI to prove identical hashes.
A canonical intermediate manifest would sort by stable ID and record resolved values plus alias provenance before target-specific output.
Reviewers see added, removed, renamed, and value-changed tokens; any generated diff without a source diff fails the reproducibility gate.

Why interviewers ask this: The interviewer is evaluating deterministic generation and reviewability in a multi-target token pipeline.

contrastwcaga11y

I would validate declared color relationships, because isolated color tokens cannot prove contrast by themselves.

The schema would define usage pairs such as text.primary on surface.default, including required ratio, text size class, and supported modes.
Validation would resolve aliases per brand and mode, then report the semantic pair and consuming components for each failed ratio.
Release requires all 34 changed pairs to pass their thresholds and snapshots of the 12 previously failing states to be attached to the manifest.

Why interviewers ask this: The interviewer is checking whether accessibility constraints are represented as relationships in the token model.

tokensnormalization

I would preserve semantic design intent without pretending rem, points, and dp are physically interchangeable.

Spacing and radius would use canonical semantic steps with explicit, reviewed values per target; typography would keep target-specific font-size and line-height values rather than apply one global multiplier.
The schema would reject mixed-unit arithmetic and require a unit, rounding policy, minimum target value, and precision for every platform transform.
A golden fixture of the 96 divergent tokens must produce reviewed CSS, Swift, and Kotlin outputs before the contract becomes stable.

Why interviewers ask this: The interviewer is assessing cross-platform unit judgment rather than simplistic one-to-one conversion.

tokens

I would publish identity-preserving aliases and make removal depend on observed consumer migration, not the calendar alone.

The manifest would map old stable IDs to new names, state the semantic reason, identify affected modes, and declare the first removable version.
Generated packages keep old exports as aliases with warnings, while repository scanners report exact files and package versions still using them.
A rename can become deletion only after all 13 repositories pass CI on the new names and production telemetry is clean for one release cycle.

Why interviewers ask this: The interviewer is evaluating whether token renames have a verifiable consumer contract and safe end state.

tokenscode-reviewfigma

I would make the plugin propose signed source changes rather than publish generated artifacts directly.

The plugin would open a branch containing stable IDs, old and new values, Figma node provenance, and the authoring library version.
CI would regenerate all targets, run schema and visual impact checks, and require the same two CODEOWNERS approvals as hand-edited changes.
Production publishing uses a short-lived CI identity tied to the approved commit, so a Figma credential cannot release packages.

Why interviewers ask this: The interviewer is testing authorization boundaries in a designer-friendly token workflow.

tokenscomponentsa11y

I would declare high contrast as a target with required semantic capabilities, not append a sparse override file.

The matrix would mark which roles use system colors, which retain brand identity, and which decorations disappear without losing information.
Every component token must resolve through a semantic role in default, dark, and high-contrast modes; missing paths are build errors.
The 58 gaps close only after forced-colors browser fixtures and Windows High Contrast manual checks cover focus, status, and selection states.

Why interviewers ask this: The interviewer is evaluating whether alternate display modes are first-class token targets with explicit fallbacks.

tokens

I would version the token contract independently from generated packages and declare compatibility against contract ranges.

A semantic change lands as additive first, with old and new roles generated for both trains before any consumer switches meaning.
The manifest records minimum transformer and consumer versions, so mobile cannot accept an artifact it interprets under older semantics.
Removal waits until both trains acknowledge the replacement; CI tests the current web version against mobile lagging by exactly three versions.

Why interviewers ask this: The interviewer is checking release ordering when consumers advance at different speeds.

Locked questions

21
A React 19 and Vue 3.5 library must share 72 components under a 14 KB adapter budget; where would you draw the framework-neutral boundary?
reactcomponentsvue
22
You are considering Web Components for 35 primitives used in 3 React apps and 2 Vue apps; what 5 criteria decide whether that boundary is justified?
reactcomponentsvue
23
A shared Select serves React, Vue, and plain HTML on 18 forms, but each platform models value updates differently; what event protocol would you specify?
htmlreactvue
24
A 48-component React package must work in Next.js streaming SSR while its Vue peer runs in Nuxt 3; how would you define 4 hydration invariants?
reactcomponentshydration
25
React consumers use controlled state while Vue consumers expect v-model for 26 field components; what state protocol avoids adapter drift over 12 releases?
reactcomponentsforms
26
A shared overlay stack spans 4 React shells, 2 Vue widgets, and Web Components inside shadow roots; how would you assign portal and focus ownership?
reactcomponentsvue
27
You need one theming contract for 3 brands across React, Vue, and 42 Web Components, but shadow DOM blocks inherited selectors; what would you expose?
reactcomponentsdom
28
A framework-neutral behavior core saves duplication for 31 components but adds 19 KB to every bundle; what build-versus-native decision would your RFC make?
componentsdecision-making
29
Three framework adapters for 55 components keep releasing out of sync by 2 weeks; what package and CI design would enforce parity without one giant package?
componentsdesign
30
A React wrapper around 24 Web Components duplicates events during hydration in 7% of sessions; how would you diagnose and repair the adapter contract?
reactcomponentshydration
31
A Button API has grown to 27 props across 186 call sites, including 9 boolean style switches; what would your replacement RFC expose?
decision-makingapi
32
A DataTable serves 12 products and now has 43 configuration props; how would you govern extensibility without freezing legitimate product needs?
config
33
A Select rewrite must preserve 8 years of usage across 214 call sites, but the old API mixes async loading, search, and form state; where do you cut the contract?
formsapiasync
34
A Dialog package has 16 variants and consumers request direct access to its focus-trap internals; what governance decision would you record for the next 3 releases?
35
Four teams propose incompatible Card composition APIs for 63 surfaces; how would an RFC choose among props, slots, and compound components using 6 sample layouts?
componentsapidecision-making
36
A FormField API is used 340 times, and 28 consumers manually wire error IDs; what invariant would you move into the component contract?
componentsapi
37
A component council receives 37 API proposals per quarter but only 4 maintainers can review them; what lightweight governance artifact prevents a queue without lowering the bar?
componentsapidata-structures
38
A package promises semantic versioning, yet 6 minor releases changed DOM and broke 19 CSS overrides; what public-contract policy would you adopt?
cssdomversioning
39
A Combobox has 11 supported behaviors but Storybook documents only 3; what contract artifact would make API review executable?
storybookapiartifacts
40
You must deprecate an Icon API with 96 names after moving to a 1,400-glyph set; how would you govern naming and prevent bundle regressions?
api
41
A motion language must cover 138 components, but menus feel slow at 220 ms and toasts vanish too abruptly at 90 ms; how would you define role-based timing?
components
42
A 9-route product wants View Transitions, but 2 routes stream content and browsers without support still represent 18% of traffic; what progressive contract would you ship?
43
A dashboard reorders 64 live cards every 5 seconds, and layout animation drops to 24 fps; what motion architecture preserves data clarity?
motionarchitecture
44
A reduced-motion audit finds spatial travel in 47 of 120 components; what artifact distinguishes essential state feedback from removable motion?
componentsfeedbackartifacts
45
A 380 KB Lottie success animation appears in 14 checkout surfaces and delays interaction by 160 ms; would you keep it, and what asset contract applies?
motion
46
An onboarding prototype uses a 240 KB Rive state machine with 18 inputs, but production needs only 4 user states; what integration contract would you approve?
prototypingprototypesonboarding
47
A configurator proposal adds Three.js to 6 product pages, increasing JavaScript by 310 KB; what performance envelope would justify the 3D path?
configjavascript
48
A drag interaction across 96 kanban cards uses spring motion, but rapid pointer reversals cause 3 queued animations; what interruption protocol would you define?
data-structurestypingagile
49
A modal exit lasts 280 ms across 44 surfaces, but focus returns after the animation and screen-reader users wait; how would you separate visual and interaction timelines?
dialogsmotion
50
A motion token update changes 112 Storybook stories and creates 640 Chromatic diffs; what release artifact separates intended rhythm changes from regressions?
tokensstorybookartifacts
51
Produce an accessibility ownership map for 46 WCAG 2.2 defects spread across 9 teams and 3 release trains; how would you clear the critical path in 6 weeks without turning the central team into a bottleneck?
schedulingtrackinga11y
52
An Accessibility Conformance Report prepared with a VPAT template is due for renewal in 30 days, but 4 of 18 documented exceptions no longer have valid product constraints; produce an exception burn-down register that keeps the report honest.
a11yerror-handling
53
An axe scan reports 1,240 violations across 70 routes, yet manual sampling shows 82% come from 5 shared primitives; produce a remediation sequence for the next 4 sprints.
samplingagile
54
A banking flow has 12 custom widgets and must pass EN 301 549 V3.2.1 (2021-03) plus WCAG 2.2 AA before a launch in 5 weeks; create a conformance evidence matrix for sign-off.
wcaga11y
55
After a token release, 260 text-background pairs across 6 brands need contrast verification in default, dark, and forced-colors modes; design a 2-stage compliance gate.
contrastdesigntokens
56
Customer support logged 37 keyboard traps from 3 embedded checkout partners, while your host shell owns only 2 focus boundaries; produce an integration remediation contract for 21 days.
keyboard
57
Your mobile app mirrors 34 web components, but 11 accessibility fixes cannot share implementation; create a parity rubric that reaches 95% equivalent task coverage in 2 releases.
componentsa11ycoverage
58
A new WCAG gate blocks 28% of pull requests because legacy pages contribute unrelated failures; define a baseline policy that reduces false blocking below 3% in 2 sprints without masking regressions.
wcagcode-reviewa11y
59
Your Playwright VRT runs 9 browser-viewport combinations over 2,100 pages and costs 1,800 CI minutes daily; produce a tiering model that cuts usage by 55% while retaining every payment-state check.
cssplaywright
60
A 6,400-snapshot Chromatic build queues for 24 minutes although capture takes only 7; diagnose the managed queue and propose a plan using no more than 40 concurrent builds without inventing story-level worker control.
snapshotvisual-regressionconcurrency
61
WebKit snapshots fail 4.6% of the time only on ARM runners after a GPU image update; produce a flake investigation record that reaches a 0.4% quarantine threshold in 10 days.
snapshot
62
A token rename changes 14,000 snapshots across 5 repositories, but only 320 represent intentional visual differences; create a baseline approval protocol that can finish in 2 days.
tokenssnapshottyping
63
Product screenshots use 7 locales and 3 density settings, creating 21 variants per story; define a coverage matrix that holds the suite below 5,000 images while catching truncation in German and Arabic.
coverage
64
A canvas-based chart creates 900 noisy diffs after each Chrome update, while its labels and legend remain DOM nodes; design a hybrid VRT contract with a 15-minute pull-request SLA.
domdesign
65
Your VRT cache hit rate fell from 78% to 19% after moving 8 packages into a monorepo; produce a cache-key audit that restores at least 65% without serving stale baselines.
cachingmonorepo
66
Two reviewers approve the same visual diff differently in 31% of cases across 1,600 monthly changes; create a severity calibration artifact that gets disagreement below 10% in 6 weeks.
conflictseverity-priorityartifacts
67
A navigation redesign scores 8.4 versus 7.1 for perceived polish with 24 participants, but task completion slows by 11%; produce a decision sheet for the next iteration.
iteration
68
Three onboarding variants have equal 62% completion, yet delayed surveys from 180 users rate trust at 54, 67, and 73; design a perceived-quality measurement plan that identifies why.
onboardingdesign
69
A motion update raises a 7-point delight score but 9 of 42 participants describe the interface as slower although median task time is unchanged; create an evidence review.
types
70
Support calls fall 18% after an error-state redesign, but a 5-point quality survey lift has a 38% response rate; produce a confidence note before claiming success.
71
A design-system refresh improves brand-consistency ratings from 6.8 to 8.0 across 4 products, but one product drops 6 points in findability; build a quality scorecard that prevents averaging away the regression.
system-designdesignconsistency
72
A prototype receives 91% preference in a 33-person moderated study but only 46% of 12,000 beta users keep the feature enabled after 14 days; produce a reconciliation brief.
prototypingprototypesreact
73
At 09:20, checkout p75 INP jumps from 170 ms to 410 ms for Android users after a component release used by 22% of sessions; produce the first 60-minute incident plan.
componentsincidentssessions
74
A homepage LCP incident affects only the slowest 25% of 4G visits after a 480 KB hero image variant ships; define the rollback threshold and diagnostic artifact for 90 minutes.
rollbackartifactsincidents
75
A consent banner pushes CLS from 0.06 to 0.23 in 17 countries, but legal copy length differs by 3 times; produce a containment spec before the next 48-hour campaign.
web-vitals
76
Your design-system package adds 34 KB of first-load JavaScript to 64 routes, breaching a 90 KB budget on 11 routes; create a budget attribution report and release rule.
system-designdesignjavascript
77
Field data shows p75 INP at 190 ms globally but 360 ms for the 8% of sessions using screen magnification; design a performance budget that does not erase this cohort.
web-vitalsdesignsessions
78
A third-party chat widget raises p75 LCP by 0.4 seconds and INP by 85 ms on 38 routes, yet support requires it after 10 seconds of user inactivity; produce a loading contract.
web-vitalsdependencies
79
A responsive image refactor passes Lighthouse but worsens field LCP from 2.2 to 2.9 seconds for 13-inch Retina laptops over 7 days; create a lab-to-field reconciliation artifact.
responsiveweb-vitalsreact
80
Six teams need token editing in Figma within 8 weeks; Tokens Studio covers aliases but not your approval workflow, while a plugin would take 14 engineer-weeks; produce a build-versus-buy spike plan.
tokensfigma
81
Your 1,300-story VRT contract renews in 45 days; Chromatic offers managed review, while Playwright can reuse existing runners but lacks baseline governance for 7 teams; create a capability scorecard.
playwrightvisual-regression
82
A Rive prototype meets the interaction brief in 3 days, but the product needs 40 scenes offline on low-end Android with a 6 MB total asset cap; write a runtime decision record.
prototypingprototypes
83
A vendor can sync 2,400 Figma variables to 4 platforms, but its transform language cannot express your Android typography rules; design a 3-week interoperability proof.
typographydesignprocurement
84
A Figma plugin used by 85 designers depends on 1 maintainer and an undocumented API scheduled to change in 60 days; produce a replacement decision with a 2-week discovery cap.
designapifigma
85
Your team can buy an accessibility testing platform for 120 components or extend axe and Playwright in 7 engineer-weeks; create a pilot that measures the manual-review gap over 5 weeks.
componentsa11ytesting
86
An internal motion editor took 16 engineer-weeks and serves 3 experts, while 28 designers still export Lottie by hand; produce a sunset-or-invest review for the next 30 days.
design
87
An RFC to replace 3 Tooltip implementations has 46 comments from 8 teams and no decision after 18 days; produce a closure record that resolves the disputed interactive-content case.
decision-makingclosures
88
A semantic-token RFC is accepted by 5 platform teams but ignored by 12 product teams, leaving 37% raw color usage after 2 releases; create an adoption recovery plan.
decision-makingtokensrecovery
89
Four repositories release the same component contract on 3 cadences, causing 9 compatibility incidents in one quarter; write a governance RFC for synchronized evidence, not synchronized deploys.
incidentsdecision-makingdeployment
90
A contribution policy requires 4 approvals for every design-system change, pushing median review to 6.5 days across 70 monthly pull requests; propose a risk-based amendment.
system-designdesigncode-review
91
After 6 months, 14 teams have created 23 private forks despite a contribution RFC promising a 5-day response; produce a fork reconciliation register.
decision-makingreact
92
A motion RFC passes with 7 teams, but telemetry shows only 41% of eligible transitions use its roles after 90 days; create an adoption audit with a deprecation trigger.
decision-making
93
An accessibility RFC has 3 unresolved objections from localization, security, and mobile teams 48 hours before its 30-day deadline; produce a decision meeting brief.
decision-makingestimationa11y
94
A design-system council meets every 2 weeks, yet 68% of 94 agenda items are status updates and decisions wait a median 19 days; redesign the operating artifact.
system-designdesignartifacts
95
You mentor 2 engineers migrating 48 components, but after 4 weeks they still ask you to approve every prop change; create a delegation ladder for the remaining 6 weeks.
mentoringdelegationcomponents
96
A senior product designer is learning production React and has shipped 3 prototypes with 17 accessibility defects; design a 5-week coaching artifact without turning them into a frontend generalist.
reacta11ydesign
97
A mentee owns a real VRT flake seen in 17 intermittent failures on 1 renderer; create a diagnosis exercise with a minimal reproduction and prove transfer on a new renderer incident 2 weeks later.
incidents
98
A mentee's token codemod migrates 96% of 7,500 usages but corrupts 23 composite typography values; plan a 4-session debugging apprenticeship.
tokenssessionstypography
99
You are coaching 4 RFC authors; 6 of their last 9 proposals reopened because success metrics were not testable; create a review rubric for the next 8 weeks.
success-metricsdecision-makingmonitoring
100
One engineer owns a 10-week accessibility remediation but escalates every screen-reader discrepancy among 36 components; design an independence checkpoint at week 5.
componentsa11ydesign

Questions

1You have 14 weeks to replace 132 CSS-in-JS components across 4 React storefronts while weekly releases continue; what would your migration RFC require?

2A design system has 168 components in 6 applications, but 41 primitives are forked; how would you design a 2-quarter consolidation plan and its dependency map?

3You must move 104 components from a monorepo into versioned packages used by 9 independently deployed surfaces; what release-train architecture prevents lockstep deployment?

4After a brand acquisition, 127 components must support 3 brands and 2 density modes within 10 weeks; what architecture decision record would you write?

5A portal migration touches 119 components across 5 microfrontends owned by separate teams, and duplicate React copies already add 74 KB; how would you frame the integration RFC?

6You are replacing 143 physical-direction CSS components for RTL across 7 locales in 12 weeks; what should the migration ledger and gate contain?

7A legacy admin suite has 151 components and 38 global Sass entry points; teams demand zero selector breakage during a 16-week move to scoped styles. What is your strangler plan?

8A new accessibility primitive must replace 116 home-grown dialogs on 22 routes without changing analytics events; how would you prove the migration is behaviorally compatible?

9You need to retire 109 deprecated components across 11 repositories, but 17 cannot be found by static imports because they are loaded from JSON; what migration control plane do you build?

10A typography change affects 126 components on 8 surfaces and could shift checkout layouts; what 6-week rollout architecture would you choose for the new variable font?

11A pipeline exports 842 tokens to Figma Variables, CSS, Swift, and Kotlin, and 29 aliases broke last release; what belongs in token schema version 3?

12Tokens Studio contains 615 tokens, but Figma and code disagree on 46 mode mappings; how would you define a bidirectional ownership contract without creating 2 sources of truth?

13You must add a 4th brand to 1,180 tokens without allowing brand aliases to reference component tokens; how would your schema enforce the dependency direction?

14A Style Dictionary build emits 7 target packages from 730 tokens, but nondeterministic ordering changes 300 lines on every run; what pipeline contract fixes review noise?

15A token release changed 34 foreground-background pairs and caused 12 WCAG failures; how would you add contrast semantics to a 560-token contract?

16Web accepts rem while iOS requires points and Android uses dp; 96 of 480 dimension tokens currently diverge. What unit-normalization contract would you approve?

17You need to rename 210 semantic tokens consumed by 13 repositories with a 6-week deprecation window; what must the release manifest guarantee?

18A Figma plugin can write 900 token values directly, while pull requests require review by 2 owners; how would you prevent the plugin from bypassing governance?

19A 670-token pipeline must support high-contrast mode, but 58 component tokens have no semantic fallback; what capability matrix would you write?

20Two release trains consume 760 tokens, and the mobile train lags web by 3 versions; how would you stop semantic changes arriving out of order?

Locked questions