Node.js Developer Interview Questions

Your JavaScript code runs on one main thread. Node doesn't spin up a new thread for every incoming request the way some older server models do. Instead, it hands off slow operations like file reads or network calls to the system, then keeps the main thread free to handle other work while it waits.

Node's package manager. It installs and manages the third-party libraries your project depends on, and it ships with Node itself, so if you have Node installed, you already have npm. Almost every Node project leans on npm packages for things you'd rather not write from scratch, like parsing dates or hashing passwords.

It's the manifest file at the root of a Node project. It lists the project's name and version, its dependencies and their version ranges, and scripts you can run with npm run. Delete it and your project technically still has code, but nothing knows how to install or run it correctly anymore.

dependencies are packages your application actually needs to run in production, like Express. devDependencies are tools you only need while developing, like a testing framework or a linter. Running npm install --production skips devDependencies entirely, which keeps a deployed app's footprint smaller.

require() is the original CommonJS syntax, loaded synchronously. import is the newer ES Modules syntax, statically analyzed by the engine before anything runs. Node supports both today, though mixing them in the same file takes some care around file extensions and a type field in package.json.

Synchronous code runs line by line, and each line blocks until the previous one finishes. fs.readFileSync is a synchronous example. Asynchronous code lets Node move on to other work while a slow operation, like fs.readFile, completes in the background, then comes back to handle the result once it's ready.

A callback is a function passed as an argument, meant to run once some operation finishes. Early Node leaned on callbacks for nearly everything asynchronous, since there wasn't yet a cleaner built-in alternative. The pattern works, but nested callbacks several levels deep get hard to read fast, which is exactly the problem Promises were built to solve.

It's what happens when callbacks get nested inside callbacks inside callbacks, each one waiting on the last, until the code forms a sideways staircase that's painful to read or debug. Promises flatten that structure with .then() chains, and async/await flattens it further into code that reads almost like synchronous logic.

An object representing the eventual result of an asynchronous operation. It can be pending, fulfilled, or rejected. Instead of passing a callback directly into a function, you get back a Promise and attach .then() for success and .catch() for failure, chaining cleanly without the nested pyramid callbacks tend to produce.

async/await is syntax sugar built directly on top of Promises. Marking a function async lets you use await inside it to pause execution until a Promise resolves, without writing an explicit .then() chain. Under the hood it's still Promises doing the work. It just reads more like ordinary, top-to-bottom code.

The Promise that async function returns rejects silently unless something is watching for it. In modern Node, an unhandled rejection can even crash the process outright, depending on configuration. This is exactly why a try/catch block around your awaited calls, or a .catch() on the returned Promise, isn't optional in real code.

A reusable, self-contained piece of code, usually one file, that exports something (a function, an object, a class) for other files to import. Node's own module system, plus every package you install through npm, is built on this idea. It's how a codebase stays organized instead of turning into one enormous file.

Write your logic in a file, then attach whatever you want to expose to module.exports (CommonJS) or use export (ES Modules). Another file then pulls it in with require('./yourfile') or import. Anything not explicitly exported stays private to that file.

File system operations. Reading files, writing files, checking whether a path exists, watching a directory for changes. It ships as a core Node module, so there's nothing to install, just require('fs') or import it from 'node:fs' and you're working with files.

readFile is asynchronous and takes a callback, letting the rest of your code keep running while the file loads. readFileSync blocks execution entirely until the read finishes. On a server handling multiple requests, using the synchronous version on a large file can stall every other request in the meantime, which is why the async version is almost always the right default.

Building and manipulating file paths in a way that works correctly across operating systems. Windows uses backslashes, Linux and macOS use forward slashes, and path.join() handles that difference for you instead of you hardcoding a separator that breaks on someone else's machine.

Core modules ship built into Node itself, no npm install required. Besides fs and path, common ones include http (building servers), os (system information), crypto (hashing and encryption), and events (the EventEmitter pattern that a lot of Node's own APIs are built on).

Express is a minimal web framework built on top of Node's own http module. Writing a raw HTTP server by hand for anything beyond a toy example gets tedious fast, routing, parsing request bodies, handling different HTTP methods. Express wraps all of that in a small, well-understood API, which is why it became the default choice for years before newer frameworks like Fastify and NestJS picked up their own following.

app.get('/users', (req, res) => { res.send('list of users') }). That one line registers a handler for GET requests to /users. app.post, app.put, and app.delete follow the same shape for their respective HTTP methods.

A function that sits in the request-response cycle with access to the request, the response, and a next() function to hand control to whatever comes after it. Middleware is how Express handles cross-cutting concerns like logging, authentication, and parsing JSON bodies, applied once instead of repeated in every route handler.

app.use() applies middleware to every request that matches the given path prefix (or all requests, if no path is given), regardless of HTTP method. app.get() only fires for GET requests to that exact path. You'd use app.use() for something like logging every request, and app.get() for the actual logic answering a specific endpoint.

req.params gives you named segments from the route path, like the id in /users/:id. req.query gives you everything after the question mark in the URL, like ?page=2&limit=10. They answer different questions: params identify a specific resource, query strings usually filter or modify a request.

Add a catch-all middleware after every other route is defined. Since Express checks routes in the order they're registered, anything that hasn't matched by the time it reaches that final middleware genuinely doesn't exist, and you can respond with a proper 404 there instead of the request just hanging.

app.use(express.json()) as global middleware. Once that's registered, any request with a JSON body gets automatically parsed into a JavaScript object, available on req.body inside your route handlers. Without it, req.body is undefined even if the client sent valid JSON.

process.env.VARIABLE_NAME. For local development, most projects load a .env file into process.env using a package like dotenv, so secrets and configuration don't have to be hardcoded directly into the source. In production, environment variables are usually set by whatever platform is running the app, not read from a file at all.

Because source control keeps history forever. Even if you delete the secret in a later commit, it's still sitting in the repository's history for anyone with access to find. Environment variables, loaded at runtime and kept out of version control entirely, are the standard fix.

Wrap the risky code in a try/catch, and on failure respond with an appropriate status code and message, something like res.status(400).json({ error: 'Invalid input' }). Letting an unhandled error bubble up usually crashes the process or leaves the client hanging with no response at all.

JSON.stringify() converts a JavaScript object into a JSON string, useful when sending data over the network or writing it to a file. JSON.parse() does the reverse, turning a JSON string back into a usable JavaScript object. You'll use both constantly the moment your app talks to any external API.

CORS, Cross-Origin Resource Sharing, is a browser security mechanism that blocks a webpage from calling an API on a different domain unless that API explicitly allows it. If your frontend runs on localhost:3000 and your API runs on localhost:5000, the browser blocks the request by default until the API sends back the right CORS headers, usually handled in Express with the cors package.

It records the exact version of every package (and every package those packages depend on) that got installed, down to the last dependency. Without it, two people running npm install on the same package.json could end up with slightly different dependency trees, since version ranges in package.json allow some flexibility. The lock file removes that flexibility and guarantees everyone gets the same thing.

npm install can update package-lock.json if it doesn't perfectly match package.json. npm ci does a clean install strictly from the lock file, and fails outright if the two are out of sync, rather than silently reconciling them. Most CI pipelines use npm ci specifically because that strictness catches dependency drift before it reaches production.

Custom commands defined in the scripts section of package.json, run with npm run scriptname. A start or test script doesn't even need the run keyword, npm start and npm test work directly. It's a simple way to standardize how a project gets built, tested, or launched without everyone remembering a long custom command.

Major.Minor.Patch. A major version bump signals a breaking change. A minor bump adds functionality without breaking existing usage. A patch is a bug fix with no new features. The caret and tilde symbols in package.json (^4.2.1 versus ~4.2.1) control how much of that range npm is allowed to auto-update to.

A peer dependency declares that a package expects a specific other package to already be installed by whoever's using it, rather than bundling its own copy. It's common in plugin-style packages, a React component library might list react itself as a peer dependency, since it needs to share the exact same React instance as the app using it, not its own separate copy.

Microtasks, Promise callbacks and process.nextTick, run immediately after the current operation finishes, before the event loop moves to its next phase. Macrotasks, like setTimeout and setImmediate callbacks, wait for their specific phase in the loop. This is why a resolved Promise's .then() callback consistently runs before a setTimeout(fn, 0), even though both were technically queued around the same time.

process.nextTick() queues a callback to run immediately after the current operation, before the event loop even continues to its next phase, which gives it the highest priority of the two. setImmediate() runs during the check phase of the loop, after I/O callbacks have already had their turn. Overusing process.nextTick() can actually starve the event loop, since it can keep getting reinserted ahead of everything else.

Because there's only one thread running your JavaScript. A synchronous loop crunching numbers for two seconds occupies that thread completely for those two seconds, and nothing else, no other request, no other callback, can execute until it finishes. This is the real cost of Node's single-threaded model, and it's exactly why CPU-bound work gets offloaded rather than run inline.

Offload it. worker_threads run genuinely parallel JavaScript on separate threads for CPU-bound tasks within the same process. For heavier or longer-running work, offloading to a completely separate service, or a background job queue, keeps the main API server responsive no matter how long the actual computation takes.

Streams process data in chunks as it arrives, rather than loading an entire file or response into memory all at once. For a large file or a big HTTP response, streaming keeps memory usage flat regardless of size, where reading the whole thing into memory first could exhaust available RAM on a large enough input.

Readable (you can read data from it, like a file being read), Writable (you can write data to it, like a file being written), Duplex (both readable and writable, like a network socket), and Transform (a duplex stream that modifies data as it passes through, like a gzip compressor).

Connecting a readable stream directly to a writable stream so data flows from one to the other automatically, handling backpressure for you along the way. readStream.pipe(writeStream) is the classic example, streaming a file's contents straight into an HTTP response without manually managing chunks or waiting for buffers to drain.

A fixed-size chunk of raw binary data, used when Node needs to work with data that isn't plain text, like reading an image file or handling a TCP socket's raw bytes. JavaScript in the browser never had to deal with this directly, but a server-side runtime touching files and network sockets constantly does.

Backpressure happens when a readable stream produces data faster than a writable stream can consume it. Without handling it, unconsumed data piles up in memory and can eventually crash the process. Node's pipe() method manages this automatically by pausing the readable stream when the writable side's internal buffer fills up, which is one of the main reasons to prefer pipe() over manually shuffling data between streams yourself.

Wrap the sequence in a single try/catch rather than one per await, unless different failures genuinely need different handling. Centralizing it keeps the happy path readable and avoids repeating the same catch logic three or four times in a row for calls that would all fail the same way anyway.

As of recent Node versions, an unhandled rejection logs a warning and, depending on configuration, can terminate the process. You can listen globally with process.on('unhandledRejection', handler) to log it or fail gracefully, but that's a safety net, not a substitute for actually catching errors at the call site where they happen.

Start with the actual crash logs and stack trace rather than guessing. If those aren't enough, the built-in inspector (node --inspect) combined with Chrome DevTools lets you attach a debugger to a running process. For issues that only show up under real load, structured logging with request IDs and timestamps often tells you more than a debugger ever could, since you can't always reproduce an intermittent bug on demand.

An operational error is an expected failure in a working system, a network timeout, a file that doesn't exist, invalid user input. A programmer error is an actual bug, a typo, calling a function with the wrong argument type. Operational errors should be handled gracefully and recovered from. Programmer errors usually shouldn't be caught and silently ignored, since doing so just hides a bug instead of surfacing it.

Jest is probably the most widely adopted, bundling a test runner, assertion library, and mocking support in one package. Mocha is older and more modular, usually paired separately with an assertion library like Chai. Vitest has picked up popularity more recently, especially in projects already using Vite, for its speed.

Using Jest, jest.mock() replaces the module making the real HTTP call with a fake version that returns whatever canned response you configure, so the test doesn't depend on network access or the real service being available. This keeps tests fast, deterministic, and able to simulate error responses you couldn't easily trigger against the real API on demand.

A unit test checks one function or module in isolation, usually with its dependencies mocked out entirely. An integration test exercises multiple pieces together, an actual HTTP request hitting a real (or test) database through the full route handler, checking that the pieces genuinely work together rather than just in isolation.

supertest lets you make requests directly against your Express app object in memory, without binding to an actual network port, then assert on the response status and body. It's the standard approach for testing Express routes quickly, since spinning up a real server for every test would slow the whole suite down.

The native driver gives you raw, unopinionated access to MongoDB's operations. Mongoose adds schema definitions, validation, and a more structured, model-based way of interacting with your data on top of that driver. Most application code benefits from Mongoose's structure, while the raw driver shows up more in scripts or situations needing very specific low-level control.

Most database drivers and ORMs (pg, mysql2, Mongoose) handle pooling internally once configured, reusing a set number of open connections instead of opening a new one for every single query. The main things to get right are sizing the pool appropriately for your expected concurrency and making sure connections are actually released back to the pool after each query, not silently leaked.

SQL databases enforce a fixed schema and relationships through tables, which usually means an ORM like Sequelize or Prisma modeling those relationships explicitly. NoSQL databases like MongoDB store more flexible, document-shaped data, which pairs naturally with JavaScript objects and JSON, one reason MongoDB became such a common pairing with Node early on.

Always use parameterized queries, placeholders the driver fills in safely, rather than building SQL strings through direct concatenation or template literals with user input. Every mainstream Node SQL library (pg, mysql2, Sequelize, Prisma) supports parameterization natively, so there's rarely a good reason to hand-build a query string with raw user input inside it.

An Object-Relational Mapper lets you interact with a database using JavaScript objects and method calls instead of writing SQL directly, handling a lot of the underlying query generation for you. The trade-off is that an ORM can generate inefficient queries for complex cases without you noticing, and very specific performance-critical queries sometimes need to drop down to raw SQL anyway.

cluster spins up entirely separate processes, each with its own memory space, mainly useful for scaling an HTTP server across cores. worker_threads run within the same process and can share memory more efficiently through SharedArrayBuffer, which fits genuinely CPU-bound computation better than spinning up a whole new process would.

For a single-instance app, an in-memory cache (a simple Map, or a library like node-cache) works and is trivial to set up. Once you're running multiple instances behind a load balancer, that in-memory cache won't be consistent across them, so a shared cache like Redis becomes the right call instead, keeping all instances reading from the same cached data.

Vertical scaling means a bigger machine. Horizontal scaling means more instances running behind a load balancer. Since a single Node process is capped by one core's throughput regardless of how much RAM or CPU the machine has, Node applications generally scale horizontally, more instances or more cluster workers, rather than expecting one giant process to make full use of a large machine on its own.

Start with the built-in --prof flag or a tool like clinic.js to get a CPU profile showing where time is actually being spent, rather than guessing based on which function looks suspicious. For memory issues specifically, taking heap snapshots with the inspector and comparing them over time reveals what's actually accumulating.

Memory that should have been freed but stays referenced, so garbage collection can never reclaim it, causing memory usage to climb steadily over time. Common causes include a growing array or cache with no eviction policy, event listeners that get added repeatedly without ever being removed, and closures unintentionally holding onto large objects longer than needed.

Take a heap snapshot using the built-in inspector, let the process run under normal load for a while, then take a second snapshot and compare the two. Objects that grew in count between snapshots without a clear reason are the usual suspects. Restarting the process before investigating just resets the clock and buys you nothing toward actually fixing it.

SQL or NoSQL injection from unsanitized input, cross-site scripting if you're rendering any user-supplied content, insecure handling of authentication tokens, and dependency vulnerabilities inherited from outdated npm packages. Running npm audit regularly catches a surprising number of known issues sitting quietly in a project's dependency tree.

Never store them in plain text. Hash them with a purpose-built algorithm like bcrypt or argon2, both of which are deliberately slow and include salting to resist brute-force and rainbow-table attacks. A general-purpose fast hash like plain SHA-256 is the wrong tool here specifically because its speed makes brute-forcing easier, not harder.

On login, the server issues a signed token containing the user's identity and any relevant claims. On later requests, the client sends that token, usually in an Authorization header, and middleware verifies its signature and expiry before letting the request through, without needing to look up a session in a database on every single call.

Rate limiting caps how many requests a client can make in a given time window, protecting an API from abuse or accidental overload. In Express, a package like express-rate-limit handles this with middleware, tracking request counts per IP (or per user, if authenticated) and rejecting requests once they cross the configured threshold.

The helmet package sets a range of security-related HTTP headers automatically, things that prevent clickjacking, disable content sniffing, and enforce HTTPS in supported browsers, without you having to configure each one manually. It's usually one of the first middleware packages added to a production Express app, right alongside CORS handling.

It's an attack where a malicious package published under the same name as an internal, private package tricks a build system into pulling the public malicious version instead of the intended private one. Scoping internal package names properly and configuring npm to only resolve them from a private registry closes this gap, one that's easy to overlook until it's explained once.

Synchronous REST or gRPC calls are simplest to reason about but couple the caller's availability directly to the callee's uptime and latency. Asynchronous, event-driven communication through a message broker like RabbitMQ or Kafka decouples the services and improves resilience, at the cost of eventual consistency and a genuinely harder debugging story across a chain of async events.

A circuit breaker, using a library like opossum, stops calling a failing downstream service after a threshold of failures, failing fast instead of letting requests pile up waiting on a service that's already struggling. Combined with a bounded retry for genuinely transient failures, this keeps one failing service from cascading into an outage across the whole system.

Propagate a correlation ID through every request, generated at the entry point and passed along in headers to every downstream call, then logged consistently by each service. Tools like OpenTelemetry standardize this and can visualize a request's full path across services, which turns a genuinely painful multi-service debugging session into something you can actually follow.

An API Gateway sits in front of all your services as a single entry point, handling routing, authentication, and rate limiting centrally instead of each service reimplementing them. Without one, every client needs to know about and talk to each service directly, which gets unmanageable fast once you're running more than a handful of services.

Centralize it rather than letting each service maintain its own scattered environment files, using a shared configuration service or a secrets manager that services pull from at startup. This makes rolling out a configuration change consistent and auditable across every service, instead of updating a dozen separate .env files by hand and hoping none of them get missed.

URI versioning (/api/v1/users, /api/v2/users) is the most explicit and easiest for consumers to understand, even if it's not the most theoretically pure REST approach. Whatever scheme you pick, the real discipline is committing to a deprecation window and communicating it clearly, rather than pulling an old version out from under clients with no warning.

Accept an idempotency key from the client, a unique value the client generates once per logical request, and store it alongside the result of processing that request. If the same key arrives again, whether from a genuine retry or a network hiccup that made the client resend, return the stored result instead of creating a second payment. This is exactly how most real payment APIs prevent a flaky network from charging someone twice.

Wrap all database access behind an interface, a UserRepository with methods like findById and save, so the rest of the application talks to that interface instead of directly to Mongoose or a raw SQL client. This makes it far easier to swap the underlying database technology later, and makes unit testing business logic possible without touching a real database at all.

Pass dependencies into a function or a class constructor explicitly rather than importing and instantiating them directly inside the module. It's simple, doesn't need a heavy framework like InversifyJS or NestJS's built-in container, and makes testing far easier since you can pass in a mock dependency instead of the real one during a test.

A Factory centralizes the logic for creating an object, so the calling code doesn't need to know the details of construction, useful when the exact type of object needed depends on some runtime condition. A common Node example is a factory that returns a different logger implementation depending on the current environment, verbose console logging in development, structured JSON logging in production.

Listen for the process termination signal (SIGTERM), stop accepting new connections immediately, but let requests already in progress finish before actually exiting. Most Node HTTP servers expose a close() method for exactly this, and it's a detail that's easy to skip until a deployment starts silently dropping requests mid-flight.

They're the same underlying idea. The Observer pattern describes a subject notifying a set of subscribers when something happens, and EventEmitter is Node's concrete implementation of exactly that, used throughout the core Node API itself. Streams, HTTP servers, and plenty of other built-in modules all extend EventEmitter under the hood.

Organizing by feature, grouping a feature's routes, logic, and data access together, tends to hold up better than organizing purely by technical layer, where all controllers sit in one folder, all models in another. Feature-based structure keeps related code physically close, which matters a lot once a codebase has more than a handful of contributors.

Run it incrementally. Get the codebase and its dependencies passing under both the old and new Node versions where possible, lean on existing test coverage to catch regressions early, and roll the upgrade out service by service rather than all at once across the whole system. A full stop-everything migration is rarely something the business will actually tolerate.

I look at whether it's solving the real problem or just its symptom, what happens when a downstream dependency fails rather than only the happy path, and whether it's consistent with patterns already established elsewhere in the system. An inconsistent one-off pattern becomes a maintenance burden the whole team inherits later, so I'd rather ask a few pointed questions that surface the team's own blind spots than hand them a prescribed answer.

Automate what can be automated: linting (ESLint), formatting (Prettier), and dependency version alignment, enforced in CI so standards aren't a matter of opinion in code review. For architectural conventions that resist automation, I'd document the handful of decisions that actually matter, with the reasoning behind them, rather than a long style guide nobody reads end to end.

Weigh it against concrete benefit, performance improvements, security support lifetime, features teams are actively blocked without, against the real migration cost and risk to velocity while it's underway. I'd pilot the upgrade on a lower-risk service first rather than the most critical one, with a rollback plan defined before starting, not decided halfway through.

First rule out environmental differences, connection pool sizing, data volume, and whether staging traffic actually resembles production concurrency. Then I'd want structured logging and distributed tracing to see where time is actually going, since 'intermittent under load' is very often event-loop blocking from a synchronous call somewhere, or connection pool exhaustion, neither of which reliably shows up in low-traffic staging.

A basic /health endpoint checking process liveness is the floor, not the ceiling. I'd extend it with checks for what actually matters, database connectivity, downstream dependency availability, event loop lag specifically, since a Node process can technically be 'up' while its event loop is badly backed up and every request is crawling.

Treat the package's public API as a contract. Additive changes are generally safe. Changing or removing an existing function's signature needs a documented deprecation period before actual removal, not a silent breaking change in a minor version bump. I'd also want visibility into who's actually importing the old function before removing it, rather than assuming nobody depends on it.

Mitigation before root-causing. Roll back a recent deploy, restart the affected instances, or shed load if that stops the bleeding, even before fully understanding why it broke. I'd also make sure one person is clearly driving the incident and communicating status, since incidents usually drag on longer because of diffuse ownership, not a lack of technical skill in the room.

Start from actual load testing at realistic traffic shapes rather than linear extrapolation, since the real bottleneck, a database, a downstream API's rate limit, a single-threaded hot path somewhere, rarely scales linearly and often shows up well before the target load. I'd identify the actual constraint first, then decide whether the fix is more instances, caching, offloading work to a queue, or redesigning the hot path itself.

This is a judgment question interviewers use to see how you reason under uncertainty, not to test a specific fact. A strong answer names the actual constraint that forced the decision, the realistic options that were genuinely on the table, why you picked one knowing it wasn't guaranteed to be right, and what you'd do differently with what you know now.

I'd walk through a real incident or near-miss from the codebase together, tracing exactly what happened when a dependency timed out or an input was malformed, rather than lecturing about defensive programming in the abstract. Seeing a concrete failure trace through their own mental model of the system tends to change how they write the next piece of code far more than general advice does.

I wouldn't push a full rewrite. I'd migrate one genuinely painful, callback-nested file as a visible example, let the team see the readability difference on code they already recognize, and let that build the case rather than arguing the merits abstractly. Migrating incrementally, new code in the new style, old code updated opportunistically when it's touched anyway, avoids a disruptive big-bang rewrite nobody has time for.

I'd bring the actual data behind my position, load test results, real incident history, current resource utilization, rather than a general preference for one approach over another. Most disagreements like this resolve once both sides are looking at the same concrete numbers instead of arguing from differing assumptions about how the system behaves under load.

I'd translate the technical risk into numbers leadership already cares about: no more security patches after a specific date, growing difficulty hiring engineers familiar with an outdated stack, and any concrete incident that's already happened because of a missing feature only the newer version has. Framed as risk reduction with a deadline attached, it competes far better for budget than framed as a general engineering nice-to-have.