The Advanced JavaScript Interview

Start by scoping, not coding. Clarify: expected QPS and result latency, result count, keyboard-only accessibility, mobile, do stale results matter, is ranking client- or server-side. State a target, e.g. suggestions within ~100ms of a pause, p95.

Client architecture:

• Debounce keystrokes (~150-300ms) so you query on pause, not per character.
• Cancel in-flight requests with AbortController when a newer keystroke supersedes them, otherwise a slow old response can overwrite a fresh one (the out-of-order race).
• Cache by query string (an LRU Map) so backspacing or repeating a prefix is instant and offline-friendly.
• Race handling: tag each request with a sequence number and ignore any response older than the latest rendered query, belt-and-suspenders with cancellation.
• Minimum query length and trimming to avoid useless calls.

UX & a11y: a combobox with proper ARIA roles, arrow-key navigation, aria-activedescendant, debounced live-region announcements, and visible loading/empty/error states.

Failure modes I'd name up front: network errors (show retry, keep last good results), the stale-response race, unbounded cache growth, and hammering the backend (debounce + min length + server rate limiting).

You never render 10k DOM nodes, the browser can't lay them out or paint them in a 16ms frame. The core technique is windowing / virtualization: render only the ~visible rows plus a small overscan buffer, absolutely position them inside a tall spacer whose height equals totalRows * rowHeight, and swap contents as the user scrolls. That keeps the live node count constant regardless of dataset size.

Round it out with: variable row heights via measurement + a position cache; incremental data loading (infinite scroll with a sentinel + IntersectionObserver, plus request cancellation); keeping scroll-handler work tiny and off the critical path (passive listeners, requestAnimationFrame, avoid layout thrash by batching reads then writes); and offloading heavy transforms to a Web Worker so the main thread stays free. I'd frame it around a main-thread budget: measure with Performance panel / long-task API and keep per-frame work under budget.

Wrap fetch in a client that adds cross-cutting concerns so every call site gets them for free:

• De-duplication: keep an in-flight Map keyed by request signature; concurrent identical requests share one promise. Prevents N components triggering N identical calls.
• Caching with staleness: a keyed cache with TTL, and a stale-while-revalidate policy, serve cached data instantly, refetch in the background. Expose cache invalidation by tag.
• Retries with backoff + jitter, but only for idempotent requests and retryable statuses (network errors, 5xx, 429 with Retry-After), never blindly retry a POST.
• Cancellation via AbortController, wired to component lifecycle so unmounts abort.
• Error normalisation so callers get a consistent error shape.

Trade-offs I'd call out: caching risks staleness (correctness vs speed, pick TTLs per resource); retries can amplify an outage (why jitter + caps + circuit-breaking matter); de-dup assumes requests are truly equivalent. This is essentially what React Query/SWR give you, I'd usually adopt one rather than rebuild it, and I'd say so.

The shape: a loop that awaits a fetch, and on success resets the delay to the base and waits the normal interval; on failure multiplies the delay (capped) and retries.

Key production details interviewers look for:

• Exponential backoff with a cap so a struggling server isn't hammered, min(base * 2^n, max).
• Jitter (randomise the delay) so many clients don't retry in a synchronised thundering herd.
• `AbortController` to cancel the in-flight request on unmount/cleanup, otherwise you set state on a dead component and leak.
• Pause when the tab is hidden (document.visibilityState) to save battery and quota.
• Stop conditions, give up after N failures or surface the error.

This is a classic async race. Each click fires fetch(id) and renders when it resolves. If request A (slow) was fired before request B (fast) but resolves after it, A's response lands last and overwrites B, so the panel shows the record you clicked earlier, not the current selection. Responses aren't guaranteed to arrive in request order.

Fixes, in order of preference:

1. Cancel superseded requests with AbortController, when a new selection happens, abort the previous fetch.
2. Ignore stale responses: capture the current selection id (or a monotonically increasing request counter) in the closure and, when the response arrives, only render if it still matches the latest, otherwise drop it.
3. In React, a cleanup function that sets an ignore flag on effect re-run does the same thing.

I'd use cancellation and the stale-guard together, cancellation frees the network, the guard is the correctness backstop.

Yes. 'Non-blocking' refers to I/O, not CPU. The event loop drains the entire microtask queue before it renders a frame or handles the next task. So a chain of microtasks that keeps scheduling more microtasks, e.g. a recursive Promise.resolve().then(...) or a tight await loop over synchronous work, never lets the loop reach rendering or input. The tab is fully responsive in principle but visually frozen: this is microtask starvation.

The fixes: break heavy work into macrotasks (setTimeout(…, 0), MessageChannel, or scheduler.postTask) so the loop can render between chunks; use requestIdleCallback/requestAnimationFrame to cooperate with the frame; or move the CPU work to a Web Worker entirely. The general principle: keep any synchronous slice under a few milliseconds and yield the thread between slices.

Confirm and locate first. Take heap snapshots in DevTools Memory tab over time; a growing retained size and rising detached-DOM-node count point to a leak. Compare snapshots to see which constructor is accumulating, and use 'retainers' to find what's holding the objects alive.

Common culprits in SPAs:

• Listeners/subscriptions not removed on unmount, the single most common one. Every addEventListener, interval, observer, or store subscription needs teardown.
• Detached DOM nodes kept alive by a JS reference (a closure or array still pointing at a removed node).
• Unbounded caches / arrays that only ever grow.
• Closures pinning large objects longer than needed.

Fixes: pair every subscription with an unsubscribe (React cleanup, AbortController for listeners via signal), bound caches (LRU), and use `WeakMap`/`WeakSet` for metadata keyed by objects so entries are collected when the key object dies. Then re-snapshot to prove the growth is gone.

XSS is executing attacker-controlled script in a user's session, stealing tokens, acting as them. It happens when untrusted data reaches an HTML/JS sink: innerHTML, dangerouslySetInnerHTML, document.write, unsanitised URLs (javascript:), or injecting into inline event handlers.

Defence in depth:

• Contextual output encoding, treat data as data. Frameworks like React auto-escape text by default; the danger is opting out (dangerouslySetInnerHTML).
• Sanitize any HTML you must render with a vetted library (DOMPurify), never a hand-rolled regex.
• Content Security Policy as a second wall, disallow inline scripts and restrict script origins, so even an injection struggles to execute. Use nonces/hashes.
• `HttpOnly`, `Secure`, `SameSite` cookies so a successful XSS still can't read the session token from JS.
• Validate/normalise URLs before using them in href/src.
• Guard against prototype pollution and untrusted JSON/template inputs; keep dependencies patched (supply-chain).

The framing that lands: no single control is enough, encode by default, sanitize what must be HTML, and let CSP + cookie flags contain the blast radius.

It's a signal because a11y forces you to understand semantics and interaction states, not just visual layout, juniors style a div to look like a button; seniors reach for the right element and know the keyboard and screen-reader contract.

For a modal: use <dialog> or a container with role="dialog" + aria-modal, move focus into it on open and trap focus within it, restore focus to the trigger on close, close on Escape, and mark the rest of the page inert so the screen-reader and Tab don't wander out. For a combobox: the WAI-ARIA Authoring Practices pattern, role="combobox", aria-expanded, aria-controls, arrow-key navigation with aria-activedescendant, and announcing result counts via a polite live region.

The senior instincts: start from semantic HTML (it gives you keyboard and roles for free), only reach for ARIA to fill genuine gaps ('no ARIA is better than bad ARIA'), test with keyboard-only and a screen reader, and respect prefers-reduced-motion. It's a product-quality signal, not a checkbox.

I start by separating kinds of state, because they want different tools:

• Server cache state (data from APIs), the bulk of most apps. This belongs in a data-fetching cache (React Query/SWR): it handles caching, revalidation, dedup, and staleness far better than hand-rolled global state. Conflating server data with UI state is the most common architectural mistake.
• Global UI/client state (theme, auth session, cross-cutting flags), a lightweight store (Zustand/Redux Toolkit/Context) sized to actual sharing needs.
• Local component state, keep it local; don't hoist to global 'just in case'.
• URL state (filters, tabs, pagination), the URL is shared, linkable state; put it there.

Trade-offs to name: a single global store is simple but couples teams and re-renders; too many small stores fragment and duplicate; Context re-renders all consumers on any change, so it's for low-frequency values. For multi-team scale I'd emphasise clear ownership boundaries (feature-scoped stores), a normalised server cache, and avoiding a giant shared blob everyone mutates. The decision framework matters more than the library.

API design principles: make the common case a one-liner and the complex case possible; prefer a small, orthogonal surface over many overlapping options; design for the call site (how it reads where it's used), not the implementation; sensible defaults so most users configure nothing; and fail loudly with clear errors. For components: controlled/uncontrolled done right, composition over a giant props bag, and accessibility baked in, not bolted on.

Evolution without breakage: treat the public surface as a contract under semver. Add, don't mutate, new optional params and new components are non-breaking; changing behaviour or removing anything is a major. Deprecate before removing: mark it, warn in dev, document the migration, and give a window (and ideally a codemod). Keep internal APIs clearly separated from public ones so you can refactor freely. Version the docs, and treat a breaking change as an org-wide event with a migration guide, the cost is other teams' time, so the bar is high.

This is a judgment question, they're screening for whether you optimise for the system and the team, not for novelty. A strong answer has a shape:

1. The context and constraints, team size and experience, timeline, the actual scale (not imagined scale), maintenance reality.
2. The options and their real costs, including the seductive one you didn't pick, and why its costs (learning curve, operational burden, lock-in, complexity budget) outweighed its benefits here.
3. The decision and the trade-off you knowingly accepted, 'I chose the boring, well-understood option; I traded some raw performance/elegance for reliability and a team that can maintain it at 2am.'
4. How it played out, and what you'd revisit if constraints changed.

The meta-signal interviewers want: you have a framework for 'it depends', you can name what it depends on (scale, team, reversibility, blast radius) rather than defaulting to the shiniest tool. Principal engineers are hired for judgment, and boring-on-purpose is often the senior move.