The JavaScript questions that follow

Every question in a frontend interview is anchored to something in your project. These six come up because React (or any component framework) makes you use all of them, whether you noticed or not.

1. Closures

A closure is a function that keeps access to the variables of the scope it was created in, even after that scope has returned.

function counter() {
  let n = 0;                 // still alive after counter() returns
  return () => ++n;          // because this function closes over it
}
const next = counter();
next(); // 1
next(); // 2

Why it gets asked: every event handler you write inside a component is a closure over that render's props and state. That is the mechanism behind the classic React bug where a handler or an interval sees a stale value — it closed over the variable from the render in which it was created, and that render's values never change.

2. The event loop

JavaScript runs on one thread. Long-running work blocks everything, including painting. Asynchronous work — a fetch, a timer — is handed off, and its callback is queued to run once the current work finishes.

The distinction worth knowing: microtasks (promise callbacks) drain before the next macrotask (a setTimeout callback), and both wait for the currently running code to finish.

console.log("A");
setTimeout(() => console.log("B"), 0);
Promise.resolve().then(() => console.log("C"));
console.log("D");
// A D C B

If you can explain that ordering you can explain the event loop, and this exact snippet is asked constantly.

3. this

In a regular function, this is determined by how the function is called. In an arrow function it is taken from the surrounding scope at definition time and cannot be reassigned.

const obj = {
  name: "PlacedElite",
  regular() { return this.name; },        // "PlacedElite"
  arrow: () => this?.name,                // not obj — the outer scope's this
};

Why it gets asked: it is the reason arrow functions became the default for handlers and the reason older class components needed .bind(this) in the constructor.

4. == vs ===

=== compares without conversion. == converts types first, and its rules produce results nobody wants to reason about (0 == "" is true; null == undefined is true but null == 0 is false).

Use ===. The one common exception is x == null as a deliberate check for "null or undefined".

5. Reference equality and immutability

Objects and arrays compare by reference, not contents.

[1, 2] === [1, 2]   // false — two different arrays

Why this matters more in frontend than anywhere else: frameworks decide whether to re-render by comparing references. Mutating state in place produces the same reference, so the framework concludes nothing changed and the screen does not update:

items.push(newItem);     setItems(items);        // same reference — often no update
setItems([...items, newItem]);                   // new reference — updates

This is the single most common cause of "my state changed but the UI didn't". Being able to explain why, in terms of reference equality, is a strong answer.

6. Why a component re-rendered

Expect: "what causes a re-render?" The honest short answer is a state change, a prop change, or a parent re-rendering. And the follow-up: "how would you stop an unnecessary one?" — memoise the component, or stabilise the props and callbacks you pass down so their references stop changing on every render.

Do not volunteer that you optimise everything. The correct professional position is that you measure first: premature memoisation adds code and bugs for no gain, and saying so signals experience.

How to prepare these

Do not learn them abstractly. For each one, find where it appears in your own project — the handler that is a closure, the fetch that goes through the event loop, the state update that needed a new array. Then your answer is "here, in this file" rather than a recited definition, and the interview turns into a conversation about your work.

That is the whole strategy of both of these courses: know your own project deeply enough that every fundamentals question has a concrete answer attached to it.