LinkedIn Hook

Before async/await existed, before Promises existed, JavaScript had exactly one tool for handling asynchronous work — the humble callback.

And for almost a decade, that single tool almost broke the language. Developers called it the "Pyramid of Doom." Twitter called it "callback hell." Every production codebase written between 2008 and 2015 carries scars from it.

But the ugly indentation was never the real disease — it was just the symptom. The actual problem is called inversion of control: you hand a function to a library, and now that library decides when your code runs, how many times it runs, and whether it runs at all. Maybe it calls your callback twice and charges the customer twice. Maybe it never calls it and the order hangs forever.

In this lesson you'll learn what a callback really is, why nesting them produces the Pyramid of Doom, the four specific problems it creates, and the deeper inversion-of-control issue that Promises were invented to fix.

If you jumped straight from callbacks to async/await without fully understanding this middle chapter — this lesson closes the gap.

Read the full lesson -> [link]

#JavaScript #InterviewPrep #Callbacks #AsyncJS #Frontend #CodingInterview #WebDevelopment

Callbacks & Callback Hell thumbnail

What You'll Learn

What a callback function actually is and why JavaScript relies on them
How nested callbacks produce the Pyramid of Doom and the four problems it creates
What "inversion of control" means and why it matters more than the indentation

What Is a Callback?

A callback is simply a function you pass to another function, saying "call this when you're done." Think of it like leaving a note for your roommate: "When the delivery arrives, put it on the kitchen table." You don't wait around — you hand off the task and the instruction together.

function fetchUserData(userId, callback) {
  setTimeout(() => {
    const user = { id: userId, name: "Rakibul" };
    callback(user);
  }, 1000);
}

fetchUserData(1, (user) => {
  console.log(user); // { id: 1, name: "Rakibul" }
});
console.log("This runs first!");

Notice "This runs first!" prints before the user data — the callback is scheduled for later, and the current call stack finishes synchronously in the meantime.

The Callback Hell Problem (Pyramid of Doom)

Real applications chain async operations — fetch a user, then their orders, then order details, then shipping status. With callbacks, each step nests inside the previous one:

// Callback Hell — the "Pyramid of Doom"
getUser(userId, (err, user) => {
  if (err) {
    console.error("Failed to get user:", err);
    return;
  }
  getOrders(user.id, (err, orders) => {
    if (err) {
      console.error("Failed to get orders:", err);
      return;
    }
    getOrderDetails(orders[0].id, (err, details) => {
      if (err) {
        console.error("Failed to get details:", err);
        return;
      }
      getShippingStatus(details.trackingId, (err, status) => {
        if (err) {
          console.error("Failed to get status:", err);
          return;
        }
        console.log("Shipping status:", status);
        // ... even more nesting?
      });
    });
  });
});

The problems here go far beyond ugly indentation:

Pyramid of Doom — code grows horizontally, becoming unreadable.
Inversion of Control — you hand your callback to another function and trust it to call it correctly, once, at the right time. You have no guarantee.
Error handling is manual — every level needs its own if (err) check. Miss one and errors vanish silently.
Hard to reason about — control flow is scattered across nested functions.

Inversion of Control — The Deeper Problem

// You're trusting thirdPartyCheckout to call your callback correctly
thirdPartyCheckout(cart, () => {
  // What if this gets called twice? You charge the customer twice.
  // What if it's never called? The order hangs forever.
  // What if it's called synchronously instead of async?
  chargeCustomer(cart.total);
  sendConfirmationEmail();
});

With callbacks, the callee controls when and how your continuation runs. Promises flip this — you control the flow, because a Promise is a trustable object you chain onto from the outside.

Callbacks & Callback Hell visual 1

Common Mistakes

Thinking callback hell is purely an indentation problem — the real disease is inversion of control, not the whitespace.
Forgetting to handle the error argument at every level — in Node-style (err, result) callbacks, skipping a single if (err) silently swallows failures up the chain.
Assuming your callback will be called exactly once — third-party functions can call it zero times, twice, or synchronously, and any of those can corrupt your program state.

Interview Questions

Q: What is a callback function?

A function passed as an argument to another function, to be executed at a later time — typically after an async operation completes.

Q: What is callback hell and why is it a problem?

Callback hell (pyramid of doom) occurs when multiple async operations are nested inside each other's callbacks. It creates deeply indented, hard-to-read code with scattered error handling. The deeper issue is inversion of control — you surrender your program's continuation to another function with no guarantees about how it will be called.

Q: What is inversion of control in the context of callbacks?

When you pass a callback to a third-party function, you lose control over when, how many times, and whether your callback is invoked. The external function controls your program's flow. Promises solve this by returning a trustable object that you chain onto, keeping control in your hands.

Q: Name three problems with callback-based async code.

(1) The Pyramid of Doom makes nested async code unreadable, (2) every level needs manual if (err) error handling, and (3) you inherit inversion of control — the callee decides when/if/how-often your callback fires.

Quick Reference — Cheat Sheet

CALLBACKS — QUICK MAP

Definition:
  A function passed into another function, called later.

Shape (Node-style):
  fn(arg, (err, result) => { ... })

Problems when nested:
  1. Pyramid of Doom        -> unreadable indentation
  2. Inversion of Control   -> callee controls your flow
  3. Manual error plumbing  -> if (err) at every level
  4. Hard to compose        -> no return values to chain

Escape hatch:
  Promises + async/await (next lessons)

Previous: Starvation of Callbacks Next: Promises — Chaining & Error Handling

This is Lesson 3.6 of the JavaScript Interview Prep Course — 14 chapters, 87 lessons.

Callbacks & Callback Hell