The Closures Question That Actually Gets Asked

From the recruiter team, sombody asks you "explain closures" in an interview, and there's a good chance you freeze for half a second; not because you don't know it, but because you've never had to say it out loud before. That's basically why I sat down and wrote this out for myself first.

The Question That Actually Gets Asked

It's rarely just "what is a closure." It's usually:

"Write a function that returns a counter, where each counter keeps its own count."

That's it. That's the whole test. And it trips people up because they know closures work, but they've never had to build one from scratch, on the spot, while someone watches.

Closures: Not Magic, Just Memory

Here's the thing nobody explains well: a closure isn't a special JavaScript feature. It's just a function that remembers the variables that were around when it was created, even after the outer function has already finished running.

function makeCounter() {
  let count = 0;
  return function () {
    count += 1;
    return count;
  };
}

const counter1 = makeCounter();
const counter2 = makeCounter();

counter1(); // 1
counter1(); // 2
counter2(); // 1 — totally separate `count`

count should be gone once makeCounter() returns. It isn't. The inner function is still holding onto it. That's the whole trick, no magic, just scope that outlived its function.

The Event Loop: Why Order Isn't What You Think

Okay, separate topic, but it always gets asked in the same breath. Here's the question that actually catches people:

console.log("first");

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

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

console.log("fourth");

Guess the order before you scroll. Most people say first, second, third, fourth. It's actually first, fourth, third, second.

Why? Because of setTimeout, even with 0 ms it gets queued as a macrotask, and Promise.then gets queued as a microtask. JS finishes the synchronous code first, then drains all microtasks, and only then moves to the next macrotask.

The Follow-Up That Catches People Off Guard

If they're being thorough, they'll ask: "what if you had two .then() calls?" Both microtasks still run before the setTimeout fires, microtasks always fully drain before the next macrotask gets a turn. That's the actual mental model to hold onto:

Synchronous code first. Then every microtask, until there are none left. Then one macrotask. Repeat.

Quick Recap

• A closure = a function + the scope it remembers, not a special syntax
• The event loop doesn't run things "in order". It runs sync code, then all microtasks, then one macrotask, on repeat
• Promise.then = microtask. setTimeout = macrotask. That one fact answers most of the trick questions
• If you can build the counter example from memory, you can talk through this in an interview without freezing

And honestly, once you've written the counter function once by hand, you stop forgetting it. That's the whole point of doing this instead of just reading about it.