NestJS Interview Questions and Answers

NestJS is a TypeScript-first Node.js framework for server-side apps. It adds structure (modules, controllers, providers) and dependency injection on top of Express or Fastify.

Why choose it:

• Enforced architecture, so large teams write code the same way.
• Built-in DI makes services easy to test and swap.
• First-class support for validation, config, OpenAPI, GraphQL, WebSockets and microservices.
• Decorators for routing, guards and pipes keep controllers thin.

Downsides: more repeated setup code and a learning curve compared with a 50-line Express app. For tiny scripts, plain Express or Fastify is fine.

What they are checking: Whether you can explain a framework choice with its pros and cons

A module is a class decorated with @Module() that groups related controllers and providers together. Every app has at least a root module.

@Module({
  imports: [DatabaseModule],      // other modules whose exports we need
  controllers: [UsersController],
  providers: [UsersService],
  exports: [UsersService],        // what other modules may inject
})
export class UsersModule {}

• Providers are private to a module unless listed in exports.
• A module must import another module to use its exported providers.
• Modules are singletons by default, so a shared module is instantiated once.

What they are checking: Whether you understand encapsulation between modules

A controller handles incoming requests, extracts input, calls a service, and returns the response; it should contain no business logic.

@Controller('users')
export class UsersController {
  constructor(private readonly users: UsersService) {}

  @Get(':id')
  findOne(@Param('id', ParseIntPipe) id: number) {
    return this.users.findOne(id);
  }

  @Post()
  @HttpCode(201)
  create(@Body() dto: CreateUserDto) {
    return this.users.create(dto);
  }
}

Decorators such as @Get, @Post, @Param, @Query, @Body and @Headers map HTTP to method arguments. Return a value or a promise, and Nest serialises it.

What they are checking: Whether you keep controllers thin and know the routing decorators

A provider is any class (service, repository, factory, helper) that Nest can inject as a dependency. @Injectable() marks the class so Nest's DI container can manage it and read its constructor metadata.

@Injectable()
export class UsersService {
  constructor(private readonly repo: UsersRepository) {}
  findOne(id: number) { return this.repo.findById(id); }
}

Register it in the providers array of a module. By default it is a singleton shared across the module graph. Business logic belongs in providers, which makes it reusable and easy to unit test with a mock.

What they are checking: Whether you understand providers as the home of business logic

Nest has an IoC container. It reads the types of constructor parameters (from TypeScript metadata). It finds the provider registered under that token, creates it once, and injects it.

@Injectable()
export class OrdersService {
  constructor(
    private readonly users: UsersService,           // class token
    @Inject('PAYMENT_CLIENT') private readonly pay: PaymentClient, // string token
  ) {}
}

Steps: build a dependency graph from modules, resolve providers in order, instantiate singletons, then inject. Interfaces vanish at runtime, so inject them with a string, symbol or class token using @Inject(). Benefits: loose coupling and simple mocking in tests.

What they are checking: Whether you know tokens and how Nest resolves the graph

Each handles a different concern at a different point of the request lifecycle.

Key difference: middleware does not know which handler will run. Guards, interceptors and pipes have an ExecutionContext and know which controller and method will run. Pick the narrowest tool: validation in pipes, permissions in guards, and shared before-and-after logic in interceptors.

What they are checking: Whether you pick the right layer for each concern

Define a DTO class with class-validator decorators and enable the global ValidationPipe. It checks incoming data. If the check fails, it returns a 400 with messages.

Install @nestjs/typeorm and typeorm, configure TypeOrmModule.forRootAsync with your config. Define entities. Then register repositories in each feature module with forFeature.

Use @nestjs/config: ConfigModule.forRoot loads .env files and gives values through ConfigService. Add validation, so the app stops at once if a setting is missing.

Build a testing module with Test.createTestingModule. Provide the service under test plus mocks for its dependencies. Then check its behaviour.

Pipes work on input before the handler (they check or change arguments). Exception filters work on errors after something throws, and turn them into responses.

Interceptors wrap the handler using RxJS. So they can run logic before and after it, change the result, add caching, measure time, or change errors.

@Global() makes a module's exported providers available everywhere without importing the module in each consumer.

Install @nestjs/swagger, build a document in main.ts with DocumentBuilder, and expose it with SwaggerModule.setup. Decorators or the CLI plugin describe the DTOs and endpoints.

Custom providers let you control how a token is resolved.

@Module({
  providers: [
    { provide: 'CACHE', useFactory: async (cfg: ConfigService) => {
        const client = createClient({ url: cfg.get('REDIS_URL') });
        await client.connect();
        return client;
      },
      inject: [ConfigService] },
    { provide: PaymentGateway, useClass: process.env.NODE_ENV === 'test' ? FakeGateway : StripeGateway },
  ],
})
export class AppModule {}

Async factories delay app start until they resolve, which is useful for connections.

What they are checking: Whether you can wire non-trivial dependencies cleanly

A circular dependency happens when two providers (or modules) need each other. Nest cannot decide which to create first. forwardRef() delays the reference, so both can be resolved later.

@Injectable()
export class AService {
  constructor(@Inject(forwardRef(() => BService)) private b: BService) {}
}
@Injectable()
export class BService {
  constructor(@Inject(forwardRef(() => AService)) private a: AService) {}
}
// modules need it too:
@Module({ imports: [forwardRef(() => BModule)] })
export class AModule {}

This is only a workaround. The better fix is to remove the cycle. Move the shared logic to a third service, use events (EventEmitter2) for one direction, or move the code to the right module. Also watch for circular file imports. They show up as undefined.

What they are checking: Whether you treat forwardRef as a last resort and know design fixes

Incoming request flow is: middleware, guards, interceptors (before), pipes, controller handler, service, interceptors (after), exception filters (only on errors), then the response.

1. Global, then module-bound middleware.
2. Guards (global, controller, route).
3. Interceptors, pre-controller part.
4. Pipes (global, controller, route, param).
5. Controller method and service.
6. Interceptors, post-response part (reverse order).
7. Exception filters catch anything thrown from the guard onward.

Within each type, global runs first, then controller-level, then route-level. Interceptors unwind in reverse on the way out. A guard that returns false stops the pipeline before pipes and the handler.

What they are checking: Whether you can place each building block in the pipeline

A guard implements CanActivate and returns a boolean (or promise or observable) that decides whether the request proceeds. For RBAC, combine a roles decorator that stores metadata with a guard that reads it using Reflector.

export const Roles = (...roles: string[]) => SetMetadata('roles', roles);

@Injectable()
export class RolesGuard implements CanActivate {
  constructor(private reflector: Reflector) {}
  canActivate(ctx: ExecutionContext): boolean {
    const required = this.reflector.getAllAndOverride<string[]>('roles', [ctx.getHandler(), ctx.getClass()]);
    if (!required) return true;
    const { user } = ctx.switchToHttp().getRequest();
    return required.some(r => user?.roles?.includes(r));
  }
}

@Roles('admin')
@UseGuards(JwtAuthGuard, RolesGuard)
@Delete(':id')
remove(@Param('id') id: string) {}

Order matters: authentication first so request.user exists. Returning false gives 403.

What they are checking: Whether you can implement authorisation with metadata and guards

Run all related writes in one transaction so they either all commit or all roll back. With TypeORM use a DataSource and a query runner or the transaction helper; with Prisma use $transaction.

Use @nestjs/passport with passport-jwt. A login endpoint checks the credentials and issues a signed token with JwtService. A JwtStrategy plus AuthGuard('jwt') protects routes.

Scope sets how long a provider lives. DEFAULT is one instance for the whole app (a singleton). REQUEST makes a new instance for each incoming request. TRANSIENT makes a new instance for each class that injects it.

Pick Prisma for type-safe queries, a clear schema file and good migrations. Pick TypeORM when you prefer decorators, the Active Record or Data Mapper style, or need features such as complex entity inheritance.

Issue a short-lived access token (about 15 minutes) and a long-lived refresh token. Store the refresh token on the server as a hash, and replace it on each use.

Nest abstracts transports so the same patterns work over TCP, Redis, NATS, MQTT, RabbitMQ, Kafka and gRPC. You create a microservice app with NestFactory.createMicroservice and call it from a client built with ClientProxy.

With transform: true the pipe turns the plain payload into an instance of the DTO class, and changes simple values to the declared type. It uses class-transformer.

@MessagePattern handles request-response messages, where the sender waits for a reply. @EventPattern handles fire-and-forget events, with no reply.

Create the full app (or a part of it) from AppModule in a testing module. Then call it over HTTP with supertest, without opening a real port.

A dynamic module is a module whose providers are set up when it is imported. A static method that returns a DynamicModule does this. So one reusable module can be set up in a different way by each user.

Nest works with different platforms. Express is the default and has the most middleware. Fastify handles more requests per second and uses fewer resources, with a design built around schemas.

Use createParamDecorator to pull a value out of the ExecutionContext so controllers stay clean.

NestJS is built around several patterns, and I also apply others on top of it.

Require an Idempotency-Key header made by the client. Store the key with a fingerprint of the request and the result. Then a repeat gets the saved response and does not run again.

Compare both sources by a stable key, classify the differences, and make the job re-runnable and auditable.

Measure first, then fix the biggest cost, which is usually the database.

This is a lost-update race. Prevent it by letting the database handle changes one at a time. Use an atomic update, a row lock, or optimistic versioning.

Find why each one needs the other. Then break the cycle by moving shared logic or reversing one direction, instead of leaving forwardRef everywhere.

Define one common interface and implement it for each gateway (adapter). Then pick the right one at run time (strategy) through DI.

Apply a global throttler, with a stricter limit on login routes. Count by IP and by account. Slow attackers down more after repeated failures.

Use a queue (BullMQ with Redis through @nestjs/bullmq) so work is persisted, retried and processed outside the request.

Verify authenticity, acknowledge fast, and process each event exactly once by its id.

Add liveness and readiness endpoints with @nestjs/terminus. Enable shutdown hooks, so work in progress finishes before the process exits.