Question 1

What is the difference between synchronous and asynchronous code in JavaScript?

Accepted Answer

Synchronous code runs to completion on the call stack uninterrupted; asynchronous operations schedule work to continue later via the event loop without blocking the whole process (ideally). JS runs on a single main thread with a call stack. Long synchronous work blocks UI/events. Async APIs (timers, fetch, FS in Node) start work and register callbacks/promises that run later as tasks/microtasks. Async does not mean parallel CPU by itself — it means non-blocking scheduling. CPU-heavy work still needs workers/processes. Understanding this distinction prevents freezing the main thread and clarifies why await yields back to the event loop.

Question 2

What is callback hell, and how did Promises/async-await address it?

Accepted Answer

Deeply nested callbacks for sequential async flow become unreadable and hard to error-handle; Promises flatten chains and async/await restores linear style. Callback-based APIs nest success handlers, often duplicating error-first checks (err, data). Promises represent future values with .then/.catch composition, enabling flatter control flow and centralized error handling. async/await is syntactic sugar over promises that lets you write asynchronous steps that look synchronous while still yielding between awaits. You still need to understand concurrency (Promise.all) vs sequencing. Modern APIs prefer promises; wrap callbacks with new Promise when needed.

Question 3

How does async/await work under the hood?

Accepted Answer

An async function always returns a Promise; await pauses the function's progress until the awaited promise settles, then resumes with the value or throws. async function wraps the return value in a resolved promise (or rejects if you throw). await desugars roughly to promise .then continuation of the rest of the function (similar to a state machine). While awaiting, the call stack unwinds so the event loop can run other work. Errors from awaited rejections become throw-able in try/catch. await on non-promises wraps them via Promise.resolve. Top-level await exists in modules. Avoid awaiting in serial loops when parallelism is safe.

Question 4

How do you run async operations in parallel vs sequentially with async/await? What are the trade-offs?

Accepted Answer

Sequential: await one after another. Parallel: start promises first, then await Promise.all. Parallel is faster but uses more resources and fails differently. Sequential awaits are correct when each step depends on the previous. If independent, kicking off all promises before awaiting overlaps latency. Promise.all fails fast on first rejection; allSettled waits for all; race/any pick first settle/fulfill. Parallelism can overwhelm APIs — use pools/limits. In UI, parallel requests improve TTI but need cancellation (AbortController) on navigation. Always measure and respect rate limits.

Question 5

How do you cancel in-flight async work in the browser, and what cannot be cancelled?

Accepted Answer

Use AbortController/AbortSignal with fetch and many APIs; pure JS promises cannot be forcibly cancelled mid-executor once running. Create a controller, pass signal to fetch, and call abort() on navigation/unmount. Listen for abort events for cleanup. Libraries should accept signals. Note: aborting rejects fetch with AbortError — handle without treating as a hard failure in UI. Timers can be cleared; WebSocket/streams have their own close. A raw new Promise(executor) keeps running unless the executor cooperatively checks a signal. Design APIs to be cancellation-aware from day one in SPAs.

Question 6

Describe a race condition in async UI data loading and how you would fix it.

Accepted Answer

A slower earlier request can overwrite newer results; fix with ignore flags, abort, request IDs, or reducers that drop stale responses. Example: user types quickly; request for 'ap' returns after 'apple' and paints stale data. Fixes: increment a request generation token and ignore outdated responses; abort previous fetch; debounce input; use libraries with built-in race handling. At architecture level, centralize async state machines (idle/loading/success/error) and make updates idempotent. Tests should simulate out-of-order resolution. This is a common senior frontend interview scenario.

Question 7

Design resilience for a JS client that depends on flaky upstream APIs (timeouts, retries, backoff, idempotency).

Accepted Answer

Combine timeouts, bounded exponential backoff with jitter, idempotency keys for safe retries, circuit breaking, and clear user-facing degradation. Specify per-request timeouts (AbortController). Retry only idempotent/safe operations or those with idempotency keys. Use exponential backoff + jitter to avoid thundering herds. Circuit breakers stop hammering a failing dependency; bulkheads isolate critical flows. Surface partial UI with stale-while-revalidate where acceptable. Centralize HTTP policy in one client (not ad-hoc per call). Observe with metrics (success rate, p95 latency, retry counts). Document which errors are retryable. At lead level, align with backend SLAs and rate limits, and decide UX for offline/queueing.

Async JavaScript JavaScript Interview Questions

Other JavaScript interview topics