JavaScript & Node.js Interview Questions

The double equals operator performs type coercion before comparing: if the two values have different types, JavaScript converts one to match the other before checking equality. Triple equals, the strict equality operator, skips that conversion and returns false if the types differ. In practice I default to === everywhere because the coercion rules for == are complex enough that even experienced developers get them wrong: 0 == false is true, null == undefined is true, but null == false is false. The only case where I reach for == intentionally is a null check like value == null, which catches both null and undefined in one expression without any other surprises.

I picture the event loop as a single-threaded waiter in a restaurant. The waiter takes one order, hands it to the kitchen (the OS), and immediately turns back to take the next order. When the kitchen is done, it rings a bell and the callback enters the task queue. The waiter finishes what it is currently doing, then picks up the next queued item. That is Node.js in one image: one thread, non-blocking I/O, callbacks queued by the OS. The subtle part is the microtask queue: resolved Promises and queueMicrotask callbacks drain completely before the event loop moves to the next macrotask. So long-running microtask chains can still stall the loop even when no I/O is blocked.

Node.js runs JavaScript on a single thread, and its speed for I/O comes from a simple principle: instead of blocking while waiting for a disk read or network response, it registers a callback and moves on. libuv handles the actual I/O asynchronously under the hood, queuing completions back onto the event loop. The thread is almost always free to take new work, which is why a single Node process can handle thousands of concurrent connections with very little memory. The catch is CPU: if I run a tight computation loop, I monopolize that one thread and nothing else runs. For CPU-heavy work I move the task to a worker thread or a separate process, keeping the event loop free for the I/O the runtime was designed for.

I split the app by concern from day one. Routes live in a routes/ folder, each resource in its own file. Business logic lives in a services/ layer that routes call into. Data-access functions live one layer below that. Middleware is registered centrally in app.js and never buried inside route handlers. I keep index.js to a handful of lines: import the app, attach a port, start listening. The rule I enforce on every team is: route handlers should read like a table of contents, not contain logic. If a handler grows past ten lines, something belongs in a service. That structure survives team growth because every new file follows the same pattern automatically.

My first move is to look at numbers before touching code. I check response time percentiles in my APM tool, not averages, because p95 and p99 are where the real pain lives. Then I attach Chrome DevTools profiler (or 0x) to the running process: it samples the event loop, garbage collection, and I/O in one shot and points me at the biggest contributor. If the flame graph shows a hot synchronous path, I check whether a library is blocking the main thread. If it shows I/O wait, I look at query plans and connection pool saturation. For CPU-bound slowness I run --inspect in staging and record a CPU profile in Chrome DevTools. Nine times out of ten the culprit is an unindexed query, a missing pool limit, or a synchronous JSON parse on a large payload.

My first move is to confirm I actually have a leak rather than a one-time allocation spike. I run the service under realistic load and watch heap usage over time with process.memoryUsage() or a Prometheus gauge. If RSS climbs without recovery across multiple GC cycles, I take a sequence of heap snapshots using Chrome DevTools connected over --inspect, then compare them to find which constructor is accumulating. Common culprits in Node are event listeners never removed from an EventEmitter, closures holding references in module-level arrays, and unbounded in-memory caches. Once I identify the growing object class, I trace back to where instances are created and add the missing cleanup or cap the collection size.