JavaScript Event Loop Interview Questions: Tasks, Microtasks, and Async Traps

Practice JavaScript event loop interview questions on tasks, microtasks, Promises, async/await, rendering, timers, and browser vs Node.js traps.

Author: PracHub

Published: 8/13/2026

JavaScript Event Loop Interview Questions: Tasks, Microtasks, and Async Traps

August 13, 2026

Quick Overview

A practical JavaScript event loop interview guide for frontend engineers. Learn a five-step output-prediction method and work through Promise executors, task vs microtask ordering, async/await continuations, nested microtasks, zero-delay timers, rendering blocks, async forEach, fetch, starvation, and browser vs Node.js differences.

Frontend EngineerFree

You have 30 seconds to predict this output:

console.log("A");

setTimeout(() => console.log("B"), 0);

Promise.resolve().then(() => console.log("C"));

console.log("D");

If your answer is A, D, C, B, the next question is usually harder: why does the Promise callback run first, what changes after an await, and would the same reasoning hold in Node.js?

That is what JavaScript event loop interview questions are really testing. Use PracHub's real Frontend Engineer interview questions and Software Engineering Fundamentals questions to practice current prompts, then use the method below to explain every queue transition instead of guessing the output.

JavaScript event loop interview questions covering tasks microtasks async await and rendering

The reliable mental model tracks what runs now, what is queued, and when the browser can render.

Quick Verdict

For browser JavaScript, start with four rules: synchronous code runs to completion; Promise reactions and queueMicrotask() callbacks are microtasks; the microtask queue drains at a checkpoint before another task; and the browser may render only when JavaScript yields and a rendering opportunity exists.

A strong interview answer sounds like this: "I will trace the current task first, record each callback when it is queued, drain microtasks in insertion order, account for rendering separately, and only then select the next task."

One vocabulary upgrade immediately improves your answer: task is the browser-standard term. "Macrotask" is common teaching shorthand, but the HTML standard defines task queues and task sources, not one universal macrotask queue.

What the Interviewer Is Actually Scoring

SignalStrong evidenceWeak answer
Execution modelSeparates current stack, tasks, microtasks, and renderingSays "async runs later"
PredictionWrites the queue state after every scheduling operationGuesses from memorized output
Promise reasoningDistinguishes synchronous executors from queued reactionsCalls everything involving a Promise asynchronous
Environment awarenessStates whether the code runs in a browser or Node.jsMixes setImmediate, rendering, and browser timers
Production judgmentConnects ordering to UI responsiveness and correctnessStops after naming the queues

The Browser Event Loop Mental Model

During a browser event-loop iteration, the runtime can run a task, perform a microtask checkpoint, and update rendering when appropriate. MDN summarizes the browser cycle as at most one pending JavaScript task, then pending microtasks, then any needed rendering and painting.

A task might begin with initial script execution, a timer callback, or a user event. Promise reactions, queueMicrotask(), and Mutation Observer callbacks use microtasks. At a microtask checkpoint, newly queued microtasks also run before the browser moves on, which is why recursive microtasks can starve later tasks and paint.

WorkTypical sourceInterview implication
Current synchronous workFunction calls and Promise executorsRuns before any queued callback
Microtask.then/.catch/.finally, await continuation, queueMicrotaskDrains before the next task
TaskTimers, user events, posted messages, some platform callbacksRuns after the current task and its microtasks finish
Rendering workStyle, layout, animation frame callbacks, paintNot guaranteed after every task

A Five-Step Method for Predict-the-Output Questions

  1. Name the environment. Browser and Node.js have different host scheduling rules.
  2. Run synchronous code. Include function bodies up to the first suspension point and Promise executors.
  3. Record, do not execute, callbacks. Put Promise reactions in microtasks and timer callbacks in their task source.
  4. Drain the microtask queue. Append any new microtasks and continue until it is empty.
  5. Consider paint, then the next task. Rendering is an opportunity, not an automatic step after every line.

Five step method for solving JavaScript event loop output questions

Write the queue state beside the code. A visible trace is easier to defend than an output guess.

JavaScript Event Loop Interview Questions and Answers

1. Why Does a Promise Beat setTimeout Zero?

console.log("A");
setTimeout(() => console.log("B"), 0);
Promise.resolve().then(() => console.log("C"));
console.log("D");

Output:A, D, C, B. The script runs synchronously, so A and D print first. The fulfilled Promise queues its reaction as a microtask. The timer becomes eligible only after its minimum delay, and its callback runs as a later task.

setTimeout(..., 0) never means "run immediately." The delay is a minimum threshold; the current task, queued microtasks, scheduling, and browser throttling can all make the actual delay longer.

2. Is a Promise Executor Synchronous?

console.log("A");

new Promise((resolve) => {
  console.log("B");
  resolve();
}).then(() => console.log("C"));

console.log("D");

Output:A, B, D, C. The function passed to new Promise() executes immediately during construction. Calling resolve() changes the Promise state and queues the attached reaction; it does not run the .then() callback inline.

This distinction catches candidates who label an entire Promise expression "asynchronous." In an interview, point to the exact boundary: executor now, reaction later.

3. What Exactly Happens at await?

async function run() {
  console.log("B");
  await Promise.resolve();
  console.log("D");
}

console.log("A");
run();
console.log("C");

Output:A, B, C, D. Calling run() begins synchronously, so B prints before control returns. The await suspends the function; its continuation is scheduled through Promise machinery and resumes asynchronously.

MDN describes an async function body as being split at each await, with the later code behaving like a .then() continuation. await does not block the thread, but it does introduce an asynchronous boundary even when the value is already fulfilled.

4. Do Microtasks Run Between Two Timer Callbacks?

setTimeout(() => {
  console.log("timer 1");
  Promise.resolve().then(() => console.log("microtask"));
}, 0);

setTimeout(() => console.log("timer 2"), 0);

Browser output:timer 1, microtask, timer 2. The first timer callback is one task. When it finishes, the browser performs a microtask checkpoint before selecting another task, so the Promise reaction runs before the second timer callback.

A common weak answer says that all ready timers run as a batch. The stronger model places a microtask checkpoint after the current task returns control.

5. How Does a Promise Chain Add Microtasks?

Promise.resolve()
  .then(() => {
    console.log("A");
    queueMicrotask(() => console.log("B"));
  })
  .then(() => console.log("C"));

queueMicrotask(() => console.log("D"));

Output:A, D, B, C. Initially, the first Promise reaction and D are queued. While the first reaction runs, it queues B. Only after that reaction completes does the next link become ready and queue C, so the final queue order is D, B, C.

This is why you should trace individual reactions rather than treat a Promise chain as one callback.

6. Can Microtasks Freeze the UI?

function spin() {
  queueMicrotask(spin);
}

spin();
setTimeout(() => console.log("never reached"), 0);

Do not run this in a production page. Each microtask queues another before the checkpoint can finish. The browser does not reach the next task, and it may not get a rendering opportunity, so input and paint appear frozen.

MDN explicitly warns about recursive microtask starvation. Break large work into bounded chunks and yield through an appropriate task or scheduling API instead of recursively filling the microtask queue.

Eight JavaScript event loop interview traps involving Promises await timers rendering and Node.js

Most wrong answers come from misclassifying one operation or forgetting when control returns to the host.

7. Does Updating the DOM Mean the User Sees It Immediately?

status.textContent = "Loading";

const end = performance.now() + 2000;
while (performance.now() < end) {}

status.textContent = "Done";

Usually the user sees only Done. Both mutations happen inside one long task, and the browser cannot paint the intermediate state while JavaScript still owns the main thread. Replacing the loop with a long chain of microtasks may still block paint because the checkpoint must drain first.

Use requestAnimationFrame() when work must align with a visual update; its callback is requested before the next repaint. Do not claim a universal timer-versus-animation-frame output order because rendering opportunities and timer selection depend on host timing.

8. Why Does await array.forEach(async ...) Finish Too Early?

await items.forEach(async (item) => {
  await save(item);
});

console.log("all saved");

forEach() ignores the Promises returned by its callback and returns undefined. Awaiting that return value does not wait for the saves, so all saved can print while operations are still pending.

Use for...of with await for intentional sequencing, or await Promise.all(items.map(save)) for concurrent work with fail-fast rejection. State which behavior you want before choosing the fix.

9. Is fetch a Task or a Microtask?

The question is deliberately underspecified. Calling fetch() starts host-managed network work and returns a Promise. Once that Promise settles, attached .then() reactions run as microtasks. It is misleading to label the entire network operation as either "a task" or "a microtask."

In output questions, first determine when the response Promise becomes settled. Then place its reactions in the microtask queue at that point. Network completion timing is not determined by source-code order.

10. Is the Browser Event Loop the Same as Node.js?

No. The shared JavaScript concepts include the execution stack and Promise jobs, but the host scheduling model differs. Browsers coordinate tasks with rendering. Node.js uses libuv phases such as timers, poll, check, and close callbacks, and it has Node-specific APIs including process.nextTick() and setImmediate().

Node's official event-loop guide says process.nextTick() is processed after the current operation before the event loop continues, and recursive use can starve I/O. It also warns that top-level setTimeout(0) versus setImmediate() ordering can vary; inside an I/O callback, setImmediate() is the dependable first callback.

Common Event Loop Interview Mistakes

  • Calling every deferred callback asynchronous in the same way. Identify the host operation and the queue used by its callback.
  • Forgetting synchronous Promise executors. Only reactions wait for a later job.
  • Thinking zero-delay timers have priority. Zero is a threshold, not a bypass.
  • Assuming paint follows every task. Rendering happens only when the browser has an opportunity and work to show.
  • Mixing browser and Node rules. State the runtime before predicting environment-specific APIs.

A 5-Day JavaScript Event Loop Practice Plan

DayFocusPractice output
1Tasks, microtasks, and synchronous executionTrace five Promise-versus-timer snippets
2Promise executors and chainsDraw each reaction as a separate microtask
3async/await and iteration trapsRewrite sequential and concurrent examples
4Rendering, long tasks, and starvationExplain why a loading state does not paint
5Browser versus Node.jsAnswer one mixed-runtime mock without assumptions

For the final mock, open PracHub's Frontend Engineer question bank, select a JavaScript prompt, and narrate every synchronous step and queue mutation before revealing the result. Use company-specific interview prep to match the frontend depth of your target loop.

JavaScript Event Loop Interview FAQ

What is the difference between a task and a microtask?

A task starts work such as script execution, a timer callback, or an event callback. After the current task returns control, the browser performs a microtask checkpoint and drains queued Promise reactions and other microtasks before another task. Rendering may occur when the browser has an appropriate opportunity.

Are microtasks always FIFO?

Microtasks are dequeued in the order they enter the microtask queue, but code running inside one microtask can enqueue additional work. Promise-chain reactions may become eligible only after the previous reaction resolves its derived Promise, so write down the exact enqueue moment instead of grouping a chain together.

Does await create a new thread?

No. await suspends progress through the async function and returns control to the caller. When the awaited value settles, the continuation becomes eligible through Promise job processing. The asynchronous operation may involve host or worker threads, but the JavaScript continuation still runs according to the host event loop.

Should I say macrotask in an interview?

You can acknowledge it as common shorthand, then use the more precise browser term task. Explain that the HTML model has task sources and queues rather than one guaranteed global macrotask FIFO. That precision matters when candidates try to infer ordering across unrelated task sources.

Final Takeaway

JavaScript event loop questions become much easier when you stop memorizing outputs. Run synchronous code, mark the exact enqueue point for every callback, drain microtasks to completion, account for rendering separately, and state the host environment before using runtime-specific rules.

Practice with PracHub's real interview questions with written solutions, browse Frontend Engineer interview questions, and use company-specific interview prep to turn the model into an answer you can defend under follow-up pressure.

Sources and Further Reading


Comments (0)