JavaScript interview questions covering language fundamentals, async patterns, Node.js, TypeScript, and modern ecosystem practices.
Use a concrete example: "After a click handler runs, all queued Promise callbacks execute before the browser repaints or fires the next setTimeout. That is why an infinite chain of microtasks can freeze the UI."
JavaScript is single-threaded with an event loop that processes a call stack, a microtask queue (Promises, queueMicrotask, MutationObserver), and a macrotask queue (setTimeout, setInterval, I/O). After each macrotask, all microtasks are drained before the next macrotask runs. This means Promise.then callbacks execute before setTimeout callbacks even if setTimeout was scheduled first. Strong candidates explain how this affects UI rendering (microtasks can block repainting) and Node.js I/O scheduling.
Core JavaScript knowledge. Candidates who cannot explain the event loop will write code with subtle timing bugs. Ask them to predict the output order of a mix of console.log, setTimeout, and Promise.resolve calls.
Show the concept and the gotcha: "Closures power the module pattern for encapsulation. The classic pitfall is capturing a loop variable with var — each closure shares the same reference. Using let creates a new binding per iteration."
A closure is a function that retains access to variables from its outer lexical scope even after the outer function has returned. Essential uses: data privacy (module pattern), factory functions, callbacks and event handlers, partial application. Problems: unintended variable capture in loops (the classic var-in-for-loop bug, fixed by let or IIFE), memory leaks when closures hold references to large objects or DOM elements that should be garbage collected.
Fundamental JavaScript concept. Candidates who cannot explain closures have a gap in language understanding. Ask them to solve the classic loop closure problem to test practical understanding.
Match the method to the requirement: "Promise.all for parallel fetches that all must succeed. Promise.allSettled when I need partial results. Promise.race for implementing timeouts around slow operations."
Callbacks: oldest pattern, leads to nesting (callback hell). Promises: chainable, better error handling with catch. Async/await: syntactic sugar over Promises, reads like synchronous code. Promise.all: resolves when all settle successfully, rejects on first failure — use for independent tasks where all must succeed. Promise.allSettled: resolves when all settle regardless of success/failure — use when you want all results even if some fail. Promise.race: resolves/rejects with the first to settle — use for timeouts or fastest-response-wins patterns.
Tests async JavaScript fluency. Candidates who default to sequential awaits when operations are independent miss easy parallelism. Those who cannot explain Promise.allSettled may not handle partial failures well.
Be balanced: "TypeScript catches entire categories of bugs before runtime and makes refactoring safe. But for a 50-line script or a rapid prototype, the build step and type ceremony slow you down more than they help."
TypeScript benefits: catches type errors at compile time, self-documenting code, better IDE support (autocompletion, refactoring), enforces contracts between modules, and makes large codebases maintainable. Wrong choice: quick prototypes, small scripts, teams unfamiliar with type systems (learning curve), environments where build step is unwanted. Strong candidates discuss: strict mode adoption, the any escape hatch problem, type narrowing, discriminated unions, and the trade-off between type safety and development speed.
Tests practical judgement. Candidates who refuse TypeScript for large projects or insist on it for tiny scripts both lack nuance. Look for experience with gradual adoption in existing codebases.
Show the connection: "ES6 class methods are defined on Constructor.prototype, exactly like the old pattern. class extends sets Child.prototype = Object.create(Parent.prototype). It is syntactic sugar, not a new model."
Every JavaScript object has an internal [[Prototype]] link. Property access walks the prototype chain until found or reaching null. ES6 classes are syntactic sugar over constructor functions and prototypes — they do not introduce a new object model. class methods go on the prototype, class fields go on instances, and extends sets up the prototype chain. Strong candidates explain: Object.create, __proto__ versus prototype property, and how class syntax makes prototype patterns more readable without changing the mechanics.
Core language understanding. Candidates who think classes are like Java classes will be confused by JavaScript behaviour. Those who understand the prototype chain can debug inheritance issues and make informed design choices.
Highlight the key difference: "ES modules are statically analysable so bundlers can tree-shake unused exports. CommonJS require is dynamic so bundlers must include everything. This is why ESM is the future."
CommonJS: synchronous require(), dynamic, used in Node.js. ES modules: static import/export, enables tree-shaking, async loading, now supported in Node.js and browsers. Webpack: established, plugin-rich, bundles everything into chunks. Esbuild: extremely fast (Go-based), limited plugin API. Vite: uses native ES modules in dev (no bundling), esbuild for transpilation, Rollup for production builds. Strong candidates discuss tree-shaking requirements (ES modules only), code splitting strategies, and why Vite dev server is fast.
Tests ecosystem knowledge. Candidates who only know webpack may not be up to date. Those who understand why Vite uses native ESM in dev and Rollup in production demonstrate modern tooling awareness.
Show the distinction: "Programmer errors like TypeError should crash and be fixed. Operational errors like network timeouts should be caught, retried, and surfaced to the user gracefully. I handle them differently."
Patterns: try/catch for synchronous and async/await code, .catch() for Promise chains, global handlers (window.onerror, process.on uncaughtException/unhandledRejection), error boundary components in React. Best practices: create custom Error subclasses for different error types, always log with context, fail fast for programming errors, recover gracefully from operational errors. Strong candidates distinguish between programmer errors (bugs, should crash) and operational errors (network failures, should retry or degrade gracefully).
Tests code robustness thinking. Candidates who use empty catch blocks or who do not handle Promise rejections will write fragile applications. Look for a systematic approach with custom error types and clear recovery strategies.
Show production readiness: "I layer Express middleware for auth, validation, and rate limiting. Services are stateless so I scale horizontally behind a load balancer. Redis handles sessions and caching."
Structure: separate routes, controllers, services, and data access layers. Authentication: JWT or session-based depending on client type, middleware-based auth checks. Scaling: cluster mode or PM2 for multi-core, stateless design for horizontal scaling, Redis for session storage, connection pooling for databases. Strong candidates discuss: middleware patterns (Express/Fastify), input validation (Zod/Joi), rate limiting, graceful shutdown, health checks, and structured logging.
Senior Node.js question. Candidates who put everything in route handlers will create unmaintainable code. Those who discuss layered architecture, stateless design, and operational concerns (logging, health checks, graceful shutdown) are production-ready.
Cover both sides: "Frontend: CSP headers block inline scripts, I never use innerHTML with user data. Backend: parameterised queries prevent injection, npm audit runs in CI, and I use helmet for security headers."
Frontend: XSS (sanitise user input, Content Security Policy, avoid innerHTML), CSRF (SameSite cookies, CSRF tokens), clickjacking (X-Frame-Options), sensitive data exposure in client bundles. Backend/Node.js: injection (parameterised queries), dependency vulnerabilities (npm audit), prototype pollution, SSRF, and insecure deserialization. Strong candidates discuss security headers, npm audit in CI, and the principle of least privilege for API tokens.
Critical for any JavaScript developer. Candidates who only think about one side (frontend or backend) have blind spots. Those who mention CSP, npm audit, and prototype pollution demonstrate comprehensive security awareness.
Pick features you actually use: "Optional chaining and nullish coalescing eliminated hundreds of lines of defensive null checking. structuredClone replaced our hacky JSON deep-copy pattern with proper semantics."
Impactful features: optional chaining (?.), nullish coalescing (??), destructuring, template literals, array methods (flatMap, at()), structuredClone, top-level await, private class fields (#), and the Temporal API (Stage 3). Strong candidates describe real refactoring: replacing nested null checks with optional chaining, using nullish coalescing instead of || for falsy defaults, or adopting structuredClone to replace JSON.parse(JSON.stringify()). They should mention browser/Node.js compatibility considerations.
Tests whether candidates keep current with the language. Those who still write verbose null checks or use lodash.cloneDeep when native alternatives exist are behind. Ask about compatibility — do they use Babel/TypeScript to target older environments?