JavaScript "this" Keyword Interview Questions

How `this` is set — the spec mechanism

Under the hood, every function call is a [[Call]] operation that receives a thisArgument. The JavaScript engine fills this in based on the call site before the function body executes. The function has no influence over what this it receives — only the caller determines it.

This is why this is called dynamic binding: it is bound fresh on every invocation, based on who called the function and how.

function show() {
  console.log(this)
}
 
// Same function — completely different 'this' based on call site
show()                      // undefined (strict) or global
show.call({ x: 1 })        // { x: 1 }
new show()                  // newly created {}
({ fn: show }).fn()         // { fn: show }

Rule 1 — Default binding: plain call, no context

function whoAmI() {
  console.log(this)
}
 
whoAmI()           // window (browser, sloppy mode)
                   // global (Node, sloppy mode)
                   // undefined (strict mode OR ES module)

Global scope: this differs by environment

// Browser — non-module script
console.log(this === window)   // true
 
// Node.js — at module top level (CommonJS)
console.log(this === module.exports)   // true — NOT global
console.log(this === global)           // false (surprise!)
 
// Node.js — inside a function (non-strict)
function fn() { console.log(this === global) }   // true
 
// ES module (type="module" in browser, .mjs in Node)
console.log(this)   // undefined — modules are always strict

The Node module-level this being module.exports (not global) surprises many senior developers. It is a common interview gotcha.

Rule 2 — Implicit binding: method call

const user = {
  name: 'Alice',
  greet() {
    console.log(`I'm ${this.name}`)   // this = user
  }
}
 
user.greet()   // "I'm Alice"

The key question: what is directly to the left of the call parentheses? That object becomes this.

// Chained property access — the LAST object before the call is 'this'
const a = {
  b: {
    c: {
      name: 'deep',
      show() { console.log(this.name) }
    }
  }
}
 
a.b.c.show()   // 'deep' — 'c' is immediately left of the call

Implicit binding loss — the most common bug:

const user = {
  name: 'Alice',
  greet() { console.log(this.name) }
}
 
user.greet()          // 'Alice' ✓ — method call
const fn = user.greet
fn()                  // undefined/TypeError ✗ — plain call, this = global/undefined
 
// The same extraction bug happens with callbacks:
setTimeout(user.greet, 1000)   // 'undefined' — setTimeout calls greet as plain fn
 
// Destructuring also extracts:
const { greet } = user
greet()   // 'undefined' — same problem

Extracting a method from an object strips its context. The function is the same; its this becomes whatever the call site provides.

Rule 3 — Explicit binding: call, apply, bind

function introduce(city, lang) {
  console.log(`${this.name}, ${city}, ${lang}`)
}
 
const alice = { name: 'Alice' }
 
// call — this + args spread
introduce.call(alice, 'Mumbai', 'JavaScript')    // 'Alice, Mumbai, JavaScript'
 
// apply — this + args array
introduce.apply(alice, ['Mumbai', 'JavaScript']) // 'Alice, Mumbai, JavaScript'
 
// bind — returns new function with 'this' permanently locked (hard binding)
const aliceIntro = introduce.bind(alice)
aliceIntro('Delhi', 'TypeScript')   // 'Alice, Delhi, TypeScript'
 
// Can you override a bound function's 'this' with call?
aliceIntro.call({ name: 'Bob' }, 'Pune', 'React')   // 'Alice, Pune, React'
// NO — bind creates a hard binding. call/apply CANNOT override it.

Hard binding: bind() creates a wrapped function that permanently enforces a specific this. Calling the bound function with call() or apply() passes arguments fine — but the this is ignored and the bound value is used. This is a deliberate design decision.

Double bind — who wins?

function show() { console.log(this.x) }
 
const bound1 = show.bind({ x: 1 })
const bound2 = bound1.bind({ x: 2 })
 
bound2()   // 1 — NOT 2
// First bind wins. bind() creates a hard-bound function.
// Calling .bind() on an already-bound function does nothing to 'this'.
// The second { x: 2 } is completely ignored.

Rule 4 — new binding: constructor call

function Person(name, age) {
  // Inside a new call, JavaScript does this automatically BEFORE your code runs:
  // 1. Creates a fresh object: this = Object.create(Person.prototype)
  // 2. Sets 'this' to that object
  // 3. Executes function body
  // 4. Returns 'this' (unless function explicitly returns a different object)
 
  this.name = name   // attached to the new object
  this.age  = age
}
 
const alice = new Person('Alice', 30)
console.log(alice.name)   // 'Alice'
 
// What happens if the constructor explicitly returns an object?
function Tricky() {
  this.x = 1
  return { x: 99 }   // returning a DIFFERENT object overrides 'this'
}
const t = new Tricky()
console.log(t.x)   // 99 — returned object replaces 'this'
 
// Returning a primitive is IGNORED — 'this' is returned instead
function Fine() {
  this.x = 1
  return 42   // primitive: ignored
}
const f = new Fine()
console.log(f.x)   // 1 — 'this' returned, 42 discarded

new vs bind — the only case new beats explicit binding

function Counter(start) {
  this.count = start
}
 
const BoundCounter = Counter.bind({ count: 999 })  // explicit binding to { count: 999 }
 
// new overrides bind — 'this' becomes the fresh object, NOT { count: 999 }
const c = new BoundCounter(10)
console.log(c.count)   // 10 — new wins! bind's 'this' is ignored.
// (But bind's pre-filled arguments still work:)
const BoundStart = Counter.bind(null, 100)
const c2 = new BoundStart()
console.log(c2.count)   // 100 — partial application preserved

new overrides bind()'s this. This is the only case where new beats explicit binding. It makes bind() useful for partial application of constructor arguments — you can pre-fill args while still letting new create fresh instances.

The binding precedence — commit this to memory

Priority	Rule	Triggered by	'this' value
1 (highest)	new binding	new fn()	Newly created object
2	Explicit binding	fn.call(x) / fn.apply(x) / fn.bind(x)()	The value x (cannot be overridden)
3	Implicit binding	obj.fn()	obj
4 (lowest)	Default binding	fn()	global (sloppy) or undefined (strict)
N/A	Arrow function	Any call	Lexical — from enclosing scope, immutable

Arrow functions — lexical this, permanently sealed

const obj = {
  value: 42,
  // Regular function — 'this' depends on call site
  regular: function() { return this.value },
  // Arrow function — 'this' locked to enclosing scope at WRITE TIME
  arrow: () => this.value    // 'this' here = whatever 'this' is at obj definition time
}
 
console.log(obj.regular())   // 42 ✓ — method call, this = obj
console.log(obj.arrow())     // undefined — 'this' is global/undefined (arrow captured outer this)
 
// Arrow function as object method is a COMMON MISTAKE
// The arrow closes over 'this' from the scope where the object literal is written
// If the object is at module/global scope, 'this' there is undefined/global — not the object

Arrow functions cannot be bound, called, or applied with a different this:

const arrow = () => this
 
// All of these silently ignore the provided 'this':
arrow.call({ x: 1 })    // outer 'this' — { x: 1 } is ignored
arrow.apply({ x: 1 })   // outer 'this' — ignored
arrow.bind({ x: 1 })()  // outer 'this' — ignored
 
// new with arrow throws:
new arrow()   // TypeError: arrow is not a constructor

The correct use of arrow functions with this:

const timer = {
  seconds: 0,
  start() {                      // regular method — called as timer.start(), this = timer
    setInterval(() => {          // arrow — inherits 'this' from start(), which is timer
      this.seconds++             // this = timer ✓
      console.log(this.seconds)
    }, 1000)
  }
}
timer.start()   // 1, 2, 3 ...

'this' in class — static vs instance vs inherited

class Animal {
  constructor(name) {
    this.name = name           // 'this' = new instance
  }
 
  speak() {
    return `${this.name} makes a noise.`  // 'this' = instance (if called as method)
  }
 
  static create(name) {
    return new this(name)      // 'this' in static = the CLASS ITSELF (or subclass)
  }
}
 
class Dog extends Animal {
  speak() {
    return super.speak() + ' Woof!'  // super.speak() calls Animal.speak with this = dog instance
  }
}
 
const d = Dog.create('Rex')   // Animal.create → new this(name) → new Dog('Rex') (polymorphic!)
console.log(d.speak())        // 'Rex makes a noise. Woof!'
 
// 'this' in static method = the class (not the instance)
class MyClass {
  static who() { return this }
}
console.log(MyClass.who() === MyClass)   // true
console.log(MyClass.who() === new MyClass())   // false — 'this' is the class, not an instance

Class methods are strict mode by default — extracting a class method and calling it as a plain function gives this = undefined, not this = global.

class Service {
  name = 'MyService'
  log() { console.log(this.name) }
}
 
const s = new Service()
s.log()            // 'MyService' ✓
 
const fn = s.log
fn()               // TypeError: Cannot read properties of undefined
                   // In class strict mode: this = undefined, not global

'this' with Array method thisArg — the hidden second parameter

// forEach, map, filter, find, findIndex, some, every all accept thisArg as second arg
const processor = {
  multiplier: 3,
  process(arr) {
    return arr.map(function(n) {
      return n * this.multiplier   // 'this' would normally be undefined/global in a callback
    }, this)                       // ← second arg sets 'this' for the callback
  }
}
 
console.log(processor.process([1, 2, 3]))   // [3, 6, 9] ✓
 
// Without thisArg — the classic array callback bug:
const obj = {
  factor: 2,
  double(arr) {
    return arr.map(function(n) {
      return n * this.factor   // this = undefined (strict), TypeError!
    })
  }
}
// Fix: use arrow function (no own 'this', inherits from double)
double(arr) {
  return arr.map(n => n * this.factor)   // arrow: this = obj ✓
}

'this' in getters and setters

const obj = {
  _name: 'Alice',
  get name() {
    return this._name   // 'this' = obj when accessed as obj.name
  },
  set name(val) {
    this._name = val.trim()   // 'this' = obj when assigned as obj.name = '...'
  }
}
 
obj.name = '  Bob  '
console.log(obj.name)   // 'Bob'
 
// BUT: destructuring a getter loses 'this'
const { name } = obj   // this executes the getter — returns the current value
// name is now 'Bob' (a string), not a live getter

Indirect calls — the trickiest 'this' interview questions

These three patterns all look like method calls but are actually default/global binding:

const obj = {
  name: 'Alice',
  greet() { return this.name }
}
 
// 1. Grouped expression — looks like method call but is NOT
;(obj.greet)()     // 'Alice' — identical to obj.greet(), grouping changes nothing
 
// 2. Comma operator — evaluates to the function, loses reference
;(0, obj.greet)()  // undefined — this is a PLAIN CALL. The comma operator evaluates
                   // the expression, which returns the function without its base object.
 
// 3. Assignment expression — same as comma
let fn
;(fn = obj.greet)()  // undefined — assignment evaluates to the function value,
                     // the object reference is lost. Plain call. this = global/undefined.
 
// 4. Logical operators — same pattern
;(false || obj.greet)()  // undefined — logical OR evaluates to obj.greet (the fn),
                         // not the reference. Plain call.
;(true && obj.greet)()   // undefined — same issue

This is one of the most asked senior-level this questions at Google and Atlassian. The key: any expression that evaluates to a function without preserving the base object reference becomes a plain call.

'this' in Promise .then callbacks

class ApiService {
  constructor() { this.baseURL = 'https://api.example.com' }
 
  fetchData() {
    return fetch(this.baseURL)    // 'this' = ApiService instance ✓ (called as method)
      .then(function(res) {
        console.log(this.baseURL) // undefined — 'this' inside .then callback is undefined (strict)
        return res.json()
      })
      .then(res => {              // arrow function — 'this' = outer ApiService instance ✓
        console.log(this.baseURL) // 'https://api.example.com'
        return res
      })
  }
}
 
// .then callbacks are always called as plain functions (in strict mode = undefined 'this')
// Arrow functions are the standard solution for .then callbacks

Mixin pattern and 'this'

// Mixins work because 'this' is dynamic — same function, different object
const Serializable = {
  serialize() {
    return JSON.stringify(this)   // 'this' will be whatever calls it
  }
}
 
const Validatable = {
  validate() {
    return this.name && this.age > 0   // 'this' will be whatever calls it
  }
}
 
class User {
  constructor(name, age) {
    this.name = name
    this.age  = age
    Object.assign(this, Serializable, Validatable)   // copy methods onto instance
  }
}
 
const u = new User('Alice', 30)
u.serialize()    // '{"name":"Alice","age":30}' — 'this' = u ✓
u.validate()     // true — 'this' = u ✓

Soft bind — filling the gap between default and hard binding

// Problem: bind() is too hard — you can't override it with implicit binding later
// Problem: no bind = lost context on plain calls
 
// Soft bind: like bind, but allows method call (implicit binding) to override
Function.prototype.softBind = function(defaultThis, ...boundArgs) {
  const fn = this
  return function(...args) {
    // If 'this' is global/undefined (default binding) → use defaultThis
    // If 'this' was set by implicit/explicit binding → use that this
    const ctx = (!this || this === globalThis) ? defaultThis : this
    return fn.apply(ctx, [...boundArgs, ...args])
  }
}
 
function greet() { console.log(this.name) }
const softBound = greet.softBind({ name: 'default' })
 
softBound()                        // 'default' — default binding → use provided fallback
softBound.call({ name: 'Alice' })  // 'Alice' — explicit binding overrides softBind
const obj = { name: 'Bob', fn: softBound }
obj.fn()                           // 'Bob' — implicit binding overrides softBind

Soft bind is rarely used in production but frequently asked as a senior-level implementation question. It shows deep understanding of this binding semantics.

React 'this' patterns — the full picture

// Pattern 1: Constructor bind (verbose, but explicit)
class Button extends React.Component {
  constructor(props) {
    super(props)
    this.handleClick = this.handleClick.bind(this)   // 'this' locked to instance
  }
  handleClick() { console.log(this.props.label) }
  render() { return <button onClick={this.handleClick}>...</button> }
}
 
// Pattern 2: Arrow class field (most common in modern React)
class Button extends React.Component {
  handleClick = () => {     // arrow: 'this' = instance at class field initialization
    console.log(this.props.label)
  }
  render() { return <button onClick={this.handleClick}>...</button> }
}
 
// Pattern 3: Inline arrow in render (new function on every render — OK for simple cases)
class Button extends React.Component {
  handleClick() { console.log(this.props.label) }
  render() {
    return <button onClick={() => this.handleClick()}>...</button>
    // New arrow created every render — if passed to PureComponent child, causes re-render
  }
}
 
// Why React needs this fix at all:
// When React calls onClick={this.handleClick}, it calls handleClick() as a plain function
// In strict mode (which React uses): this = undefined → TypeError
// The fix ensures 'this' is the component instance when the callback fires