Skip to content
tezvyn:

Bug report to deployed fix workflow

Source: interviewEasyHow cards are made

Summary

Whether you have a disciplined bug-fix pipeline.

Key points

Triage and reproduce, write a failing test, fix it, pass CI gates and review, then patch-release and notify.

What's really being asked

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.

The full answer

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.

The mistakes people make

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.

What usually comes next

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

A 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.

Interview question

Why write a failing test that reproduces the bug before implementing the fix?

  • a.It automatically converts the fix into a major release
  • b.It proves the bug is caught and guards against the same regression returning laterCorrect
  • c.Tests are required by Semantic Versioning
  • d.It lets you skip code review for the change
Why?

A failing-then-passing test proves the fix works and locks in protection against regression. It does not bypass review or change the version type; a backward-compatible fix is a patch regardless.

Just read this? Test yourself on what you have been reading.

Read the original → uxpin.com

Put your scrolling time to good use

Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on design-systems — each one lists the topics its interview covers.

See open roles