What happens when you declare var globally versus let or const?
knowledge that var creates a Window property while let and const do not. A good answer notes var adds window.x, let/const do not pollute the global object, yet both are globally scoped.
claiming let/const lack global scope.
What's really being asked
This question tests whether you understand the distinction between global scope and the global object in browser environments. Many developers assume var, let, and const behave identically in global scope, but only var creates a property on the global Window object. The interviewer wants to see if you know where global variables live, how they can be accessed, and why this distinction matters for avoiding global namespace pollution.
The full answer
First, state that a top-level var declaration in a browser script creates a writable, configurable property on the global object, which is Window. Second, clarify that let and const declarations are also globally scoped, meaning they are accessible throughout the script, but they do not become properties of Window. Third, mention that this means window.myVar works for var but returns undefined for let or const. Fourth, note that globalThis provides a standard way to reference the global object across browsers, Workers, and Node.js, while window is browser-specific. Fifth, briefly explain that function declarations at the top level behave like var in this regard, also creating Window properties.
The mistakes people make
A major red flag is claiming that let and const are not in global scope at all. They are globally scoped; they simply do not pollute the global object. Another error is saying var is hoisted to window but let/const are not hoisted. While temporal dead zone is a real difference, the question specifically asks about global scope behavior, so pivoting to hoisting without addressing property creation misses the point. Saying all three declarations create window properties is factually wrong. Claiming the difference is about mutability rather than global object attachment is also off target.
What usually comes next
The interviewer may ask how to reliably access the global object in a cross-platform library, which is where globalThis comes in. They might ask whether this behavior changes in strict mode, which it does not for this specific distinction. They could ask what happens with global function declarations, which create Window properties just like var. Another follow-up is asking why global object pollution matters, touching on naming collisions with third-party scripts or built-in APIs.
A concrete example
Imagine a script tag in HTML with var legacy = 1; let modern = 2; const fixed = 3;. In the console, window.legacy returns 1, but window.modern and window.fixed both return undefined. However, legacy, modern, and fixed are all accessible as bare identifiers in subsequent script tags because they share the same global scope. If another script later sets window.legacy = 99, it overwrites the var binding because they reference the same property. In contrast, reassigning window.modern has no effect on the let binding since it lives in the lexical environment, not on the object.
Interview question
In a browser script, what distinguishes a top-level var declaration from let or const?
- a.let and const are not globally scoped, unlike var
- b.var creates a property on the global Window object, while let and const do not, though all three are globally scopedCorrect
- c.var is hoisted to the Window object, while let and const are not hoisted
- d.All three create Window properties, but only var allows reassignment via window.x
Why? this is the answer
var creates a writable property on the global Window object, while let and const are globally scoped without becoming Window properties. Option A is a tempting misconception because let and const are indeed globally scoped; they simply do not pollute the global object.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #javascript
- #global-scope
- #browser
- #var
- #es6
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on javascript — each one lists the topics its interview covers.
See open roles