intermediate 2 min answer

Three product teams have forked the design system to meet deadlines. Components have diverged. How do you recover?

design-systemadoptiongovernance
Show the full answer Hide the answer

What the interviewer is testing

Whether you treat forking as a product failure of the design system rather than as team indiscipline.

Why they forked

Almost always one of: the component did not support what they needed and the contribution path was too slow; the release cadence was too slow, so a fix they needed was quarters away; or breaking changes made upgrading expensive, so they pinned and then diverged.

Teams fork under deadline pressure when the supported path costs more than the fork. That is a rational response to the system's economics, and changing the economics is the fix.

The recovery

Fix the contribution path first. A team needing a variant must be able to contribute it and have it released in days, not quarters. Until this is true, any reconciliation will fork again — this is the binding constraint and it must be addressed before anything else.

Understand what each fork changed. Diff them. The changes cluster into a small number of genuinely needed capabilities, and those become the roadmap. Frequently all three teams needed the same thing.

Absorb the needed variants into the core with proper extension points, rather than asking teams to give up capability.

Provide a migration path: codemods where the API changed, and the design system team doing the first migration itself.

Then converge, team by team, with the core now genuinely better than their fork.

Preventing recurrence

Semantic versioning with a real deprecation policy, so upgrading is safe and predictable. Documented extension points for legitimate customisation, so teams can vary without forking. Adoption measured as a product metric, with forks as the leading indicator of a gap.

What a strong answer adds

The reason this matters beyond consistency: the design system is where accessibility, keyboard behaviour, theming and interaction correctness are solved once. Three forks means three divergent accessibility implementations, and a remediation must now be done four times — which is the argument that funds the recovery.

Common weak answers

Mandating the core system. Deprecating the forks without addressing why they exist.