Blocking versus non-blocking I/O in Node

WHAT THIS TESTS Whether the candidate understands the foundational difference that makes Node suitable for I/O-heavy workloads, and the practical danger of synchronous APIs.

A GOOD ANSWER COVERS Blocking I/O means the calling thread waits, doing nothing, until the operation finishes and returns the result. In Node, where JavaScript runs on a single thread, a blocking call freezes the entire event loop: no other requests, timers, or callbacks run until it completes. Non-blocking I/O returns control to the program immediately; the actual work proceeds in the background (via libuv's thread pool or OS async facilities) and the result is delivered later through a callback, a promise, or an event. This lets one thread keep many operations in flight. The synchronous variants in Node are suffixed Sync and should be reserved for startup or scripts, never hot request paths.

COMMON WRONG ANSWERS Believing non-blocking means JavaScript runs on multiple threads; the JS callback execution is still single-threaded. Using readFileSync inside an HTTP handler under load. Confusing returning quickly with the work being instantaneous.

LIKELY FOLLOW-UPS Where does the background work actually run? When is a Sync API acceptable? How do promises and async/await relate to callbacks here? What happens to throughput if you block?

ONE CONCRETE EXAMPLE Blocking: const data = fs.readFileSync('big.txt'); console.log('read'); console.log('after'). The program cannot print after until the whole file is read, and during that time no other request is served. Non-blocking: fs.readFile('big.txt', (err, data) => console.log('read')); console.log('after'). Here after prints first because readFile returns immediately, the read happens in the background, and the callback runs later when data is ready, leaving the event loop free to handle other work in the meantime.