Top 60 Express Interview Questions (2026)

Express is a minimal, unopinionated web framework for Node.js. It sits on top of Node's built-in http module and adds routing, a middleware pipeline, and helper methods on the request and response objects. It handles the tedious parts of an HTTP server, matching routes and chaining middleware, without forcing an architecture on you.

Teams use it because it handles the tedious parts of an HTTP server, parsing URLs, matching routes, chaining middleware, without forcing an architecture. You keep control of structure while skipping the boilerplate of raw Node.

Middleware is a function that runs during the request-response cycle with access to the request object, the response object, and the next function. It can read or change req and res, end the response, or call next() to pass control to the following middleware.

Everything in Express flows through this chain: logging, body parsing, authentication, routing, and error handling are all middleware. Understanding the chain is understanding Express.

req is the request object: it holds incoming data like req.params (route parameters), req.query (query string), req.body (parsed body), and req.headers. res is the response object: you send data back with res.send(), res.json(), res.status(), and res.redirect(). Together they represent one HTTP exchange from arrival to reply.

Both wrap Node's raw IncomingMessage and ServerResponse and add convenience methods, so you rarely touch the raw Node objects directly.

A route pairs an HTTP method and a URL path with a handler function: app.get, app.post, app.put, app.delete, and so on. When an incoming request matches both the method and the path, Express runs that handler and stops looking. Routes are checked in the order you register them, so the first match wins.

Paths can be literal (/users), parameterized (/users/:id), or pattern-based. app.all matches every method, and app.route lets you chain handlers for one path.

Route parameters are named segments in the path itself, defined with a colon and read from req.params, so /users/:id captures the id. Query strings are key-value pairs after the ? in the URL, read from req.query, so /search?term=node gives you the term. One is part of the resource path, the other is optional extra data.

Use route params to identify a specific resource and query strings for optional filters, sorting, or pagination. That convention maps cleanly to REST.

res.send() sends a string, buffer, or object and sets sensible headers for you. res.json() serializes to JSON explicitly. res.status(code) sets the status. res.redirect() sends a redirect, res.sendFile() streams a file, and res.end() ends the response without a body. Each of these is a terminating method that finishes the request.

You call exactly one terminating method per request. Calling res.send() twice throws the 'headers already sent' error, one of the most common Express mistakes.

Register the built-in express.json() middleware, which reads the raw request body, parses it as JSON, and puts the result on req.body for your handlers to use. Without it, req.body is undefined for JSON requests because Express doesn't parse bodies by default. You opt in with this one line of middleware.

Since Express 4.16 this is built in, so you don't need the separate body-parser package anymore. Use express.urlencoded() for form-encoded bodies.

Use the built-in express.static middleware, pointing it at a directory on disk. Files in that folder are then served directly at the root path, or under a mount path you choose, without writing a route for each one. Express matches the URL to a file name and streams it back with the right Content-Type.

This is how you serve HTML, CSS, images, and client JavaScript without writing a route for each file.

app.use() mounts middleware that runs for any HTTP method whose path starts with the given prefix, which defaults to /. app.get() registers a handler that runs only for GET requests matching the exact path. So app.use() is for cross-cutting concerns like logging or auth, and the method functions handle the actual endpoints.

So app.use() is for cross-cutting middleware (logging, parsing, auth), and the method functions (get, post, put, delete) are for actual endpoints.

next() passes control to the next matching middleware or route in the stack. It's the mechanism that keeps the request-response cycle moving. Without it, a middleware that doesn't send a response leaves the request hanging, and the client eventually times out waiting for a reply that never comes.

Calling next('an error') or next(err) skips ahead to the error-handling middleware. Calling next('route') skips the rest of the current route's handlers and moves to the next matching route.

Initialize a Node project with npm init, install Express with npm install express, then create an entry file that requires express, creates an app with express(), defines at least one route, and calls app.listen on a port. Running that file with node starts the server. From there you add middleware and routes as the app grows.

That's the whole minimum. From there you add middleware and routes as the app grows.

Express has a method function for each HTTP verb: app.get, app.post, app.put, app.patch, app.delete, app.head, app.options, and more. Each one registers a handler that runs only for requests using that verb at the matching path, so the same path can behave differently for a GET than for a POST.

In a REST API the mapping is conventional: GET reads, POST creates, PUT and PATCH update, DELETE removes. app.all handles a path for every method at once.

res.json() always serializes its argument to JSON and sets Content-Type to application/json, no matter what you pass. res.send() is more general: it sends strings, buffers, or objects, and when you hand it an object it serializes to JSON too. For an API, res.json() makes the intent explicit and handles edge cases like null cleanly.

In practice res.json() makes your intent explicit for API responses and also handles edge cases like sending null cleanly.

Call res.status(code) to set the status, then chain a terminating method that actually sends the response. For example, res.status(404).send('Not found') sets the code and sends the body in one line, and res.status(201).json(obj) does the same for a created resource. The status call on its own sends nothing.

res.sendStatus(code) sets the status and sends the standard status message as the body in a single call, handy for empty responses.

Read values from process.env, falling back to sensible defaults, like const port = process.env.PORT || 3000. Deployment platforms set PORT for you at runtime, and NODE_ENV tells you whether you're in development or production so you can toggle behavior. This keeps config out of the code and specific to each environment.

For local development, a package like dotenv loads a .env file into process.env. Keep secrets out of the repo and pass config in through the environment.

Add a catch-all middleware after all your routes. Because middleware runs in registration order, any request that didn't match an earlier route falls through to it, and there you respond with a 404. It has no special API; it's simply the last non-error middleware in the chain, so anything unmatched lands on it.

It's not a special API; it's just the last middleware in the chain. Placement is everything: put it after your routes, before the error handler.

A template engine renders HTML from template files with embedded data placeholders. Express supports engines like EJS, Pug, and Handlebars: you set the view engine, put templates in a views folder, and call res.render() with the data to inject. Express runs the engine and sends the finished HTML back as the response.

For server-rendered pages this replaces string concatenation. Many modern Express apps skip it and serve JSON to a separate frontend instead.

express.Router() creates an isolated group of routes and middleware, a mini-application, that you mount onto a path with app.use. It keeps a growing app from becoming one giant file: related routes live in their own module, and the mount path prefixes all of them, so a users router mounted at /users owns every /users route.

You define related routes in their own module, export the router, and mount it with app.use('/users', usersRouter). Routes inside are relative to the mount path.

Yes. A route handler has the exact same (req, res, next) signature as middleware; the only difference is that a handler is bound to a specific method and path. A single route can even have several handlers that run in order, each calling next() to reach the one after it. Seeing that routes and middleware share one shape makes the framework click.

Seeing that routes and middleware are the same shape is a small insight that makes the whole framework click.

The raw http module gives you a request and response and nothing else: you parse URLs, match methods, and set headers by hand. Express adds a router, the middleware chain, body parsing, static file serving, and dozens of response helpers.

You can build a server without Express, but you'd reinvent routing and middleware. Express is that common layer, standardized and battle-tested.

Use a tool like nodemon, which watches your source files and restarts the Node process automatically whenever you save, so you don't stop and start the server by hand after every edit. Recent Node versions also ship a built-in --watch flag that does the same thing without an extra dependency. Either one speeds up the edit-run loop.

It's a development convenience only; in production you run plain node behind a process manager or container.

Error-handling middleware has four arguments instead of three: (err, req, res, next). Express recognizes it purely by that four-argument signature, not by name, and calls it only when an error is passed via next(err) or thrown in a synchronous handler. You register it last so it can catch errors from every route and middleware above it.

You register it last, after all routes and other middleware, so it catches everything. One central error handler keeps error formatting consistent across the app.

In Express 5, a rejected promise from an async handler is forwarded to your error middleware automatically, so a plain async function with an await that throws just works. In Express 4 it doesn't: an unhandled rejection escapes Express entirely.

On Express 4 you wrap handlers in try/catch and call next(err), or use a small wrapper (or the express-async-errors package) that catches rejections for you.

Middleware runs in registration order. A body parser registered after a route means req.body is undefined in that route. An auth check registered after the protected route never runs. The error handler registered before the routes never sees their errors.

So the mental model is a pipeline: put parsing and logging first, then auth, then routes, then the 404 handler, then the error handler last.

Application-level middleware is bound with app.use or app.METHOD and runs for the whole app. Router-level middleware is the same but bound to a router instance. Error-handling middleware has the four-argument signature. Built-in middleware ships with Express (express.json, express.static). Third-party middleware comes from npm (cors, helmet, morgan).

CORS (cross-origin resource sharing) is a browser rule that blocks requests from a page on one origin to an API on another unless the API sends the right headers. When your frontend and API live on different domains, the browser enforces it.

The cors middleware sets those headers for you. Configure it to allow specific origins and methods rather than opening it to everyone in production.

Use the helmet middleware, which sets a group of HTTP response headers that reduce common attack surface. It removes the X-Powered-By header that advertises Express, sets X-Content-Type-Options to stop MIME sniffing, configures a default Content-Security-Policy, and adds several others. One line gives you the defaults most apps should have.

It's one line and covers defaults most apps should have. You then tune the Content-Security-Policy for your own assets.

Pass a limit option to the body parser, like express.json({ limit: '100kb' }), so Express rejects anything larger before it fully buffers. Without a cap, a client can send a huge payload that exhausts memory, which is a simple denial-of-service vector. The limit protects the process from both accidents and abuse.

Set the limit to the largest legitimate request your API accepts. Oversized requests then get rejected with a 413 before they're fully buffered.

Split routes into Router modules by resource, like users, orders, and products, each in its own file, then mount them under a base path with app.use. Add versioning by mounting under /api/v1. Keep handlers thin and push real logic into service functions, so the routing layer stays readable. This turns one giant file into a predictable folder structure.

This turns one thousand-line file into a predictable folder structure a new teammate can handle without a map.

req.params holds named route segments, so /users/:id gives req.params.id. req.query holds parsed query string values, so ?page=2 gives req.query.page. req.body holds the parsed request body, but only after a body-parsing middleware like express.json() has run. Each source maps to a different part of the incoming request.

A frequent bug: reading req.body without registering express.json() first, so it's undefined. Each source maps to a different part of the request.

Pass several functions to a single route and each runs in order, calling next() to hand off to the next one. This is how you compose per-route middleware, like a validation step, then an auth step, then the final handler that sends the response. It keeps cross-cutting checks out of the handler body and reusable across routes.

app.route() gives a cleaner form for one path across methods, and arrays of middleware let you reuse handler groups.

Write a small middleware that logs the method, URL, and response timing, or use the morgan package for ready-made access logs. Register it early in the chain so it sees every request, including ones that later fail or 404. Logging after the routes would miss anything that short-circuits before reaching it.

For production, structured JSON logs from a logger like pino feed better into log aggregation than plain text.

Map each resource to routes by HTTP method: GET for reads, POST to create, PUT or PATCH to update, DELETE to remove. Parse bodies with express.json(), validate input, call your data layer, and respond with the right status code and JSON.

Return 201 on create, 204 on delete, 400 on bad input, and 404 when a resource isn't found. Consistent status codes are what makes an API predictable.

res.locals is an object scoped to a single request and reset for the next one. Middleware can attach data to it, like the authenticated user or a generated request id, and later middleware, handlers, or rendered views can read it back. It's the clean way to pass computed values down the chain without touching global state.

It's the clean way to pass computed values down the chain for one request without polluting global state or the req object's own fields.

express.json() only parses JSON, not multipart form data, so file uploads need a dedicated middleware like multer. It parses multipart/form-data requests, writes each uploaded file to disk or memory, and puts the file metadata on req.file or req.files for your handler. You then validate the file type and size before saving it.

You then validate file type and size before saving, because uploads are a common security and storage risk.

Use res.set(name, value) or res.header() to set a response header, and req.get(name) to read an incoming request header. res.redirect(url) sends a redirect that defaults to a 302 (temporary), and res.redirect(301, url) makes it a permanent one. You can set several headers at once by passing an object to res.set.

Set headers before sending the body. Once the response starts, you can't change headers, which is the root of the 'headers already sent' error.

The cookie-parser middleware reads incoming cookies into req.cookies, and res.cookie() sets them on the response. For sessions, express-session stores just a session id in a cookie and keeps the session data server-side, in memory for development or in a shared store like Redis for production. The cookie identifies the session; the data lives on the server.

Set cookies with httpOnly and secure flags so client scripts can't read them and they only travel over HTTPS.

Branch on process.env.NODE_ENV: enable detailed error output and looser CORS in development, then tighten both in production so you don't leak stack traces or open your API to every origin. Keep the values themselves in environment variables, not hardcoded in the source, so the same build runs anywhere.

app.get('env') reads the same NODE_ENV. Load a .env file with dotenv locally, and let the deployment platform inject real values in production.

Use express-rate-limit as middleware. It counts requests per client, usually by IP address, inside a rolling time window and rejects anything over the limit with a 429 status. This blunts brute-force login attempts and scraping without any code in your handlers. Apply it globally or scope it to sensitive routes like login.

For anything distributed across multiple servers, back the limiter with a shared store like Redis so the count is global, not per process.

Validate in middleware before the handler runs, using a library like express-validator, Joi, or Zod. Check required fields, types, and formats, then respond with a 400 and a clear message when the input is bad, before any business logic touches it. Validating at the edge keeps handlers clean and shields the data layer from garbage.

Validating at the edge keeps handlers clean and protects the data layer from garbage. Never trust req.body, req.query, or req.params directly.

Capture the server object that app.listen returns, then listen for SIGTERM or SIGINT and call server.close(), which stops accepting new connections while letting in-flight requests finish. Once close completes, tear down database pools and other resources, then exit. This is what makes a deploy or scale-down drain cleanly instead of dropping active requests.

Without this, a deploy or scale-down can cut off active requests mid-response. Graceful shutdown is what makes rolling deploys safe.

Express keeps an ordered stack of layers, each pairing a path pattern with a handler. For each request it walks the stack top to bottom, compiling each route's path into a regular expression and testing method and path. The first matching layer runs, and next() advances to the next candidate.

So routing is linear and order-dependent, not a hash lookup. That's why a broad app.use() placed early can intercept requests meant for a later specific route.

The headline change is async error handling: Express 5 forwards a rejected promise from an async handler to the error middleware automatically, which Express 4 did not. Path matching also tightened, some deprecated method signatures were removed, and the router internals were modernized.

For interviews, the async-rejection behavior is the one that changes how you write handlers. In 5 you can drop most of the try/catch-plus-next boilerplate.

next() tells the router to invoke the next layer whose method and path match the request. Internally the router holds an index into its layer stack; next() advances that index and calls the corresponding handler. Passing an argument (next(err)) tells the router to skip ahead to the next error-handling layer instead.

Because it's a continuation, calling next() twice in one middleware runs the rest of the chain twice, a subtle bug that often shows up as 'headers already sent'.

A single Node process uses one core. To use all cores, run one Express process per core behind a load balancer: Node's cluster module forks workers sharing a port, or you run multiple containers and let the orchestrator balance them. The second approach is more common in production because the platform handles restarts and health checks.

Either way, keep the app stateless, so any worker can handle any request. Push shared state (sessions, caches) into Redis or a database.

Define an error class hierarchy (a base AppError with fields like statusCode and a public message, plus specific subclasses). Handlers throw or next() those errors. One central error middleware maps them to responses: known operational errors return their status and message, unknown errors return a generic 500 and get logged in full.

The line that matters is operational versus programmer errors: a missing record is a 404 you handle, a null dereference is a bug you log and fix. Leaking stack traces to clients is both a security and a professionalism failure.

Model resources as nouns and use HTTP methods as the verbs: GET /orders, POST /orders, GET /orders/:id, PATCH /orders/:id, DELETE /orders/:id. Version the API under a prefix like /api/v1, return correct status codes, and keep every response consistent in shape so clients can rely on it. Predictable URLs and status codes are what make an API easy to consume.

Layer the code: routers hold routing only, controllers handle request and response, services hold business logic, and a data layer talks to the database. Thin controllers and reusable services keep the app testable as it grows.

Two common models. Sessions: on login you create a server-side session and set a session-id cookie; middleware loads the session on each request. JWT: on login you sign a token the client sends in an Authorization header; middleware verifies the signature and attaches the user, with no server-side session store.

JWT scales statelessly but is hard to revoke before expiry; sessions revoke instantly but need a shared store. Put the verification in middleware so every protected route reuses it.

Test handlers and middleware in isolation as plain functions where you can, and test routes end to end with supertest, which drives the app in memory without binding a real port. Assert on status codes, response bodies, and side effects like a database write. Keep a few integration tests against a real test database for confidence.

Export the app separately from the code that calls app.listen, so tests import the app directly. Mock external boundaries (database, third-party APIs) and keep a few integration tests against a real test database for confidence.

Because res is a Node writable stream, you can pipe a readable stream straight into it, like fs.createReadStream(path).pipe(res). That sends the data in chunks without ever loading the whole file into memory, and Node handles backpressure for you so a slow client doesn't overwhelm the server. It's how you serve large files or long exports safely.

For generated data, write chunks and call res.write() repeatedly, then res.end(). Streaming is how you serve large files or long database exports without blowing up memory.

Node runs your handlers on a single event-loop thread. A synchronous CPU-heavy loop or a blocking call freezes that thread, so every other request in flight has to wait, no matter how many are queued behind it. Throughput collapses under one slow handler, and even health checks start timing out. This is the classic Node performance trap.

The fixes: move CPU work off the loop with worker threads or a separate service, use async I/O so waits don't block, and never call the sync versions of fs functions in a request path.

Enable gzip or brotli with the compression middleware to shrink response bodies over the wire. Set Cache-Control and ETag headers so clients and proxies can reuse responses. For expensive computed responses, cache the result in memory or Redis keyed by the request.

In production, terminate compression and TLS at a reverse proxy or CDN when you can, so Express spends its cycles on application work rather than encoding.

When Express runs behind a reverse proxy or load balancer, the client's real IP and protocol arrive in X-Forwarded headers, not on the socket. app.set('trust proxy', ...) tells Express to trust those headers so req.ip, req.protocol, and secure-cookie logic reflect the original client.

Get this wrong and rate limiting sees the proxy's IP for everyone, and secure cookies over HTTPS-terminated-at-the-proxy don't get set. It's a small setting with outsized production impact.

Layer defenses: helmet for security headers, cors locked to known origins, rate limiting on auth and write endpoints, body-size limits, input validation on every route, and secrets in environment variables. Never leak stack traces to clients, and keep dependencies patched.

Beyond middleware, run over HTTPS, set httpOnly and secure cookies, and log security-relevant events. No single setting is enough; production safety is the sum of these layers.

Choose Express for small to mid services, prototypes, or when the team wants full control and the widest middleware ecosystem. Choose NestJS when a large team needs enforced structure, dependency injection, and TypeScript conventions out of the box. Choose Fastify when raw throughput and schema-based validation matter most.

The honest coverage names the cost of Express too: no enforced structure means discipline is on you, and its per-request overhead is higher than Fastify's. Picking on requirements rather than familiarity is the signal.

Keep the database out of your route handlers. Create a connection pool once at startup, expose data access through a repository or service layer, and have controllers call those functions instead of running queries inline. Reuse the pool across requests rather than opening a connection per request, which would exhaust the database. That boundary is what keeps the app testable.

Handle connection errors and pool exhaustion explicitly, and shut the pool down on graceful shutdown. Whether you use a query builder, an ORM, or raw queries, the boundary between web layer and data layer is what keeps the app testable.

Express itself speaks HTTP, not the WebSocket protocol, but they share a server. You create the HTTP server, pass it to both Express and a WebSocket library like ws or Socket.IO, and the library handles the upgrade requests while Express handles normal routes.

So the technical answer is: Express handles the REST side, the WebSocket library handles the real-time side, and they coexist on one port through the same underlying http.Server.

Every registered middleware that matches a request runs on that request, so a long global chain adds work to every call. The fix is scoping: mount middleware only where it's needed (on a router or a route) instead of globally, and avoid redundant parsers or loggers.

Also skip work early: return fast for health checks, short-circuit auth on public routes, and don't parse bodies on GET requests. Placement and scope, not micro-optimizing each function, is where the wins are.

Observe first: check logs and metrics for which route and status, then look at request duration and error rate. Is the event loop blocked (rising latency across all routes), is one endpoint slow (a query or external call), or is it a spike in a specific error? Correlate with recent deploys and dependency changes.

Then confirm with a tool: an event-loop lag metric, an APM trace, or a heap snapshot for a memory climb. Fix at the right layer (a missing index, a blocking call, a missing timeout) and verify the metric returns to normal.

Set timeouts at every layer: a server-level request timeout so a stuck request doesn't hold a connection forever, and per-call timeouts on database queries and outbound HTTP so a slow dependency can't hang your handler indefinitely. On timeout, respond with a 503 or 504 rather than leaving the client waiting.

The failure to avoid is unbounded waits: without a downstream timeout, one slow third-party API can exhaust your connections and cascade into an outage.