Question 1

Compare the Fetch API with XMLHttpRequest. When might XHR still appear?

Accepted Answer

Fetch is promise-based, streaming-friendly, and modern; XHR is older callback/event based. Legacy code and some progress-upload cases still use XHR. Fetch uses promises, supports AbortController, and integrates with streams. It does not reject on HTTP error statuses (only network failures) — you must check res.ok. XHR provides upload progress events historically harder with fetch (though modern streams/progress patterns evolve). Cookies/credentials differ by defaults (credentials option). Prefer fetch in new code; know XHR for maintenance interviews.

Question 2

Compare localStorage, sessionStorage, and IndexedDB for client-side persistence.

Accepted Answer

localStorage persists string key-values; sessionStorage lasts per tab session; IndexedDB stores larger structured data asynchronously. Web Storage is synchronous, string-only, ~5MB-ish (varies), and blocks the main thread on large reads/writes. sessionStorage is isolated per tab. IndexedDB is async, transactional, supports indexes and larger quotas — better for offline apps. Alternatives: Cache API for Request/Response, cookies for small server-sent state (with security caveats). Never store secrets in Web Storage on XSS-prone apps. Prefer structured cloning in IDB over JSON.stringify trees when appropriate.

Question 3

What problem does Intersection Observer solve, and how would you use it?

Accepted Answer

It asynchronously notifies when elements enter/leave a viewport (or root), enabling lazy loading and infinite scroll without scroll listener jank. Scroll listeners that call getBoundingClientRect force layout frequently. IntersectionObserver runs off the main-thread-friendly observation path and delivers callbacks when thresholds cross. Use for image lazy-loading, infinite lists, ad viewability, and animation triggers. Remember to unobserve/disconnect on teardown. Root margins and thresholds tune prefetch distance. Pair with loading="lazy" where sufficient.

Question 4

When should you use Web Workers, and what are their limitations?

Accepted Answer

Use workers for CPU-heavy JS off the main thread; they can't touch the DOM and communicate via messaging/structured clone or SharedArrayBuffer. Workers have their own event loop and global scope. Great for parsing, encryption, image processing, search indexes. Limitations: no DOM access, data copy costs (unless transferable/SAB with care), debugging complexity, and duplicate module memory. Dedicated vs shared vs service workers serve different roles — service workers are for network proxying/offline, not general CPU offload. Design clear message protocols and timeouts. Measure whether transfer overhead dominates.

Question 5

How would you choose a service worker caching strategy for an authenticated SPA?

Accepted Answer

Cache static shell aggressively; use network-first or stale-while-revalidate for APIs carefully; never cache sensitive personalized responses without explicit rules. App shell: cache-first for hashed assets. API data: often network-first with fallback, or SWR for non-sensitive feeds. Auth: avoid caching private JSON in shared caches; respect Cache-Control; prefer session-bound strategies; beware multi-user browsers. Version caches and purge on activate. Handle updates (skipWaiting trade-offs) so users aren't stuck on old clients. Coordinate with backend ETags. Provide offline UX messaging. Lead discussion includes threat model (XSS reading cache), storage quotas, and rollback.

Browser APIs JavaScript Interview Questions

Other JavaScript interview topics