Systematic Debugging and Root Cause Analysis Questions

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.

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.

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.

Correlating a frontend performance complaint with backend traces requires the frontend's own timing data to be joined with backend spans through a shared identifier, not just guessed at from backend metrics alone.

The method

1. Real User Monitoring (RUM) in the browser captures actual page-load and interaction timing for real users (not synthetic tests), including navigation timing, resource timing, and any custom spans around the slow interaction.
2. Propagate a correlation ID from the frontend request through to the backend (as a header on the API call the slow page makes), so a specific user's slow page load can be joined to the exact backend trace that served it. Concretely: the frontend attaches a header like traceparent: 00-8f2b1c7d4e...-01 to the API call the slow page makes; the backend reads that same header and logs it as the trace ID on its own span, so a frontend span named pageload.dashboard stitches directly to a backend span named GET /api/dashboard sharing that identifier.
3. Consistent span naming conventions across frontend and backend spans (matching operation names/prefixes) let a single trace view stitch a "page load" frontend span to the backend spans it triggered, rather than requiring manual correlation by timestamp guessing.
4. Sampling strategy: full RUM capture for a sampled percentage of real users, escalated to full detail specifically for sessions that already look slow (a threshold-triggered upgrade in fidelity: a cheap, low-overhead signal runs always-on for every session, and only once a session already looks anomalous does the system escalate to full, expensive-to-collect detail, since capturing full detail for every user by default would be too costly at scale, while waiting until a complaint arrives before capturing anything loses the very data needed to diagnose it).

A related worked instance

A load-balancer misconfiguration causing 502/503s for a subset of users is diagnosed the same way in reverse: correlate the client-visible symptom (which users, which requests) against infra-layer logs/metrics (LB health-check status, backend pool membership) using the same request-level correlation ID, rather than assuming the cause is in application code just because that's where the symptom is visible.

Trade-offs and pitfalls

RUM data can be noisy (real user devices/networks vary far more than a controlled synthetic test), so a single slow session is weak evidence on its own; the technique's value is in aggregating across many correlated frontend-to-backend traces to find a consistent pattern (a specific endpoint, a specific backend service) rather than chasing one anomalous session.

Direct answer

Record the Performance panel during the interaction. Layout thrashing shows many small purple "Layout" blocks flagged as forced reflow, interleaved with script, versus one long uninterrupted block for plain slow JS.

Structured elaboration

• Thrashing happens when code alternates writes (el.style.width = x) with reads (el.offsetWidth) in a loop; each read forces a synchronous layout flush to stay accurate.
• In the recording, expand "Layout" entries with a warning triangle; DevTools names the exact call stack and line.
• Fix by batching all reads into variables first, then performing all writes, and re-record to confirm the many small Layout events collapse into one per frame.

Worked example

Touching 200 elements with a read right after each write means:

$\frac{200}{1} = 200\times \text{ more layout passes than necessary}$

Batching reads then writes brings it back to effectively one pass regardless of element count.

Trade-offs and pitfalls

Caching read values is only safe if nothing else mutates the DOM between your read and write phases. requestAnimationFrame aligns writes to paint but doesn't by itself stop thrashing if reads and writes stay interleaved inside it.

What the interviewer probes next

Which specific properties force a synchronous layout, and how a library like FastDOM automates the batching.