JavaScript Interview Questions

Core concepts

1. Event loop ordering — microtasks before macrotasks; see Event Loop blog. — MDN: The event loop
2. Closures & scope — var vs let, hoisting, TDZ. — MDN: Closures
3. this binding — implicit, explicit, new, arrow lexical this. — MDN: this
4. Prototypes & classes — inheritance vs composition. — javascript.info: Prototypal inheritance
5. Async patterns — Promise.all vs allSettled, race conditions, debounce/throttle. — MDN: Promise.all

Concept videos

YouTube lessons for these topics. On a large screen they open in the reading panel next to the roadmap, same as the article links on each core concept.

• Event loop — Event Loop (Philip Roberts)
• Closures & scope — Closures (Web Dev Simplified)
• Interview set — JavaScript Interview Questions (Web Dev Simplified)

Explanation

Interviews are teaching moments in reverse — interviewers want to hear you predict what code will do and why. These five themes appear again and again because they reveal whether you understand the language, not just frameworks.

Event loop ordering

Draw the stack and queues on a whiteboard. Walk through setTimeout vs Promise.then ordering. Link to real bugs: UI freezes from sync work, stale renders from microtask floods. Interviewers care that you can debug timing, not memorize specs verbatim.

Closures & scope

Explain hoisting with var vs block scope with let. The temporal dead zone is the gap between entering a scope and executing let x. Closure questions often hide loops — fix with let or IIFE. Tell a story about a debounced search box to show practical closure use.

this binding

this is who called the function, except arrows inherit lexical this. Demonstrate call, apply, bind with one object example. React class components vs hooks differ in this — mention briefly if interviewing for frontend roles.

Prototypes & classes

Classes are sugar; prototypes are the mechanism. Prefer composition (mix small objects) over deep inheritance in modern answers. Mention Object.create only if interviewer goes deep.

Async patterns

Compare Promise.all (fail fast) vs allSettled (collect results). Debounce/throttle show you understand user input and performance. Tie async to product behavior: double-submit on payments, race conditions on stale fetch responses.

What Is It?

This chapter collects behavioral JavaScript questions: event loop, this, prototypes, coercion, and async pitfalls.

The goal is to predict runtime output and tie answers to real debugging stories.

Pair each topic with a tiny snippet you can whiteboard in two minutes.

Why Should I Care?

Screening loops still use classic snippets even when day jobs are TypeScript and React.

Explaining tradeoffs (mutability vs immutability, microtasks vs macrotasks) signals seniority.

Real World Analogy

Interview prep is flashcards for behavior, not flashcards for dictionary definitions — you explain what the code does, not what MDN chapter it lives in.

Visual Mental Model

question --> predict output --> explain why --> relate to production

Beginner Explanation

Practice explaining event loop order, closure examples, and prototype lookups out loud. Interviewers care about reasoning steps.

Smallest Possible Example

console.log(typeof NaN); // "number"
console.log(Number.isNaN(NaN)); // true

Common Mistakes

❌ Memorizing answers without running the code.

Engines evolve; your story should come from observed behavior.

❌ Rambling without stating the output first.

Lead with the result, then walk through the mechanism — interviewers track clarity.

❌ Dismissing 'trick' questions entirely.

They often encode real bugs teams hit (coercion, hoisting). Learn the lesson, not the gotcha.

Real Project Example

Frontend loops at Meta, Amazon, and Shopify include live coding in JS even for React roles.

Staff engineers at Netflix still ask async ordering to see if candidates understand their own fetch pipelines.

Build This Mini Project

Pick five questions from this page, record yourself answering in under 90 seconds each, and re-run any snippet you got wrong in Node.

Interview Question

How do you prepare for JavaScript interviews without cramming APIs?

Build a set of tiny programs covering closures, async ordering, and object mutation. For each, practice saying the output, the reason, and one production bug it relates to. That pattern beats memorizing MDN lists.

Key Takeaways

• Predict output before explaining theory.
• Tie answers to bugs you have seen or can imagine.
• Practice out loud with a timer.
• Run code — do not trust memory.

Resources

• 50 React interview questions (JS-heavy)
• MDN JavaScript reference

The 60-second story

An interview is a coffee line where someone asks you to run the shop for five minutes. They do not want a glossary. They want to hear that you have worked a Saturday rush and know which mistakes spill.

Start with the single cook, because half the questions are that story in a tie. One person at the stove. Slow jobs leave tickets. Tiny receipt updates (microtasks, Promises) are handled before the “check back later” tickets (setTimeout). If you can say that order out loud, event-loop questions stop being trivia.

Next they point at a function that still remembers a variable after its outer function returned. That is the backpack. Closures carry variables. var is a backpack with one pocket shared by a whole loop, which is why every button prints the last index. let gives each trip its own pocket. The temporal dead zone is the moment the pocket exists on the form but you are not allowed to reach in yet. Hoisting pulled the name up. It did not fill it early for let.

Then they ask about this. Think of a name tag. A regular function looks at who called it. An arrow function wears the name tag from the room where it was written. call and apply slap a different tag on for one shift. new means “this tag belongs to a fresh object.” If you mix those up, you are not bad at interviews. You are grabbing the wrong name tag.

Prototypes are the house rules in the cabinet, not a copy on every sticky note. Classes are nicer handwriting for the same cabinet. Composition is bringing your own tools instead of inheriting the whole cabinet from a parent who also owns a boat. Prefer composition when the family tree is a lie.

Async questions are about the rush, not about keywords. Promise.all is “wait until every supplier answers, and fail if one truck crashes.” Promise.allSettled is “tell me how each truck did, even if one crashed.” Debounce is “wait until the customer stops tapping the counter.” Throttle is “we will listen, but only once a second.” Race conditions are two cooks grabbing the same last croissant.

Map the interview to the shop.

• Event loop = one cook, two ticket piles.
• Closure = a backpack.
• var in a loop = one shared pocket.
• this = whose name tag.
• Prototype = cabinet rules, shared.
• Promise.all versus allSettled = fail-fast versus full report.
• Debounce versus throttle = wait for quiet versus limit the rate.

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0);
}

With let, you log 0, 1, 2. Each timeout closed over its own i. With var, you log 3, 3, 3. One pocket. That demo has ended more interviews than any definition paragraph.

These questions exist because production bugs cluster here: shared state, wrong this, and async ordering. The feature was not invented for whiteboards. The whiteboard is how we check you have seen the rush.

Mental model: a Saturday shift. If you can narrate the cook, the backpack, the name tag, and the supplier trucks, you can answer the usual JavaScript loop without memorizing a blog’s bullet list.

Say the var loop out loud once before you walk in. Then explain why let fixes it in one sentence. That is the whole page, told as a shift instead of a glossary.