Question 1

What is the JavaScript event loop?

Accepted Answer

The event loop coordinates the call stack, task queues, and microtask queue so async callbacks run after synchronous code finishes. While the call stack is empty, the event loop takes the next task (macrotask) from the appropriate queue and runs it to completion. Between tasks (and after each task), it drains the microtask queue (promise jobs, queueMicrotask, MutationObserver). Browser and Node have similar conceptual models with host-specific task sources (UI events, timers, I/O). The event loop enables concurrency on a single thread without running JS in parallel on the main thread.

Question 2

What is the difference between microtasks and macrotasks?

Accepted Answer

Macrotasks include timers, I/O, UI events; microtasks include promise reactions and queueMicrotask. Microtasks run before the next macrotask and after the current call stack clears. After a script/task finishes, the engine processes all pending microtasks before rendering or the next timer task. That is why Promise.resolve().then(...) runs before setTimeout(fn, 0). Continuous microtask scheduling can starve rendering and timers. Node also has process.nextTick (runs before promise microtasks in Node's model). Knowing the ordering is essential for predicting output questions and avoiding UI jank.

Question 3

Predict the output order:

Accepted Answer

A, E, C, B, D. Synchronous logs: A then E. The promise microtask runs next: C, and schedules timeout D. Then the timer task queue runs B (scheduled first), then D. All microtasks from the script complete before any timer callbacks. This tests understanding of sync → microtasks → macrotasks and that microtasks can enqueue more macrotasks.

Question 4

How does browser rendering relate to the event loop?

Accepted Answer

Browsers typically aim to render between tasks; long tasks and microtask floods delay paint, input, and style/layout work. A frame budget (~16ms at 60Hz) must cover JS, style, layout, paint, and composite. The event loop may yield for rendering after a task if it's time to paint (implementation details vary). requestAnimationFrame callbacks run before the next paint. Endless microtasks defer rendering. Long synchronous JS is a long task that blocks input. Performance tools (Long Tasks API, Performance panel) help find blockers. Scheduling work with scheduler.postTask, idle callbacks, or chunking helps keep interaction responsive.

Question 5

How can promise microtasks starve the event loop, and how do you fix it?

Accepted Answer

A chain that continually queues new microtasks never reaches the next macrotask/render; break work into macrotasks or use schedulers/idle time. Example: a recursive Promise.resolve().then(processNext) draining a huge queue will keep the microtask queue non-empty, delaying timers and paint. Fix by batching N items per turn, then setTimeout(0)/postMessage/scheduler.postTask to yield. Similarly, huge sync loops block entirely. Prefer streaming/chunking algorithms. In Node, be aware of nextTick loops as well. Diagnose with frozen UI and delayed timeouts despite 'async' code.

Question 6

How does Node.js's event loop model differ from the browser's?

Accepted Answer

Node uses a phased loop (timers, pending, poll, check, close) with nextTick and microtasks; browsers focus on tasks, microtasks, and rendering. Node's libuv-driven loop has phases: timers (setTimeout/setInterval), pending callbacks, idle/prepare, poll (I/O), check (setImmediate), close callbacks. process.nextTick queues run after the current operation before other microtasks in Node's historically specific ordering (promise thenables interact carefully). Browsers don't expose setImmediate (historically) and prioritize rendering/input. Both share the microtask concept for promises. When writing isomorphic code, avoid relying on Node-only ordering. Workers exist in both environments with their own loops.

Question 7

As a lead, how would you set a scheduling strategy for expensive client-side work (hydration, search indexing, analytics) without harming INP?

Accepted Answer

Prioritize user input, chunk work, use priority schedulers/idle time, defer non-critical tasks, and budget long tasks with measurement gates in CI. Define task priorities: blocking (input handlers), high (visible UI updates), low (analytics, prefetch). Use scheduler.postTask / requestIdleCallback (with timeouts) / worker offloading for CPU-heavy jobs. Chunk hydration and list rendering. Abort low-priority work on route change. Establish Long Task and INP budgets in RUM; fail CI on regressions for critical paths. Educate teams that microtask-heavy libraries need yielding. Prefer web workers for parse/index; keep main thread for DOM. Document which features may degrade under load.

Event Loop JavaScript Interview Questions

Other JavaScript interview topics