NestJS interviews probe whether you understand the framework's structure rather than its decorators. Expect modules and providers, dependency injection and scopes, the division of work between controllers and services, the request lifecycle through middleware, guards, interceptors and pipes, exception filters, testing, and how an ORM such as TypeORM or Prisma is wired in.
9 questions (2 easy · 4 medium · 3 hard), each with what a strong answer covers and where people lose the point. Free to read, no account.
1.What is a module in NestJS, and how does a provider become available to another class?
Warm-up
What a strong answer covers
A module groups a slice of the application, declaring its controllers, its providers, the modules it imports and the providers it exports.
A provider is injectable into a class when it is declared in the same module, or when it is exported by a module that the consuming module imports.
Declaring a provider in a module does not make it globally available: without an export and a matching import, injection fails at startup.
A strong answer mentions that a module can be marked global to avoid repeated imports for genuinely cross-cutting providers, and that doing so widely undermines the explicit dependency graph modules are for.
Where people lose the point
×Assuming a provider is available everywhere because it is decorated as injectable.
×Exporting from the wrong module or forgetting the import on the consumer.
×Marking many modules global to make errors go away.
2.What belongs in a controller and what belongs in a service?
Warm-up
What a strong answer covers
A controller handles the transport concern: routing, extracting parameters, body and headers, and returning a response shape. It should be thin.
A service holds the business logic and is transport agnostic, which is what allows the same logic to be reached from an HTTP route, a message handler or a scheduled job.
Data access sits behind the service, typically in a repository or data layer, so the service is not tied to a specific ORM call pattern.
The practical test is whether the logic would need rewriting to be triggered by something other than an HTTP request. If so, it is in the wrong place.
A strong answer notes this separation is what makes unit testing cheap, since a service can be tested without constructing an HTTP context at all.
Where people lose the point
×Putting business rules and database queries directly in controller methods.
×Injecting the request object deep into services and coupling logic to HTTP.
×Creating a service that is a pass-through with no logic, adding indirection without benefit.
3.Put middleware, guards, interceptors, pipes and exception filters in execution order and say what each is for.
Hard
What a strong answer covers
Middleware runs first, outside Nest's execution context, with access to the raw request and response. It suits framework-level concerns such as body parsing, correlation ids and low-level logging.
Guards run next and decide whether the request proceeds, which makes them the correct place for authentication and authorisation, with access to the execution context and route metadata.
Interceptors run before the handler, wrapping it, which is why they suit logging, timing, caching and response transformation on both sides of the call.
Pipes run just before the handler receives its arguments, transforming and validating them, which is where DTO validation belongs.
The handler runs, interceptors complete on the response path, and any exception thrown anywhere in the chain is caught by exception filters, which produce the error response.
A strong answer draws the practical consequence: a guard cannot depend on a value produced by a validation pipe, because the guard already ran.
Where people lose the point
×Placing pipes before guards in the order.
×Implementing authorisation in middleware where route metadata is unavailable.
×Describing interceptors as running only before or only after the handler.
4.When do you use a guard and when do you use an interceptor?
Core
What a strong answer covers
A guard answers a yes or no question about whether the request may proceed, and returning false results in the request being rejected.
An interceptor does not decide access, it wraps the handler, so it can act before and after and can transform the response or the error stream.
Authentication and role or permission checks belong in guards, often combined with route metadata read through the reflector so the rule is declared on the handler.
Logging, timing, caching, response envelope shaping and mapping a stream of results belong in interceptors.
A strong answer notes both are provided through DI, so they can inject services, and that ordering matters when several apply to the same route.
Where people lose the point
×Doing authorisation in an interceptor after work has already begun.
×Using a guard to modify the request or response.
×Duplicating the same check in both, so changing the rule requires two edits.
5.How do you validate incoming request data in NestJS?
Core
What a strong answer covers
Define a DTO class describing the expected shape and apply a validation pipe so incoming payloads are checked before the handler runs.
The common approach pairs class-validator decorators on the DTO with class-transformer to convert the plain payload into an instance of the class.
The pipe can be applied per parameter, per handler, per controller or globally, and global application is usual so that validation is not something individual routes can forget.
Useful options include stripping properties that are not in the DTO and rejecting requests that contain unexpected properties, which narrows the surface an attacker can reach.
A strong answer distinguishes shape validation at the boundary from business rule validation in the service, since a value can be well-formed and still not allowed.
Where people lose the point
×Validating manually inside controllers with hand-written checks.
×Applying validation to some routes and forgetting others.
×Putting business rules in DTO decorators where they cannot see application state.
6.How should errors be turned into HTTP responses?
Core
What a strong answer covers
Throw the built-in HTTP exceptions or extend the base HTTP exception where the error genuinely maps to a status code, and let the framework's handling produce the response.
Use an exception filter to centralise the response shape, so every client sees one consistent error contract rather than a different one per controller.
Distinguish expected domain errors from unexpected failures: the first should map to a meaningful status and message, the second should be logged fully and returned as a generic error without internal detail.
Filters can be applied per handler, per controller or globally, and a global filter is usually the right default with narrower ones for specific cases.
A strong answer mentions keeping internal messages, stack traces and driver errors out of responses, and including a correlation identifier so a support report can be traced to a log entry.
Where people lose the point
×Wrapping every controller method in try/catch and building responses by hand.
×Leaking ORM or driver error text to clients.
×Mapping every failure to a 500 regardless of cause.
7.How do you integrate TypeORM or Prisma into a Nest application?
Hard
What a strong answer covers
With TypeORM, the ORM module is registered at the root with connection configuration, entities are registered per feature module, and repositories are injected into services.
With Prisma, the usual pattern is a service that owns the Prisma client instance and is exported from a module, with lifecycle hooks used to connect and disconnect cleanly.
Configuration should come from the config module rather than being hard-coded, using async registration so that connection details resolve at startup from environment values.
Keep query concerns behind the service or a repository abstraction so that controllers never speak to the ORM, which is what keeps the choice of ORM replaceable and the service testable.
A strong answer covers transactions explicitly, since operations spanning several writes need to run in one transaction, and notes that migrations should be run as a deliberate deployment step rather than by automatic schema synchronisation in production.
Where people lose the point
×Leaving automatic schema synchronisation enabled in production.
×Injecting repositories or the ORM client directly into controllers.
×Handling multi-write operations without a transaction and leaving partial state on failure.
8.How do you test a NestJS service and a NestJS controller?
Core
What a strong answer covers
For unit tests, build a testing module with the class under test and replace its dependencies with mocks through provider overrides, so nothing real is constructed.
Testing a service this way verifies business logic without a database or an HTTP layer, which is where most of the value of unit testing sits.
Testing a controller in isolation mostly verifies wiring and parameter handling, since the logic should live in the service, so keep those tests thin.
End-to-end tests bootstrap the application and exercise real routes over HTTP, which is what verifies guards, pipes, filters and the module graph actually compose.
A strong answer states what each level is for: unit tests for logic, end-to-end for composition and contract, and warns that mocking the ORM heavily can produce tests that pass while the queries are wrong.
Where people lose the point
×Writing controller unit tests that re-test service logic through mocks.
×Mocking so deeply that the test verifies the mock rather than the code.
×Having no end-to-end coverage, so guard and pipe composition is never exercised.
9.What is provider scope in NestJS, and how do you deal with a circular dependency?
Hard
What a strong answer covers
Providers are singletons in the application context by default, which is why they can be injected widely at low cost.
Request scope creates an instance per request, which is useful for genuine per-request state, and transient scope creates a new instance per consumer.
Scope propagates: a singleton that depends on a request-scoped provider becomes request-scoped itself, which can quietly change the instantiation behaviour of a large part of the graph and affect performance.
Circular dependencies between two modules or two providers can be resolved with forward referencing, but that is a workaround rather than a fix.
A strong answer treats a cycle as a design signal and prefers extracting the shared concern into a third module or introducing an event or interface boundary so the dependency runs one way.
Where people lose the point
×Using request scope by default without understanding the propagation.
×Reaching for forward references immediately and leaving the cyclic design in place.
×Storing per-request state on a singleton provider, which leaks between requests.
A question a NestJS panel actually asks, answered out loud, scored on what you said and how you said it. Under two minutes, and nothing to sign up for.
“What is a module in NestJS, and how does a provider become available to another class?”
We never store the audio. Your answer is deleted within 24 hours unless you save the result.
How NestJS answers get judged
The weights a NestJS interviewer is holding, whether or not they say so out loud. Round Zero scores your practice answers against exactly these, and quotes your own words back as the evidence for each.
Module and DI architecture
35%
Explains modules, providers, exports and imports accurately, reasons about provider scope and circular dependencies, and structures an application so responsibilities are separable and testable.
Request lifecycle command
30%
Knows what middleware, guards, interceptors, pipes and exception filters each do and the order they execute in, and picks the right one for a given requirement instead of putting everything in middleware.
Data access and error handling
20%
Integrates an ORM cleanly, keeps transaction and query concerns out of controllers, validates input at the boundary, and returns errors through a consistent, deliberate mechanism.
Testing
15%
Uses the testing module to build isolated units with mocked providers, knows when an end-to-end test is the honest one, and explains what each level of test is actually verifying.
You have read what strong NestJS answers contain. The next thing that moves the needle is producing one under time, out loud, and finding out where it falls apart.
What NestJS interview questions should I practice?
Start with the core areas NestJS interviewers probe: What is a module in NestJS, and how does a provider become available to another class; What belongs in a controller and what belongs in a service; Put middleware, guards, interceptors, pipes and exception filters in execution order and say what each is for.. This page outlines strong answers and common mistakes, and the scored path drills each one with follow-ups.
Is the NestJS practice free?
Yes. The NestJS path runs free inside Round Zero: lessons, practice questions and flashcards. Drills are unlimited on every plan, free included. So is the full scorecard. Free also covers 3 complete scored interviews, no card.
How is this different from a NestJS question list?
A static list gives you questions with no feedback. Round Zero runs a live scored practice that probes your actual answers, rotates difficulty, and tells you exactly what to fix, grounded in a NestJS rubric.
How should I prepare for a NestJS interview?
Learn the concepts, drill the questions until answers come fast, then prove it in a scored mock. Round Zero sequences all three so you know you are ready, not just that you read about NestJS.
How is a NestJS answer scored?
NestJS answers are scored on module and di architecture, request lifecycle command, data access and error handling, testing, with evidence quoted from what you actually said, so feedback is specific instead of generic praise.
More free tools
Try everything. Sign up only when you want the full version.