Callback hell and how to refactor it

WHAT THIS TESTS Whether the candidate can structure asynchronous sequences cleanly and handle errors consistently, a daily concern in Node code.

A GOOD ANSWER COVERS Callback hell, also called the pyramid of doom, happens when several asynchronous steps depend on each other and each is nested inside the previous callback. The code drifts rightward, becomes hard to follow, and error handling is duplicated in every callback with no single place to catch failures. The fix is to flatten control flow. Promises let you chain steps with .then and centralize failures in one .catch. async/await goes further, letting you write asynchronous steps as if synchronous, using a normal try/catch for errors, while still being non-blocking under the hood since it is sugar over promises. Extracting named functions also helps by giving each step a clear identity and enabling reuse and testing.

COMMON WRONG ANSWERS Believing deep nesting is the only way to sequence dependent operations. Thinking async/await makes code multithreaded or parallel; it does not, the event loop is still single-threaded. Forgetting to handle rejections, which leads to unhandled promise rejections.

LIKELY FOLLOW-UPS How do you run independent async tasks in parallel rather than in series? (Promise.all). How does error propagation differ between callbacks and promises? What is an unhandled rejection?

ONE CONCRETE EXAMPLE Nested form: getUser(id, (e, u) => { getOrders(u, (e, o) => { getItems(o, (e, i) => { ... }) }) }), with error checks repeated at every level. Refactored with async/await: const u = await getUser(id); const o = await getOrders(u); const i = await getItems(o); all wrapped in one try/catch. The logic reads top to bottom, errors funnel to a single catch, and each step can be a named, testable function.