Question 1

How does Nest's DI container resolve dependencies?

Accepted Answer

Reflects constructor param types/tokens, recursively constructs the provider graph within module visibility rules. emitDecoratorMetadata + @Injectable matter. Ambiguous types need @Inject(token).

Question 2

Why forwardRef exists and when it's a smell?

Accepted Answer

Breaks circular constructor deps between providers/modules — often indicates tangled design. Prefer extracting a third module/service or inverting the dependency. forwardRef is a last resort.

Question 3

Optional dependencies with @Optional() — use cases?

Accepted Answer

Soft dependencies like metrics/cache that may be absent in some environments. Handle undefined carefully. Don't overuse — missing required deps should fail fast at boot.

Question 4

Constructor injection vs @Inject() property injection?

Accepted Answer

Prefer constructor injection for required deps and testability; property injection is rarer. Constructor makes dependencies explicit and immutable-friendly. Property injection complicates reasoning.

Question 5

Scenario: two implementations of the same interface for A/B payments.

Accepted Answer

Bind different tokens or use a factory that selects strategy from config/feature flag. Avoid conditional logic scattered in domain services — strategy pattern via DI keeps it clean.

Question 6

Lead: how do you keep DI graphs understandable at 200+ providers?

Accepted Answer

Module boundaries by domain, public tokens documented, forbid random cross-imports, and architecture tests. Visualize critical subgraphs. Reject god modules. Prefer fewer, clearer providers over micro-classes everywhere.

Dependency Injection NestJS Interview Questions

Other NestJS interview topics