Question 1

What is an execution context in JavaScript, and what are its main components?

Accepted Answer

An execution context is the environment where JavaScript code is evaluated and executed. It holds the Variable Environment, Lexical Environment, and the value of this. Every time a function runs (or the global script starts), the engine creates an execution context. It has three main parts: (1) Variable Environment — bindings for var declarations and function declarations; (2) Lexical Environment — bindings for let/const, function arguments, and the outer environment reference used for scope chain lookup; (3) this binding — determined by how the function was called. There is always a Global Execution Context, and each function call pushes a new Function Execution Context onto the call stack. Understanding this model explains hoisting, scope, and this behavior.

Question 2

What happens during the creation phase vs the execution phase of an execution context?

Accepted Answer

Creation sets up the environment (hoisting bindings, resolving this); execution runs the code line by line and assigns values. In the creation phase, the engine scans the code and allocates memory: function declarations are fully initialized, var bindings are created and set to undefined, and let/const bindings are created in the Temporal Dead Zone (uninitialized). The outer lexical environment link and this are also determined. In the execution phase, statements run in order: assignments happen, functions are invoked (pushing new contexts), and expressions are evaluated. This two-phase model is why you can call a function declaration before its line, but accessing a let before initialization throws.

Question 3

How does the call stack relate to execution contexts, and what happens on a stack overflow?

Accepted Answer

Each function call pushes an execution context onto the call stack; returning pops it. Unbounded recursion overflows the stack. JavaScript is single-threaded for its main call stack: only one execution context runs at a time. Calling a function pushes a new context; returning (or throwing out of the function) pops it. The currently running context is always the top of the stack. A stack overflow (RangeError: Maximum call stack size exceeded) occurs when recursion or mutual calls nest deeper than the engine allows — typically from missing base cases or accidental infinite recursion. Async callbacks do not grow the same synchronous stack indefinitely; they run later as new top-level tasks.

Question 4

Explain the difference between Lexical Environment and Variable Environment in an execution context.

Accepted Answer

Variable Environment historically tracked var/function bindings; Lexical Environment tracks let/const and block scopes. Both link to an outer environment. Per the ECMAScript spec, an execution context has a LexicalEnvironment and a VariableEnvironment component. In practice: VariableEnvironment is where var declarations and function declarations in the function body are recorded. LexicalEnvironment starts as a copy of that for the function, but let/const and block statements ({}, catch, etc.) push new declarative environments onto the LexicalEnvironment chain without changing VariableEnvironment. That is why var ignores block boundaries inside a function, while let is block-scoped. Both environments have an outer reference used for identifier resolution (scope chain).

Question 5

How do eval and with affect execution contexts and scope, and why are they discouraged?

Accepted Answer

They can dynamically introduce or alter bindings in the current (or new) environment, defeating static scope analysis and hurting optimization and security. Direct eval in non-strict mode can add variables into the calling VariableEnvironment, effectively mutating the current execution context's bindings at runtime. with extends the scope chain with an object, so property lookups become dynamic identifier lookups. Both break lexical predictability: engines cannot optimize identifier resolution as aggressively, tooling cannot analyze code statically, and eval of untrusted input is a serious XSS/injection risk. Strict mode restricts eval (creates its own declarative environment) and forbids with. In modern codebases, prefer Function constructors only when necessary, and never with.

Question 6

You are designing a plugin system where third-party scripts run in the same page. How would you reason about execution contexts, isolation, and this/globalThis risk?

Accepted Answer

Same-realm scripts share the global execution context; isolate via iframes/workers/realms, freeze globals, and avoid relying on ambient this. All classic scripts and modules in the same realm share one Global Execution Context (modules get their own module environment but still share globalThis). A plugin can overwrite globals, monkey-patch prototypes, or capture privileged closures. Mitigations: run untrusted code in a sandboxed iframe or Worker (separate realm/global), expose a narrow API via postMessage, use Object.freeze / compartment patterns (SES) where available, load plugins as modules with explicit imports, and never pass privileged this or closures accidentally. Document that arrow functions and modules change this expectations. At lead level, discuss threat model: intentional malice vs accidental global pollution, CSP, and which APIs must never be reachable from plugins.

Question 7

What are global, function, and block scope in JavaScript?

Accepted Answer

Global is top-level; function scope wraps var/params; block scope ({}) applies to let, const, and class bindings. Global scope is the outermost environment — browsers expose it via window/globalThis for classic scripts. Function scope means var declarations and function declarations inside a function are visible throughout that function, ignoring inner blocks. Block scope, introduced widely with ES6, means let, const, and class declarations are confined to the nearest enclosing {} (including if, for, while, and bare blocks). Modules have their own top-level scope that does not leak to globalThis. Choosing the right declaration keyword is the practical way to control scope.

Question 8

How does the scope chain work when resolving a variable?

Accepted Answer

The engine looks in the current lexical environment, then walks outer environments until it finds the binding or throws ReferenceError. Identifier resolution follows the lexical scope chain (static scope): nested functions close over the environment where they were defined, not where they are called. Lookup starts in the active Lexical Environment, then follows the [[OuterEnv]] link to parent environments, eventually reaching the global environment. If the binding is never found, you get a ReferenceError. Shadowing occurs when an inner binding hides an outer one with the same name. This chain is fixed at definition time for lexical bindings — which is the foundation of closures.

Question 9

Compare var, let, and const in terms of scope, redeclaration, and reassignment.

Accepted Answer

var is function-scoped and redeclarable; let/const are block-scoped; only const forbids reassignment of the binding. var: function/global scoped, hoisted as undefined, can be redeclared in the same scope, assignable anytime. let: block-scoped, TDZ until initialized, cannot redeclare in the same scope, can reassign. const: like let but the binding cannot be reassigned after initialization — objects/arrays held by const can still be mutated unless frozen. Prefer const by default, let when reassignment is needed, and avoid var in new code except for rare legacy interop.

Question 10

What is the Temporal Dead Zone (TDZ), and how does it show up in interviews?

Accepted Answer

TDZ is the period from entering a scope until a let/const/class binding is initialized; accessing it throws ReferenceError. When a block is entered, let/const bindings exist in the environment but are uninitialized. Any read or write before the declaration statement runs throws ReferenceError — that window is the TDZ. It also affects default parameters that reference later parameters, and typeof on an undeclared let (unlike undeclared globals, typeof does not safely return 'undefined' for TDZ bindings). TDZ exists to catch use-before-define bugs that var's silent undefined hid.

Question 11

How does module scope differ from classic script global scope?

Accepted Answer

ES modules have their own top-level scope; top-level bindings do not become properties of globalThis, and modules are strict by default. A classic <script> (non-module) shares the global object: top-level var and function declarations become globalThis properties. An ES module has a Module Environment Record: top-level let/const/class/function/var stay module-private unless exported. Modules always run in strict mode, support import/export, and are deferred by default when loaded via type="module". This isolation reduces global namespace collisions and makes dependencies explicit. Cross-module sharing happens only through exports or intentional globalThis assignment.

Question 12

Explain illegal shadowing and how catch clause bindings interact with block scope.

Accepted Answer

You cannot shadow a let/const with var in nested blocks of the same function in ways the spec forbids; catch bindings are block-scoped to the catch block. Shadowing is normally allowed (let x inside a block can hide outer let x). Illegal shadowing occurs in specific cases — notably declaring a var that would hoist across a block containing a let/const of the same name, or conflicts between function-scoped and block-scoped names that the early error rules catch at parse time. A catch (err) parameter is scoped only to that catch block (like let). Optional catch binding (catch {) avoids an unused binding. In nested try/catch, each err is independent. These rules matter when transpiling or when debugging surprising SyntaxErrors about redeclaration.

Question 13

What is hoisting in JavaScript?

Accepted Answer

Hoisting is the behavior where declarations are processed during the creation phase of an execution context before code runs, so bindings exist before their line in source. During context creation, the engine registers declarations: function declarations are initialized fully; var is registered and set to undefined; let/const/class are registered but left in the TDZ. People summarize this as 'declarations are moved to the top,' but nothing is rewritten — it is environment setup. Understanding hoisting prevents bugs with use-before-define and explains differences between declaration kinds.

Question 14

How does hoisting differ between function declarations and function expressions?

Accepted Answer

Function declarations are fully hoisted and callable before their line; function expressions only hoist the variable binding (var → undefined, let → TDZ). A function foo() {} declaration is instantiated during creation, so foo() works anywhere in that scope. A function expression like var foo = function() {} only hoists foo as undefined until the assignment runs — calling early throws TypeError. With const foo = () => {}, the binding is in TDZ until initialization — calling early throws ReferenceError. Named function expressions expose the name only inside the function for recursion/debugging.

Question 15

What is logged and why?

Accepted Answer

First log prints undefined; second throws ReferenceError due to TDZ on b. var a is created and initialized to undefined during the creation phase, so reading a before assignment yields undefined. let b is also created during creation but remains uninitialized until the let b = 2 line executes, so accessing b earlier is a TDZ ReferenceError. The first console.log does run; the second statement throws and stops further execution.

JavaScript Interview Questions & Answers

JavaScript interview topics

All JavaScript interview questions

Execution Context interview questions

Scope interview questions

Hoisting interview questions

Closures interview questions

this interview questions

Prototype interview questions

OOP interview questions

Functional Programming interview questions

Async JavaScript interview questions

Event Loop interview questions

Promises interview questions

Memory Management interview questions

DOM interview questions

Browser APIs interview questions

Performance interview questions

Modules interview questions

Error Handling interview questions