Question 1

Is NestJS better than plain Express in 2026?

Accepted Answer

For non-trivial APIs, almost always yes. NestJS gives you dependency injection, modular structure, validation, guards, interceptors, microservice transports, and GraphQL out of the box — features you would otherwise bolt onto Express piecemeal with disparate libraries that do not agree on conventions. Plain Express is still a good choice for very small services or single-file webhooks where the structure would be overhead, but for anything intended to live in production for more than a quarter the NestJS investment pays off quickly.

Question 2

How much does a NestJS developer earn in India?

Accepted Answer

Around ₹8-25 LPA in 2026 for mid-to-senior backend developers with NestJS as their primary stack. Razorpay, Swiggy, Zerodha, CRED, Postman, and global SaaS teams hiring out of India (GitLab, Adidas, Roche) pay at the upper end, especially for engineers comfortable with microservices, GraphQL, CQRS, and observability. Engineers who also know infrastructure (Kubernetes, Terraform, distributed tracing) can push past that range for staff-level roles.

Question 3

Should I learn Angular before NestJS?

Accepted Answer

No, but the experience helps. NestJS borrows modules, decorators, and dependency injection from Angular, so Angular developers feel at home immediately. You do not need to know Angular to learn NestJS — solid TypeScript and an understanding of constructor-based dependency injection are enough. Many NestJS engineers in India come from a React background and learn the framework in two to three weeks without ever writing Angular code.

Question 4

How does NestJS compare with Spring Boot for enterprise backends?

Accepted Answer

Conceptually very similar — both are opinionated, DI-driven frameworks with strong type systems, decorators or annotations, and unified support for REST, GraphQL, and messaging. The choice usually comes down to language and ecosystem: Spring Boot if your team is Java or Kotlin and CPU-heavy workloads dominate; NestJS if you want a TypeScript end-to-end stack, faster iteration on I/O-bound APIs, and shared tooling between backend and frontend engineers.

Question 5

When should I use Fastify instead of Express in NestJS?

Accepted Answer

Switch to FastifyAdapter when you are serving high-throughput JSON APIs and want 15-30% more requests per second on the same hardware. The main trade-off is the Express ecosystem — some Express middleware does not work transparently and you may need Fastify-native plugins. For lower-traffic apps the default Express adapter is fine, and migrating later is a small refactor confined to main.ts and any custom middleware.

Question 6

Is NestJS production-ready for fintech and payment platforms?

Accepted Answer

Yes, and it is widely used for exactly that. Indian fintech players like Razorpay, Zerodha, and CRED run NestJS in production for serious workloads including payment orchestration, fraud detection, and ledger services. The framework's structured DI and explicit interfaces make audit, testing, and compliance easier than ad-hoc Express services, which is exactly what regulated industries need. Pair it with Postgres for the core ledger, Kafka for event distribution, and OpenTelemetry for end-to-end traceability and you have an architecture that survives RBI audits.

Question 7

What is NestJS and what problem does it solve?

Accepted Answer

NestJS is a progressive Node.js framework for building efficient, scalable, server-side applications using TypeScript. Released in 2017 by Kamil Mysliwiec, it sits on top of Express (the default HTTP adapter) or Fastify, and adds a structured architecture inspired by Angular: modules, controllers, providers, decorators, and a powerful dependency injection container. The problem NestJS solves is the lack of an opinionated structure in plain Express or Koa apps. Teams that start with Express often end up with a tangle of routes, middleware, and hand-rolled singletons that becomes hard to test and maintain past a few thousand lines of code. NestJS replaces that with clear separation of concerns: controllers handle HTTP, services hold business logic, modules wire things together, and the DI container manages lifecycles. It also unifies HTTP, WebSockets, GraphQL, and microservices behind one programming model, so you do not need to learn three different patterns for one application. In India, this single-paradigm advantage is what convinces engineering managers at fintech and SaaS firms to standardise on Nest — a new joiner who knows the framework can navigate any service in the organisation, whether it is a REST API, a Kafka consumer, or a GraphQL gateway.

Question 8

What are modules, controllers and providers in NestJS?

Accepted Answer

These are the three core building blocks of every NestJS application. A module is a class annotated with @Module() that groups related controllers and providers, declares its imports and exports, and forms a feature boundary. Every Nest application has at least one root AppModule, and most non-trivial codebases split into feature modules such as UsersModule, AuthModule, and PaymentsModule, each owning its own controllers and services. A controller is annotated with @Controller() and handles incoming HTTP requests, mapping URL paths and HTTP verbs to handler methods using decorators like @Get, @Post, @Patch, @Param and @Body. A provider is any class that can be injected as a dependency — typically a service annotated with @Injectable() that contains business logic, but also repositories, factories, helpers, configuration objects, or even values. The DI container instantiates providers as singletons by default and injects them into controllers and other providers via the constructor. Keeping controllers thin and pushing logic into services is the canonical NestJS pattern and the single biggest indicator of code quality interviewers look for during code reviews and pair programming rounds.

Question 9

How does dependency injection work in NestJS?

Accepted Answer

NestJS has its own IoC (inversion of control) container. When the application bootstraps, the container scans every module, reads the metadata emitted by TypeScript decorators (via the reflect-metadata package), and builds a dependency graph. When you declare a class with @Injectable() and add it to a module's providers array, you can constructor-inject it into any other provider or controller in that module or in modules that import it. By default every provider is a singleton at the application level, so the same instance is reused for every request. You do not call new yourself — the container instantiates each provider once and wires up its dependencies recursively. This is the foundation that makes NestJS so testable: in unit tests, you replace a real provider with a mock using the Test.createTestingModule() builder, and the container injects the mock instead of the production class. The same machinery powers advanced patterns such as custom providers (useValue, useFactory, useClass, useExisting), async providers (where the factory is asynchronous), and injection tokens (string or symbol keys for interface-like injection). Understanding this graph deeply is what separates a beginner from a senior NestJS engineer — almost every advanced topic eventually reduces to a question about provider resolution.

Question 10

How do you handle route parameters, query strings and request bodies?

Accepted Answer

NestJS provides parameter decorators that extract the right piece of the request and pass it to your handler argument. @Param() reads URL path parameters, @Query() reads the query string, @Body() reads the parsed JSON body, @Headers() reads HTTP headers, and @Req() / @Res() give you the underlying Express or Fastify request and response if you need them. You can extract a specific key or the whole object — @Param('id') gives you just the id, while @Param() gives you the entire params object. Combine these with class-validator DTOs and the global ValidationPipe to automatically validate and transform inputs at the boundary, so by the time data reaches your service, it is already typed and trustworthy. Avoid reaching for @Res() unless you absolutely need to set custom headers or stream a response — once you do, you lose the benefit of returning a value from your handler, and Nest no longer applies interceptors to the response. For file uploads use @UploadedFile() (or @UploadedFiles() for multiple) combined with FileInterceptor and the multer engine, which Nest bundles automatically. For very large uploads, stream to S3 directly using the AWS SDK's multipart upload API instead of buffering in Node memory, and validate the MIME type up front to reject malicious payloads before they touch your storage layer.

Question 11

What is a DTO and how does class-validator integrate with NestJS?

Accepted Answer

A DTO (Data Transfer Object) is a TypeScript class that describes the shape of a request payload. Combined with the class-validator and class-transformer packages, DTOs become the runtime validation layer for every incoming request. You decorate each property with rules like @IsString(), @IsEmail(), @IsInt(), @Min(0), @IsOptional(), @ValidateNested(), then register the global ValidationPipe on the app. NestJS deserializes the incoming JSON into the DTO class, runs validators, and returns a 400 with structured error details if anything fails. You should always enable whitelist: true and forbidNonWhitelisted: true to strip and reject unknown fields — this is your first line of defence against mass-assignment vulnerabilities where an attacker sends extra fields like isAdmin: true hoping your code passes the payload straight to the database. With transform: true, query strings are coerced from strings to their declared TypeScript types before reaching the handler, so a parameter typed as number will arrive as a real number, not '42'. In production at Razorpay-style fintech, DTO validation is treated as a security boundary, not a convenience — every payload that crosses the network is a DTO with strict whitelisting and explicit length / range limits.

Question 12

What is the difference between @Controller and @Injectable?

Accepted Answer

Both decorators register a class with the Nest DI container, but they serve different roles. @Controller() marks a class as an HTTP request handler — Nest reads its method-level decorators (@Get, @Post, etc.) and registers routes with the underlying HTTP adapter. Controllers are not injectable into other providers; they are an entry point, not a service. @Injectable() marks a class as a provider, meaning it can be injected wherever the DI container resolves dependencies — into controllers, into other services, into guards, pipes, interceptors, and even into resolvers in GraphQL modules. As a rule of thumb: controllers are thin HTTP shells, while @Injectable() services hold the business logic that controllers call. Mixing them is a common anti-pattern that produces controllers difficult to unit-test, and during interviews this is often the first signal a candidate has not internalised the framework's philosophy. When in doubt, ask yourself whether the class will be reused — anything used in more than one place should be an @Injectable() service. The same separation applies to other entry points: @Resolver() for GraphQL, @WebSocketGateway() for WebSockets, and @Catch() for exception filters are all entry-point decorators that should stay thin and delegate to injectable services for the actual work. Get this right and your tests become trivial; get it wrong and every controller test becomes a slow integration test.

Question 13

How do you generate a new NestJS project and module?

Accepted Answer

The Nest CLI (@nestjs/cli) is the canonical way. Install it globally with npm i -g @nestjs/cli, then run nest new project-name to scaffold a new project with TypeScript, Jest, ESLint, Prettier, and a working src/main.ts already configured. Inside an existing project, nest generate (or nest g for short) scaffolds individual pieces: nest g module users creates a UsersModule, nest g controller users creates the controller and wires it into the module, nest g service users does the same for the service. The CLI also supports nest g resource users which generates the whole CRUD bundle — controller, service, module, DTOs, and entity — in one command, and even asks whether you want a REST, GraphQL code-first, GraphQL schema-first, or microservice variant. In team environments the CLI is strongly preferred because it keeps file naming, exports, and module wiring consistent across developers, so a code review never devolves into arguing about where a file should live. The CLI also writes proper unit and e2e test stubs alongside each generated file, which nudges everyone toward writing tests from day one. For monorepos, nest new --strict supports a workspace flavour where multiple apps and libraries share the same node_modules and TypeScript config — useful when you are running a frontend in Next.js and a backend in NestJS within the same Turborepo or Nx workspace, a common 2026 setup at Indian SaaS startups.

Question 14

What are pipes in NestJS and what are they used for?

Accepted Answer

Pipes are classes annotated with @Injectable() that implement the PipeTransform interface. Nest runs them between the framework and the handler method, giving you a hook for two things: transformation (turning a string '123' into the number 123) and validation (throwing a BadRequestException if the input is invalid). The framework ships with built-ins like ParseIntPipe, ParseUUIDPipe, ParseBoolPipe, ParseArrayPipe, ParseEnumPipe and the ValidationPipe. You can also write your own — for example, a TrimPipe that strips whitespace from query parameters, or a SlugifyPipe that normalises user-supplied strings. Apply pipes at the parameter level (@Param('id', ParseIntPipe)), the handler level via @UsePipes(), the controller level, or globally on the app. Per-parameter pipes are the cleanest pattern because the type coercion is local and obvious; reach for global pipes only when the rule applies uniformly to every request such as the ValidationPipe. Pipes also have access to ArgumentMetadata, which includes the parameter type, the parameter name, and where the value came from (body, query, param, custom) — useful when writing reusable pipes that need to behave differently depending on context. A common interview trick is asking when transformation happens relative to validation: the answer is that pipes run in registration order, so if you apply ValidationPipe before a transforming pipe the validator sees the raw string, not the coerced type.

Question 15

How do you handle errors and return correct status codes?

Accepted Answer

NestJS ships with a built-in HttpException class and a family of subclasses such as NotFoundException, UnauthorizedException, BadRequestException, ForbiddenException, ConflictException, UnprocessableEntityException and InternalServerErrorException. Throwing one of these from any controller, service, guard, or interceptor causes Nest to short-circuit the request and return a JSON response with the right status code and a structured payload. For domain-specific errors that should also map to HTTP responses — for example a PaymentDeclinedError or an InventoryUnavailableError — write a custom exception filter with @Catch(MyError) so callers can handle them by code, not by message. For changing the default 200 status code on a handler, use @HttpCode(201). The single biggest beginner mistake is throwing raw Error objects: they fall through to Nest's generic 500 handler with a meaningless response body and no useful logging, which makes production debugging painful. Always throw a typed exception, even if it is a temporary one — your future self pulling on-call at 3 AM will thank you. A robust pattern in 2026 is to define one base AppError class with a code, message, statusCode, and optional cause field, then derive every domain error from it; a single ExceptionFilter then maps any AppError subtype to its JSON contract uniformly, while still letting you catch specific subclasses elsewhere.

Question 16

How do you configure environment variables in a Nest app?

Accepted Answer

Use the official @nestjs/config package. It reads from process.env and from .env files (with dotenv under the hood), validates the schema with Joi or Zod, and exposes a ConfigService that you inject anywhere. Make ConfigModule.forRoot({ isGlobal: true }) the very first import of your AppModule so every other module can resolve ConfigService without re-importing. Never read process.env directly inside services — that breaks both testability and validation. Always pass a validation schema so the application fails fast at boot if a required variable is missing or malformed: a DATABASE_URL with a typo should crash the container before serving a single request, not produce confusing 500s an hour later. In production, do not commit .env files; pull values from a real secret manager like AWS Secrets Manager, Doppler, HashiCorp Vault, or Infisical (popular among Indian devops teams). For 12-factor compliance, every config value should be overridable by environment variable, even if it has a sensible default for local development. A useful refinement is the load function pattern — write small typed config factories per concern (database, jwt, redis) and register them via ConfigModule.forRoot({ load: [databaseConfig, jwtConfig] }). You then inject the typed config object directly rather than calling configService.get<string>('DATABASE_URL'), which gives you compile-time safety on every config access.

NestJS Interview Questions

What is NestJS and what problem does it solve?

What are modules, controllers and providers in NestJS?

How does dependency injection work in NestJS?

How do you handle route parameters, query strings and request bodies?

What is a DTO and how does class-validator integrate with NestJS?

What is the difference between @Controller and @Injectable?

How do you generate a new NestJS project and module?

What are pipes in NestJS and what are they used for?

How do you handle errors and return correct status codes?

How do you configure environment variables in a Nest app?

How do you enable CORS in a NestJS application?

How does NestJS compare with plain Express in 2026?

What are guards and how are they different from middleware?

What is an interceptor and when should you use one?

Exception filters vs error-handling interceptors — what is the difference?

What are the injection scopes in NestJS and when do you use REQUEST scope?

How do you handle circular dependencies between modules or providers?

How do you write unit tests for a NestJS service with mocked providers?

How do you write end-to-end tests with Supertest in NestJS?

How do you implement microservices with NestJS over TCP, Redis, RabbitMQ or Kafka?

What are hybrid applications in NestJS?

How do you build a GraphQL API with NestJS using the code-first approach?

Code-first vs schema-first GraphQL in NestJS — which should you pick?

How do you integrate TypeORM or Prisma with NestJS?

How do you compare NestJS with Spring Boot for backend development?

How do you implement the CQRS pattern in NestJS?

How do you build a custom decorator (including parameter decorators)?

What are dynamic modules and when do you need them?

How do you instrument a NestJS app with OpenTelemetry for distributed tracing?

How would you architect a NestJS backend for 10,000+ requests per second?

Companies Hiring NestJS

Salary Insights

Frequently Asked Questions