Debug Scenarios
Practice the part interviews usually miss: root cause, debug order, fixes, and guardrails under production-style pressure.
How it works
Each scenario is a short simulator: likely root cause, debug order, best fix set, and regression guard. Progress stays local and separate from coding or trivia.
Typing gets laggy after the third character because every keypress does too much work and also triggers a request.
Cached results and slower network results both update the same list, so an older query can briefly show up again.
The modal looks fine on screen, but keyboard focus escapes behind it and screen readers do not announce it properly.
Route changes and filter changes keep adding listeners, so old listeners stay alive and still use old filter values.
One big shared context holds too much fast-changing state, so typing in one place rerenders parts of the page that did not actually change.
If the network is slow, an older autosave response can still overwrite what the user typed a moment later.
A live order update arrives, but the row keeps showing the old status until the user clicks, sorts, or filters the table.
The header badge and the cart page stop agreeing because one feature quietly creates a second CartService instance.
The product grid updates, but one filter label stays old because store state was destructured into plain values.
The list updates, but edit state and draft text jump to the wrong row because `v-for` is keyed by index instead of item identity.