Design systems engineer behavioural interview questions

As asked

Tell me about a time when the design team and the engineering team had strong conflicting opinions about how to name or structure something in the design system. How did you resolve it and what was the outcome?

Sample answer outline

A strong story shows the candidate facilitating a structured conversation with concrete examples rather than letting it devolve into opinion. They should describe the criteria they used to evaluate options (consistency, discoverability, alignment with existing conventions, impact on downstream consumers), the process (a proposal doc, async feedback, a synchronous decision meeting), and the outcome including how the decision was documented so it does not resurface. Bonus points for mentioning that they updated a naming convention guide to prevent the same debate recurring.

Expect these follow-ups

• In hindsight, do you think you chose the right option? What would you do differently?
• How did you handle the person on the losing side of the decision who still disagreed after the decision was made?

As asked

Describe a time you had to deprecate a widely used component or API and migrate many teams to the new version. How did you communicate the change, support the migration, and handle teams who missed the deadline?

Sample answer outline

A strong answer shows proactive communication (advance deprecation warning in the changelog, console warnings in the library, direct team notification), tooling support (a codemod that automates 80% of the migration), a generous migration window, and a clear escalation path for teams who cannot migrate. The candidate should describe how they tracked migration progress and what they did with teams who were still on the old API at sunset, whether that was extending the timeline, pairing on the migration, or temporarily maintaining both versions.

Expect these follow-ups

• How did you decide how long the deprecation window should be?
• Were there any teams that pushed back on the migration itself, not just the timeline? How did you handle that?

As asked

Tell me about a time you had to advocate for accessibility improvements in a design system when the organization was not prioritizing it. How did you make the case and what did you achieve?

Sample answer outline

Strong answers show the candidate reframing accessibility as a risk and business benefit rather than a moral argument: legal liability (WCAG-related lawsuits have increased significantly), market reach (15% of the population has a disability), and performance overlap (accessible markup is faster to parse and better for SEO). They should describe concrete data they gathered (audit results, specific failure examples) and who they took the case to. The outcome should show either a policy change, a dedicated sprint, or at minimum a measurable improvement in a specific component.

Expect these follow-ups

• What was the most significant accessibility barrier you fixed and how did you verify it worked with real assistive technology?
• How do you maintain accessibility standards when you are not directly reviewing every product PR?

As asked

Walk me through a time you were brought in to create a design system for a company that had no formal system. How did you assess the current state, prioritize what to build first, and get initial buy-in from product teams who were already building without you?

Sample answer outline

A strong answer describes an audit phase (cataloging existing components across products, identifying redundancy and inconsistency), a prioritization framework (highest-frequency components first, those with the most inconsistency, those with known accessibility issues), and a buy-in strategy (not mandating adoption but making the system so good that teams want to migrate). The candidate should mention the importance of early adopter product teams who co-design the first components, giving them ownership and making them advocates.

Expect these follow-ups

• How did you decide between building on an existing open-source library versus building from scratch?
• What was the first component you released and why did you choose that one?

As asked

Tell me about a time a product team refused to use a component you built because it didn't fit their needs. How did you respond and what did you change as a result?

Sample answer outline

A strong answer shows curiosity (scheduling a pairing session to understand specifically what was missing), honesty about whether the component had a real gap or the team had an unusual edge case, and a principled decision process (extending the component API if the use case was broadly applicable, documenting a pattern instead if it was too specific). The candidate should avoid defensiveness and show that they updated their requirements-gathering process to involve product teams earlier in the component design phase.

Expect these follow-ups

• What process change did you make to prevent similar rejections in the future?
• How do you distinguish between a product team's legitimate need that should change the component versus a preference that should not?

As asked

You join a team that has been maintaining a design system for two years. Adoption by product teams is stagnant at 30%. What steps do you take to understand why, and how do you prioritize what to fix?

Sample answer outline

A systematic investigation starts with data (what components exist, what do product teams actually use, what are they building instead). Then qualitative research: interviews with product engineers to understand specific friction points (installation complexity, missing components, documentation gaps, breaking changes that burned them). Common root causes are: the system lacks the components teams most need, the DX is too painful (poor TypeScript types, no autocomplete), or teams had a bad migration experience from a past breaking change and lost trust. Prioritization should rank by impact on the most common friction points and be shared transparently with all stakeholders.

Expect these follow-ups

• How would you present your findings and recommendations to the VP of Engineering who is questioning whether to continue investing in the design system?
• What is one change you have seen reliably increase adoption that is underestimated by most design systems teams?

As asked

A product team alerts you on a Friday afternoon that a design system update they deployed has broken the visual appearance of their entire checkout flow. Colors are wrong across the board. What do you do?

Sample answer outline

Immediate triage: identify the specific version bump that caused the regression, whether it is in the token package or a component. Check the CHANGELOG and any visual regression baselines from CI for that version. Mitigation: advise the team to pin back to the previous version in their package.json while the root cause is investigated. Root cause analysis: was a token renamed without a migration path, was a CSS custom property default changed, or was there a specificity change in the component styles? Fix and follow-up: patch release with the fix, add a regression test that catches the specific case, and post a post-mortem to prevent recurrence.

Expect these follow-ups

• If the root cause was a missing visual regression test, what test would you add and how would you make sure it catches this class of issue in future?
• How would you communicate this incident to all 30 product teams who might be affected?

As asked

A senior engineer from a product team has contributed a new component to the design system, but the implementation doesn't meet your accessibility or API design standards. They're busy and have little time for revisions. How do you handle this?

Sample answer outline

A productive approach is to pair with the contributor rather than issuing a review comment list. The candidate should describe specific communication: acknowledging the contribution positively, explaining concretely why each standard exists (not just citing rules), and offering to do the revision work together or even take on the fix themselves if the contributor is blocked on time. A strong answer also reflects on process: the standards should be documented before contributors start, not discovered at review time, and contribution templates or a checklist should surface requirements upfront.

Expect these follow-ups

• What would you do if the contributor pushed back and said the accessibility requirement was unnecessary for their use case?
• How do you balance maintaining quality standards with not discouraging contributions from busy product engineers?

As asked

You inherited a token system where names like --blue-primary and --text-dark were used inconsistently across 50 components, and the naming has no semantic meaning. How did you (or how would you) approach cleaning this up without breaking every consuming product?

Sample answer outline

A gradual migration with backward compatibility is the only safe path. Introduce the new semantic token names first, then create aliases from old names to new names (--blue-primary: var(--color-action-primary)) so consumers continue working. Build an AST-based scanner to show all usages of old token names across product codebases. Set a deprecation timeline and notify teams. Ship codemods to automate migration. After the deadline, remove the old aliases in a major version bump. The candidate should mention that this kind of migration requires executive alignment on the timeline because it touches every team.

Expect these follow-ups

• How long would you give product teams to migrate, and what factors influence that decision?
• How do you handle a team that is on a product freeze and genuinely cannot migrate within your timeline?

As asked

You notice that engineering implementations of components consistently diverge from the Figma designs: wrong spacing, wrong font weight, wrong color. The designers are frustrated but the engineers say they're following the component code. What do you do?

Sample answer outline

This is a token sync problem. The candidate should describe auditing whether Figma variables match code token values numerically, whether the token names are the same or the mapping is ambiguous, and whether components in code use tokens or hardcoded values. The fix is usually one of: syncing Figma variables with code tokens via an automated pipeline, fixing components that hardcode values instead of referencing tokens, or adding a design review step to the PR process. A strong answer includes proactive steps like visual diff tools (Chromatic + Figma plugin) that show side-by-side comparisons during review.

Expect these follow-ups

• How do you build trust with designers who feel like this problem will keep recurring?
• What is the single most common cause of design-implementation drift in your experience?

As asked

Your design system supports both React 17 and React 18 because product teams are on different upgrade tracks. Tell me about the challenges of maintaining a library that must work across both versions and how you manage the complexity.

Sample answer outline

The main challenge is peer dependency conflicts (react and react-dom as peerDependencies with a version range like >=17), testing both versions in CI (matrix builds or separate test runs), and avoiding React 18-only APIs (like useId or startTransition) in code paths that must run on 17. The candidate should describe their actual CI setup, how they handle breaking changes that affect one version differently, and the communication plan for product teams still on 17. A strong answer includes a clear sunset timeline for React 17 support so the team can eventually simplify.

Expect these follow-ups

• How do you handle a security vulnerability in React 17 that you cannot patch because it requires a breaking API change?
• How do you communicate to React 17 teams that a new design system feature requires React 18?