Top 8 Dependency injection Interview Questions
Browse 8 real-world technical and behavioral interview questions about Dependency injection. Review scenarios, edge cases, and architectural best practices.
Startup fails with NoUniqueBeanDefinitionException after someone adds a second implementation. Do you reach for @Primary, @Qualifier or a list of beans, and which fix ages badly?
NoUniqueBeanDefinitionException means one injection point matches two beans by type. Fix it where the decision belongs: a qualifier at the consumer when callers need different beans, a List or Map when all are used, a conditional bean when only one should exist. A primary bean is the quick fix that ages worst.
After a Spring Boot upgrade the app refuses to start with a circular reference between two services. Do you turn the check off?
Spring Boot has prohibited circular references by default since 2.6. Setting spring.main.allow-circular-references=true restores the old behaviour, defensible only as a dated stopgap. The fix is to break the cycle, usually by extracting what both services need, and to use constructor injection so new cycles fail fast.
Messages arrive with a type field and each type needs a different object built to process it. How do you design the creation so you do not end up with a growing switch statement?
Replace the switch with a registry the application builds once at startup: a map from discriminator to a factory, validated for duplicate and missing keys as it is constructed, injected rather than global, and with a decided answer for a type the consumer has never seen.
Angular, Vue and React are answers to the same problems. Compare how each handles change detection, reactivity and dependency injection.
Each must decide what to re-render when data changes, how derived values stay correct, and how a component gets a dependency it did not create. Angular answers with dirty checking now moving to signals plus a hierarchical injector, Vue with proxy-based per-property tracking, React with convention plus memoisation.
You kick off background work from a controller action and it throws once the response has gone out. What is happening?
Detached ASP.NET Core background work can fail after the response because the request scope is disposed. Copy required values, create a fresh service scope, and run tracked work through IHostedService, BackgroundService or a durable queue.
What are the three DI lifetimes in ASP.NET Core, and what goes wrong when you inject a scoped service into a singleton?
ASP.NET Core DI lifetimes matter because a singleton that captures a scoped service turns per-request state into process-wide state. Captive dependencies cause stale data, threading bugs and disposed object failures.
Go gives you no project layout and no dependency-injection container. How do you structure a service so it stays testable as it grows?
Wire dependencies explicitly through constructors from one place in main, define narrow interfaces where they are consumed rather than implemented, and keep handlers thin enough that the logic beneath is testable without a server. With no framework, these are decisions rather than defaults.
Why does @Transactional sometimes do nothing at all, even though the annotation is right there?
Spring applies @Transactional through a proxy that wraps the bean. Calling the annotated method from another method of the same class goes through `this`, not the proxy, so the advice never runs and no transaction is started. The same silence affects @Cacheable, @Async and @Retryable. It also connects dependency injection to the point an interviewer is testing.