JavaScript Callback Interview Questions

Callbacks are just functions passed as arguments

Before anything else: a callback is not special syntax. It's just a function you pass to another function. The receiving function decides when to call it.

// Synchronous callback — called immediately, inline
function doTwice(fn) {
  fn()
  fn()
}
doTwice(() => console.log('hello'))  // 'hello', 'hello'

// Event-driven callback — called when the event fires
document.addEventListener('click', (event) => {
  console.log('clicked at', event.clientX, event.clientY)
})

// Async callback — called when the async work completes
setTimeout(() => {
  console.log('1 second has passed')
}, 1000)

// All three are the same concept — a function given to another function to call

Synchronous vs asynchronous callbacks — a critical distinction

// Synchronous callback — runs BEFORE the next line
const doubled = [1, 2, 3].map(n => n * 2)
console.log(doubled)  // [2, 4, 6] — map's callback ran first, synchronously

// Asynchronous callback — runs AFTER the current call stack clears
setTimeout(() => console.log('async'), 0)
console.log('sync')
// Output: 'sync', 'async'
// Even with 0ms delay, setTimeout's callback is a macrotask — runs after sync code

// This inconsistency is a common bug source:
function getUserData(id, callback) {
  if (cache[id]) {
    callback(cache[id])   // synchronous if cached
  } else {
    fetch(`/api/${id}`)
      .then(r => r.json())
      .then(callback)     // asynchronous if not cached
  }
}
// Callers can't know if their callback fires sync or async — unpredictable!

The rule (popularised by Node.js): always call callbacks asynchronously. If you have a synchronous result, use process.nextTick() or Promise.resolve().then() to defer it. Consistent behavior is safer than micro-optimizing away the async hop.

The Node.js error-first callback convention

Node.js standardized a callback signature: the first argument is always an error (null if none), and subsequent arguments are the results. This is the "error-first" or "errback" pattern. Every Node.js core API uses it.

const fs = require('fs')

// Error-first callback: (err, result)
fs.readFile('./config.json', 'utf8', (err, data) => {
  if (err) {
    console.error('Failed to read file:', err.message)
    return  // ← always return after handling the error
  }
  const config = JSON.parse(data)
  console.log(config)
})

// Building your own following the same convention:
function divide(a, b, callback) {
  if (b === 0) {
    callback(new Error('Division by zero'))
    return
  }
  callback(null, a / b)
}

divide(10, 2, (err, result) => {
  if (err) return console.error(err.message)
  console.log(result)  // 5
})

Callback Hell — why it happens, what it looks like

When async operations depend on each other's results, callbacks nest. Three levels deep, code becomes hard to read. Five levels deep, it becomes unmaintainable. This is "callback hell" or the "pyramid of doom."

// Callback hell — real-world example: login → get profile → get friends → get their posts
loginUser(username, password, (err, user) => {
  if (err) return handleError(err)

  getUserProfile(user.id, (err, profile) => {
    if (err) return handleError(err)

    getFriends(profile.id, (err, friends) => {
      if (err) return handleError(err)

      friends.forEach(friend => {
        getRecentPosts(friend.id, (err, posts) => {
          if (err) return handleError(err)

          posts.forEach(post => {
            renderPost(post)  // now we're 5 levels deep
          })
        })
      })
    })
  })
})

The problems: deeply indented code that's hard to read, error handling repeated at every level, variables from outer scopes trapped in closures at each level, and the logic flows right then down in an inverted triangle.

Escaping callback hell — three strategies

Strategy 1: Named functions (flatten the pyramid)

// Extract each level into a named function
function onLogin(err, user) {
  if (err) return handleError(err)
  getUserProfile(user.id, onProfile)
}

function onProfile(err, profile) {
  if (err) return handleError(err)
  getFriends(profile.id, onFriends)
}

function onFriends(err, friends) {
  if (err) return handleError(err)
  friends.forEach(f => getRecentPosts(f.id, onPosts))
}

function onPosts(err, posts) {
  if (err) return handleError(err)
  posts.forEach(renderPost)
}

loginUser(username, password, onLogin)
// Same logic, flat structure — no more pyramid

Strategy 2: Promisify (modernize the API)

const { promisify } = require('util')

// Convert Node.js callback functions to Promise-returning functions
const readFile = promisify(fs.readFile)
const writeFile = promisify(fs.writeFile)

// Now use them with async/await
async function processConfig() {
  const data   = await readFile('./config.json', 'utf8')
  const config = JSON.parse(data)
  config.updated = Date.now()
  await writeFile('./config.json', JSON.stringify(config))
}

// Manual promisification — how util.promisify works:
function promisify(fn) {
  return function(...args) {
    return new Promise((resolve, reject) => {
      fn(...args, (err, result) => {
        if (err) reject(err)
        else resolve(result)
      })
    })
  }
}

Strategy 3: Async libraries (for complex flows)

// async.js — control flow for callback-based code (pre-Promises era)
const async = require('async')

// Series — run in order, each waits for previous
async.series([
  callback => loginUser(username, password, callback),
  callback => getUserProfile(userId, callback),
  callback => getFriends(profileId, callback),
], (err, results) => {
  if (err) return handleError(err)
  const [user, profile, friends] = results
})

Callbacks and closures — how they share state

// Callbacks close over surrounding variables — this is how they share context
function createCounter() {
  let count = 0  // closed over by the callback

  return {
    increment: () => count++,   // callback — closes over count
    decrement: () => count--,   // callback — same count
    getCount:  () => count      // callback — same count
  }
}

const counter = createCounter()
counter.increment()
counter.increment()
counter.getCount()  // 2

// The classic loop bug — callbacks close over a shared variable
for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100)  // all print 3 — share the same i
}

// Fix with let (block-scoped, new i per iteration)
for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100)  // 0, 1, 2
}

// Fix with IIFE (pre-ES6)
for (var i = 0; i < 3; i++) {
  ;(function(j) {
    setTimeout(() => console.log(j), 100)  // 0, 1, 2 — j is captured per call
  })(i)
}

Inversion of control — the fundamental problem with callbacks

When you pass a callback to a third-party function, you lose control over how it's called. The third party decides: when to call it, how many times, with what arguments, whether to call it at all, synchronously or asynchronously. Promises were designed specifically to reclaim that control.

// You have no guarantee the library calls your callback:
// - Once (it might call it multiple times)
// - At all (it might swallow errors and never call it)
// - Asynchronously (it might call it synchronously, breaking your assumptions)
// - With the right arguments (it might pass garbage)

thirdPartyLibrary.process(data, function(result) {
  chargeCustomer(result)  // called multiple times = charged multiple times!
})

// With Promises, you take back control:
// A Promise settles exactly once — fulfilled or rejected, never both, never twice
thirdPartyLibrary.processAsync(data)
  .then(result => chargeCustomer(result))
  .catch(err => handleError(err))
  // .then() on a settled Promise only ever fires once — guaranteed by spec