Spring Interview Questions

Inversion of Control means an object doesn't create or look up its own dependencies directly. Instead, the Spring container creates those dependencies and hands them to the object, inverting the usual control flow where a class would normally instantiate what it needs itself.

Dependency Injection is the specific mechanism Spring uses to implement IoC, where the container supplies an object's dependencies from the outside, commonly through a constructor, a setter method, or field injection, rather than the object constructing them internally.

A bean is simply an object that's created, configured, and managed by the Spring IoC container. Instead of the application code instantiating these objects with `new`, Spring manages their entire lifecycle, from creation through dependency wiring to eventual destruction.

BeanFactory is the most basic Spring container, providing core dependency injection support with lazy bean initialization by default. ApplicationContext builds on BeanFactory and adds enterprise features like event publishing, internationalization support, and eager initialization of singleton beans by default, and it's what most Spring applications actually use.

Constructor injection supplies dependencies through a class's constructor, making them required and immutable once the object is created. Setter injection supplies dependencies through setter methods after the object is constructed, which allows optional dependencies and reconfiguration, but leaves a small window where the object could exist in a partially configured state.

The most common is singleton, where the container creates exactly one shared instance for the entire application context. Prototype creates a new instance every time the bean is requested. Web-specific scopes like request and session also exist, tying a bean's lifecycle to an HTTP request or session.

@Autowired tells Spring to automatically inject a matching bean into a field, constructor, or setter method, without the developer needing to manually wire it in configuration. Spring resolves the match primarily by type, and by name if there are multiple beans of the same type.

@Component marks a class as a Spring-managed bean, telling Spring's component scanning to automatically detect and register it in the application context. It's the generic stereotype annotation, with more specific variants like @Service, @Repository, and @Controller conveying additional semantic meaning for the same underlying mechanism.

All three register a class as a Spring bean and are functionally similar under the hood, but they convey different semantic roles. @Service typically marks business logic classes, @Repository marks data access classes and adds automatic translation of database exceptions into Spring's own exception hierarchy, and @Component is the generic, catch-all annotation for anything else.

The application context is the central container that holds all the beans Spring manages for an application, along with the configuration and dependency wiring between them. It's created at application startup, and it's what the ApplicationContext interface represents in code.

@Configuration marks a class as a source of bean definitions, meaning Spring will process methods annotated with @Bean inside it to register those objects as beans in the application context. It's the Java-based alternative to defining beans in an XML configuration file.

@Bean is placed on a method inside a @Configuration class, telling Spring that the object returned by that method should be registered as a bean in the application context. It's typically used when you need more manual control over how an object is constructed than @Component-based scanning provides.

Component scanning is the process where Spring automatically searches specified packages for classes annotated with stereotype annotations like @Component, @Service, or @Repository, and registers them as beans without requiring explicit manual configuration for each one.

Spring MVC is Spring's module for building web applications, following the Model-View-Controller pattern. A DispatcherServlet routes incoming HTTP requests to the appropriate controller method, which processes the request and returns a response, often rendered through a view template or serialized as JSON.

A controller, marked with @Controller or @RestController, handles incoming HTTP requests for specific URL patterns, defined using annotations like @GetMapping or @PostMapping. It typically delegates actual business logic to a service layer and returns either a view name or a response body.

@Controller is used for traditional web applications that return view names, which get resolved to an HTML template. @RestController combines @Controller with @ResponseBody, meaning every method's return value is automatically serialized directly into the HTTP response body, typically as JSON, which is what most REST APIs use.

AOP lets you separate cross-cutting concerns, like logging, security checks, or transaction management, from an application's core business logic, applying that shared behavior across multiple classes and methods without duplicating the code in each one. Spring AOP implements this using proxies that wrap around target objects.

A bean's lifecycle includes instantiation, dependency injection, any custom initialization logic (through an @PostConstruct method or an InitializingBean callback), the bean being ready for use, and finally destruction, where custom cleanup logic can run through @PreDestroy or a DisposableBean callback.

@Qualifier is used alongside @Autowired to specify exactly which bean to inject when multiple beans of the same type exist in the application context, since Spring can't automatically decide between them based on type alone in that situation.

XML-based configuration defines beans and their dependencies in a separate XML file, which was the original way to configure Spring applications. Annotation-based and Java-based configuration, using annotations directly in code, has largely replaced it in modern applications since it keeps configuration closer to the code it configures and is generally easier to read and maintain.

@Value injects a value, often read from a properties file or environment variable, directly into a field or constructor parameter. It's commonly used for injecting simple configuration values, like a URL or a timeout setting, without needing to manually read them from a properties object.

getBean() retrieves a bean directly from the application context by its type or name, bypassing normal dependency injection. It's generally discouraged in application code in favor of letting Spring inject dependencies automatically, since manually pulling beans this way works against the framework's IoC approach and makes code harder to test.

With eager initialization, Spring's default for singleton beans, the container creates the bean as soon as the application context starts up. With lazy initialization, marked with @Lazy, the bean isn't created until it's actually first requested, which can speed up startup time for beans that aren't always needed.

An interceptor lets you run custom logic before and after a controller handles a request, similar in spirit to a servlet filter but working within Spring MVC's request handling pipeline. It's commonly used for things like logging requests or checking authentication before a controller method actually runs.

@RequestMapping maps an HTTP request to a specific controller method, based on criteria like the URL path, HTTP method, and request parameters. More specific annotations like @GetMapping and @PostMapping are shorthand versions of @RequestMapping for a specific HTTP method.

Because dependencies are injected from outside rather than created internally, a class's real dependencies can be easily swapped for mock or stub implementations during a unit test. This makes it straightforward to test a class in isolation, without needing its actual dependencies, like a real database connection, to be available.

A Spring singleton bean means the container creates exactly one instance per application context, but that instance is still managed and created by Spring rather than through a private constructor and static instance, as the classic Singleton design pattern uses. Multiple separate application contexts, if they exist, would each have their own singleton instance of the same bean.

@PostConstruct marks a method that Spring should call automatically right after a bean has been fully constructed and its dependencies injected, but before it's put into active use. It's commonly used for initialization logic that depends on those injected dependencies already being available.

A ViewResolver takes the logical view name a controller returns and resolves it to an actual view implementation, like a specific JSP or Thymeleaf template file, that gets rendered and sent back as the HTTP response.

@PathVariable extracts a value from a URL's path itself and binds it to a method parameter, used when part of the URL represents a dynamic value, like an ID. For example, in a URL like /users/42, @PathVariable would let a controller method capture 42 as a parameter.

@RequestParam extracts a value from the query string or form data of a request, like ?id=42 in a URL. @PathVariable extracts a value that's embedded directly in the URL's path structure itself, like /users/42, rather than appended as a query parameter.

The DispatcherServlet is the central entry point for all incoming web requests in a Spring MVC application. It receives every request first, then delegates to the appropriate controller based on the URL and request mapping configuration, and finally handles returning the resulting response.

A profile lets you define beans or configuration that should only be active under certain conditions, like a 'dev' profile using an in-memory database and a 'prod' profile using a real production database connection. Activating a specific profile at startup determines which set of beans and configuration values Spring actually loads.

@ComponentScan tells Spring which packages to search when looking for classes annotated with stereotype annotations like @Component or @Service, so they can be automatically registered as beans. Without specifying it, or relying on Spring Boot's default behavior, Spring wouldn't know where to look for these classes.

A circular dependency happens when two or more beans depend on each other, directly or indirectly, forming a loop. Spring can resolve circular dependencies for setter or field injection since it can create the beans first and wire dependencies afterward, but it generally can't resolve a circular dependency between beans using constructor injection, since both would need to be fully constructed before either one can be.

Spring AOP is proxy-based and only intercepts method calls made through the Spring container, which means it can't advise calls made internally within the same class or on objects created outside Spring's management. AspectJ is a full aspect-oriented programming implementation that weaves advice directly into bytecode, either at compile time or load time, letting it advise essentially any join point, at the cost of more setup complexity.

@Transactional, placed on a method or class, tells Spring to wrap that method's execution in a transaction using a proxy, similar to how AOP advice works. The transaction commits automatically if the method completes normally, or rolls back automatically if it throws a runtime exception, without the developer needing to manually manage the transaction's begin, commit, and rollback calls.

Because Spring's transaction management relies on proxies, and a call from one method to another within the same class happens directly on the actual object, bypassing the proxy entirely. Since the proxy is what actually applies the transactional behavior, that internal call never goes through it, so the second method's @Transactional annotation has no effect in that scenario.

REQUIRED, the default, joins an existing transaction if one is already active, or starts a new one if there isn't. REQUIRES_NEW always starts a completely new, independent transaction, suspending any existing one, which means a rollback in the new transaction won't affect the outer transaction that was suspended.

A typical layered approach separates controllers, handling HTTP request and response concerns, from a service layer, containing the actual business logic and transaction boundaries, from a repository or DAO layer, handling data access. Keeping each layer focused on its own concern, and having dependencies flow in one direction, controller to service to repository, keeps the application easier to test and reason about.

@ControllerAdvice combined with @ExceptionHandler lets you define centralized exception handling logic that applies across multiple controllers, rather than duplicating try-catch logic in every controller method. This typically returns a consistent, well-structured error response regardless of which controller or endpoint the exception originated from.

@Async marks a method to run asynchronously on a separate thread rather than blocking the calling thread, letting the caller continue executing while the annotated method runs in the background. It requires enabling async support in the application's configuration and works, like transaction management, through Spring's proxy-based mechanism.

MockMvc, part of Spring's testing support, lets you send simulated HTTP requests directly to a controller and assert on the resulting response, without needing an actual running server. Combined with mocking the controller's service-layer dependencies, this keeps the test focused on the controller's own request handling logic.

@Mock, from Mockito, creates a mock object independent of the Spring context, generally used in plain unit tests that don't load Spring at all. @MockBean, from Spring's testing support, replaces an actual bean in the Spring application context with a mock, used when a test needs to load at least part of the Spring context but wants to substitute a specific dependency.

Spring's container analyzes the dependency graph between beans and creates them in an order that satisfies those dependencies, generally creating a bean's dependencies before the bean itself. When circular dependencies exist and can be resolved, Spring uses techniques like early exposure of a partially constructed bean reference to break the cycle.

Spring events let one part of an application publish an event that other parts can listen for and react to, without the publisher needing direct knowledge of who's listening. ApplicationEventPublisher is used to publish a custom event, and a method annotated with @EventListener in another bean can react to it, which decouples the two pieces of code from each other.

You'd create a custom annotation paired with a ConstraintValidator implementation containing the actual validation logic, following the same pattern as Bean Validation's built-in annotations like @NotNull or @Size. Applying @Valid on the controller method's parameter then triggers that validation automatically before the method body runs.

Field injection uses @Autowired directly on a field, which is concise but makes dependencies implicit and harder to test outside the Spring container. The Spring team generally recommends constructor injection, since it makes dependencies explicit, required, and immutable, and it makes writing plain unit tests, without needing Spring at all, much more straightforward.

You'd define multiple DataSource beans, each configured with its own connection details, and use @Qualifier or @Primary to specify which one should be injected where it's needed. Each data source typically also needs its own separate transaction manager, since transactions can't span two independent physical data sources.

Environment provides a unified way to access configuration properties, whether they come from properties files, environment variables, or system properties, along with support for activating specific profiles. It abstracts away where a given configuration value actually comes from, letting application code read it consistently.

By default, Spring only triggers an automatic rollback for unchecked (runtime) exceptions, not checked exceptions, since checked exceptions are often considered expected, recoverable conditions rather than genuine failures. This default can be overridden using the rollbackFor attribute on @Transactional to specify additional exception types that should also trigger a rollback.

I'd map HTTP methods to their conventional meaning, GET for retrieval, POST for creation, PUT or PATCH for updates, DELETE for removal, and structure URLs around resources rather than actions. Using appropriate HTTP status codes in responses, and consistent, predictable JSON structures for both success and error responses, rounds out an API that's genuinely easy for other developers to work with.

A singleton bean is created once and shared across the entire application, which is efficient for typically stateless services. A prototype bean creates a new instance on every request for it, which is appropriate for objects that genuinely hold mutable, request-specific state that shouldn't be shared across different parts of the application.

I'd use Spring profiles combined with environment-specific properties files, like application-dev.properties and application-prod.properties, activating the appropriate profile through an environment variable or startup argument at deployment time. Sensitive values, like database credentials, are typically kept out of the properties files entirely and injected through environment variables or a secrets manager instead.

ResponseEntity gives a controller method full control over the HTTP response, including the status code, headers, and body, rather than just returning the body directly and letting Spring infer a default status code. It's commonly used when an API needs to return different status codes depending on the outcome, like 201 for a successful creation or 404 when a resource isn't found.

Spring's @Cacheable annotation, combined with a configured cache manager, lets you mark a method's result to be cached automatically based on its input parameters, skipping the actual method execution on subsequent calls with the same parameters until the cache entry expires or is evicted. This decouples the caching behavior from the business logic itself, without needing to manually manage a cache inside the method.

@Primary marks one bean as the default choice when multiple candidates exist and no more specific qualifier is given, resolving the ambiguity automatically in most cases. @Qualifier is used at the injection point itself to explicitly specify exactly which bean should be injected, overriding whatever @Primary might otherwise select.

The service layer typically throws meaningful, specific exceptions representing business rule violations or failures, without knowing anything about HTTP. The controller layer, or a centralized @ControllerAdvice, is responsible for translating those exceptions into appropriate HTTP status codes and response bodies, keeping the service layer genuinely independent of the web framework's concerns.

Since proxy-based AOP can't intercept internal method calls within the same class, or calls on objects not created through the Spring container, I'd deliberately structure code to route cross-cutting concerns like transactions and caching through properly injected, Spring-managed beans rather than calling through `this` internally. Being aware of this limitation upfront avoids subtle, hard-to-diagnose bugs where an annotation like @Transactional silently doesn't apply.

I'd check whether a bean with a shorter-lived intended scope, like prototype, is being injected into a singleton bean, since the singleton would hold onto that single prototype instance for its entire lifetime rather than getting a fresh one, effectively pinning state that should have been transient. Heap dump analysis, correlated against the application's bean scope configuration, usually confirms whether that's actually the cause.

I'd profile where startup time is actually going, often component scanning across an overly broad set of packages, expensive eager bean initialization that could be made lazy, or a large number of beans with complex dependency graphs. Narrowing component scan scope and being selective about which beans genuinely need eager initialization usually addresses the bulk of unnecessary startup overhead.

You'd implement the Scope interface, defining how the custom scope creates, retrieves, and destroys bean instances, then register it with the application context using ConfigurableBeanFactory.registerScope(). This is a fairly advanced, uncommon need, usually reserved for genuinely custom lifecycle requirements that none of Spring's built-in scopes actually fit.

A BeanPostProcessor lets you hook into the bean lifecycle, running custom logic before and after a bean's initialization callbacks, across every bean in the application context. It's used for advanced framework-level concerns, like wrapping beans in proxies automatically or validating configuration, rather than typical application-level business logic.

I'd migrate incrementally rather than all at once, since Spring supports mixing XML and Java configuration within the same application, converting one module or bean definition group at a time and thoroughly testing after each step. Prioritizing frequently modified or error-prone areas of the XML configuration first tends to deliver the most value early in the migration.

I'd reserve AOP for concerns that genuinely need to apply transparently across many unrelated classes without those classes needing to know about it, like transaction management or centralized logging. For something simpler or narrower in scope, a base class, a utility method, or even just duplicated code in a few places is often more straightforward and easier for other developers to follow than an AOP aspect.

I'd keep the core business logic in a single, well-tested method or service, then expose both a synchronous entry point that calls it directly and an asynchronous entry point, using @Async or a message queue, that calls the same underlying logic. This avoids duplicating the actual business logic across two separate code paths that could drift out of sync.

I'd generally avoid mutable instance state in a singleton bean entirely, since it's shared across every concurrent request and prone to race conditions. If mutable state is genuinely unavoidable, I'd use thread-safe data structures or explicit synchronization, and where possible, prefer scoping that state to a request or thread-local context instead of the shared singleton itself.

I'd build an adapter layer, a dedicated set of classes that translate between the legacy system's interface and clean, Spring-idiomatic interfaces the rest of the application actually depends on. Isolating the legacy system's quirks behind that adapter keeps the rest of the application's code clean and makes eventually replacing or upgrading the legacy system much less disruptive.

Declarative management with @Transactional is simpler and covers the vast majority of use cases cleanly. Programmatic management with TransactionTemplate gives finer-grained control, useful when transaction boundaries need to be more dynamic or conditional than a simple method-level annotation can cleanly express, though it comes at the cost of more verbose, explicit code.

I'd establish shared conventions for the things that genuinely matter for maintainability and onboarding, package structure, exception handling patterns, how cross-cutting concerns like logging and security are applied, while leaving room for teams to make their own reasonable choices on implementation details within their own domain. Over-standardizing every small decision tends to slow teams down without meaningfully improving the codebase's overall quality.

I'd quantify the actual cost of the current state in concrete terms, developer time lost to working around the existing architecture, defect rates in the affected areas, and how much longer new features are taking to build compared to a well-architected part of the codebase. Framing the investment around measurable velocity and risk reduction, beyond just abstract code quality, makes the case land with leadership focused on business outcomes.

I'd look at whether new team members can actually understand and safely modify the affected code without deep, tribal knowledge of how the AOP configuration works, since that's usually the clearest sign advanced framework features have tipped from clever to costly. Advanced features earn their complexity when they solve a genuinely recurring problem cleanly, not when they're used simply because they're available.

I'd ground the disagreement in specific, concrete tradeoffs, deployment independence needs, differing scaling requirements, team ownership boundaries, rather than letting it become a matter of general architectural philosophy or personal preference. If a clear technical answer doesn't emerge from that analysis, I'd make a call based on the best available evidence and be transparent about the tradeoffs of that decision going forward.

I have them own the reasoning behind an architectural decision for a real feature, beyond just the implementation, walking through the tradeoffs of different approaches and defending their choice to the rest of the team. Exposing them to the consequences of past architectural decisions, both good and bad, in the existing codebase builds the judgment that using Spring's features well alone doesn't teach.

I'd look at trend lines rather than a single snapshot, whether the time and risk involved in making changes is steadily increasing, whether incidents are increasingly traced back to the same architectural pain points, and whether new engineers are taking longer than they should to become productive. Debt that's stable and well-understood is very different from debt that's actively compounding and needs deliberate investment to address.

I'd push hard on whether the specific workload genuinely benefits from a reactive, non-blocking model, typically high-concurrency, I/O-bound workloads, rather than adopting it broadly just because it's the newer approach. The added complexity of reactive programming, different debugging patterns, a steeper learning curve, needs to be justified by a genuine, measurable performance or scalability need.

I'd anchor that direction in where the business itself is heading, projected growth in traffic and team size, rather than chasing every new Spring ecosystem feature as it's released. Building in periodic checkpoints to reassess as actual needs become clearer keeps the direction grounded in real requirements instead of speculation made too far in advance.

I'd weigh the genuine duplication and inconsistency cost of teams solving the same problems slightly differently against the coordination overhead and reduced flexibility a shared library introduces. A shared library earns its cost when the pattern is genuinely common, stable, and low-variance across teams, while a pattern that still varies significantly by team's actual needs is often better left to each team for now.

I'd translate the technical tradeoffs into terms stakeholders actually care about, delivery timeline impact, risk to reliability during the transition, and the longer-term benefit to feature velocity or scalability, rather than walking through the technical mechanics themselves. Being honest about the real short-term cost of a migration, beyond just its eventual payoff, builds more durable trust than an overly optimistic pitch.

I'd revisit the specific, concrete goals that justified the change in the first place, deployment frequency, incident rate, developer velocity, and honestly compare actual outcomes against them, rather than assuming success just because the migration itself completed without major incident. Being willing to acknowledge when a change didn't deliver the expected value is what keeps future architectural decisions grounded in evidence rather than repeated optimism.

I'd invest in mapping and documenting the actual aspect configuration and its effects systematically before attempting any significant change, since undocumented, deeply interconnected AOP behavior fails in genuinely surprising ways when touched carelessly. I'd push for incremental, well-tested simplification over time rather than a risky wholesale rewrite, given how much hidden behavior is often embedded in a system nobody fully understands anymore.

I'd calibrate the level of architectural rigor to the actual stakes and expected lifespan of the specific piece of code, applying more care to foundational, widely depended-upon components and being more pragmatic about lower-stakes, easily replaceable code. Treating every part of the codebase with the same level of ceremony either slows down low-stakes work unnecessarily or, worse, under-invests in something that genuinely needed more care.

I'd periodically revisit whether Spring and its surrounding ecosystem genuinely remain the best fit for the organization's dominant workloads and team skill sets, and whether newer needs are being forced awkwardly into existing patterns out of familiarity rather than genuine fit. A mature technology strategy uses the right tool and pattern for each genuine need rather than defaulting to what's already familiar out of institutional inertia.

I focus on getting them comfortable making the business case for architectural investments in terms leadership actually cares about, and having them own technical relationships and alignment across multiple teams rather than only being consulted reactively on their own team's decisions. Pairing them on organization-wide initiatives where they have to negotiate priorities and tradeoffs across teams builds the influence that deep technical skill alone doesn't teach.

I'd make the actual cost of that debt concrete and specific, incident history, growing engineering time lost to working around it, features that are becoming measurably harder to build safely, rather than arguing for the investment in the abstract. Even when the final prioritization decision goes against my recommendation, making sure it's an informed decision with the real tradeoffs understood matters more than winning the specific argument.

Beyond just operational reliability, a mature engineering organization should be proactively identifying where architectural limitations are quietly constraining what the business can build next, and surfacing that before it becomes an urgent blocker on a critical initiative. I try to make sure the engineering organization is positioned as an enabler of what the business wants to do next, not only a function that keeps the lights on for what already exists.

Signals of needing fundamental change include chronic firefighting that never seems to reduce despite ongoing effort, a pattern of major incidents traced back to the same underlying architectural causes repeatedly, or a structure that no longer matches how the business and engineering organization have grown. I'd rather diagnose root causes honestly and propose real structural change when it's genuinely warranted than keep patching symptoms with incremental fixes that don't address the underlying gap.

I push for that knowledge to live in documented architecture decision records, onboarding materials, and shared code review practices rather than only in people's heads, and I deliberately involve less senior engineers in architecture discussions earlier than might feel comfortable so the reasoning spreads naturally through the team. Relying on a couple of people as the sole source of critical architectural knowledge is a genuine organizational risk if either of them leaves.

I'd anchor the vision in where the business itself is heading over the next several years, then work backward to the architecture, tooling, and team capabilities that will need to be in place well before they become urgent. A vision built purely around adopting newer technology for its own sake, disconnected from where the business is actually going, tends to lose leadership buy-in quickly.

I'd weigh how core and differentiating that specific capability is to the business against the ongoing cost and risk of building and maintaining deep in-house expertise for it. A capability that's central to the company's competitive advantage generally justifies in-house investment despite higher upfront cost, while a well-solved, commoditized problem is often better served by an established third-party solution the organization doesn't need to build itself.

I'd focus entirely on business outcomes and risk, how the architecture affects the organization's ability to ship reliably and scale, and the cost of underinvestment measured in delivery slowdown or outage impact, deliberately leaving out implementation detail that isn't relevant at that level. Board-level credibility comes from clear, confident framing of risk and impact, not from demonstrating technical depth that audience isn't positioned to evaluate.

I'd separate the immediate response, containing the damage and communicating transparently with affected stakeholders, from the longer root-cause investigation, resisting pressure to assign blame before the actual cause is fully understood. Turning the postmortem into concrete, tracked architectural and process changes matters more long-term than the specifics of any single incident.

I push for shared visibility into architectural health metrics and decisions rather than keeping that reasoning siloed within a central team, and I involve product engineering teams directly in decisions that affect the shared architecture they depend on. Recognizing and reinforcing that architectural quality is a shared responsibility, beyond something one team alone is accountable for, changes how teams design and build in the first place.

I'd weigh how urgently a specific capability or fix is needed against how long building genuine internal expertise for it would realistically take, and how core that capability is to the business's long-term competitive position. An urgent, complex problem the team doesn't yet have deep expertise in usually favors bringing in outside help now, while something central and ongoing is worth the longer internal investment, even if it means moving more slowly at first.

I'd assess whether architectural decision-making is currently too concentrated in one or two individuals to scale, whether the organizational structure still matches how the business has grown and diversified, and whether the team has a genuine pipeline for developing the next generation of technical leaders. Proactively evolving the structure ahead of clear strain tends to go far better than waiting until the current structure has visibly broken under growth.