The JavaScript Beginner Interview

undefined means 'this has not been assigned a value', it's what you get from an uninitialised variable, a missing object property, a missing function argument, or a function with no return. null is an intentional 'no value here', something you assign deliberately to say 'empty on purpose'.

typeof undefined is 'undefined', but typeof null is 'object', a famous, un-fixable bug preserved for backwards compatibility. To check for null specifically you compare value === null.

=== is strict equality: no type conversion, different types are never equal. == is loose equality: it coerces the operands toward a common type first, which produces famously non-transitive results.

The output:

• 0 == '' → true ('' coerces to 0)
• 0 == '0' → true ('0' coerces to 0)
• '' == '0' → false (both strings, compared as-is)
• null == undefined → true (a special case in the spec)
• null === undefined → false (different types)

That first trio, 0 == '' and 0 == '0' are true but '' == '0' is false, is why the rule is: always use `===`, and treat == null as the one deliberate exception (it matches both null and undefined).

There are exactly eight falsy values: false, 0, -0, 0n (BigInt zero), '', null, undefined, and NaN. Everything else, including '0', 'false', [], and {}, is truthy.

|| returns the right side when the left is falsy, so count || 10 replaces 0 with 10, often a bug. ?? (nullish coalescing) only falls through when the left is null or undefined, so count ?? 10 keeps a legitimate 0. Use ?? when 0, '', or false are valid values you want to preserve.

• 1 + '2' → '12'. + with a string means concatenation, so 1 becomes '1'.
• '5' - 1 → 4. - has no string meaning, so '5' is coerced to the number 5.
• '5' + + '5' → '55'. The unary + turns the second '5' into number 5, then + concatenates '5' and 5 → '55'.
• [] + [] → ''. Arrays coerce to strings for +; an empty array becomes ''.
• typeof NaN → 'number'. NaN is a numeric value meaning 'not a valid number', and it's the only value not equal to itself.

The lesson: + is overloaded (concat vs add), while the other arithmetic operators always coerce to number.

Three axes: scope, re-assignment, and hoisting.

• var is function-scoped and hoisted, initialised to undefined before its line runs. It can be re-declared and re-assigned, and it leaks out of blocks.
• let is block-scoped, can be re-assigned but not re-declared in the same scope, and lives in the temporal dead zone until its declaration, reading it early throws.
• const is block-scoped like let but can't be re-assigned. Note it doesn't freeze the value: a const object's properties can still change.

In modern code I default to const, switch to let only when I genuinely re-assign, and avoid var entirely, its function scoping causes the classic loop bugs.

First line prints undefined. var a is hoisted, the declaration moves to the top of the scope, but the assignment (= 1) stays put, so a exists but is undefined when logged.

foo() prints 'hi'. Function declarations are hoisted whole, body and all, so you can call them before they appear.

The console.log(b) line throws a ReferenceError. let and const are hoisted too, but they sit in the temporal dead zone until their declaration executes, so accessing b early is an error, not undefined. That TDZ is a feature, it turns a silent bug into a loud one.

A closure is a function bundled together with the variables from the scope where it was defined, it keeps access to those variables even after the outer function has returned. Functions in JS 'remember' their birthplace.

A practical use is a private counter: the inner functions close over count, which nothing outside can read or corrupt directly, that's encapsulation without a class:

this is determined by how a function is called, not where it's defined. Call it as obj.method() and this is obj; call the same function bare (fn()) and in a regular function this is undefined in strict mode (or the global object otherwise). That's why a method passed as a callback 'loses' its this.

Arrow functions don't have their own `this`, they capture it lexically from the surrounding scope at definition time. So inside a class method, an arrow callback (arr.forEach(x => this.handle(x))) keeps pointing at the instance, which is exactly what you want. The trade-off: never use an arrow function as an object method or constructor, because it won't get the calling object as this.

Destructuring unpacks values from arrays or objects into variables: const { name, age } = user or const [first, second] = arr. You can rename ({ name: n }), set defaults ({ age = 0 }), and pull nested values.

Both spread and rest use ...; direction is what differs:

• Spread expands an iterable into individual elements, [...a, ...b] to merge arrays, { ...obj, x: 1 } to copy-and-override, or fn(...args) to pass an array as arguments.
• Rest collects the remainder into one variable, function f(first, ...others) gathers extra args into an array, and const { a, ...others } = obj collects the leftover properties.

Rule of thumb: spread on the right-hand side (spreading out), rest on the left-hand side or in a parameter list (gathering in).

It prints 2, then 2.

Objects are held by reference. const b = a copies the reference, not the object, so a and b point at the same object, mutating through b is visible through a. Hence a.count is 2.

Inside reset, obj is a copy of the reference. Re-assigning obj = { count: 0 } just repoints the local variable at a new object; it doesn't touch what a points to. If instead we'd written obj.count = 0 (mutating the shared object), a.count would become 0. Primitives (numbers, strings, booleans) are copied by value and don't have this behaviour.

Mutating (change in place, return varies): push, pop, shift, unshift, splice, sort, reverse, fill.

Non-mutating (return a new array or value, leave the original alone): map, filter, reduce, slice, concat, flat, and the newer toSorted/toReversed/with.

It matters because mutation causes bugs when data is shared, especially in React/Redux, where state must be treated as immutable so change detection works. Reaching for the non-mutating variants (or copying first with [...arr].sort()) keeps side effects out of shared state.

Chain the three workhorse methods, each doing one job, filter to keep evens, map to square, reduce to sum:

Each step returns a new array (or value) and never mutates nums. You could fold it into a single reduce for one pass instead of three, the chain just reads more clearly, which is usually the right call unless the array is huge.

querySelector/querySelectorAll take any CSS selector and are what I reach for by default. The key subtlety: querySelectorAll returns a static `NodeList`, a snapshot that doesn't update if the DOM changes, whereas getElementsByClassName/getElementsByTagName return a live `HTMLCollection` that does auto-update.

The live collection surprises people: iterating it while adding/removing matching elements can loop forever or skip items. NodeList from querySelectorAll also supports forEach directly; HTMLCollection doesn't, so you spread it ([...coll]) first.

Bubbling: when an event fires on an element, it then fires on that element's ancestors in turn, up to document. A click on a <button> inside a <li> inside a <ul> triggers handlers on the button, then the li, then the ul.

Event delegation uses that: instead of attaching a listener to every child, you attach one listener to the parent and check event.target to see what was actually clicked:

It's useful because (1) it's far fewer listeners, better memory and setup cost, and (2) it automatically covers elements added after you wired it up, which per-element listeners don't.

It's about when the script downloads and executes relative to HTML parsing:

• Plain `<script>`: parsing stops, the script downloads and runs, then parsing resumes. It blocks rendering, worst for perf if placed in <head>.
• `async`: downloads in parallel with parsing, then runs as soon as it's ready, pausing the parser at that moment. Order between multiple async scripts isn't guaranteed. Good for independent third-party scripts (analytics).
• `defer`: downloads in parallel, but waits to run until parsing is finished, and runs deferred scripts in order. Best default for your own app scripts that touch the DOM.

The JS engine runs your code on a single call stack, one thing at a time. But the browser (or Node) provides extra capabilities, timers, network, the DOM, that run outside that thread. When you call fetch, JS hands the request off to the browser and immediately continues; it doesn't sit and wait.

When the response is ready, the browser queues your callback. The event loop waits until the call stack is empty, then pulls queued work onto the stack to run. So the main thread is never blocked waiting on I/O, it's free to keep handling clicks and rendering. We express that queued work with callbacks, Promises, or async/await.

A Promise is an object representing a value that isn't ready yet, it's in one of three states: pending, fulfilled, or rejected. You attach reactions with .then/.catch, or consume it with await. It fixes 'callback hell' by making async steps chainable and giving errors a single path.

With async/await the nested version flattens out, and one try/catch covers both steps:

(This assumes getUser/getPosts return promises; a callback-only API would be wrapped in new Promise first.)