Debugging Live in Interviews

A repeatable method to debug broken UI or JS under interview pressure — isolate, form hypotheses, instrument, and narrate.

intermediate4 min readUpdated Aug 4, 2026

interview
debugging-live

Live debugging rounds test process under stress. Interviewers often hand you a broken sandbox and watch whether you thrash or systematically narrow.

This is a protocol, not a bag of console tricks.

What interviewers score

Reproduce reliably before “fixing”
Hypotheses you can falsify
Binary search the fault domain
Narration — they can’t grade silence
Minimal fix that doesn’t invent new architecture

The 6-step protocol

1. Restate expected vs actual
2. Reproduce with smallest input
3. Localize: data | logic | render | network | CSS
4. Instrument one layer
5. Fix + regression check
6. Summarize root cause + prevention

Timebox: if stuck 5+ minutes in the wrong layer, re-localize.

Layer map for frontend bugs

Layer	Symptoms	Tools / moves
Data shape	undefined property, empty UI	`console.log` / debugger on props/state
Logic	wrong calculation, off-by-one	Pure function unit trace
React state	stale UI, infinite loop	React DevTools; effect deps
Network	spinner forever, 4xx/5xx	Network tab; mock vs real
CSS	“not clickable”, overlap	Inspect computed styles; stacking
Timing	race, flicker	breakpoints; fake timers in tests

Network-heavy: Network tab debugging interview. Browser: Network panel.

Narration templates

Start:
“Expected list of 3 todos; I see blank. First I’ll confirm the fetch resolves and the state shape.”

Hypothesis:
“Either the response isn’t an array, or we’re filtering everything out. I’ll log data before setState.”

After find:
“Root cause: API returns { items: [] } but we treated the whole body as an array. Fix: data.items. I’d add a type guard / schema parse in production.”

React-specific live debug

Bug class	First checks
Infinite re-render	setState in render; effect without deps fixing
Stale closure	effect/handler missing deps; see closures
Wrong list state	bad `key`; keys in lists
Effect thrash	object/array deps recreated each render
Event not firing	pointer-events; overlay; disabled button

// Classic: "count is always 0 inside timeout"
function BrokenCounter() {
  const [count, setCount] = useState(0);
  useEffect(() => {
    const id = setInterval(() => {
      // stale if you close over count without functional update
      setCount(count + 1);
    }, 1000);
    return () => clearInterval(id);
  }, []); // missing count — or better: setCount(c => c + 1)
}

Say: “Functional update avoids depending on stale count.”

JS runtime debug

Breakpoints over console.log spam when the editor allows
Conditional breakpoints for rare cases
Watch event loop order: event loop — microtasks vs timeouts
async errors: missing await, unhandled rejection

CSS “it looks wrong” protocol

Inspect element — is it the node you think?
Box model diagram — margin/padding surprise
Computed display / position / z-index
Parent overflow: hidden clipping
Flex/Grid free space — min-width: auto overflow

See Stacking contexts and Flexbox fundamentals.

When you may ask for help

After a genuine attempt:

“I’ve ruled out network and state shape; the reducer looks pure. Is the bug intended to be in the selector?”

Asking early with zero work looks weak. Asking never looks stuck.

Anti-patterns

Anti-pattern	Replace with
Random code edits	One change per hypothesis
Rewrite component	Smallest patch first
Blame the framework	Show evidence
Quiet for 10 minutes	Checkpoint out loud
Fix symptom only	State root cause

Practice drills

Break a working todo app on purpose; fix under 15 minutes.
Mis-configure CORS on a toy API; diagnose via Network.
Introduce a stale closure; catch it with logging.
Record yourself — count silent gaps > 45s.

Out-loud close

Always end with:

Root cause in one sentence
Fix
How you’d prevent (test, type, lint rule, monitoring)

That prevention sentence is a senior signal.