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.

Execution Context JavaScript Interview Questions

Other JavaScript interview topics