Bug report to deployed fix workflow

WHAT THIS TESTS The interviewer wants a disciplined, test-first defect workflow proving you fix the bug at the source, prevent regressions, and ship through the proper release pipeline rather than band-aiding it in one consumer.

A GOOD ANSWER COVERS Receive and triage: capture a clear repro, the affected version, browsers, and a minimal example, then assess severity and how many consumers are hit to set priority. Reproduce the bug locally in Storybook or a test harness. Write a failing automated test that captures the defect before touching the fix, so the bug is provably caught. Implement the minimal fix. Run the full CI gates: unit tests, visual regression, accessibility, type checks, and lint. Get CODEOWNERS review and design sign-off if the visuals change. Release it as a patch version since it is a backward-compatible fix, update the changelog, and notify the reporter and other affected teams to upgrade. For critical issues, consider a hotfix or backport to supported major lines.

COMMON WRONG ANSWERS Fixing it only in the reporting team's application, leaving the shared component broken for everyone else. Shipping the fix with no regression test, so it can silently reappear. Bumping a minor or major version for a simple fix. Skipping the changelog so consumers do not know to upgrade.

LIKELY FOLLOW-UPS How do you handle a critical production bug needing a hotfix? Why write the test first? How do you backport to older major versions?

ONE CONCRETE EXAMPLE A Tooltip mispositions near the viewport edge. You reproduce it in Storybook, add a failing positioning test, fix the offset logic, pass visual and axe checks, get a core review, and ship version 2.4.1 as a patch with a changelog entry, then ping the teams still on affected versions.