6 Advanced JavaScript Questions That Separate Seniors from Mid-Levels

1. Stale closure & primitive capture

What is the output of the following code?

function createIncrement() {
  let count = 0;
  const message = `Count is ${count}`;

  function increment() {
    count++;
  }

  function log() {
    console.log(message);
  }

  return { increment, log };
}

const { increment, log } = createIncrement();
increment();
increment();
log();

Test your understanding of closures, lexical scope, and primitive value capture.

✅ Output

Count is 0

🧠 Explanation

This is a classic stale closure trap — but not in the way most developers expect.

Step-by-step execution:

1. createIncrement() is invoked → new lexical environment created:
   • count = 0 (mutable binding)
   • message = "Count is 0" (primitive string, interpolated immediately at assignment)
2. Inner functions increment and log are defined. Both close over the same lexical environment.
3. increment() is called twice:
   • count mutates: 0 → 1 → 2 ✓
   • This works as expected.
4. log() is called:
   • It references the variable message
   • message still holds the original string value "Count is 0"
   • The template literal was evaluated once, at the moment of assignment — not re-evaluated when log() runs.

🔑 Core Concept

> Closures capture variables, not expressions.
> But if a variable holds a primitive value (string, number, boolean), that value is fixed at assignment time.

message is not a live reference to count. It is a snapshot.

🛠 How to fix it (if dynamic output is desired)

Re-evaluate the template literal inside log():

function log() {
  console.log(`Count is ${count}`);
}

🎯 What this question tests

2. JavaScript context trap: losing this

What will this code output when user.greet() is called?

const user = {
  name: "Alex",
  greet() {
    console.log(`Hello, ${this.name}!`);

    const innerNormal = function () {
      console.log(`Normal: ${this.name}`);
    };

    const innerArrow = () => {
      console.log(`Arrow: ${this.name}`);
    };

    innerNormal();
    innerArrow();
  },
};

user.greet();

Test your understanding of execution context, function invocation patterns, and arrow function lexical binding.

✅ Output

Hello, Alex!
Normal: undefined
Arrow: Alex

🧠 Explanation

This question tests three different ways this is resolved in JavaScript:

1. Method call: greet()

• Called as user.greet()
• this is bound to the object preceding the dot → user
• Output: Hello, Alex!

2. Regular function: innerNormal()

• Called as a standalone function: innerNormal()
• No object precedes the call. In strict mode (default in modern JS/modules), this is undefined. In non-strict browser environments, it falls back to window.
• undefined.name evaluates to undefined (or window.name which is typically "")
• Output: Normal: undefined

3. Arrow function: innerArrow()

• Arrow functions do not have their own this binding
• They capture this lexically from the enclosing execution context at definition time
• The enclosing context is greet(), where this === user
• Output: Arrow: Alex

🔑 Core Concept

> Regular functions resolve this at call time (dynamic binding).
> Arrow functions capture this at definition time (lexical binding).

🛠 How to fix innerNormal if you want it to see user

// Option 1: Explicit binding at call time
innerNormal.call(this);

// Option 2: Explicit binding at definition time
const innerNormal = function () {
  console.log(this.name);
}.bind(this);

// Option 3: Lexical capture via closure (older pattern)
const self = this;
const innerNormal = function () {
  console.log(self.name);
};

🎯 What this question tests

3. Illusion of an "own" property on mutation

What will the code log to the console at the end?

const grandparent = {
  heritage: ["gold", "land"],
  coins: 100,
};

const parent = Object.create(grandparent);
const child = Object.create(parent);

child.coins += 50;
child.heritage.push("debts");

console.log(grandparent.coins); // (1) ?
console.log(grandparent.heritage); // (2) ?
console.log(child.coins); // (3) ?
console.log(child.heritage); // (4) ?

Test your understanding of the difference between reading a property from the prototype chain and writing a property on an object.

✅ Output

100
["gold", "land", "debts"]
150
["gold", "land", "debts"]

🧠 Explanation

This is the mental trap:

For coins

The expression child.coins += 50 desugars to child.coins = child.coins + 50.

1. JavaScript reads child.coins. It is not found on child, so the engine walks the prototype chain to grandparent and reads 100.
2. It adds 50 → 150.
3. It writes the result to child.coins.

Writes always land on the object that received the assignment. child gets its own coins: 150, while grandparent.coins stays 100.

For heritage

The expression child.heritage.push("debts") does not assign to heritage.

1. JavaScript reads child.heritage, finds the array on grandparent, and keeps a reference to that same array in the heap.
2. .push("debts") mutates that shared array.

child never gets an own heritage property — it still resolves to the grandparent's array, which now includes "debts".

🔑 Core Concept

> Read vs write behave differently on the prototype chain.
> Assignment creates (or updates) an own property on the target object.
> Mutating a referenced object affects the shared value visible to every object in the chain that points to it.

🛠 How to avoid accidental prototype mutation

// Option 1: Assign a new array instead of mutating the inherited one
child.heritage = [...child.heritage, "debts"];

// Option 2: Copy mutable values when creating the child
const child = Object.create(parent);
Object.assign(child, {
  coins: grandparent.coins,
  heritage: [...grandparent.heritage],
});
child.coins += 50;
child.heritage.push("debts"); // now only child's copy is affected

🎯 What this question tests

4. JavaScript coercion & precedence trap

What will this code output?

console.log(+"5" + [1] + !"0");

Test your understanding of operator precedence, implicit type conversion, and left-to-right evaluation.

✅ Output

"51false"

🧠 Explanation

This expression combines unary operators, object-to-primitive coercion, and left-to-right associativity. Here's the exact execution flow:

Step 1: Unary operators (highest precedence)

Unary + and ! are evaluated before binary +.

• +"5" → ToNumber conversion → 5
• !"0" → "0" is truthy → !true → false
• Expression becomes: 5 + [1] + false

Step 2: Left-to-right evaluation & first +

Binary + is left-associative. It evaluates 5 + [1] first.

• One operand is a Number, the other is an Object.
• JS invokes ToPrimitive([1]) → calls Array.toString() → "1"
• Since one operand is now a string, + switches to string concatenation
• "5" + "1" → "51"
• Expression becomes: "51" + false

Step 3: Second + & final coercion

• "51" (string) + false (boolean)
• Boolean false is coerced to string → "false"
• Concatenation: "51" + "false" → "51false"

🔑 Core Concept

> Precedence decides what runs first.
> Associativity decides direction (left → right for +).
> Coercion decides how types interact when mismatched.

The + operator is unique in JS: it performs both addition and concatenation. If either operand becomes a string during ToPrimitive, the entire operation switches to string concatenation.

🛠 Common pitfalls to avoid

🎯 What this question tests

5. JavaScript event loop & queue priority trap

In what order will the numbers be printed to the console?

console.log("1");

setTimeout(() => {
  console.log("2");
  Promise.resolve().then(() => {
    console.log("3");
  });
}, 0);

new Promise((resolve) => {
  console.log("4");
  resolve();
}).then(() => {
  console.log("5");
  setTimeout(() => {
    console.log("6");
  }, 0);
});

console.log("7");

Test your understanding of the call stack, microtask queue, and macrotask queue execution order.

✅ Output

1
4
7
5
2
3
6

🧠 Explanation

This question tests the exact execution order defined by the JavaScript event loop.

Step 1: Synchronous execution (call stack)

• console.log("1") runs immediately → outputs 1
• setTimeout schedules its callback as a macrotask and exits
• new Promise executor runs synchronously → console.log("4") outputs 4. resolve() is called
• .then() schedules its callback as a microtask
• console.log("7") runs immediately → outputs 7
• Call stack is now empty

Step 2: Microtask queue (priority over macrotasks)

• The event loop checks the microtask queue before picking the next macrotask
• Microtask 1 runs: console.log("5") → outputs 5
• Inside it, setTimeout schedules a new callback as macrotask 2 (appended to the macrotask queue)
• Microtask queue is now empty

Step 3: Macrotask queue (first cycle)

• Event loop picks macrotask 1 (the first setTimeout)
• console.log("2") → outputs 2
• Promise.resolve().then(...) schedules microtask 2

Step 4: Microtask queue (again)

• Before moving to the next macrotask, the event loop must completely drain the microtask queue
• Microtask 2 runs: console.log("3") → outputs 3
• Microtask queue is empty

Step 5: Macrotask queue (second cycle)

• Event loop picks macrotask 2 (the second setTimeout)
• console.log("6") → outputs 6

🔑 Core Concept

> Execution order: synchronous code → microtasks (Promise, queueMicrotask) → macrotasks (setTimeout, setInterval, I/O) → repeat.
>
> Every time a macrotask finishes, the event loop must completely drain the microtask queue before proceeding to the next macrotask. Nested microtasks created during a macrotask will delay the next macrotask.

🎯 What this question tests

6. Microtask order: async/await vs promise chains

In what exact order will the logs be printed to the console?

async function asyncFunc() {
  console.log("2");
  await Promise.resolve();
  console.log("3");
}

console.log("1");
asyncFunc();

Promise.resolve()
  .then(() => {
    console.log("4");
  })
  .then(() => {
    console.log("5");
  });

console.log("6");

Test your understanding of how await is compiled under the hood and its exact scheduling priority compared to .then().

✅ Output

1
2
6
3
4
5

🧠 Explanation

This question reveals exactly how async/await is translated into promise chains and how the event loop schedules continuations.

Step 1: Synchronous phase

• console.log("1") executes → outputs 1
• asyncFunc() is invoked. Code runs synchronously until the first await
• console.log("2") executes → outputs 2
• await Promise.resolve() is encountered. The expression on the right evaluates to an already-resolved promise. The engine wraps the remaining function body (console.log("3")) in a microtask and suspends execution. This microtask is queued
• Control returns to the global scope
• Promise.resolve().then(...) registers a callback. This creates microtask 2 (logs 4). The chained .then (logs 5) is not queued yet; it waits for microtask 2 to resolve
• console.log("6") executes → outputs 6
• Call stack is empty. Event loop switches to the microtask queue

Step 2: Microtask queue processing (FIFO order)

• Microtask 1 (from await continuation): runs console.log("3") → outputs 3
• Microtask 2 (from first .then): runs console.log("4") → outputs 4. Its resolution immediately queues the next .then callback as microtask 3
• Microtask 3 (from chained .then): runs console.log("5") → outputs 5
• Microtask queue is empty

🔑 Core Concept

await is syntactic sugar for .then().
The code after await is compiled into a .then() callback and scheduled as a microtask.
Microtasks are processed in strict FIFO order based on when they were registered during synchronous execution.

Want more? I’m maintaining a curated repository with tricky JS questions and edge cases. Check the full list here: [https://github.com/Skillhacker-io/javascript-interview-questions/blob/main/questions/top-javascript-questions.md]