6 Advanced JavaScript Questions That Separate Seniors from Mid-Levels

Vitaly Obolensky — Sat, 30 May 2026 18:42:14 +0000

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:

createIncrement() is invoked → new lexical environment created:
- count = 0 (mutable binding)
- message = "Count is 0" (primitive string, interpolated immediately at assignment)
Inner functions increment and log are defined. Both close over the same lexical environment.
increment() is called twice:
- count mutates: 0 → 1 → 2 ✓
- This works as expected.
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

Concept	Why it matters
Template literal evaluation timing	They run at assignment, not at access
Primitive vs reference types	Primitives are copied by value; objects/arrays are referenced
Closure capture semantics	Closures close over bindings, but the value of a primitive is immutable once assigned
Mental model of "live" variables	Not all variables in a closure are "live views" — only the bindings themselves are

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

Concept	Why it matters
Implicit `this` binding	Regular functions lose context when called without an explicit receiver
Lexical `this` capture	Arrow functions inherit `this` from their parent scope
Strict vs non-strict mode	Changes fallback behavior (`undefined` vs global object)
Mental model of execution context	`this` is dynamic for regular functions, static for arrows

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.

JavaScript reads child.coins. It is not found on child, so the engine walks the prototype chain to grandparent and reads 100.
It adds 50 → 150.
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.

JavaScript reads child.heritage, finds the array on grandparent, and keeps a reference to that same array in the heap.
.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

Concept	Why it matters
Prototype property lookup	Reads fall through the chain until a property is found
Assignment vs mutation	`+=` writes locally; `.push()` mutates a shared reference
Own vs inherited properties	`hasOwnProperty` and debugging surprises depend on this distinction
Reference types on prototypes	Shared mutable state on a prototype affects all descendants

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

Mistake	Why it's wrong
Thinking `5 + [1]` equals `6`	`[1]` is not a number; it's coerced to `"1"`
Thinking `!"0"` equals `true`	Only `""`, `0`, `null`, `undefined`, `NaN` are falsy. `"0"` is a non-empty string → truthy
Assuming right-to-left evaluation	`+` is strictly left-associative in JS

🎯 What this question tests

Concept	Why it matters
Operator precedence table	Determines evaluation order before execution begins
`ToPrimitive` & `ToString` algorithms	How objects/arrays convert in mixed-type expressions
Left-to-right associativity	Critical for chaining `+` operations with side effects or type shifts
Falsy/truthy rules	Essential for `!`, `&&`, `

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

🧠 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

Concept	Why it matters
Promise executor timing	Runs synchronously during construction, not asynchronously
Microtask vs macrotask priority	Microtasks always clear before the next macrotask runs
Nested async scheduling	New tasks are appended to the back of their respective queues
Event loop phases	Critical for debugging race conditions, UI freezes, and API batching

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

🧠 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]

How to Actually Measure Your Programming Level (Without Tutorial Hell)

Vitaly Obolensky — Sat, 18 Apr 2026 11:00:13 +0000

We all know the feeling: you watch a course, build a small project, and still aren't sure if you're "ready" for a junior role or a real codebase.

Imposter syndrome isn't always about skill. Often, it's about lack of measurable feedback.

Let's talk about why traditional learning leaves us guessing, and how structured testing + peer benchmarking can change that.

📉 Why "I know it" isn't the same as "I can prove it"**

Passive learning (tutorials, docs, videos) creates an illusion of competence. You recognize the syntax, so your brain says "got it". But recognition ≠ recall.

Cognitive science calls this the fluency illusion. The fix? Active recall + spaced repetition. In programming, that means:

Answering targeted questions under mild time pressure
Explaining why the wrong options are wrong
Tracking progress over weeks, not hours

🧩 Why multiple-choice (4 options) isn't "just guessing"

Many devs dismiss MCQs as "quiz trash". But in skill assessment, they're a powerful tool when designed right:

Distractors matter – good wrong answers expose specific misconceptions (e.g., confusing let vs var, or sync vs async behavior).
Speed + accuracy = real-world proxy – interviews and debugging both reward quick pattern recognition.
Benchmarking – comparing your score to the community average removes ego and shows where you actually stand.

It's not about memorizing answers. It's about stress-testing your mental models.

📊 The missing piece: peer comparison

Studying alone keeps you in a bubble. You might score 8/10 and think "I'm solid", until you see the average is 9.4 and the top 10% finish in half the time.

Healthy benchmarking:

Shows skill gaps you didn't know existed
Motivates consistent practice without burnout
Turns vague "I need to get better" into specific "I'm weak on event loop edge cases"

🔧 I built a lightweight tool to try this

While researching learning methods, I put together a small platform focused on practice vs testing modes, 4-option questions, and anonymous community benchmarking.

It's not another LeetCode clone. It's built for quick daily check-ins, tracking weak spots, and seeing how your answers compare to other developers' averages.

👉 Try it here: skillhacker.io
(Full disclosure: I'm the author. It's in early stages, so feedback is highly appreciated.)

📌 How to start measuring your level today

Pick 1 topic you "kind of know"
Take a 10-question set in test mode
Review every wrong answer + read why distractors are wrong
Repeat in practice mode without time pressure
Compare your score to the community average

Rinse. Repeat weekly. Watch the imposter syndrome shrink.

What's your go-to method for validating your skills? Drop it in the comments 👇

DEV Community: Vitaly Obolensky

6 Advanced JavaScript Questions That Separate Seniors from Mid-Levels

1. Stale closure & primitive capture

✅ Output

🧠 Explanation

🔑 Core Concept

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

🎯 What this question tests

2. JavaScript context trap: losing this

✅ Output

🧠 Explanation

1. Method call: greet()

2. Regular function: innerNormal()

3. Arrow function: innerArrow()

🔑 Core Concept

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

🎯 What this question tests

3. Illusion of an "own" property on mutation

✅ Output

🧠 Explanation

For coins

For heritage

🔑 Core Concept

🛠 How to avoid accidental prototype mutation

🎯 What this question tests

4. JavaScript coercion & precedence trap

✅ Output

🧠 Explanation

Step 1: Unary operators (highest precedence)

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

Step 3: Second + & final coercion

🔑 Core Concept

🛠 Common pitfalls to avoid

🎯 What this question tests

5. JavaScript event loop & queue priority trap

✅ Output

🧠 Explanation

Step 1: Synchronous execution (call stack)

Step 2: Microtask queue (priority over macrotasks)

Step 3: Macrotask queue (first cycle)

Step 4: Microtask queue (again)

Step 5: Macrotask queue (second cycle)

🔑 Core Concept

🎯 What this question tests

6. Microtask order: async/await vs promise chains

✅ Output

🧠 Explanation

Step 1: Synchronous phase

Step 2: Microtask queue processing (FIFO order)

🔑 Core Concept

How to Actually Measure Your Programming Level (Without Tutorial Hell)

📉 Why "I know it" isn't the same as "I can prove it"**

🧩 Why multiple-choice (4 options) isn't "just guessing"

📊 The missing piece: peer comparison

🔧 I built a lightweight tool to try this

📌 How to start measuring your level today

2. JavaScript context trap: losing `this`

1. Method call: `greet()`

2. Regular function: `innerNormal()`

3. Arrow function: `innerArrow()`

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

For `coins`

For `heritage`

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

Step 3: Second `+` & final coercion

6. Microtask order: `async/await` vs promise chains