Systematic Debugging and Root Cause Analysis Questions

Direct answer

Set a line breakpoint where the argument is used, then right-click it and add a condition. DevTools then only pauses on the call you actually care about, instead of resuming through every call by hand, and unlike a console.log you don't have to edit the source, redeploy, or remember to strip it back out afterward.

Structured elaboration

• Locate the function (Cmd/Ctrl+P to jump to file, or jump from the triggering element/request).
• Set a plain breakpoint, then right-click its gutter marker and add a condition like arg === undefined.
• Use the Scope and Call Stack panels at the pause to see the value and who called it, which gives you every in-scope variable and the full caller chain for free, versus a console.log that only shows whatever single expression you remembered to print.
• If pausing would break timing-sensitive code, use a logpoint instead (same menu), which prints without stopping and without touching the source file at all.

Worked example

Say the function runs 500 times per page load and only 2 calls are malformed:

$\frac{500}{2} = 250$

A plain breakpoint costs about 250 resumes per bad call found; a conditional one costs one setup and zero resumes. A console.log approach would need a code edit, a reload, and manually scanning 500 printed lines for the 2 that matter.

Trade-offs and pitfalls

An expensive condition re-evaluates on every hit and can slow a hot loop, so keep conditions cheap and side-effect free. Never ship a leftover debugger; statement, the same discipline problem console.log has, just caught by the debugger itself instead of a stray log line reaching production.

What the interviewer probes next

Whether you know logpoints exist, and how you'd do this against a minified production bundle.

Direct answer

The effect's [] dependency array means it runs once, on mount, so the setInterval closure permanently captures count as it was then: 0. Every tick computes setCount(0 + 1), so state keeps resetting to 1 instead of advancing.

Structured elaboration

Each render creates a fresh count binding; an effect with [] never recreates its closure, so it stays bound to the first render's value forever. Fix with the functional updater setCount(c => c + 1), which reads the current value from React at call time instead of the captured variable, so keeping [] is safe.

Worked example

This reproduces the exact mechanism and was executed:

function render(i) {
  const count = i;
  return { tick: () => console.log('sees count =', count) };
}
const staleTick = render(0).tick;
for (let n = 1; n <= 3; n++) { render(n); staleTick(); }

Output: sees count = 0 three times, proving the closure never sees later renders. The functional-updater fix, also executed:

let live = 0;
const tick = (u) => { live = u(live); console.log(live); };
for (let n = 1; n <= 3; n++) tick(c => c + 1);

Output: 1, 2, 3.

Complexity

O(1) per tick either way; this is a correctness/closure-lifetime bug, not a performance one.

Edge cases

Adding count to the deps array without the functional form "fixes" it but tears down and recreates the interval every second, wasteful and prone to drift. React StrictMode double-invoking effects in dev won't leak a second timer here since cleanup calls clearInterval.

Trade-offs and pitfalls

Functional updates only solve closures over the state you're setting; an unrelated stale prop still needs a ref or the dependency array.

What the interviewer probes next

When you'd reach for useRef instead of adding something to the dependency array.

Direct answer

The trace is only useful once decoded with the source map from the exact build that crashed. Error trackers like Sentry do this automatically if maps were uploaded during CI; otherwise you resolve it manually with the same map.

Structured elaboration

• Every production build should emit and upload a .map file per bundle tagged to the release, never served publicly.
• The map must match the EXACT deployed bundle; a hotfix rebuild, even of "the same" code, produces a different minified layout.
• Resolve a frame like main.a3f1.js:1:24681 against the matching map to get the real file and line, then confirm against the release live at the error's timestamp, not current main.

Worked example

at a (main.a3f1.js:1:24681) resolves via the correct map to src/components/Checkout.jsx:142:10, inside calculateShippingDiscount. Without the map, neither name means anything.

Trade-offs and pitfalls

If the CI step that uploads maps fails silently, an entire release's errors show "unable to locate source map," exactly when you most need visibility right after a risky deploy; alert on that condition specifically. Never serve maps unauthenticated from your CDN.

What the interviewer probes next

How you'd detect a silently failed map upload, and how release tagging ties an error back to a commit.

Direct answer

Most likely a service worker (a background script the browser installs per origin that can intercept network requests and serve cached responses, even across page reloads and closed tabs), or an aggressive cache, is still serving the previous build. The new worker's lifecycle can sit in "waiting" until every open tab of the old version closes, so a plain refresh doesn't guarantee fresh code.

Structured elaboration

• In DevTools' Application > Service Workers, check whether an old version is "activated" while a newer one sits "waiting."
• Check the Network tab's Size column for "(ServiceWorker)" instead of real bytes, meaning the request never reached the server.
• Fix going forward with skipWaiting() in install and clients.claim() in activate, paired with content-hashed filenames so a stale cache can never mismatch HTML and JS.
• For already-stuck users, add a version-check ping that triggers a one-time forced reload on detecting a newer deployed version.

Worked example

A user with 3 open tabs can have a new worker fully installed but waiting indefinitely, since activation requires ALL old-version tabs to close first, which for a pinned tab might not happen for hours.

Trade-offs and pitfalls

skipWaiting() plus clients.claim() can swap app code under a user mid-session; some teams prefer the default wait-for-close behavior plus an in-app "refresh to update" banner instead.

What the interviewer probes next

How you'd cache-bust HTML differently from hashed JS/CSS, and how you'd monitor rollout completion.

Every button logs the same final value of i because var is function-scoped (not block-scoped): all three closures created inside the loop capture the same variable i, and by the time any button is actually clicked, the loop has already finished and i holds its final value, 3.

for (var i = 0; i < 3; i++) {
  var btn = document.createElement('button');
  btn.textContent = 'Button ' + i;
  btn.onclick = function() { console.log('clicked', i); };   // all three share one 'i'
  document.body.appendChild(btn);
}

Verified demonstration

Simulating the closures firing after the loop completes confirms all three log 3; switching the declaration from var to let and rerunning the identical logic confirms each closure captures its own per-iteration binding and logs 0, 1, 2 correctly.

Two fixes

1. Use let instead of var (ES6+): let creates a fresh binding of i for each loop iteration, so each closure captures its own value.

for (let i = 0; i < 3; i++) { btn.onclick = function() { console.log('clicked', i); }; }

2. Capture the value explicitly with an IIFE (Immediately Invoked Function Expression, a function defined and called in the same statement, so it runs immediately with the current value of i) or a bound argument if you must keep var (e.g. for older-runtime compatibility): btn.onclick = (function(idx) { return function() { console.log('clicked', idx); }; })(i); or store the index on the element itself (btn.dataset.index = i) and read it from the event target at click time instead of relying on closure capture at all.

Complexity and edge cases

No complexity change (O(n) either way); the edge case worth testing explicitly is a loop with zero iterations (no buttons, nothing to click) and a loop where the closure is invoked during the loop (synchronously) rather than after it completes, since a synchronous invocation would not exhibit this bug at all, only deferred/asynchronous invocation (like a click handler) does.