ES6 Interview Questions and Answers

What is the difference between let, const and var?

`var` is function-scoped and hoisted with an initial value of `undefined`, so reading it before its declaration is legal and returns `undefined`. `let` and `const` are block-scoped and hoisted without initialisation, which puts them in the temporal dead zone — accessing them early throws a ReferenceError rather than silently giving you a wrong value. `const` additionally prevents reassignment of the binding.

The point people miss is that `const` freezes the binding, not the value. A const object's properties are freely mutable, which is why `const` is safe to use as the default even for arrays and objects you intend to update immutably. Use `let` only where a value genuinely has to be reassigned, and treat any remaining `var` in a codebase as legacy.

How do arrow functions differ from normal functions?

Arrow functions are not just shorter syntax. They have no `this` of their own, so `this` resolves lexically to the enclosing scope; they have no `arguments` object; they cannot be used as constructors with `new`; and they have no `prototype` property. That lexical `this` is the whole reason they exist — it removes the `const self = this` and `.bind(this)` boilerplate that callbacks used to need.

So the rule is simple to state and worth stating in an interview: use arrow functions for callbacks and anything that should inherit the surrounding `this`; use regular functions for object methods, for constructors, and for anything that needs its own `this` or `arguments`. Getting that distinction right in one sentence answers three follow-up questions before they are asked.

The interview framing to have ready is that arrow functions did not replace regular functions — they gave you a choice you did not previously have. Before ES6, every function got its own `this`, so callbacks needed `.bind(this)`, a `self` variable, or the little-known second argument some array methods accept. Arrow functions made "inherit the surrounding this" the default for the case where it is almost always what you want.

How does destructuring work, including defaults and renaming?

Destructuring extracts values from arrays by position and from objects by key, in a single statement. You can rename as you extract, supply defaults, nest patterns, and use rest to collect whatever is left. It is one of the features that most changes how everyday code reads, which is why interviews test the edge cases rather than the basics.

That last case is the one that catches people out and it applies to default parameters too. A default fires only when the value is `undefined` — passing `null`, `0`, `false` or an empty string uses the value you passed. This is deliberate and it is the difference from the old `x = x || fallback` idiom, which also replaced every falsy value and quietly broke on legitimate zeros.

Destructuring is also what makes React function components read the way they do. Writing `function Button({ label, variant = "primary", ...rest })` is object destructuring with a default and a rest collection, all in the parameter list — and the `rest` there is what gets spread onto the underlying element. Being able to name each part of that signature is a small thing that reads as fluency rather than pattern-matching.

What is the difference between spread and rest?

Same three dots, opposite directions, distinguished by where they appear. Rest collects remaining items into an array or object and only appears in a parameter list or on the left of a destructuring assignment. Spread expands an iterable into individual elements and appears in a call, an array literal or an object literal.

One practical warning about spread that comes up in code review more than in interviews: order matters in object spread, and later keys win. `{ ...defaults, ...overrides }` behaves as you would hope, while the reverse silently discards the overrides. The same rule makes `{ ...props, className: x }` a deliberate override and `{ className: x, ...props }` an accident waiting to happen.

Are ES6 classes just syntactic sugar?

Mostly, but not entirely — and the exceptions are what get asked. A class still creates a constructor function with methods on its prototype, so the underlying model is unchanged. What differs is that class declarations are not hoisted in a usable way, class bodies always run in strict mode, methods are non-enumerable, and calling a class without `new` throws instead of silently misbehaving.

Private fields are the newest part of that list and the one worth volunteering. A `#name` field is enforced by the language rather than by convention, so it is genuinely unreachable from outside the class — unlike the old underscore prefix, which was only ever a request. Accessing one from outside is a syntax error at parse time, not a runtime undefined, which is a meaningfully stronger guarantee.

What is the difference between ES modules and CommonJS?

ES modules use `import` and `export` and are statically analysable: the imports are known before the code runs, which is what makes tree shaking possible. CommonJS uses `require` and `module.exports`, resolves at runtime, and can therefore be called conditionally inside a function. ES module imports are also live bindings — if the exporting module reassigns the value, importers see the new one — whereas `require` copies the value at the moment it runs.

Modules also changed two things people forget to mention: module code is always strict mode, and top-level `this` is `undefined` rather than the global object. Both catch out scripts copied from an older codebase into a module without adjustment, and both are reasonable follow-ups if you claim familiarity with the difference.

A useful way to answer the modules question is to say what each one made possible rather than listing syntax. Static imports are why bundlers can drop unused exports, why your editor can rename a symbol across files reliably, and why a circular import is detectable at build time instead of producing a half-initialised object at runtime. Those consequences are what the interviewer is checking you understand.

When should you use Map and Set instead of objects and arrays?

Use a `Map` when keys are not strings, when insertion order matters, when you add and remove entries frequently, or when key names could collide with inherited properties. Use a `Set` for uniqueness. Objects remain the right choice for records with known fields and for anything you need to serialise to JSON, since neither Map nor Set survives `JSON.stringify`.

One more distinction worth having ready: `Set` gives you uniqueness by the same rules as `===`, with the single exception that it treats `NaN` as equal to itself. So a Set deduplicates primitives perfectly but does nothing for objects with identical contents, because those are still separate references. If someone asks you to dedupe an array of objects, the answer is a Map keyed on whatever field defines identity, not a Set.

What other ES6+ features come up?

The query says ES6 but interviewers usually mean modern JavaScript generally, so the newer additions are fair game. Optional chaining and nullish coalescing in particular appear constantly, because they replaced defensive code that was both verbose and subtly wrong.

Two of those deserve emphasis because they changed everyday code the most. Optional chaining removed the long `a && a.b && a.b.c` guards that used to precede every nested read, and nullish coalescing fixed the bug those guards often introduced by treating a legitimate zero as missing. Generators and iterators round out the list and are worth a sentence even if you never write one. Any object implementing `Symbol.iterator` works with `for…of`, spread and destructuring — which is why those three all work on Maps, Sets and strings but not on plain objects. That single fact explains a lot of otherwise arbitrary-looking behaviour.