30 NestJS Interview Questions and Answers (2026)

NestJS has become the default choice for backend teams that want structure, testability, and TypeScript from day one. It shows up constantly on job postings for backend engineers, full-stack developers, and API architects. The framework borrows Angular's module system and dependency injection model and brings them to Node.js, which makes it powerful, but it also means interviews probe architectural thinking, not just syntax.

These 30 questions reflect what interviewers are actually asking in 2025 and 2026, from foundational concepts to microservices and testing. The answers are written to be said out loud in an interview: clear, specific, and backed by real code examples you can reference if you're asked to write something on a whiteboard or shared editor.

If you're setting up a fresh NestJS project to practice these concepts in, getting your npm scripts and Node.js tooling right first means you're not fighting build configuration while you're trying to demo dependency injection and module structure.

These questions establish whether you understand what NestJS adds on top of Node.js and Express, and whether you can reason about its architecture rather than just its syntax. They are almost always the opening questions in a NestJS interview.

NestJS is a TypeScript-first Node.js framework for building scalable server-side applications. It is built on top of Express by default (or Fastify as an alternative) and adds a full architectural layer: modules, dependency injection, decorators, and a clear separation between controllers, services, and providers.

Plain Express is minimal by design. It gives you routing and middleware and leaves every architectural decision to you. That works fine for small apps but creates inconsistency across teams at scale. NestJS solves this by enforcing a module-based structure inspired by Angular: every feature is a self-contained module, dependencies are injected rather than imported and instantiated directly, and the result is code that's easier to test, easier to refactor, and consistent across the entire codebase.

The practical difference: in Express you write a route handler and manage all of its dependencies manually. In NestJS you define a controller with decorators, inject a service, and the framework wires everything together for you.

A module is the basic building block of a NestJS application. Every application has at least one module, the root AppModule. Modules use the @Module() decorator and declare four things: imports (other modules whose exported providers this module needs), controllers (the request handlers belonging to this module), providers (services, repositories, guards, and other injectables), and exports (providers this module makes available to other modules that import it).

Modules enforce encapsulation. A provider declared in UsersModule is not available anywhere else unless it's exported. This prevents unintended coupling between features and is one of the reasons large NestJS codebases stay maintainable as they grow.

A Controller handles incoming HTTP requests and returns responses. It maps routes to handler methods using decorators like @Get(), @Post(), @Put(), and @Delete(). Controllers should contain no business logic: they receive input, call a service, and return the result.

A Provider is anything injectable: a service, repository, guard, interceptor, or factory. Services contain the business logic. They're marked with @Injectable() and injected into controllers or other services through the constructor.

NestJS uses an IoC (Inversion of Control) container managed at the module level. When you declare a provider in a module's providers array, NestJS registers it in the container. When a controller or service declares a dependency in its constructor, NestJS resolves and injects it automatically.

You never call new MailerService() anywhere. NestJS creates the instance, manages its lifecycle, and injects it wherever it's needed. Providers are singleton by default within a module, meaning one instance is shared across all consumers.

This pattern makes testing straightforward: you can replace any dependency with a mock without changing the class that uses it, which is exactly what Q28 and Q29 in this guide cover.

NestJS supports four provider types, and knowing when to reach for each one is a strong signal of real architectural understanding.

Use factory providers when initialization is asynchronous or when the provider depends on runtime configuration, such as a database connection string that comes from ConfigService.

Decorators are TypeScript functions that attach metadata to classes, methods, parameters, or properties. NestJS uses them everywhere to configure behavior without imperative setup code.

You can also create custom decorators to extract reusable logic, which is a common follow-up question once you've named the built-in ones.

This is one of the most commonly asked NestJS interview questions, and it's the one this guide's research found almost no competing article explains clearly. The full execution order for an incoming request is:

A circular dependency occurs when Module A imports Module B and Module B imports Module A, or when Service A depends on Service B and Service B depends on Service A. NestJS cannot resolve these at startup and will throw an error.

The correct fix is architectural: refactor so the shared logic lives in a third SharedModule that both A and B import. This is almost always the right answer, and it's the answer that shows you think about dependency graphs rather than reaching for a quick patch.

If you genuinely cannot avoid the circular reference, NestJS provides forwardRef() as an escape hatch:

For modules, you apply forwardRef() in the imports array of both modules involved.

This category goes deep on the layers introduced in Q7's lifecycle: middleware, guards, pipes, interceptors, and exception filters. Expect interviewers to probe not just what each layer does, but when you'd reach for one over another, since that distinction is where junior and senior answers diverge most.

Middleware in NestJS is identical to Express middleware: a function that runs before the route handler, with access to req, res, and next(). It's applied at the module level using configure() and the MiddlewareConsumer.

Use middleware for logging, request tracing, body parsing, CORS, rate limiting, and session management. Don't use it for authentication or authorization, that belongs in Guards. Middleware also runs before NestJS's DI-aware pipeline, so it can't inject providers as cleanly as the layers that follow it.

Guards implement the CanActivate interface and return a boolean (or a Promise or Observable that resolves to one). If a guard returns true, the request proceeds. If it returns false or throws an UnauthorizedException, the request is blocked.

Guards have access to the ExecutionContext, which provides request metadata, the handler being called, and the class it belongs to. That's what makes them suitable for both authentication (is this a valid user?) and authorization (does this user have permission?).

Pipes implement PipeTransform and run on the value of a route parameter, body, or query string before it reaches the handler. They serve two purposes: transformation (convert a string id to a number) and validation (reject input that doesn't match a schema).

Built-in pipes include ValidationPipe, ParseIntPipe, ParseUUIDPipe, ParseBoolPipe, DefaultValuePipe, and ParseArrayPipe. ValidationPipe paired with class-validator is the standard pattern for DTO validation:

Interceptors implement NestInterceptor. They wrap the route handler's execution using RxJS Observables, which lets them add behavior both before and after the handler runs.

Apply interceptors globally in main.ts with app.useGlobalInterceptors(new LoggingInterceptor()), or per-route with @UseInterceptors().

Exception filters catch exceptions thrown during request processing and transform them into HTTP responses. NestJS includes a global exception filter that handles HttpException and its subclasses; any unrecognized exception returns a 500 Internal Server Error.

You write a custom exception filter when you need consistent error response formatting, want to log errors to an external service, or need to handle exceptions thrown by third-party libraries, like TypeORM's EntityNotFoundError.

@Catch() called without arguments catches every exception, which is the pattern you'd reach for to build a single global error formatter for an API.

This is one of the most common NestJS interview questions, and the cleanest way to answer it is to anchor each one to what it has access to and what it's best used for.

Interceptors sit on the other side of the handler from guards: they wrap execution using RxJS, so they can access both the incoming request and the outgoing response. They're the right tool for logging request duration, transforming responses, caching, and adding headers, anything that needs to wrap rather than gate the request.

The summary worth memorizing: middleware is for cross-cutting concerns outside the DI system, guards are for access control, and interceptors are for wrapping execution and transforming data flow.

This question checks whether you understand the PipeTransform interface well enough to implement it yourself, not just configure the built-in pipes.

NestJS already ships a built-in ParseUUIDPipe, and it's worth saying so out loud. But writing a custom one in an interview demonstrates that you understand the interface underneath it, which is the actual point of the question.

These are parameter decorators that extract specific parts of the incoming request directly into your handler's arguments, instead of you reaching into req manually.

Once an interviewer is convinced you understand the request pipeline, they'll usually move into how you secure it. These four questions cover the patterns that come up in almost every backend role: token-based auth, role checks, configuration, and the broader security checklist.

The standard approach uses @nestjs/passport and @nestjs/jwt with the passport-jwt strategy. It comes together in three steps: configure JwtModule, create a strategy that validates the token, and guard the routes that need protection.

RBAC requires two things: attaching role metadata to routes, and checking that metadata inside a Guard. NestJS's Reflector class is what bridges the two.

Use @nestjs/config, which wraps dotenv and integrates with the DI system so you can inject configuration values like any other provider.

The validationSchema option with Joi validates required variables at startup. If DATABASE_URL is missing, the app crashes immediately with a clear error rather than failing silently the first time someone hits an endpoint that needs it.

This question is really asking whether you think about security as a set of layers rather than a single checkbox. A strong answer names each layer and the specific tool or pattern that covers it.

Almost every NestJS role involves a database, so interviewers use this category to check whether you can wire up an ORM, manage relations, and reason about transactions, not just write a findOne() call. If you want a deeper comparison of ORM tooling beyond what NestJS ships with by default, this practical Drizzle ORM migrations guide is a useful companion read.

TypeORM integration follows a consistent pattern: configure the connection at the root, declare entities, register them per feature module, and inject repositories into services.

Mongoose integration mirrors TypeORM's pattern but swaps entities and repositories for schemas and models. If you're asked to compare the two, this is the structural symmetry to point out.

TypeORM gives you two levels of control. The QueryRunner API is explicit: you connect, start the transaction, run your operations, and commit or roll back yourself.

For simpler cases, DataSource.transaction() wraps the same commit and rollback behavior automatically, which is the version worth reaching for unless you specifically need the manual control:

Relations in TypeORM are declared with decorators on both sides of the relationship. A One-to-Many relation, like one User having many Posts, pairs @OneToMany on the parent with @ManyToOne and @JoinColumn on the child:

The final stretch of a senior NestJS interview usually moves past CRUD and into how the framework scales: microservices, messaging patterns, CQRS, testing strategy, and caching. These are the questions that separate someone who has shipped a single API from someone who has run NestJS in a distributed system.

NestJS has a built-in microservices module that abstracts over multiple transport layers, so the same controller patterns work whether the underlying transport is TCP or a message broker.

Both decorators mark handlers in a microservice controller, but the communication model behind them is different, and naming that difference precisely is the point of the question.

@MessagePattern handles request-response messages: the caller sends a message and waits for a reply. Use it when the caller actually needs a result back.

@EventPattern handles fire-and-forget events: the caller emits and doesn't wait for a response. Use it for notifications, audit logging, and asynchronous side effects where the caller doesn't need to know the outcome immediately.

CQRS, Command Query Responsibility Segregation, separates write operations (commands) from read operations (queries). The @nestjs/cqrs package provides a CommandBus, QueryBus, and EventBus to implement this pattern without building the plumbing yourself.

CQRS is most valuable in complex domains where reads and writes have different scaling requirements, or where you're using event sourcing. It's worth being honest in an interview that it adds real complexity, and naming the cases where it pays for itself is more convincing than presenting it as a default choice.

NestJS uses Jest by default, and the Test module from @nestjs/testing creates a test DI container where you can swap real providers for mocks without touching the class under test.

End-to-end tests use Supertest to make real HTTP requests against the full NestJS application. They live in the test/ folder and exercise the actual request pipeline, not mocked pieces of it.

Override external dependencies, like the database or an email service, in your E2E tests so they run fast and don't require any external infrastructure to pass in CI.

NestJS has a built-in caching module, @nestjs/cache-manager, that works with in-memory storage by default and Redis for production. You can apply it broadly with an interceptor or precisely with manual cache control inside a service.

Use CacheInterceptor for simple GET route caching, and manual cache control when you need finer granularity: different TTLs per entity, cache invalidation on mutations, or composite cache keys. If you want a deeper look at the async patterns underneath caching and other I/O-heavy NestJS code, these async/await mistakes that slow down JavaScript cover the traps that show up just as often in service layers as in front-end code.

Use this as a final scan the night before an interview. If any row makes you pause, jump back up to that question's full answer.