Top 6 Dependency injection Interview Questions

Browse 6 real-world technical and behavioral interview questions about Dependency injection. Review scenarios, edge cases, and architectural best practices.

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.

mediumdesign

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.

hardconcept

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.

mediumcoding

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.

mediumconcept

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.

mediumdesign

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.

mediumconcept