Programming LanguagesFrontend Developer to Senior Full-Stack Engineer17 min read·Updated for TypeScript 5.6 & ES2026

JavaScript & TypeScript Interview Guide: From Closures to the Event Loop

Master Scope, Prototypes, Asynchronous Execution & TypeScript's Structural Type System for Frontend and Full-Stack Rounds

Priya Nakamura

Senior Frontend Engineer & TypeScript Advocate

10+ Years Building Production JavaScript & TypeScript Systems

Prep Timeline

3 to 5 Weeks

Format

3 Rounds (Language Fundamentals, Async & Event Loop, TypeScript Deep-Dive)

Conversion

+71% Technical Screen Pass Rate

JavaScript & TypeScript Interview Guide: From Closures to the Event Loop

Executive Summary & Key Takeaways

What You Must Master to Clear This Track

Closures are not a trick question topic — they underpin module patterns, memoization, and private state in every production codebase.
The event loop's rule of 'drain all microtasks before the next macrotask' explains almost every async ordering question you'll be asked.
Prototypal inheritance is the real mechanism behind `class` syntax; interviewers probe whether you know what's happening beneath the sugar.
TypeScript's type system is structural, not nominal — two differently-named types with the same shape are interchangeable.
Most 'JavaScript is weird' interview gotchas (coercion, `this`, equality) have a small, learnable rule set behind them.

Structured Preparation Timeline

Step-by-Step Study Plan

Follow this sequential roadmap designed to take you from core foundations to advanced architecture and mock interviews.

Phase 1 (Weeks 1-2)

Scope, Hoisting, Closures & Prototypes

Core Language Mechanics

Build a rock-solid mental model of how JavaScript resolves variables, how functions capture their surrounding scope, and how objects inherit behavior through the prototype chain.

Key Milestones

•Trace var/let/const hoisting and the temporal dead zone for at least 10 code snippets without running them.
•Implement a private-state module (counter, cache, or event emitter) using only closures, no classes.
•Diagram the prototype chain for a custom constructor function and for an ES6 class extending it.

Recommended Actions

•Practice reading code snippets aloud and predicting output before pasting into a console.
•Rebuild `Object.create` and a minimal class-inheritance helper from scratch to internalize the mechanism.

Phase 2 (Weeks 3-4)

Call Stack, Microtasks, Macrotasks & Promises

Asynchronous JavaScript & the Event Loop

Master the single-threaded concurrency model: how the call stack, microtask queue, and macrotask (task) queue interact, and how async/await composes on top of Promises.

Key Milestones

•Correctly predict console.log ordering for mixed sync code, Promise chains, and setTimeout calls.
•Rewrite a callback-based function into a Promise-based one, then into async/await.
•Handle rejected Promises correctly with try/catch, .catch(), and global unhandledrejection listeners.

Recommended Actions

•Draw the event loop diagram from memory: call stack, Web/Node APIs, microtask queue, macrotask queue.
•Debug at least 3 real 'race condition' bugs involving async/await inside loops.

Phase 3 (Weeks 5-6)

Generics, Utility Types, Structural Typing & Runtime Pitfalls

TypeScript Mastery & Applied Interview Drills

Move from 'TypeScript as annotations' to 'TypeScript as a design tool' — generics, conditional types, discriminated unions — while shoring up classic runtime pitfalls like `this` binding and coercion.

Key Milestones

•Write a generic function and a generic interface that both narrow correctly at call sites.
•Use Partial, Pick, Omit, and Record to reshape an existing interface without duplicating fields.
•Explain 4 distinct `this`-binding scenarios (default, implicit, explicit, arrow) with a live code example each.

Recommended Actions

•Convert 5 `any`-typed functions from a real project into properly generic, type-safe signatures.
•Run 10 timed mock questions on coercion and equality (`==` vs `===`, `[] + []`, `NaN === NaN`).

Deep-Dive Architecture & Concepts

1. Closures, Scope & Hoisting

Closures are the single most tested JavaScript concept because they explain module encapsulation, event handler bugs, and memoization in one mechanism: a function remembers the scope it was created in, not the scope it is called from.

Lexical Scope

Scope is determined by where a function is physically written in the source code, not by where or how it is invoked. Nested functions can read (and close over) variables from their enclosing function.

var vs let/const Hoisting

var declarations are hoisted and initialized to undefined at the top of their function scope; let/const are hoisted but left uninitialized in the Temporal Dead Zone (TDZ) until their declaration line executes, throwing a ReferenceError if accessed early.

Closures for Encapsulation

A closure lets an inner function retain access to outer variables even after the outer function has returned, enabling private state without classes (the classic 'module pattern').

The Classic Loop Closure Bug

A var-declared loop variable is shared across all iterations because var is function-scoped, so callbacks scheduled inside the loop (e.g. setTimeout) all see the final value. let creates a fresh binding per iteration, fixing this by design.

Private State via the Closure-Based Module Pattern

typescript

function createCounter(initialValue: number = 0) {
    let count = initialValue; // captured by closure, invisible outside
  
    return {
      increment: () => (count += 1),
      decrement: () => (count -= 1),
      getValue: () => count,
    };
  }
  
  const counter = createCounter(10);
  counter.increment();
  counter.increment();
  console.log(counter.getValue()); // 12
  
  // counter.count is undefined — there is no public property to read;
  // the only way to touch `count` is through the closures returned above.

Why it matters: Each call to createCounter produces a brand-new lexical environment. The three returned arrow functions all close over the SAME `count` variable, giving true private state without needing a class or the # private field syntax.

Interviewer Insights & Pro Tips

When asked to fix the 'var in a loop + setTimeout' bug, mention THREE valid fixes: switch to let, wrap the body in an IIFE that captures the value, or pass the value as a bind() argument.
Say 'lexical scope' and 'Temporal Dead Zone' explicitly in interviews — these are the exact terms interviewers listen for.

Red Flags & Common Pitfalls

Assuming hoisting means the whole declaration AND assignment move to the top — only the declaration is hoisted, the assignment stays in place.
Forgetting that closures capture variables by reference, not by value — mutating a captured variable later changes what every closure over it sees.

Deep-Dive Architecture & Concepts

2. Prototypes & the Prototype Chain

Every JavaScript object has an internal link to another object called its prototype. Property lookups walk this chain until the property is found or the chain ends at null — this is the real mechanism behind inheritance, even when you write `class` and `extends`.

Prototype vs __proto__

A function's `.prototype` property is the object that will become the [[Prototype]] of instances created with `new`. An object's `__proto__` (or Object.getPrototypeOf) is the actual live link used during property lookup.

Property Lookup Walk

Accessing obj.foo first checks obj's own properties; if missing, the engine walks up obj.[[Prototype]], then that object's [[Prototype]], and so on until it hits Object.prototype and finally null.

class is Sugar Over Prototypes

ES6 class syntax still creates a constructor function under the hood; methods defined in the class body are placed on ClassName.prototype, and `extends` wires up the prototype chain via Object.setPrototypeOf.

Object.create for Pure Prototypal Inheritance

Object.create(proto) creates a new object whose [[Prototype]] is set directly to `proto`, letting you build inheritance hierarchies without ever calling a constructor function.

Interviewer Insights & Pro Tips

If asked to implement inheritance without `class`, reach for Object.create(parent.prototype) and manually fix the .constructor reference — this signals you understand what `extends` does for you.
Mention shadowing: assigning obj.foo = x creates an OWN property that shadows a prototype property of the same name rather than mutating the prototype.

Red Flags & Common Pitfalls

Confusing `instanceof` (checks the prototype chain) with `typeof` (checks the primitive/type tag) — they answer different questions.
Directly mutating Object.prototype or Array.prototype ('monkey-patching' or 'prototype pollution'), which silently affects every object/array in the program and is a real security vulnerability when attacker-controlled data reaches a merge/clone utility.

Deep-Dive Architecture & Concepts

3. The Event Loop: Call Stack, Microtasks & Macrotasks

JavaScript is single-threaded, so asynchronous behavior — timers, network requests, Promise resolution — is all coordinated by the event loop, which decides what runs next once the call stack is empty. Interview questions almost always test whether you know microtasks always drain before the next macrotask.

The Call Stack

Synchronous code executes frame-by-frame on a single call stack. Nothing asynchronous can run until the stack is completely empty, which is why a long synchronous loop blocks timers and UI rendering.

Microtask Queue (High Priority)

Promise .then/.catch/.finally callbacks, async/await continuations, and queueMicrotask() callbacks all go here. The ENTIRE microtask queue is drained — including new microtasks queued while draining — before the loop touches the next macrotask.

Macrotask / Task Queue (Lower Priority)

setTimeout, setInterval, setImmediate (Node), I/O callbacks, and UI events are macrotasks. The event loop runs exactly one macrotask per turn, then drains microtasks again before the next one.

async/await is Promise Sugar

An async function always returns a Promise; `await` pauses the function and schedules its continuation as a microtask once the awaited Promise settles — it does not block the thread.

JavaScript Event Loop Execution Order

How the runtime interleaves synchronous code, microtasks, and macrotasks on every turn of the loop.

Run Synchronous Code

The call stack executes the current script top-to-bottom until it is completely empty.

Hand Off Async Work

Timers, fetch/XHR calls, and file/IO operations are delegated to the browser or Node APIs and run off the main thread.

Drain the Microtask Queue

Once the stack is empty, ALL queued Promise callbacks and queueMicrotask() entries run to completion, including any new microtasks they enqueue.

Dequeue One Macrotask

The loop pulls exactly one callback from the macrotask queue (e.g. a fired setTimeout) and pushes it onto the call stack to run.

Repeat the Cycle

After that single macrotask finishes, the microtask queue is drained again before the loop dequeues the next macrotask or the browser repaints.

Interviewer Insights & Pro Tips

When tracing output order, label every line with sync / microtask / macrotask before writing the final answer — interviewers grade the reasoning, not just the final order.
Mention that `await Promise.resolve()` yields exactly one microtask tick, which is a common building block for 'flush the microtask queue' test utilities.

Red Flags & Common Pitfalls

Assuming setTimeout(fn, 0) runs immediately after the current synchronous code — it always runs AFTER all pending microtasks, even ones queued after the timer was set.
Writing an unbounded recursive Promise chain that keeps re-queuing microtasks, starving macrotasks (and the UI) from ever running.

Deep-Dive Architecture & Concepts

4. TypeScript's Type System & Common Runtime Pitfalls

TypeScript adds a structural, compile-time type system on top of JavaScript's dynamic runtime. Interviewers test whether you can use generics and utility types to model real APIs, and whether you understand the runtime quirks (this binding, coercion) that TypeScript's types cannot fully protect you from.

Structural Typing ('Duck Typing')

TypeScript compares the SHAPE of types, not their declared names — two unrelated interfaces with identical members are freely assignable to each other, unlike nominal type systems such as Java or C#.

Generics

Generics let a function, interface, or class stay type-safe while remaining reusable across many concrete types, replacing unsafe `any` with a type parameter that TypeScript infers and checks at every call site.

Utility Types

Partial<T>, Required<T>, Pick<T,K>, Omit<T,K>, and Record<K,V> transform existing types instead of duplicating field lists, keeping a single source of truth for shared domain models.

`this` Binding Rules

Regular functions determine `this` from the CALL SITE (default, implicit object, or explicit call/apply/bind), while arrow functions have no `this` of their own and lexically inherit it from the enclosing scope — the source of most 'this is undefined' bugs.

Implicit Coercion

Operators like + and == trigger the abstract ToPrimitive/ToNumber conversion algorithm, producing famously surprising results (e.g. '5' + 3 === '53' but '5' - 3 === 2) that TypeScript's static types do not eliminate at runtime boundaries like JSON parsing or form inputs.

Generics + Conditional Types to Model an API Response

typescript

interface ApiResponse<T> {
    data: T;
    status: "success" | "error";
    timestamp: number;
  }
  
  // Conditional type with `infer`: pull the T back out of an ApiResponse<T>
  type ExtractData<R> = R extends ApiResponse<infer D> ? D : never;
  
  interface User {
    id: string;
    name: string;
  }
  
  async function fetchUser(id: string): Promise<ApiResponse<User>> {
    const res = await fetch("/api/users/" + id);
    const data: User = await res.json();
    return { data, status: "success", timestamp: Date.now() };
  }
  
  // Compose built-in utility types with our own conditional type:
  type UserShape = ExtractData<Awaited<ReturnType<typeof fetchUser>>>; // resolves to User
  
  // Reshape User without retyping fields:
  type UserPreview = Pick<User, "id" | "name">;
  type PartialUser = Partial<User>;

Why it matters: ReturnType and Awaited are built-in utility types that unwrap a function's return type and a Promise's resolved value respectively; combining them with a custom conditional type (ExtractData) shows interviewers you can compose the type system rather than only memorize utility type names.

Interviewer Insights & Pro Tips

When explaining interface vs type alias, lead with what they share (both describe object shapes, both support generics) before the differences (only interface supports declaration merging; only type alias can name unions/primitives directly).
For `this` questions, always state the four binding rules in priority order: new binding > explicit (call/apply/bind) > implicit (obj.method()) > default (undefined in strict mode / global object otherwise) — arrow functions opt out of this system entirely.

Red Flags & Common Pitfalls

Using `any` to silence a type error instead of modeling the real shape with a generic or a union — this reintroduces the exact runtime bugs TypeScript exists to prevent.
Passing an object method as a bare callback (e.g. setTimeout(obj.method, 1000)) and being surprised `this` is undefined inside it — the function is detached from `obj` at the call site.
Relying on `==` for equality checks and getting tripped up by coercion edge cases like '' == 0 or null == undefined being true while null == 0 is false.

Real-World Example

Fixing a Production Race Condition in a Checkout Flow

A mid-size e-commerce team noticed that roughly 2% of checkout submissions occasionally applied a stale discount code from a previous cart session, even though the UI showed the correct code. The bug only reproduced intermittently in production, never locally.

1The team traced the bug to an async function that fetched cart totals and discount validity inside a loop over cart items, awaiting each network call sequentially instead of in parallel.
2A closure over a shared `currentCartId` variable (declared with `let` at module scope, not per-request) was being read by a callback that resolved AFTER the user had already navigated to a new cart.
3They refactored the sequential awaits into a `Promise.all` batch keyed by a request-scoped cart ID passed explicitly as a function argument, removing the shared mutable closure variable entirely.
4They added a discriminated union (`{status: 'stale'} | {status: 'fresh', data}`) return type so any consumer was forced by TypeScript to handle the stale case instead of assuming the response always matched the current cart.
5They wrote a regression test using fake timers to simulate two overlapping cart sessions and assert the stale response was discarded.
6The fix was rolled out behind a feature flag to 10% of checkout traffic for one week before a full rollout.

Outcome: Stale-discount checkout errors dropped from roughly 2% of sessions to zero measured occurrences over the following month, and checkout-related support tickets fell by 34%.

Real-World Interview Questions

Mistakes That Sink Otherwise Strong Candidates

Declaring loop variables with `var` when scheduling async callbacks inside the loop.

Why it happens: Developers coming from other languages assume each iteration gets its own variable, not realizing `var` is function-scoped and shared across all iterations.

The fix: Use `let` for loop counters so each iteration gets a fresh binding, or explicitly capture the value in an IIFE/extra function argument.

Assuming a regular (non-arrow) method will keep its `this` when passed around as a callback.

Why it happens: `this` looks like a normal variable, so it's easy to forget it is re-derived from the call site every single time the function is invoked, not fixed at definition time.

The fix: Bind explicitly with .bind(this), use an arrow function wrapper, or define the method as a class field arrow function.

Comparing objects or arrays with == or === and expecting value/deep equality.

Why it happens: Primitives compare by value, so developers extend that intuition to objects, not realizing objects compare by reference.

The fix: Use a dedicated deep-equality check (structuredClone + compare, or a library like lodash's isEqual) when value equality is actually required.

Treating `any` as an acceptable escape hatch whenever TypeScript complains.

Why it happens: It's the fastest way to make a red squiggly line disappear under deadline pressure, and the error doesn't resurface until runtime.

The fix: Reach for `unknown` plus a type guard, or a proper generic, so the compiler still catches misuse instead of silently allowing anything.

Leaving Promise rejections unhandled inside async functions or event handlers.

Why it happens: Code paths that 'normally' succeed in development make it easy to forget the error branch, especially inside fire-and-forget async calls.

The fix: Wrap awaited calls in try/catch, attach .catch() to any Promise chain that isn't awaited, and add a global unhandledrejection listener as a safety net.

Sequentially awaiting independent async calls inside a for-loop.

Why it happens: Writing `for (const x of items) { await doThing(x); }` reads naturally and passes tests with small datasets, hiding the linear-latency cost until scale.

The fix: Start all the Promises first (e.g. items.map(doThing)) and await them together with Promise.all when the operations don't depend on each other.

Mutating Object.prototype or Array.prototype directly to 'add a helper method'.

Why it happens: It looks convenient because the method instantly becomes available everywhere, without realizing every object/array in the program — including third-party code — is affected.

The fix: Write a standalone utility function instead of extending a built-in prototype, and never let untrusted merge/clone input reach __proto__ or constructor keys.

Relying on == instead of === and expecting 'reasonable' coercion behavior in edge cases.

Why it happens: == works intuitively for the common cases (comparing a string and number that clearly represent the same value), masking the much stranger edge cases until they appear in production data.

The fix: Default to === everywhere, and only reach for == deliberately (e.g. `x == null` to check for both null and undefined in one expression).

Cheat Sheet

Quick-Reference Cheat Sheet

Type Coercion Quick Reference

[] + []'' (both arrays -> '' , concatenated)

[] + {}'[object Object]'

'5' + 3'53' (string concatenation wins)

'5' - 32 (- forces ToNumber on both sides)

null == undefinedtrue (equal only to each other)

NaN === NaNfalse (use Number.isNaN to check)

true + true2 (booleans coerce to 1/0 in arithmetic)

Microtask vs Macrotask Sources

Promise .then/.catch/.finallyMicrotask

queueMicrotask()Microtask

MutationObserver callbackMicrotask

setTimeout / setIntervalMacrotask

setImmediate (Node.js)Macrotask

I/O callbacks, UI eventsMacrotask

process.nextTick (Node.js)Higher priority than microtasks

TypeScript Utility Types

Partial<T>Makes every property optional

Required<T>Makes every property mandatory

Readonly<T>Marks every property read-only

Pick<T, K>Selects a subset of keys K

Omit<T, K>Removes a subset of keys K

Record<K, V>Builds an object type from key set K to value V

ReturnType<T>Extracts a function's return type

Awaited<T>Unwraps a Promise's resolved value type

`this` Binding Rules (Priority Order)

1. new bindingnew Fn() -> this is the new instance

2. Explicit bindingfn.call/apply/bind(obj) -> this is obj

3. Implicit bindingobj.fn() -> this is obj

4. Default bindingfn() alone -> undefined (strict) / global object

Arrow functionsNo own this; lexically inherits enclosing scope's this

Equality & Comparison Operators

===Strict equality, no type coercion

==Loose equality, coerces via Abstract Equality Comparison

Object.is(a, b)Like === but treats NaN as equal to NaN and distinguishes +0/-0

typeof xReturns the primitive type tag ('string', 'number', 'object', ...)

x instanceof YChecks whether Y.prototype appears in x's prototype chain

Assessment Integration

Recommended Practice Quizzes on QuizCluster

Test your retention and prepare for timed live coding and MCQ technical screening rounds:

620 Quizzes

JavaScript & TypeScript

Drill closures, prototypes, async patterns, and TypeScript's generics and utility types across hundreds of scenario-based questions.

Start Practice Test

50 Quizzes

JavaScript Engine & React Internals

Go deeper into the event loop, microtask ordering, garbage collection, and how the engine executes async JavaScript under the hood.

Start Practice Test

Frequently Asked Questions

Do I need to memorize TypeScript's advanced conditional types to pass a mid-level interview?

No. Mid-level rounds mostly test generics, the common utility types (Partial, Pick, Omit, Record), and interface vs type. Conditional types with infer show up more often in senior/staff rounds or when a role emphasizes library/SDK design.

Is it worth practicing the exact console.log ordering questions for the event loop?

Yes — they are extremely common because they cheaply verify you understand microtask-vs-macrotask priority, which underlies almost every real async bug (race conditions, stale closures in loops, UI jank from blocking code).

Should I learn class-based or closure-based patterns first for JavaScript interviews?

Learn closures first. Classes are sugar over prototypes and closures are the more fundamental mechanism; understanding closures makes both prototypal inheritance and the module pattern much easier to reason about.

How much TypeScript do frontend interviews actually require versus plain JavaScript?

Most frontend roles in 2026 expect working fluency in TypeScript (generics, utility types, basic narrowing) since the majority of production codebases have migrated to it, but the underlying JavaScript runtime questions (event loop, closures, `this`) are still asked just as often, if not more.

Explore Other Preparation Guides

Software Engineering

How to Prepare for SDE Interview: Complete 2026 Roadmap

16 min readRead →

Java Ecosystem

How to Prepare for Java Developer Interview: Core to Spring Boot & JVM

18 min readRead →

Microservices & Distributed Systems

How to Prepare for Microservices Developer Interview: Distributed Architecture & Cloud

17 min readRead →

System Design

System Design Interview Guide: Complete 2026 Roadmap

21 min readRead →

Databases

SQL Interview Questions & Preparation Guide: Beginner to Advanced

17 min readRead →

Programming Languages

Python Interview Preparation: Complete Guide for 2026

17 min readRead →

Frontend Engineering

React Interview Preparation: React 19 & Next.js Guide

17 min readRead →

Cloud & DevOps

Kubernetes Interview Guide: Architecture, Pods, Networking & Troubleshooting

17 min readRead →

Cloud & DevOps

AWS Solutions Architect Interview Guide: Real Architecture Scenarios

17 min readRead →

Databases

Database System Design: SQL vs NoSQL, Sharding, Replication & Indexing

19 min readRead →

Microservices & Distributed Systems

Kafka Interview Guide: Architecture, Consumers, Partitions & Exactly-Once Semantics

17 min readRead →

Backend Engineering

REST API Design Interview Guide: Authentication, Pagination, Versioning & Rate Limiting

15 min readRead →

Cloud & DevOps

Docker Interview Guide: Images, Containers, Networking & Production Debugging

15 min readRead →

Backend Engineering

Node.js Backend Interview Guide: Event Loop, Streams, APIs & Scaling

17 min readRead →

Databases

Redis System Design Guide: Caching, Eviction, Persistence & Distributed Locks

17 min readRead →

Software Engineering

Concurrency Interview Guide: Threads, Locks, Race Conditions & Deadlocks

17 min readRead →

Software Engineering

Dynamic Programming Patterns: How to Recognize and Solve DP Problems

17 min readRead →

JavaScript & TypeScript Interview Guide: From Closures to the Event Loop

What You Must Master to Clear This Track

Step-by-Step Study Plan

Scope, Hoisting, Closures & Prototypes

Call Stack, Microtasks, Macrotasks & Promises

Generics, Utility Types, Structural Typing & Runtime Pitfalls

1. Closures, Scope & Hoisting

2. Prototypes & the Prototype Chain

3. The Event Loop: Call Stack, Microtasks & Macrotasks

4. TypeScript's Type System & Common Runtime Pitfalls

Fixing a Production Race Condition in a Checkout Flow

Top Must-Know Interview Questions & Model Answers

Q1: What is a closure, and what is a practical production use case for one?

Q2: Explain hoisting and the difference between how var, let, and const are hoisted.

Q3: Why does this loop print 5 five times instead of 0,1,2,3,4, and how do you fix it? for (var i = 0; i < 5; i++) { setTimeout(() => console.log(i), 100); }

Q4: What is the difference between lexical scope and the scope chain?

Q5: How would you implement a simple memoization utility using closures?

Q6: What is the prototype chain, and how does the JavaScript engine resolve obj.someProperty?

Q7: What is the difference between a function's .prototype property and an object's __proto__?

Q8: How does ES6 `class` and `extends` map onto prototypal inheritance under the hood?

Q9: What is prototype pollution and why is it treated as a security vulnerability?

Q10: Describe the JavaScript event loop: what are the call stack, the microtask queue, and the macrotask queue?

Q11: Why does a Promise's .then() callback run before a setTimeout(fn, 0) callback, even though both were scheduled at the same time?

Q12: Trace the console.log output order for: console.log(1); setTimeout(() => console.log(2)); Promise.resolve().then(() => console.log(3)); console.log(4);

Q13: What are the different sources of microtasks versus macrotasks?

Q14: How does async/await relate to Promises, and what actually happens when you `await` a value?

Q15: What happens to an unhandled rejected Promise, and how should you guard against it?

Q16: How does Promise.all differ from Promise.allSettled and Promise.race?

Q17: Why is running `await` sequentially inside a for-loop often a performance bug, and how do you fix it?

Q18: What are generics in TypeScript, and why are they preferable to typing a parameter as `any`?

Q19: Explain structural typing in TypeScript and how it differs from the nominal typing used in languages like Java.

Q20: What do the Partial<T>, Pick<T, K>, Omit<T, K>, and Record<K, V> utility types do?

Q21: What is the difference between an `interface` and a `type` alias in TypeScript?

Q22: What are conditional types and the `infer` keyword used for in TypeScript?

Q23: What are discriminated unions in TypeScript, and how do they enable exhaustiveness checking?

Q24: What is the difference between the `unknown` and `any` types in TypeScript?

Q25: How is `this` determined in a regular JavaScript function, and how do arrow functions differ?

Q26: Why does `this` become undefined when you extract a method and pass it as a bare callback, e.g. setTimeout(obj.method, 1000)?

Q27: What is the difference between == and === in JavaScript, and what does the abstract equality algorithm actually do?

Q28: Explain the results of these expressions and why: [] + [], [] + {}, and '5' + 3 versus '5' - 3.

Mistakes That Sink Otherwise Strong Candidates

Quick-Reference Cheat Sheet

Recommended Practice Quizzes on QuizCluster

JavaScript & TypeScript

JavaScript Engine & React Internals

Frequently Asked Questions

Do I need to memorize TypeScript's advanced conditional types to pass a mid-level interview?

Is it worth practicing the exact console.log ordering questions for the event loop?

Should I learn class-based or closure-based patterns first for JavaScript interviews?

How much TypeScript do frontend interviews actually require versus plain JavaScript?

Explore Other Preparation Guides

Q7: What is the difference between a function's .prototype property and an object's proto?