DEV Community: Vitaly Obolensky

12 Tricky TypeScript Questions That Separate Good Developers From Great Ones

Vitaly Obolensky — Tue, 09 Jun 2026 14:40:53 +0000

12 Tricky TypeScript Questions That Separate Good Developers From Great Ones

Short, sharp, and deliberately uncomfortable — 12 senior-level TypeScript questions for developers who think they know TypeScript. Type-level edge cases, compiler quirks, and the gap between "I use TypeScript" and "I understand how the compiler thinks."

Topics covered: Type System, Generics, Functions, Type Guards, Interfaces and Types, Modules.

1. Ambient declaration vs implementation in global scope

Topic: Variables and Declarations · Difficulty: ⭐⭐ Hard

You need a globally accessible constant in a .d.ts-style setup where the same file may be included multiple times. What is the correct TypeScript declaration pattern — and why?

Answer:

declare const introduces an ambient declaration: it asserts that the symbol exists at runtime without emitting JavaScript. That avoids duplicate-definition errors when the file is processed more than once (for example with legacy --outFile or script concatenation).

A plain const would emit code and can cause redeclaration errors. export const creates a module-scoped binding, not a global. Assigning to globalThis is runtime-only and gives you no compile-time type safety or declaration merging.

Ambient declarations are the standard pattern for global constants in declaration files and multi-entrypoint setups.

📖 Ambient Declarations (TypeScript Handbook)

2. Impact of `as const` on literal types

Topic: Type System · Difficulty: ⭐⭐ Hard

What is the type of config after the following declaration?

const config = { apiUrl: 'https://api.example.com', timeout: 5000 } as const;

Answer:

as const converts mutable literal types into their narrowest possible readonly literal types — apiUrl becomes the specific string literal 'https://api.example.com', and timeout becomes the numeric literal 5000.

Result type:

{
  readonly apiUrl: 'https://api.example.com';
  readonly timeout: 5000;
}

This enables exhaustive type checking and prevents unintended mutation. Without as const, TypeScript would widen to { apiUrl: string; timeout: number }.

📖 Const Assertions

3. Rest parameter in overloaded function

Topic: Functions · Difficulty: ⭐⭐ Hard

Consider a function with two overloads: one accepting (a: string) and another (a: string, ...rest: number[]). What must be true about the implementation signature's rest parameter?

Answer:

The implementation signature must be callable with all overload call patterns. Since the first overload passes only one argument, rest must be optional — but TypeScript requires rest parameters in implementations to match the most permissive overload.

Here, ...rest: number[] is valid because it's omitted in calls matching the first overload (treated as []). The parameter a remains required; rest is inherently optional when omitted.

Using any[] or unknown[] violates strict typing and isn't required.

4. Type predicates and user-defined type guards

Topic: Type Guards · Difficulty: ⭐⭐ Hard

What's the difference between these two functions, and why does only one act as a proper type guard?

function isString1(val: unknown): boolean {
  return typeof val === 'string';
}

function isString2(val: unknown): val is string {
  return typeof val === 'string';
}

function process(value: string | number) {
  if (isString1(value)) {
    console.log(value.toUpperCase()); // ❌ Error
  }
  if (isString2(value)) {
    console.log(value.toUpperCase()); // ✅ OK
  }
}

Answer:

The key difference is the return type: boolean vs val is string (type predicate).

isString1 returns boolean:

Function works correctly at runtime
But TypeScript doesn't narrow the type
value remains string | number after the check
Can't call string methods without assertion

isString2 returns val is string:

This is a type predicate
Tells TypeScript: "if this returns true, then val is definitely string"
TypeScript narrows value to string inside the if-block
Full type safety enabled

Rules for type predicates:

// ✅ Valid: parameter name matches
function isUser(val: unknown): val is User {
  return typeof val === 'object' && val !== null && 'name' in val;
}

// ❌ Invalid: parameter name doesn't match
function isUser(val: unknown): data is User {
  // ...
}

// ❌ Invalid: return type must be assignable to parameter type
function isString(val: number): val is string {
  // ...
}

Key points:

Type predicates enable custom type guards
Must use parameterName is Type syntax
Parameter name must match function parameter
Essential for narrowing complex types

📖 Using Type Predicates (TypeScript Handbook)

5. Conditional types with infer keyword

Topic: Generics · Difficulty: ⭐⭐ Hard

What does this conditional type do, and how does the infer keyword work?

type UnpackPromise<T> = T extends Promise<infer U> ? U : T;

type A = UnpackPromise<Promise<string>>; // string
type B = UnpackPromise<number>; // number

Answer:

This conditional type extracts the resolved type from a Promise.

How it works:

T extends Promise<infer U>:
- Checks if T is assignable to Promise<something>
- infer U tells TypeScript to infer the type parameter and bind it to U
? U : T:
- If T is a Promise, return the inferred type U
- Otherwise, return T unchanged

Examples:

type A = UnpackPromise<Promise<string>>; // string
type B = UnpackPromise<Promise<{ id: number }>>; // { id: number }
type C = UnpackPromise<number>; // number (not a Promise)

More examples with infer:

// Extract return type of a function
type ReturnType<T> = T extends (...args: any[]) => infer R ? R : any;

// Extract element type of an array
type ElementType<T> = T extends (infer U)[] ? U : T;

type Num = ElementType<number[]>; // number

Key points:

infer can only be used in extends clauses of conditional types
It creates a type variable that TypeScript infers from the pattern
Essential for advanced type-level programming

📖 Conditional Types (TypeScript Handbook)

6. Never type and control flow analysis

Topic: Type System · Difficulty: ⭐⭐ Hard

What is the inferred return type of fail() — and why does that matter for code after the call?

function fail(message: string): ??? {
  throw new Error(message);
}

Answer:

Because fail() unconditionally throws and has no reachable return, TypeScript infers its return type as never.

That enables control flow analysis: anything after fail() is treated as unreachable, so the compiler won't expect a return value on code paths that call it.

void would mean the function could return undefined, which is false here. unknown and Error are unrelated to the return type of a throwing function.

📖 The never type (TypeScript Handbook)

7. TypeScript's `--isolatedModules` flag implication

Topic: Modules · Difficulty: ⭐⭐ Hard

What constraint does TypeScript's --isolatedModules compiler option enforce on individual files?

Answer:

--isolatedModules requires each file to be independently valid as a module — meaning it cannot rely on global ambient context or non-module syntax that assumes shared scope (e.g., declare module in non-module files). This is critical for tools like Babel or SWC that transpile files individually without full TS program analysis.

Key constraints:

All files must be modules (have import or export)
Cannot use const enum
Cannot re-export types without export type

📖 TypeScript Docs: isolatedModules

8. Mapped types with key remapping

Topic: Generics · Difficulty: ⭐⭐⭐ Hard

What does this mapped type do, and how does the as clause work?

type Getters<T> = {
  [K in keyof T as `get${Capitalize<string & K>}`]: () => T[K];
};

interface Person {
  name: string;
  age: number;
}

type PersonGetters = Getters<Person>;
// { getName: () => string; getAge: () => number }

Answer:

This mapped type creates getter methods with transformed property names.

How it works:

[K in keyof T]:
- Iterates over all keys of T
- K is each key in turn
as get${Capitalize<string & K>}:
- Key remapping (TypeScript 4.1+)
- Transforms each key name
- Capitalize is a built-in template literal type
- string & K ensures K is a string (not number or symbol)
: () => T[K]:
- Each property becomes a function returning the original type

Step-by-step for Person:

type A = UnpackPromise<Promise<string>>; // string
type B = UnpackPromise<Promise<{ id: number }>>; // { id: number }
type C = UnpackPromise<number>; // number (not a Promise)

Other key remapping examples:

// Remove optional modifier
type Required<T> = {
  [K in keyof T]-?: T[K];
};

// Filter keys by condition
type RemoveReadonly<T> = {
  [K in keyof T as K extends `readonly_${string}` ? never : K]: T[K];
};

Key points:

Key remapping enables powerful type transformations
Works with template literal types
Can filter, rename, or compute new keys
Essential for advanced utility types

📖 Key Remapping in Mapped Types (TypeScript Handbook)

9. Template literal types

Topic: Type System · Difficulty: ⭐⭐⭐ Hard

What is the type of event in this code, and how do template literal types work?

type EventType = 'click' | 'focus' | 'blur';
type Handler = (event: `on${Capitalize<EventType>}`) => void;

const handler: Handler = (event) => {
  console.log(event);
};

Answer:

The type of event is 'onClick' | 'onFocus' | 'onBlur'.

How template literal types work:

`on${Capitalize<EventType>}`:
- Takes each member of the union EventType
- Applies Capitalize to each
- Concatenates with 'on' prefix
Result:
- 'click' → Capitalize<'click'> → 'Click' → 'onClick'
- 'focus' → 'onFocus'
- 'blur' → 'onBlur'

More examples:

// CSS properties
type CSSProperty = `margin${'Top' | 'Right' | 'Bottom' | 'Left'}`;
// 'marginTop' | 'marginRight' | 'marginBottom' | 'marginLeft'

// Event handlers
type ReactEventHandler = `on${'Click' | 'Change' | 'Submit'}Capture`;
// 'onClickCapture' | 'onChangeCapture' | 'onSubmitCapture'

// URL paths
type APIRoute = `/api/${'users' | 'posts' | 'comments'}`;
// '/api/users' | '/api/posts' | '/api/comments'

Key points:

Template literal types create string literal types from unions
Work with built-in string manipulation types (Capitalize, Uppercase, etc.)
Enable type-safe string patterns
Essential for type-safe APIs and configuration

📖 Template Literal Types (TypeScript Handbook)

10. Recursive conditional types

Topic: Generics · Difficulty: ⭐⭐⭐ Hard

What does this recursive type do, and why is the conditional check necessary?

type DeepReadonly<T> = {
  readonly [K in keyof T]: T[K] extends object ? DeepReadonly<T[K]> : T[K];
};

interface Config {
  api: { url: string; timeout: number };
  features: string[];
}

type ReadonlyConfig = DeepReadonly<Config>;

Answer:

This recursive type makes all properties deeply readonly — including nested objects and arrays.

How it works:

readonly [K in keyof T]:
- Makes each property readonly
T[K] extends object ? DeepReadonly<T[K]> : T[K]:
- If the property value is an object, recursively apply DeepReadonly
- Otherwise, keep the primitive type as-is

Result for Config:

{
  readonly api: {
    readonly url: string;
    readonly timeout: number;
  };
  readonly features: readonly string[];
}

Why the conditional check is necessary:

Without extends object, you'd try to recurse into primitives:

// ❌ Bad: tries to make string readonly
type BadDeepReadonly<T> = {
  readonly [K in keyof T]: DeepReadonly<T[K]>;
};

// Would try: DeepReadonly<string> → { readonly [K in keyof string]: ... }
// This creates infinite recursion or weird results

Limitations:

Doesn't handle Date, RegExp, Map, Set correctly
Can hit recursion limits with very deep structures
Arrays become readonly T[] (which is correct)

📖 Recursive Types (TypeScript Handbook)

11. Declaration merging with interfaces

Topic: Interfaces and Types · Difficulty: ⭐⭐⭐ Hard

What happens when you declare the same interface multiple times, and why doesn't this work with type aliases?

interface Box {
  width: number;
}

interface Box {
  height: number;
}

const box: Box = { width: 10, height: 20 }; // ✅ OK

type Container = { volume: number };
type Container = { weight: number }; // ❌ Error

Answer:

This is declaration merging — a feature unique to interfaces in TypeScript.

How it works:

When you declare the same interface multiple times, TypeScript merges all declarations into a single interface:

// These two declarations:
interface Box {
  width: number;
}

interface Box {
  height: number;
}

// Merge into:
interface Box {
  width: number;
  height: number;
}

What can be merged:

Properties (must have unique names or compatible types)
Methods (create overloads)
Nested interfaces

Example with methods:

interface Logger {
  log(message: string): void;
}

interface Logger {
  log(message: string, level: 'info' | 'error'): void;
}

// Merged result:
interface Logger {
  log(message: string): void;
  log(message: string, level: 'info' | 'error'): void;
}

Why type aliases don't merge:

type Container = { volume: number };
type Container = { weight: number }; // ❌ Duplicate identifier

Type aliases create a single, immutable binding. You can't redeclare them.

When declaration merging is useful:

Extending third-party interfaces (e.g., adding properties to Window)
Module augmentation
Progressive interface building

Example — extending Window:

interface Window {
  myCustomProperty: string;
}

// Now window.myCustomProperty is typed
window.myCustomProperty = 'hello';

Key points:

Only interfaces support declaration merging
Type aliases cannot be merged
Useful for extending existing types
Common in library type definitions

📖 Declaration Merging (TypeScript Handbook)

12. Variance annotations in TypeScript 4.7+

Topic: Generics · Difficulty: ⭐⭐⭐ Hard

What do the in and out modifiers do in this interface, and why are they needed?

interface Producer<out T> {
  get(): T;
}

interface Consumer<in T> {
  set(value: T): void;
}

interface Processor<in out T> {
  process(value: T): T;
}

Answer:

These are variance annotations (TypeScript 4.7+) that control how generic types relate to each other in subtyping.

Variance explained:

out T (covariant):
- T only appears in output positions (return types)
- Producer<Dog> is assignable to Producer<Animal> if Dog extends Animal
- Safe because you only get T out
in T (contravariant):
- T only appears in input positions (parameter types)
- Consumer<Animal> is assignable to Consumer<Dog> if Dog extends Animal
- Safe because you only put T in
in out T (invariant):
- T appears in both input and output
- Processor<Dog> is NOT assignable to Processor<Animal>
- Neither direction is safe

Why they're needed:

Without annotations, TypeScript uses structural typing and might allow unsafe assignments:

// Without variance annotations
interface Box<T> {
  value: T;
}

let animalBox: Box<Animal> = { value: new Animal() };
let dogBox: Box<Dog> = animalBox; // ❌ Unsafe but allowed!
dogBox.value.bark(); // 💥 Runtime error if value is actually Animal

With variance annotations:

interface ReadOnlyBox<out T> {
  getValue(): T;
}

let animalBox: ReadOnlyBox<Animal> = getAnimalBox();
let dogBox: ReadOnlyBox<Dog> = animalBox; // ✅ Safe — covariant

Key points:

out = covariant (output only)
in = contravariant (input only)
in out = invariant (both)
Catches unsafe type relationships at compile time
Essential for library authors

📖 Variance Annotations (TypeScript Release Notes)

🎯 Ready to test yourself?

Reading answers is not the same as retrieving them under pressure.

Want to test your knowledge interactively?

📚 Full TypeScript Question Bank on GitHub — 30+ questions with detailed explanations, perfect for offline study
🚀 Take the Interactive TypeScript Assessment — timed mode, instant feedback, compare your results with other developers

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

12 Tricky TypeScript Questions That Separate Good Developers From Great Ones

12 Tricky TypeScript Questions That Separate Good Developers From Great Ones

1. Ambient declaration vs implementation in global scope

2. Impact of as const on literal types

3. Rest parameter in overloaded function

4. Type predicates and user-defined type guards

5. Conditional types with infer keyword

6. Never type and control flow analysis

7. TypeScript's --isolatedModules flag implication

8. Mapped types with key remapping

9. Template literal types

10. Recursive conditional types

11. Declaration merging with interfaces

12. Variance annotations in TypeScript 4.7+

🎯 Ready to test yourself?

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. Impact of `as const` on literal types

7. TypeScript's `--isolatedModules` flag implication

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