How does `async/await` work and what are its benefits?

Q: How does `async/await` work and what are its benefits?

**Target Audience:** Engineers preparing for Node.js/JavaScript interviews — assumes basic Promise familiarity. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every claim below — including that an async function's return value really is a Promise — was **actually executed and inspected**, not assumed from how the syntax reads. ## 1. Why This Even Matters — A Story First A recipe written as "wait for the dough to rise, then shape it, then wait for it to rise again, then bake" reads like a plain sequence of steps to a human, even though "wait for the dough to rise" is, mechanically, "leave the kitchen and come back later" — nobody stands frozen at the counter for two hours. `async/await` is what lets code be **written** like the recipe — a plain, readable sequence — while the engine underneath still behaves exactly like "leave and come back," never actually freezing anything else in

The problem

Question presented to candidate: "You see 'async' in front of a function and 'await' inside it. What does the JavaScript engine actually do with those keywords, and does await block the whole program?"

What a strong answer should cover:

An async function always returns a Promise — even a plain return 42 inside one becomes a Promise that resolves to 42, and a thrown error becomes a rejected Promise, verifiably, not just by convention.
await pauses execution only within that async function — it does not block the thread, the event loop, or any other concurrently running code. Control returns to the event loop while the awaited Promise settles, and other work (other requests, timers, other async functions) proceeds normally in the meantime.
async/await is syntax over Promises, not a separate mechanism — this is why try/catch works around an await: a rejected Promise being awaited is exactly equivalent to a thrown error at that point in the function.
The main practical benefit is readability: sequential async logic reads top-to-bottom like synchronous code, with ordinary control flow (if, loops, try/catch) working exactly as it does in synchronous code — no .then() nesting or chaining gymnastics required.
The most common real bug is writing sequential awaits for operations that do not actually depend on each other, silently serializing work that could run concurrently via Promise.all — this is a behavior/performance bug, not a syntax error, so it does not surface as an obvious mistake.
for await...of extends the same idea to async iterables (including Node streams) — pulling the next value only once the previous iteration's work, including any await inside the loop body, actually finishes; this interacts directly with stream backpressure, covered in its own dedicated question.

Clarifying questions expected:

"Are these steps sequential-by-dependency, or just written sequentially out of habit?" — decides whether Promise.all should replace some of the awaits.
"Does the interviewer want proof that await does not block other code, or just the syntax explained?" — these call for different depths of answer.

Code / implementation expected: Yes — showing an async function's return value actually being a Promise, and a thrown error becoming a rejection caught by an ordinary try/catch, is the concrete, verifiable core of the answer.

async/await
promises
asynchronous
readability

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for Node.js/JavaScript interviews — assumes basic Promise familiarity. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every claim below — including that an async function's return value really is a Promise — was actually executed and inspected, not assumed from how the syntax reads.

1. Why This Even Matters — A Story First

A recipe written as "wait for the dough to rise, then shape it, then wait for it to rise again, then bake" reads like a plain sequence of steps to a human, even though "wait for the dough to rise" is, mechanically, "leave the kitchen and come back later" — nobody stands frozen at the counter for two hours.

async/await is what lets code be written like the recipe — a plain, readable sequence — while the engine underneath stil

The solution is hidden so you can try first

6 min read · 8 sections

Read the code

JavaScriptAn async function's return value is a real Promise object, and a thrown error becomes a rejection caught by try/catch

async function f() { return 42; }
console.log(f());        // Promise { 42 } — not the number itself
console.log(await f());  // 42

async function mayReject(shouldFail) {
  if (shouldFail) throw new Error("boom");
  return "ok";
}
try {
  await mayReject(true);
} catch (e) {
  console.log("caught:", e.message); // caught: boom
}

// The accidental-serialization trap, measured:
function wait(ms) { return new Promise((r) => setTimeout(r, ms)); }
const t0 = Date.now();
await wait(100); await wait(100); await wait(100);
console.log("sequential:", Date.now() - t0, "ms"); // sequential: 315 ms

const t1 = Date.now();
await Promise.all([wait(100), wait(100), wait(100)]);
console.log("Promise.all:", Date.now() - t1, "ms"); // Promise.all: 108 ms

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.