Top 60 NestJS Interview Questions (2026)

NestJS is a TypeScript-first framework for building server-side Node.js applications. It runs on top of Express by default and adds an opinionated structure: modules, controllers, providers, and a built-in dependency injection container.

The problem it solves is architecture drift. Plain Express leaves file layout and wiring up to each team, so large codebases diverge. Nest hands you conventions borrowed from Angular, so a big team organizes code the same way and features stay testable.

Nest is built on top of Express, so it isn't a replacement so much as a structured layer over it. Express gives you routing and middleware and nothing else; you decide the folder layout, how services are wired, and how errors are handled.

Nest adds modules, dependency injection, decorators, and a defined request lifecycle. You trade a heavier learning curve and more files for consistency that pays off as the team and codebase grow.

A module is a class decorated with @Module() that groups related code: controllers, providers, and the modules it imports and exports. Every Nest app has at least a root AppModule, and features get their own modules.

Modules are how Nest scopes dependency injection. A provider is available inside its module by default, and only becomes available to other modules if the owning module exports it and the other module imports it.

A controller is a class decorated with @Controller() whose methods handle incoming requests. The decorator's argument sets a route prefix, and method decorators like @Get() and @Post() map HTTP verbs and sub-paths to handlers.

Controllers should stay thin: read the request, call a service, return the result. Business logic belongs in providers, not in the controller.

A provider is any class Nest can inject as a dependency, most often a service holding business logic. Marking it with @Injectable() tells Nest's container it can manage and inject that class.

Once a provider is registered in a module's providers array, Nest creates it and hands it to any controller or provider that asks for it in a constructor. That is dependency injection in Nest.

You declare a dependency by typing a constructor parameter, and Nest's DI container supplies the instance. You never call new on a service; the container resolves the whole graph and injects singletons where they're needed.

This inverts control: a class states what it needs, and the framework provides it. That makes classes easier to test because you can pass a mock in place of the real dependency.

Decorators are functions prefixed with @ that attach metadata to classes, methods, or parameters. Nest reads that metadata at startup to wire routes, injection, validation, and the request lifecycle.

That's why @Controller(), @Get(), @Injectable(), @Body(), and @Param() are everywhere: they describe intent declaratively, and Nest turns the metadata into behavior. Decorators come from TypeScript, and Nest builds its whole model on them.

The Nest CLI is a command-line tool that scaffolds and runs projects. nest new creates an app, and nest generate (or nest g) creates modules, controllers, services, and more with the right files, decorators, and test stubs already wired.

Teams use it to keep structure consistent: generating a resource produces the module, controller, service, and DTOs in one command, so everyone's files look the same.

main.ts is the entry point. It calls NestFactory.create() with the root AppModule to build the application instance, applies any global setup (pipes, prefixes, CORS), and then calls listen() to start the HTTP server.

During create(), Nest resolves the whole module graph and instantiates every singleton provider once, which is why a wiring mistake usually fails loudly at startup rather than at request time.

A DTO (data transfer object) is a class that defines the expected shape of data moving into or out of your app, usually a request body. It gives you a typed contract instead of untyped any.

Paired with class-validator decorators and the ValidationPipe, the DTO becomes the validation layer: bad requests get rejected before they reach your service, and the service works with a known shape.

Nest gives you parameter decorators: @Body() for the request body, @Param() for route parameters, @Query() for the query string, and @Headers() for headers. You pull exactly what you need instead of touching the raw request object.

You can grab a single value (@Param('id')) or the whole object (@Body()). Pairing @Body() with a DTO type is what enables validation.

The ValidationPipe runs class-validator rules against incoming DTOs and rejects requests that fail, returning a 400 with the reasons. It reads the decorators on your DTO classes to know what valid means.

You usually enable it globally in main.ts. Options like whitelist strip unknown properties, and transform turns the plain payload into an instance of the DTO class.

Throw one of Nest's built-in HTTP exceptions, like NotFoundException or BadRequestException, and Nest's default exception filter turns it into the right status code and JSON body. You don't set res.status by hand.

For a custom status, throw new HttpException(message, status). Unhandled errors become a 500, so throwing the specific exception is how you control the response.

Middleware is a function that runs before the route handler, with access to the request and response objects. It's the same concept as Express middleware: logging, request enrichment, raw header checks.

You register it in a module by implementing NestModule and configuring routes in the configure() method. Middleware runs first in the lifecycle, before guards.

A guard is a class that decides whether a request is allowed to reach the handler. Its canActivate() method returns true to continue or false (or throws) to block, which is how Nest models authentication and authorization.

Guards run after middleware but before interceptors and pipes, and they have access to the execution context, so they can read the request, roles, and metadata set by decorators.

Pipes do two jobs: transformation and validation. They run just before the handler on the arguments bound by decorators. ParseIntPipe transforms a string param to a number; ValidationPipe validates a DTO.

You apply a pipe at the parameter, handler, controller, or global level. If a pipe throws, the handler never runs, which is how bad input gets stopped early.

A controller handles the HTTP layer: it maps routes to methods, reads the request, and returns a response. A provider (usually a service) holds the business logic and is injected into controllers.

The separation keeps controllers thin and logic reusable and testable. The same service can be used by several controllers, a scheduled job, or a message handler.

By default a provider is private to its module. To use it elsewhere, add it to the owning module's exports array, then import that module wherever you need the provider.

This is the most common wiring bug for beginners: injecting a service from another module without exporting it and importing the module, which produces a 'Nest can't resolve dependencies' error at startup.

A handler can return a Promise, and Nest awaits it before sending the response. Mark the method async and return the awaited value; Nest also accepts an RxJS Observable and resolves it.

You return the data, not the response object. Nest serializes whatever you return to JSON with a 200 (or 201 for POST) unless you throw an exception or set a different status.

The @nestjs/config package provides ConfigModule, which loads .env files and exposes values through an injectable ConfigService. You import ConfigModule.forRoot() once, often with isGlobal: true, then inject ConfigService anywhere.

This keeps environment reads in one typed place instead of scattering process.env across the codebase, and it supports validation of required variables at startup.

Nest defaults to 200 for most handlers and 201 for POST. You override with the @HttpCode() decorator on a method, and you signal errors by throwing HTTP exceptions rather than setting a status manually.

This keeps handlers returning plain data. Reaching for the raw response object to set a status is usually a sign you're fighting the framework.

Yes. Nest is platform-agnostic through an adapter. Express is the default, but you can swap in the Fastify adapter for higher throughput and lower overhead, and most of your application code stays the same.

The trade-off: some Express-specific middleware won't work under Fastify, so you check plugin compatibility. For most apps the default Express adapter is fine.

Nest maps each HTTP verb to a method decorator: @Get for reads, @Post to create, @Patch or @Put to update, and @Delete to remove. You combine them with a route prefix on the controller and path params on the methods to cover the standard CRUD routes.

Each handler pulls what it needs with @Param, @Body, or @Query and calls the service. Keeping the controller a thin map from route to service method is the pattern the question expects to see.

Nest ships with Jest and a Test.createTestingModule() helper that builds a module in memory. You register the class under test, resolve it, and can swap real providers for mocks because everything is injected.

That's the payoff of dependency injection for testing: you never wire a real database into a unit test, you provide a fake in its place.

For an incoming request the order is: middleware, then guards, then interceptors (pre-controller part), then pipes, then the route handler, then interceptors again (post-controller part), and finally, if anything threw, exception filters.

Knowing this order matters because it decides where each concern belongs: authorization in a guard, input validation in a pipe, response shaping in an interceptor, error formatting in a filter.

Each owns one concern. A guard decides if a request may proceed. A pipe validates and transforms the incoming arguments. An interceptor wraps the handler to add behavior before and after, like logging or response shaping. An exception filter catches thrown errors and formats the response.

Mixing them up is the most common intermediate mistake. Validation in an interceptor or auth in a pipe technically runs, but it puts the logic in the wrong place and breaks the order guarantees.

An interceptor implements NestInterceptor and wraps the handler with an RxJS stream. Code before next.handle() runs before the handler; operators piped onto the returned Observable run after, so you can transform or replace the response.

Typical uses: logging with timing, mapping every response into a consistent envelope, caching, and serialization. The before-and-after nature is what makes them the right tool for cross-cutting response concerns.

You implement ExceptionFilter, decorate it with @Catch() naming the exceptions to handle, and use the arguments host to grab the response and send a shaped error body. Register it globally, on a controller, or on a method.

You write one when the default error shape doesn't fit: to add a request id, log to an external system, or map domain exceptions to a consistent API error format across the whole app.

There are three scopes. Singleton (the default) creates one instance shared app-wide. Request-scoped creates a fresh instance per request. Transient creates a new instance for each consumer that injects it.

Stay on singleton almost always; it's the fastest and simplest. Reach for request scope only when a provider must hold per-request state, and know the cost: request scope bubbles up, so anything injecting it also becomes request-scoped and loses the singleton performance.

Beyond the shorthand of listing a class, you can register providers explicitly. useClass swaps one implementation for another, useValue injects a constant or mock, and useFactory computes the provider, optionally injecting other providers to build it.

These power configuration, swapping implementations by environment, and injecting third-party clients. A factory is the usual way to create something like a database client that needs config values.

Nest resolves most dependencies by the class type. But when a provider is registered under a string or symbol token (like a config value or an interface), there's no class to key on, so you inject it with @Inject('TOKEN').

Tokens matter for injecting non-class values and for depending on an interface: TypeScript interfaces vanish at runtime, so you register the implementation under a token and inject that token.

A dynamic module is a module configured at import time by a static method that returns a module definition. That's why you write ConfigModule.forRoot(options) or TypeOrmModule.forFeature([Entity]) instead of a bare import.

The pattern lets a reusable module accept configuration: forRoot sets up the module once for the whole app, forFeature registers per-feature pieces (like the entities a given module uses). It's how library modules stay configurable.

@Global() marks a module so its exported providers are available everywhere without importing the module in each place. It's used for things needed app-wide, like configuration.

Avoid it for most feature modules. Global scope hides dependencies and makes the graph harder to reason about, so the explicit import-and-export path is better unless a provider is genuinely used almost everywhere.

With TypeORM, you import TypeOrmModule.forRoot() with the connection config once, then TypeOrmModule.forFeature([Entity]) in each feature module to inject that entity's repository. With Prisma, you wrap the generated PrismaClient in an injectable PrismaService and inject it.

Either way, data access lives in providers behind an injectable, so services depend on a repository or client rather than talking to the database directly. That keeps the data layer swappable and testable.

forRootAsync configures a dynamic module using values that aren't known statically, most often config loaded at runtime. Instead of passing a literal options object, you pass a factory that can inject ConfigService and return the options.

You need it whenever a module's setup depends on environment values: a database URL, an API key, a feature flag. Passing them through a synchronous forRoot would mean hardcoding, which defeats configuration.

You use createParamDecorator, which receives the execution context and returns whatever value you want bound to the parameter. The classic example is a @CurrentUser() decorator that pulls the authenticated user off the request.

It cleans up controllers: instead of reading req.user in every handler, you write @CurrentUser() user: User, and the extraction logic lives in one place.

You attach metadata to a route with a custom decorator built on SetMetadata (a @Roles('admin') decorator), then write a guard that reads that metadata with the Reflector and compares it to the current user's roles.

This is the standard Nest authorization pattern: the decorator declares the requirement next to the route, and one guard enforces it everywhere, so the rule and the check stay in sync.

@nestjs/passport wraps the Passport library in Nest's model. You write a strategy (JwtStrategy, LocalStrategy) whose validate() method returns the user, and Nest attaches it to the request. A guard (AuthGuard('jwt')) triggers the strategy on protected routes.

The flow: a login route issues a JWT with @nestjs/jwt, and protected routes use the JWT guard, which runs the strategy to verify the token and populate req.user. Keeping the strategy and guard split is the idiomatic setup.

Nest calls lifecycle hooks at defined moments. onModuleInit runs once the host module's dependencies are resolved, good for setup like opening a connection. onApplicationBootstrap runs after all modules are ready. onModuleDestroy and beforeApplicationShutdown run during graceful shutdown.

You implement the matching interface and the method. The shutdown hooks matter in production for clean teardown: closing database pools and finishing in-flight work when the process gets a termination signal.

The @nestjs/swagger package reads your decorators and DTOs to build an OpenAPI spec and a Swagger UI. You set it up in main.ts with a DocumentBuilder, and decorators like @ApiTags and @ApiProperty enrich the output.

Because Nest is already decorator-driven, much of the documentation comes for free from your controllers and DTO classes, so the spec stays close to the actual code.

Nest provides CacheModule, which you can back with an in-memory store or Redis. You either inject the cache manager to get and set values directly, or apply the CacheInterceptor to cache GET responses automatically.

The interceptor path is the quick win for read-heavy endpoints; the injected manager gives you control for partial or computed caching. Redis is the choice once you run more than one instance so the cache is shared.

@nestjs/schedule adds cron jobs, intervals, and timeouts through decorators. You mark a provider method with @Cron() or @Interval() and Nest runs it on schedule once ScheduleModule.forRoot() is imported.

For heavier or retryable background work you reach past the scheduler to a queue like BullMQ via @nestjs/bullmq, which persists jobs and survives restarts. The scheduler is for simple recurring work in-process.

You build the whole app with Test.createTestingModule({ imports: [AppModule] }), call createNestApplication(), and fire real HTTP requests at it with supertest. That exercises the full pipeline: routing, guards, pipes, and serialization.

You can still override providers to stub external systems while testing the real request path. E2E tests catch wiring bugs that unit tests miss, like a guard blocking a route it shouldn't.

Use the ClassSerializerInterceptor with class-transformer decorators. Mark a field with @Exclude() on the entity or response class, and the interceptor strips it before the response is sent, so a password hash never leaks.

This keeps the filtering declarative and central rather than deleting fields by hand in every handler. You enable the interceptor globally and annotate the classes.

At startup Nest scans modules, reads the constructor metadata that TypeScript emits (via emitDecoratorMetadata), and builds a dependency graph. It topologically resolves that graph, instantiating each singleton once and injecting resolved instances into constructors.

Resolution is scoped by module: a provider token is looked up in the module and its imported, exported providers. This is why the 'can't resolve dependencies' error names the token and the module, and why request-scoped providers force a per-request sub-tree instead of the startup singleton pass.

When two providers (or modules) depend on each other, Nest can't resolve the graph and errors at startup. The escape hatch is forwardRef() on both sides, which defers resolution so the container can break the cycle.

The better answer is that a circular dependency is usually a design smell. Before reaching for forwardRef, consider extracting the shared logic into a third provider both depend on, or using an event to invert one direction of the call.

Nest has a microservices layer that reuses the same controllers and providers but swaps HTTP for a message transport. You create the app with createMicroservice and pick a transporter: TCP, Redis, NATS, RabbitMQ, Kafka, or gRPC.

Handlers change from @Get() to @MessagePattern() (request-response) or @EventPattern() (fire-and-forget). The architecture point to make: message patterns give you decoupling and back-pressure that raw HTTP calls between services don't.

@nestjs/graphql integrates Apollo (or Mercurius). You write resolvers the same way you write controllers, with @Resolver, @Query, and @Mutation. The two approaches differ in where the schema comes from.

Code-first generates the GraphQL schema from TypeScript classes and decorators, so types stay the single source of truth. Schema-first starts from a .graphql SDL file and generates types from it. Code-first suits TypeScript-heavy teams; schema-first suits contracts owned outside the code.

The @nestjs/cqrs module splits writes (commands) from reads (queries) and adds events, each with its own handler. It fits domains with rich business rules where you want commands, events, and side effects as first-class, testable units rather than fat services.

The honest caveat: it adds real ceremony. For CRUD-shaped features it's over-engineering. Reach for it when the domain logic is genuinely complex or when you want an event stream driving other work, not by default.

ArgumentsHost abstracts the underlying arguments of the current context so the same guard, interceptor, or filter works across HTTP, WebSockets, and microservices. You call switchToHttp(), switchToRpc(), or switchToWs() to get the right shape.

ExecutionContext extends it with getHandler() and getClass(), which is what lets a guard read route metadata via the Reflector. This abstraction is why one RolesGuard can protect an HTTP route and an RPC handler without rewriting.

app.useGlobalGuards(new MyGuard()) registers a guard outside the DI container, so it can't inject dependencies. Binding it as a provider with the APP_GUARD token registers it through DI, so it can inject services like a ConfigService or Reflector.

The same holds for APP_PIPE, APP_INTERCEPTOR, and APP_FILTER. The rule: if the global enhancer needs dependencies, use the token form; the useGlobalX form is only fine for enhancers with no dependencies.

A request-scoped provider is rebuilt on every request instead of once at startup, and the scope is contagious: any provider that injects a request-scoped one becomes request-scoped too, and so on up the chain. A single misplaced request-scoped provider can turn much of your graph per-request.

That means more allocations and slower requests, and it can silently disable performance features that assume singletons. The strong move is to keep providers singleton and pass per-request data explicitly, using the injected REQUEST only where truly needed.

You call app.enableShutdownHooks() so Nest listens for termination signals and runs the shutdown lifecycle. Then providers implement onModuleDestroy or beforeApplicationShutdown to close database pools, drain queues, and stop accepting new work.

The production detail: pair this with the platform stopping traffic first (a readiness probe flipping to not-ready), so in-flight requests finish while new ones stop arriving. Enabling shutdown hooks without draining traffic still drops requests.

Three layers. Unit tests resolve a single provider with its dependencies mocked, fast and numerous. Integration tests build a real module (a service plus its repository against a test database) to catch wiring and query bugs. E2E tests hit the running app over HTTP to verify the full pipeline including guards and pipes.

The judgment interviewers probe is what to mock where: mock external boundaries (payment APIs, email) always, use a real database in integration tests, and override providers with Nest's testing utilities rather than reaching into internals.

The CLI has a monorepo mode with multiple apps and shared libraries under one workspace, configured in nest-cli.json. Shared code (DTOs, common guards, a database module) lives in a library that each app imports, so contracts stay in one place.

At larger scale teams often move to Nx for smarter caching and dependency graphs, but the built-in monorepo covers the common case: several Nest services sharing typed contracts without publishing internal packages.

Define a domain exception hierarchy (a base app exception plus specific subclasses), throw those from services, and use a single global exception filter to map them to HTTP responses with a stable shape. Reserve Nest's built-in HTTP exceptions for the edge, and translate domain errors at the boundary.

The filter is also where you attach a request id, log with context, and avoid leaking internals in the message. Centralizing this means every endpoint returns errors the same way, which clients and on-call engineers rely on.

class-transformer turns a plain incoming object into an instance of the DTO class (that's the transform option on ValidationPipe). class-validator then reads the validation decorators on that instance and checks each rule, collecting errors.

The order matters: transform first so nested objects and types are real class instances, then validate. Options like enableImplicitConversion coerce types (a string '5' to a number) and whitelist strips unknown properties, which together stop over-posting attacks.

A gateway is a class decorated with @WebSocketGateway() that handles real-time events. @SubscribeMessage('event') maps an incoming message to a handler, and you emit back to clients through the injected server or client socket.

The design point: guards, interceptors, and pipes still apply through the same ArgumentsHost abstraction, so authorization and validation reuse the HTTP-side components. Socket.io is the default adapter; ws is an option.

Replace the default logger with a structured one (pino via nestjs-pino) so logs are JSON with request context. Add an interceptor to time requests and emit metrics, and wire OpenTelemetry so spans propagate across service calls and into the database driver.

The senior framing is that Nest's interceptor and DI model make observability a cross-cutting concern you add in one place, not per-handler. Correlating a request id from the edge through logs, traces, and downstream calls is what makes production debugging tractable.

feature modules that own their controllers, services, and DTOs, and depend on each other only through exported providers, so boundaries stay explicit comes first. Put cross-cutting concerns (auth, logging, config) in shared modules bound globally through APP_GUARD-style tokens. Keep the data layer behind repositories so it stays swappable.

Then address scale: keep providers singleton for performance, push heavy or retryable work to queues, split into microservices only when a domain boundary and team ownership justify it, and enforce the module boundaries in review. Structuring the answer modules, cross-cutting concerns, data layer, then scale is what the question rewards.