Express.js interview questions

What a strong answer covers

• Import the Express module using `require('express')`.
• Create an Express application instance by calling `express()`.
• Define a GET route for the root path ('/') using `app.get()`.
• Inside the route handler, use `res.send('Hello World!')` to send the response.
• Start the server using `app.listen(3000, callback)` to listen on port 3000.

Where people lose the point

• ×Forgetting to call `app.listen()` to start the server.
• ×Not sending a response using `res.send()` or similar, causing the request to hang.
• ×Incorrectly defining the route path or HTTP method.

What a strong answer covers

• `app.get()` defines a route handler for HTTP GET requests, typically used for retrieving data from the server.
• `app.post()` defines a route handler for HTTP POST requests, typically used for submitting data to the server to create a new resource.
• GET requests send data via URL query parameters, while POST requests send data in the request body.
• GET requests are generally idempotent and cacheable, whereas POST requests are not.

Where people lose the point

• ×Confusing the purpose of GET (retrieve) and POST (create/submit).
• ×Incorrectly stating that GET requests can have a body (they technically can, but it's not standard practice and often ignored).
• ×Not mentioning idempotency or cacheability as key differentiators.

What a strong answer covers

• The `req` (request) object represents the incoming HTTP request from the client.
• It contains properties like `req.params`, `req.query`, `req.body`, `req.headers`, and `req.method` to access request data.
• The `res` (response) object represents the HTTP response that the server sends back to the client.
• It provides methods like `res.send()`, `res.json()`, `res.status()`, and `res.redirect()` to construct and send the response.

Where people lose the point

• ×Confusing which object is for incoming data (`req`) and which is for outgoing data (`res`).
• ×Listing properties/methods that belong to the wrong object.
• ×Providing a vague explanation without specific examples of properties or methods.

What a strong answer covers

• Use the built-in `express.static()` middleware function.
• Pass the path to your static assets directory (e.g., 'public') to `express.static()`.
• Mount this middleware using `app.use()` at the desired path (e.g., `app.use(express.static('public'))`).
• Optionally, provide a virtual path prefix (e.g., `app.use('/static', express.static('public'))`) to access files via `/static/image.png`.

Where people lose the point

• ×Forgetting to use `app.use()` to register the static middleware.
• ×Providing an incorrect or relative path to the static directory.
• ×Trying to manually create routes for each static file type.

What a strong answer covers

• Middleware functions are functions that have access to the request object (`req`), the response object (`res`), and the `next` middleware function.
• They can execute code, make changes to `req` and `res` objects, end the request-response cycle, or call `next()` to pass control to the next middleware.
• Middleware functions are executed in the order they are defined, forming a pipeline.
• They are used for tasks like logging, authentication, parsing request bodies, and serving static files.

Where people lose the point

• ×Omitting the `next()` function's role in passing control.
• ×Not emphasizing the sequential execution order of middleware.
• ×Confusing middleware with simple route handlers.

What a strong answer covers

• Define a function `loggerMiddleware(req, res, next)`.
• Inside the function, use `console.log(`${req.method} ${req.url}`);` to log the method and URL.
• Crucially, call `next()` at the end of the middleware function to pass control to the next handler.
• Apply it globally using `app.use(loggerMiddleware);` before any routes or other middleware.

Where people lose the point

• ×Forgetting to call `next()` within the middleware, which would cause requests to hang.
• ×Not including `req`, `res`, and `next` as parameters in the middleware function signature.
• ×Applying the middleware after routes, meaning it wouldn't catch all requests.

What a strong answer covers

• Route parameters (`req.params`) are part of the URL path, used to capture specific values from the URL segments (e.g., `/users/:id`). They are defined with a colon prefix in the route path.
• Query strings (`req.query`) are appended to the URL after a question mark (?), used for optional parameters or filtering (e.g., `/products?category=electronics&sort=price`). They are key-value pairs.
• Example for `req.params`: Route `/users/:userId` for URL `/users/123` results in `req.params.userId = '123'`.
• Example for `req.query`: Route `/search` for URL `/search?q=express&limit=10` results in `req.query.q = 'express'` and `req.query.limit = '10'`.

Where people lose the point

• ×Confusing the syntax or purpose of route parameters vs. query strings.
• ×Incorrectly accessing the values (e.g., trying to get `req.query.id` from a route parameter).
• ×Not providing clear, distinct examples for both.

What a strong answer covers

• Custom error handling middleware functions have four arguments: `(err, req, res, next)`.
• Express recognizes this signature and routes errors to it automatically.
• Place error handling middleware after all other `app.use()` and route calls.
• Example: `app.use((err, req, res, next) => { console.error(err.stack); res.status(500).send('Something broke!'); });`

Where people lose the point

• ×Forgetting the `err` argument, making it a regular middleware instead of an error handler.
• ×Placing the error middleware before regular routes, preventing it from catching errors from those routes.
• ×Not sending a response or calling `next()` in the error handler, causing the request to hang.

What a strong answer covers

• `express.Router()` creates a new router object, which is a complete middleware and routing system.
• It allows you to define routes and middleware for a specific part of your application in a modular way.
• You would use it to organize your application into logical, maintainable modules (e.g., separate routers for 'users', 'products', 'auth').
• Routers are then 'mounted' onto specific base paths in the main application using `app.use('/api/users', usersRouter)`.

Where people lose the point

• ×Confusing `express.Router()` with the main `app` object.
• ×Not explaining the benefit of modularity and organization.
• ×Incorrectly describing how a router is integrated into the main application.

What a strong answer covers

• The `next()` function is the third argument passed to an Express.js middleware function.
• Its purpose is to pass control to the next middleware function in the stack or to the next route handler.
• If a middleware function does not end the request-response cycle (e.g., by sending a response with `res.send()`), it *must* call `next()` to ensure the request continues processing.
• Failing to call `next()` will cause the request to hang indefinitely, as the server will not know to proceed.

Where people lose the point

• ×Not emphasizing that `next()` is crucial for continuing the request-response cycle.
• ×Incorrectly stating that `next()` is only for error handling (it's also for normal flow).
• ×Failing to mention the consequence of not calling `next()` (request hanging).

What a strong answer covers

• Asynchronous errors (e.g., from Promises, `async/await`) are not automatically caught by Express's default error handler or custom error middleware if not explicitly passed.
• For `async/await` functions, wrap the asynchronous code in a `try-catch` block and call `next(error)` in the `catch` block.
• Alternatively, use a utility like `express-async-handler` or a custom wrapper function to automatically catch promise rejections and pass them to `next()`.
• Ensure your custom error handling middleware is defined with four arguments `(err, req, res, next)` to process these errors.

Where people lose the point

• ×Assuming `async/await` errors are automatically handled without `try-catch` or a wrapper.
• ×Not calling `next(error)` when an asynchronous error occurs, leading to unhandled promise rejections.
• ×Confusing synchronous error handling with asynchronous error handling.

What a strong answer covers

• Express.js executes middleware functions sequentially in the order they are defined using `app.use()` or `app.METHOD()`.
• Middleware functions can modify the request/response objects or terminate the request-response cycle, so their position determines when these actions occur.
• If a middleware function that sends a response (e.g., `res.send()`) is placed before another middleware or route, the subsequent ones will never be executed for that request.
• Example: A body-parser middleware *must* come before any route handler that attempts to read `req.body`, otherwise `req.body` will be undefined. Similarly, an authentication middleware should come before protected routes.

Where people lose the point

• ×Understating the critical nature of middleware order, implying it's merely a suggestion.
• ×Failing to provide a concrete example where incorrect order leads to functional issues.
• ×Not mentioning that middleware can terminate the cycle, preventing subsequent execution.

What a strong answer covers

• Define a middleware function `authenticateApiKey(req, res, next)`.
• Inside, retrieve the 'Authorization' header using `req.headers.authorization`.
• Check if the header exists and if its value matches a predefined `SECRET_API_KEY`.
• If valid, call `next()` to proceed; otherwise, send `res.status(401).send('Unauthorized: Invalid API Key')`.
• Demonstrate how to apply this middleware to a specific route or globally using `app.use()`.

Where people lose the point

• ×Forgetting to call `next()` when authentication is successful, causing requests to hang.
• ×Not setting the correct HTTP status code (401 Unauthorized).
• ×Exposing the `SECRET_API_KEY` directly in the code without considering environment variables.

What a strong answer covers

• **X-Content-Type-Options: nosniff**: Prevents browsers from MIME-sniffing a response away from the declared content-type, mitigating XSS attacks.
• **X-Frame-Options: DENY/SAMEORIGIN**: Prevents clickjacking attacks by controlling whether a page can be rendered in an `<iframe>`, `<frame>`, or `<object>`.
• **Strict-Transport-Security (HSTS)**: Forces clients to connect to the server over HTTPS only, preventing downgrade attacks and cookie hijacking.
• **Content-Security-Policy (CSP)**: Mitigates XSS by specifying valid sources for content (scripts, styles, images, etc.) that the browser should load.
• **X-XSS-Protection: 0**: Disables the browser's built-in XSS auditor, as CSP is a more robust solution and the auditor can sometimes introduce vulnerabilities.

Where people lose the point

• ×Listing headers without explaining their security purpose.
• ×Confusing the purpose of different headers (e.g., X-Frame-Options vs. CSP).
• ×Not mentioning the `helmet` middleware as a common way to implement many of these.

What a strong answer covers

• **Global Middleware**: Applied to all incoming requests to the application using `app.use()`. It's suitable for tasks that need to run for every request, regardless of the route.
• **Route-Specific Middleware**: Applied only to specific routes or groups of routes. It's suitable for tasks that are relevant only to certain endpoints.
• **Global Example**: Logging middleware, body parsing (`express.json()`), security headers (`helmet`), or static file serving (`express.static()`) are typically global.
• **Route-Specific Example**: Authentication middleware for protected API endpoints, validation middleware for specific data submission routes, or authorization checks for admin-only routes.

Where people lose the point

• ×Failing to clearly distinguish the scope of application for each type.
• ×Providing examples that could be applied to either, without explaining why one is preferred.
• ×Not mentioning that route-specific middleware can be an array of functions.

What a strong answer covers

• **Resource-Based Routing**: Design routes around resources (e.g., `/users`, `/products`) using appropriate HTTP methods (GET, POST, PUT, DELETE) for CRUD operations. Utilize `express.Router()` for modularity.
• **Statelessness**: Ensure each request from a client to server contains all necessary information, with no session state stored on the server between requests.
• **Data Validation**: Implement input validation (e.g., using libraries like Joi or Express-validator) in middleware before route handlers to ensure data integrity and prevent malicious input.
• **Consistent Error Handling**: Implement a centralized error handling middleware to catch all errors, log them, and send consistent, informative (but not overly verbose) error responses (e.g., 400 Bad Request, 401 Unauthorized, 404 Not Found, 500 Internal Server Error).
• **Authentication & Authorization**: Use middleware for authentication (e.g., JWT, API keys) to verify user identity and authorization to check if the user has permission for the requested action.

Where people lose the point

• ×Confusing RESTful principles with general API design (e.g., not mentioning statelessness).
• ×Omitting crucial aspects like data validation or proper error response formats.
• ×Not emphasizing the use of Express.js features like `express.Router()` for organization.