JavaScript 'this' Interview Questions

What determines the value of `this`?

The call site, not the definition site. This is the single sentence to lead with, because every confusing `this` behaviour in JavaScript follows from it. The same function can produce four different values of `this` depending on how it is invoked, which is why you cannot answer a `this` question by looking at where the function was written — you have to find where it was called.

The rules apply in a fixed precedence order, and working through them in that order turns every puzzle into a mechanical check. Was it called with `new`? Then `this` is the new object. Was it called with `call`, `apply` or a bound wrapper? Then `this` is what was supplied. Was there an object before the dot? Then `this` is that object. Otherwise it is the default — `undefined` in strict mode and in modules, or the global object in sloppy mode.

Why does `this` get lost when you pass a method around?

Because implicit binding depends on the call site, and extracting a method destroys the call site. `obj.greet` is just a reference to a function — the connection to `obj` exists only in the moment of the `obj.greet()` call. Assign it to a variable, pass it as a callback, or hand it to `setTimeout`, and the function is later called plainly, so rule four applies and `this` is `undefined`.

The wrapper version is worth understanding rather than just copying. `() => user.greet()` works not because arrow functions are magic but because the arrow function's body contains a full `user.greet()` call — the dot is back, so implicit binding applies as normal. That is a much better answer than "arrow functions fix this", which is the thing most candidates say and which is not quite true.

How are arrow functions different?

Arrow functions have no `this` of their own at all. They are not bound to anything at call time — they simply do not participate in the rules, so a reference to `this` inside one resolves outward through the scope chain to the nearest enclosing function that does have one. That is why `call` and `apply` cannot change an arrow function's `this`: there is nothing there to change.

So the rule to state is a placement rule, not a preference. Use an arrow function when you want the surrounding `this` — callbacks, effects, handlers defined inside a method or component. Use a regular function when the function needs its own `this` — object methods, constructors, and prototype methods. Saying that as one sentence answers several likely follow-ups at once.

A detail worth volunteering is that class fields holding arrow functions are per-instance rather than shared on the prototype. That is the trade being made: you spend one function object per instance in exchange for a method that can be detached safely. For a handful of components it is irrelevant; for a list of ten thousand rows each holding four handlers, it is a real cost and worth knowing you chose it.

What is the difference between call, apply and bind?

All three set `this` explicitly. `call` and `apply` invoke the function immediately and differ only in how arguments are passed — individually for `call`, as an array for `apply`. `bind` invokes nothing; it returns a new function permanently tied to the `this` you supplied, which is what makes it right for callbacks you are handing to someone else.

That last line is a favourite follow-up. A bound function ignores any later attempt to change its `this`, including a second `bind`. The one thing that does override it is `new` — constructing a bound function creates a fresh object and uses that, because `new` sits above explicit binding in the precedence order. Being able to explain that ordering is a strong signal that you learned the rules rather than the symptoms.

What is `this` inside an event handler?

With `addEventListener` and a regular function, `this` is the element the listener is attached to — the DOM sets it explicitly, which is really rule two in disguise. With an arrow function it is whatever the surrounding scope had, which is usually the component or module. The `event.currentTarget` property gives you the element in both cases, which is why it is the more reliable choice.

There is a reason apply survived even though spread can now do the same job. Passing an array of arguments through is still clearer in code that builds argument lists dynamically, and it appears throughout older library source you will read. Modern code usually writes `fn.call(obj, ...args)` instead, which is the same thing with the array expanded at the call site.

How does `this` behave in classes and with React?

Class bodies always run in strict mode, so a detached method gets `undefined` rather than the global object — which is why the React class-component era was full of constructor binding. Every `this.handleClick = this.handleClick.bind(this)` line in an older codebase exists purely because passing `this.handleClick` to `onClick` extracts the method and destroys the implicit binding.

That last comment is the point worth making if the conversation turns to hooks. Function components do not solve the `this` problem cleverly; they remove it, because state comes from a closure rather than from an object. When someone asks why hooks replaced classes, the disappearance of `this` binding is one of the three answers the React team themselves gave, alongside logic reuse and lifecycle methods grouping code by timing rather than by concern.

What is `this` at the top level and in modules?

It depends on the context, and the answer changed with modules. In a classic script in a browser, top-level `this` is `window`. Inside an ES module it is `undefined`, because modules are always strict and have their own scope. In Node's CommonJS modules it is `module.exports`, which is an empty object. This inconsistency is exactly why `globalThis` was added — it is the one expression that reliably names the global object everywhere.

One more context worth having ready, because it appears in output questions: a nested regular function inside a method does not inherit the method's `this`. It gets its own, resolved by the same four rules — and since it is usually called plainly, that means undefined. This is precisely the bug the old `const self = this` idiom existed to work around, and the reason arrow callbacks inside methods feel so natural today.

How do you answer a `this` output question?

Work the precedence list out loud, in order, every time. It takes ten seconds, it is right on cases you have never seen, and the interviewer can hear the method rather than guessing whether you recognised the example. Most `this` puzzles are constructed specifically to defeat pattern matching, so a memorised answer usually fails on the second variation.

1. Find the call site — where is the function actually invoked, not where it is written?
2. Is it an arrow function? If so, ignore the rules and look at the enclosing scope.
3. Was it called with `new`? Then `this` is the new object.
4. Was it called with call, apply, or is it a bound function? Then `this` is what was supplied.
5. Is there an object immediately before the dot? Then `this` is that object.
6. Otherwise it is the default: `undefined` in strict mode or a module, `globalThis` in sloppy mode.

One extra habit helps on trick questions: check whether the function was extracted from its object anywhere between definition and call. That single step catches the majority of puzzles, because losing the receiver is the mechanism nearly all of them are built on — whether the extraction is an assignment, a callback, a destructure, or a method passed straight into another function.