Lesson 9 of 80

async / await

Q: Is await blocking? Walk me through exactly what it pauses and what it doesn't.

A strong answer covers: await pauses only the async function it's written in, not the whole runtime; The rest of the page keeps running — other handlers, other async functions; It's sugar over a .then() continuation, resumed as a microtask when the promise settles.

Code that waits for a promise as if it ran straight down the page — but it's promises underneath, not a new kind of concurrency.

13 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

While one async function is paused at an await, what happens to the rest of the page?

It keeps running normally — only this function is pausedThe whole page freezes until the promise settlesA new thread is spawned to keep the page responsive

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on async / await

What interviewers actually ask about this, and what a strong answer has to cover.

Is await blocking? Walk me through exactly what it pauses and what it doesn't.

A strong answer covers

await pauses only the async function it's written in, not the whole runtime
The rest of the page keeps running — other handlers, other async functions
It's sugar over a .then() continuation, resumed as a microtask when the promise settles

Likely follow-ups

So under the hood, what does the line after await actually become?
If two awaited calls don't depend on each other, what's the cost of writing them sequentially — and how would you fix it?
How do you catch a rejection from an awaited call? Why not .catch()?

Practice these with the AI interviewer →

The plain-language idea

async/await is syntax over promises, not a replacement for them. Marking a function async makes it always return a promise. Inside it, await pauses that function at that line until the promise it's waiting on settles — then resumes with the resolved value.

Nothing else on the page waits. await only pauses the function it's written in.

See it in a real thing: the same fetch, two ways

// promise chain
function loadUser(id) {
  return fetch(`/api/users/${id}`)
    .then((res) => res.json())
    .then((user) => user.name);
}

// async/await — same behaviour, reads top to bottom
async function loadUser(id) {
  const res = await fetch(`/api/users/${id}`);
  const user = await res.json();
  return user.name;
}

Both versions do exactly the same thing. The second one just doesn't nest.

async/await: pause and resumeStep 1 of 4

async/await isn't a new mechanism — it's a way to write a promise chain that reads top to bottom.

What people usually miss

Watch out

await blocks the function, not the thread. Other code — other event handlers, other async functions — keeps running while one function is paused at await.
Errors need try/catch, not .catch(). A rejected awaited promise throws inside the async function; wrap it in try { } catch (err) { } to handle it, same as any synchronous throw.
Sequential awaits are sequential in time, too. await a(); await b(); runs b only after a finishes — even if they don't depend on each other. Use Promise.all([a(), b()]) to run independent work in parallel.
async always returns a promise, even if you return a plain value or nothing at all. Forgetting this is a common source of "why is my value [object Promise]" bugs.

Why this matters in interviews

"Is await blocking?" is a trap question — the honest answer is "blocking for this function, not for the runtime," and explaining why (it desugars to a .then() microtask continuation) is what separates someone who's used await from someone who understands it.