Expert Spring Framework Interview Questions, 2026
Victor
Posted on 4 May 2026
It’s 4:30 p.m. Your panel has heard a candidate explain @Component, @Service, and @Autowired with perfect confidence. Then you ask why a transaction rolled back in one environment and committed in another, and the room goes quiet. That’s the interview failure pattern. You screened for recall and hired for production judgment.
Too many spring framework interview questions are lazy. They reward memorization, not engineering ability. You get candidates who can recite annotations and still build a service layer that turns debugging into a hostage situation.
Spring matters because it sits in the middle of serious Java systems, not toy demos. The framework won because it made enterprise Java less miserable and gave teams sane defaults around dependency management, web development, data access, security, and testing. None of that tells you whether a candidate can untangle bean wiring, explain proxy behavior, choose the right transaction boundary, or spot a bad security configuration before it reaches production.
Indeed’s analysis of Spring interview questions shows how heavily interview prep content skews toward theory instead of practical experience. That habit poisons hiring loops. Teams ask classroom questions, hear polished textbook answers, and miss the person who knows firsthand how Spring behaves under load, under failure, and under deadline.
Use a better system. This guide is a hiring toolkit with difficulty labels, model answers, short coding tasks, evaluation rubrics, and role-specific question sets, so you can separate capable Spring engineers from résumé decorators.
If you also screen for broader Java depth, pair this with Java interview questions and answers for backend hiring. Spring expertise without core Java judgment is how teams end up with fancy annotations wrapped around bad code.
Table of Contents
Your candidate is ten minutes into the interview, confidently saying, “Spring is a framework for building Java apps.” If that answer sounds acceptable to you, enjoy the outage they ship six months from now.
Spring is a modular Java framework for building enterprise applications without the old EJB-era ceremony. The point is not “Java web apps.” The point is controlled object wiring, clear application structure, and a stack of modules you can choose with intent instead of dragging in half the ecosystem because someone copied a template.
For this question, do not reward memorization. Reward precision. A real Spring engineer explains what Spring is, why modularity matters, and which modules solve which problems in production code.
A strong answer usually covers four ideas:
Spring provides an application container that manages components and their relationships. It uses modules so teams can pull in web, data, security, testing, and cross-cutting support without treating every service like a monolith. It made enterprise Java tolerable by favoring POJOs over heavyweight container-driven development. It also gives teams a consistent programming model across different layers of an application.
The candidate should name the core module groups and attach a purpose to each one:
If they list modules without context, keep pushing. Ask what they would use for a REST API, what they would skip, and why.
Practical rule: If they cannot connect modules to a real system design, they are reciting docs, not drawing from experience.
Use this question as a filter, not a warm-up.
One red flag deserves instant attention. If they say “Spring Boot is Spring” and leave it there, they do not understand the stack well enough to make good design choices.
For wider screening, pair this with Java interview questions with answers for backend hiring. Spring knowledge without solid Java fundamentals is how teams end up with pretty annotations wrapped around slow, fragile code.
Give the candidate a simple brief: build a REST API for orders, store data in a relational database, validate input, and write tests.
Then ask: which Spring modules do you need?
Good candidates choose with discipline. They mention web, data access, transaction support, validation support where appropriate, and testing. Weak candidates grab everything in sight like a junior in a free AWS account.
A candidate says, “Spring injects stuff for you,” and then stares at the ceiling when you ask who creates the objects, who owns lifecycle, and what happens when two beans match the same type. That candidate is not ready.
IoC and DI are baseline knowledge. If they cannot explain them cleanly, stop burning interview time.
Inversion of Control means application code does not control object creation and wiring. The Spring container does. Dependency Injection is the mechanism Spring uses to supply those dependencies to a class instead of letting the class build them with new. Good candidates separate those ideas fast. Pretenders blur them into annotation folklore.
What you want is a practical explanation, not textbook karaoke. The candidate should explain that the IoC container creates beans, wires dependencies, enforces configuration, and manages lifecycle. Then they should connect that to outcomes you care about: lower coupling, easier tests, clearer class contracts, and fewer hidden dependencies.
Push hard on injection style. Constructor injection should be the default answer for required dependencies. It makes the dependency graph obvious, supports immutability, and fails fast when wiring is wrong. Setter injection is acceptable for optional dependencies or late configuration. Field injection is a bad habit. It hides requirements, complicates tests, and encourages sloppy design.
If they defend field injection as their standard approach, you are probably interviewing someone who learned Spring from copy-paste tutorials and never had to debug a production system at 2 a.m.
Strong candidates go past definitions. They explain tradeoffs.
They should know that DI improves unit testing because you can pass mocks, fakes, or stubs directly into constructors. They should know that IoC is broader than DI because it covers lifecycle and container-managed behavior, not just wiring. They should also know what happens when autowiring becomes ambiguous. If multiple beans share the same type, Spring needs help through @Qualifier, bean names, or @Primary.
That last point matters. It separates people who have built real systems from people who have only launched demo apps.
Give them this design smell and ask for a rewrite:
OrderService creates new PaymentClient()OrderService creates new EmailSender()OrderService creates new AuditLogger()A good candidate replaces direct construction with constructor-injected collaborators, explains why the service becomes easier to test, and points out that object assembly now belongs in configuration, not business logic.
If you want to turn this from a trivia question into a hiring tool, ask for code. A senior candidate should produce something close to this without drama:
@Service
public class OrderService {
private final PaymentClient paymentClient;
private final EmailSender emailSender;
private final AuditLogger auditLogger;
public OrderService(PaymentClient paymentClient, EmailSender emailSender, AuditLogger auditLogger) {
this.paymentClient = paymentClient;
this.emailSender = emailSender;
this.auditLogger = auditLogger;
}
public void placeOrder(Order order) {
paymentClient.charge(order);
emailSender.sendConfirmation(order);
auditLogger.log(order);
}
}
Then ask the follow-up that catches bluffers: how would you test this class? The right answer mentions injecting test doubles and testing business behavior without booting the full container unless integration coverage is needed.
Difficulty: Easy to medium
Weak: Says DI means “using @Autowired,” mixes up IoC and DI, and cannot explain why one design is easier to test than the other.
Solid: Separates IoC from DI, recommends constructor injection for required dependencies, and explains how Spring resolves collaborators through the container.
Strong: Explains testability, immutability, wiring failures, ambiguous bean resolution, and the design problems caused by field injection.
This is how you use one question properly. You are not checking whether someone memorized two definitions. You are checking whether they understand object design, testability, and whether they let the framework serve the codebase instead of letting the codebase collapse into annotation soup.
A candidate says, “A bean is just any class with @Component.” That answer should make you nervous.
This question exposes whether they understand how a Spring application runs, or whether they survive by stacking annotations until the build stops screaming. If they cannot explain bean lifecycle clearly, they will struggle to diagnose startup failures, scope bugs, proxy surprises, and shutdown issues in production.
A Spring bean is an object the container creates, wires, configures, and manages. The interview target is not the definition. It is the sequence. A serious candidate should walk through instantiation, dependency injection, lifecycle callbacks, active use inside the application context, and destruction when the context closes.
Here’s a visual that works well in interviews when you want them to talk through lifecycle concepts:
The candidate should explain this flow in plain English:
BeanNameAware or ApplicationContextAware if the bean uses them.BeanPostProcessor logic before and after initialization.@PostConstruct, InitializingBean, or a custom initMethod.@PreDestroy, DisposableBean, or a custom destroyMethod when the context shuts down.If they skip post-processors entirely, they probably do not understand how proxies, AOP, or a lot of Spring magic shows up at runtime. That matters.
Singleton is the default scope. They need to know that cold. They should also explain why singleton does not mean “safe to store mutable shared state.” A singleton bean is shared across threads. Put a mutable counter or request-specific data inside it and you have built a race condition factory.
They should also know where other scopes fit:
Interviews yield valuable insights. Ask what changes operationally with each scope. Good candidates mention memory use, lifecycle differences, proxying for web scopes, and thread-safety implications.
“A Spring bean is an object managed by the IoC container. The container creates it, injects dependencies, runs lifecycle callbacks and post-processors, then keeps it available in the application context. For singleton beans, Spring usually creates them at startup. For destruction, Spring calls cleanup hooks when the context closes, but prototype beans are different because Spring does not fully manage their destruction after handing them out.”
That last point matters. Prototype destruction is a classic trap. Strong candidates know it.
Show them this and ask what goes wrong:
@Service
public class VisitCounterService {
private int count = 0;
public int increment() {
return ++count;
}
}
Expected answer: this is a singleton by default, multiple threads can hit increment() at the same time, and count can become inconsistent under concurrent load.
Good follow-up questions:
@PostConstruct be appropriate, and when is it a bad idea?BeanPostProcessor do, and why does it matter for features like AOP?Difficulty: Medium
Weak: Defines a bean vaguely, mentions @Component, and cannot describe the lifecycle order or scope behavior.
Solid: Explains creation, injection, initialization, runtime use, destruction, and knows singleton is the default scope.
Strong: Explains post-processors, lifecycle callbacks, scope tradeoffs, prototype destruction limits, thread safety, and the proxy implications of injecting shorter-lived beans into longer-lived ones.
@PostConstruct and BeanPostProcessor?Use this question properly and you get more than a memorized definition. You find out who understands container behavior, concurrency risks, and the parts of Spring that break at 2 a.m. when the easy answers stop working.
A candidate says, “I’ve built loads of REST APIs with Spring Boot.” Great. Then ask them to trace one request from the HTTP socket to the final response. Bad hires collapse right here.
Spring MVC is request orchestration. DispatcherServlet is the front controller that receives the request, asks Spring which handler should process it, runs the controller method through the right adapters and argument resolvers, and then hands the result to a view resolver or an HTTP message converter.
A strong candidate explains the flow in order:
DispatcherServlet receives the request.HandlerMapping finds the matching controller method.HandlerAdapter invokes that method.@Valid are present.ModelAndView, or a body object.HttpMessageConverter.@ControllerAdvice decide the response.That sequence matters. If they skip half of it, they have used Spring MVC. They have not understood it.
For API-heavy teams, insist on specifics. They should know what @RestController changes, how @RequestBody becomes a Java object, why Jackson is usually involved, and where status codes get set. They should also know that interceptors run around handler execution and that filters sit outside Spring MVC in the servlet chain. Mixing those up is a classic résumé inflation tell.
Boot saves setup time. It does not excuse ignorance about request flow.
Difficulty: Medium
“Spring MVC uses DispatcherServlet as the central entry point for web requests. It delegates to HandlerMapping to find the right controller, then uses a HandlerAdapter to invoke it. Before invocation, Spring resolves method parameters from the request and can validate them. After the controller returns, Spring either resolves a view for server-side rendering or serializes the return value for REST responses using message converters. Exceptions are handled through resolvers, often with @ExceptionHandler or @ControllerAdvice.”
If a candidate can say that clearly, they know the plumbing. If they can explain where interceptors, validation, and exception handling fit, they probably debug production issues instead of just creating tickets about them.
Give them a controller that returns 200 OK even when validation fails.
Ask them to fix it without turning the controller into a junk drawer.
Strong candidates reach for @Valid, a request DTO, and centralized exception handling with @ControllerAdvice or ResponseEntityExceptionHandler. Senior candidates also clean up the error payload so clients get predictable fields instead of random stack-trace soup.
Weak: Says DispatcherServlet “handles requests” but cannot explain handler mappings, argument resolution, or how JSON serialization happens.
Solid: Explains the front controller pattern, request mapping to controllers, request body binding, and the difference between returning a view and returning JSON.
Strong: Explains handler mappings, handler adapters, message converters, validation flow, interceptors vs filters, @ControllerAdvice, and how the MVC pipeline affects debugging, performance, and API behavior.
@Controller and @RestController?Use this question properly and you get more than a textbook MVC definition. You get a hiring tool with a difficulty label, a model answer, a coding task, and a rubric that exposes who understands the web stack and who has been coasting on generated boilerplate.
Your new hire adds spring-boot-starter-web, spring-boot-starter-data-jpa, and a database driver, then proudly says Boot “just works.” Two weeks later, the service starts with beans nobody asked for, logs nobody can explain, and a security filter chain that surprised half the team. Ask this question well and you find out fast whether the candidate understands Spring Boot or has just been riding defaults.
Auto-configuration is Spring Boot’s way of creating configuration and beans based on classpath contents, existing beans, and application properties. Starters are curated dependency sets for common use cases such as web, data access, security, or testing. That combination cuts setup time hard. It also hides complexity from people who never learned what got wired in the first place.
A strong candidate explains the mechanism, not just the convenience. They should know Boot uses conditional configuration such as @ConditionalOnClass, @ConditionalOnMissingBean, and property-based conditions to decide what to create. They should also know starters are packaging choices, not magic. Add a starter, and you pull in a tested set of dependencies that steer Boot toward a certain application shape.
Look for candidates who can explain all of this in plain English:
If they skip the override story, keep pushing. Real Spring engineers know convenience is only useful when you can turn it off.
Give them a small scenario instead of another trivia question.
Task: “Build a REST API that exposes /orders, validates input, stores data in PostgreSQL, and includes health checks. Which starters do you choose, and what would Boot auto-configure for you?”
A solid answer should include spring-boot-starter-web, validation support, JPA or JDBC depending on the design, the PostgreSQL driver, and spring-boot-starter-actuator if operational endpoints matter. Then they should explain what Boot will likely configure, such as the embedded server, MVC infrastructure, JSON serialization, datasource setup, and repository support.
The weak candidate grabs every starter in sight. That is not speed. That is future cleanup work.
Weak: Says Boot “reduces boilerplate” and cannot explain what auto-configuration inspects or how to override it.
Solid: Explains starters, classpath-based auto-configuration, embedded server defaults, and basic overrides through properties or custom beans.
Strong: Explains conditional annotations, bean back-off behavior, exclusion strategies, transitive dependency risks, and how to debug unexpected configuration with condition reports or startup logs.
spring-boot-starter-web and adding Spring MVC dependencies one by one?Use this question as a filter, not a checkbox. With a difficulty label, a model answer, a short coding task, and a rubric, it tells you who understands Boot’s wiring model and who has been shipping cargo-cult configuration.
Friday, 6:42 p.m. A checkout service charged the customer, reserved no inventory, and still sent the confirmation email. The candidate who built it swore @Transactional had everything covered. It did not.
Use this question to find out who understands data integrity under pressure and who has been sprinkling annotations like parsley.
A strong answer starts with ACID. Atomicity means the unit of work succeeds or fails as one operation. Consistency means the system moves from one valid state to another. Isolation means concurrent transactions do not trample each other in unsafe ways. Durability means committed data survives crashes.
Candidates must then explain how Spring handles transactions. Spring typically wraps eligible beans in proxies and applies transaction behavior around method calls. @Transactional gives you declarative control over boundaries, rollback rules, propagation, isolation, and read-only hints. Programmatic control exists too, usually through TransactionTemplate or direct transaction manager use. If they cannot explain both styles, they know the annotation, not the system.
Do not let them stop at definitions. Ask where transactions belong. The right answer is usually the service layer, around business operations that must commit together. Ask what happens on self-invocation. A method calling another @Transactional method in the same class often bypasses the proxy, so the transaction settings you expected may never apply. That one detail filters out a shocking number of résumé experts.
Strong candidates explain propagation without turning it into trivia night.
REQUIRED joins an existing transaction or starts one if none exists. REQUIRES_NEW suspends the current transaction and starts a separate one. That difference matters in audit logging, outbox writes, and error handling. Isolation levels matter too. If they cannot connect isolation to dirty reads, non-repeatable reads, or phantom reads, they have not dealt with concurrent systems in anger.
They should also know rollback behavior. By default, Spring rolls back on unchecked exceptions, not every exception type. That catches candidates who assume any thrown exception means everything is undone.
One more hiring tell. Ask about side effects inside transactions. Charging cards, sending emails, publishing messages, and calling third-party APIs do not belong in the same blind transaction story as local database updates. Good engineers separate transactional writes from external side effects, or they use patterns like outbox processing to avoid duplicate actions and half-failed workflows.
If they treat transactions like a lucky charm, keep them away from money and inventory.
REQUIRED and REQUIRES_NEW, and when would you choose one over the other?@Transactional fail on internal method calls in the same class?Short coding task: Hand them a service method that updates inventory, creates an order, charges a payment provider, and sends an email in one annotated method. Ask them to redesign it. Strong candidates split database work from external side effects, explain transaction boundaries clearly, and discuss idempotency, retries, and event-driven follow-up work.
Weak: Recites ACID, names @Transactional, and cannot explain proxy behavior, rollback rules, or propagation.
Solid: Explains ACID correctly, places transactions in the service layer, understands REQUIRED versus REQUIRES_NEW, and knows Spring usually rolls back on unchecked exceptions.
Strong: Explains proxy limitations, self-invocation failure, isolation tradeoffs, side-effect handling, retry safety, and patterns that prevent duplicate external actions.
@Transactional do at a high level, and why is it usually placed on service methods?This question earns its place in a hiring toolkit because it gives you more than a definition check. Add the difficulty label, model answer, coding task, and rubric, and you get a clean read on whether the candidate can protect real systems or just pronounce ACID with confidence.
You are interviewing a candidate for a Spring role. They say, “AOP is for logging,” smile, and wait for approval. Do not give it. That answer tells you they memorized a glossary and never had to clean up a codebase full of repeated security checks, audit trails, timing code, and badly placed try-catch junk.
Spring AOP exists to handle cross-cutting concerns in one place instead of smearing them across services. Good examples include request tracing, method timing, audit logging, authorization checks, retry policies, and the proxy-based transaction behavior many developers use without fully understanding. Weak candidates list terms like advice, pointcut, and join point. Strong candidates explain where AOP helps, where it becomes a debugging tax, and why proxy rules matter.
The proxy part is where pretenders fall apart. Spring AOP usually works through proxies, which means it intercepts method calls that go through the Spring-managed proxy. Self-invocation is the classic trap. One method in a bean calling another method in the same bean often bypasses the proxy, so the aspect never runs. If a candidate cannot explain that cleanly, they should not be making framework decisions.
A candidate worth hiring should tell you four things.
First, what AOP is. It separates cross-cutting behavior from business logic.
Second, how Spring applies it. Usually through JDK dynamic proxies or CGLIB proxies around Spring beans.
Third, where to use it. Use it for concerns that apply consistently across many methods, not for core business rules that need to stay obvious in the service code.
Fourth, where it breaks down. Overuse makes stack traces ugly, debugging slower, and ownership fuzzy.
For a good follow-up on persistence-heavy systems where auditing and cross-cutting data rules often show up, pair this with data modeling interview questions for backend hiring.
@Before, @AfterReturning, and @Around advice. Which one would you choose for timing logic, and why?Short coding task:
Give the candidate a service with repeated timing and audit code in several methods. Ask them to refactor it with an aspect. Then ask the harder question: which parts should stay explicit in business logic instead of being hidden behind AOP? That second answer matters more than the annotation syntax.
“Spring AOP is Spring’s way of applying cross-cutting behavior to beans without duplicating that code everywhere. Common uses are logging, metrics, auditing, security checks, and transaction boundaries. In standard Spring apps, AOP is proxy-based, so it only intercepts calls that go through the proxy. That creates limitations, especially with self-invocation inside the same bean. I would use AOP for repeated technical concerns that need consistent enforcement. I would not hide core domain decisions in aspects because that makes the code harder to trace and reason about.”
Weak: Recites AOP vocabulary and says “logging” with no useful example.
Solid: Explains cross-cutting concerns, gives practical uses such as metrics or auditing, and knows Spring AOP is usually proxy-based.
Strong: Explains self-invocation failure, proxy types, the Spring AOP versus AspectJ tradeoff, and shows discipline about keeping business rules out of hidden aspects.
Difficulty: Medium for junior and mid-level candidates. High if you push into proxies, interception limits, and design tradeoffs.
This question belongs in a real hiring toolkit because it gives you more than a definition check. Add the coding task, model answer, and rubric, and you can tell who has run Spring in production and who just watched a tutorial with good lighting.
Your team ships a feature fast, then production starts wheezing because a cute repository method inadvertently generated awful queries. That is why this question matters. It tells you whether the candidate knows Spring Data, or just knows how to autocomplete JpaRepository.
Spring Data cuts repetitive persistence code by giving you repository abstractions, query derivation, paging, sorting, auditing support, and integration with stores such as JPA, MongoDB, Redis, and Elasticsearch. The simplification is real. So is the trap. Weak engineers treat repositories like magic. Strong engineers know exactly what code Spring generates, where the abstraction ends, and when to drop to explicit queries or custom implementations.
The candidate should explain CrudRepository, PagingAndSortingRepository, and JpaRepository without reciting docs like a sleepy intern. I want to hear when they would use derived query methods, when they would stop writing absurd method names, and how they handle projections, specifications, joins, and fetch strategy. If they never mention SQL visibility, they are guessing.
For adjacent screening on schema design and query tradeoffs, pair this with these data modeling interview questions for backend roles.
Ask for a real example, not CRUD kindergarten. Try this: “Design a repository method to fetch active customers created after a date, sorted by last login, with pagination. Now explain when you would keep it as a derived query and when you would switch to @Query or a custom repository.”
Then push on performance. Repository convenience does not excuse N+1 queries, lazy loading surprises, bad count queries, or pulling entire entities when a projection would do. Anyone who says “Spring handles that” should not be handling your database layer.
“Spring Data provides repository abstractions that remove a lot of repetitive DAO code. In a JPA application, I can define interfaces such as JpaRepository and let Spring generate standard CRUD, paging, and sorting operations. For simple filters, derived query methods are fine. Once method names become hard to read, or I need joins, projections, fetch control, or database-specific behavior, I switch to @Query, specifications, Querydsl, or a custom repository implementation. The main benefit is faster development with consistent patterns. The main risk is hiding inefficient queries behind a clean interface, so I inspect generated SQL, test realistic access patterns, and choose fetch strategies deliberately.”
Weak: Says Spring Data “connects Java to the database” and can name JpaRepository, but cannot explain query derivation limits or performance risks.
Solid: Explains repositories, derived queries, paging, sorting, and when to use @Query instead of giant method names.
Strong: Explains projections, specifications or Querydsl, transaction boundaries around repository usage, fetch strategy, N+1 prevention, and how to inspect generated SQL before production teaches the lesson the hard way.
Give the candidate two entities, such as Customer and Order. Ask them to design one repository for common reads, one filtered paginated query, and one reporting query that should not return full entities.
Then ask how they would verify performance. Good candidates talk about SQL logging, execution plans, indexes, projections, and integration tests against realistic data volumes. Pretenders smile and keep typing interface methods like they are casting spells.
Difficulty: Medium for junior candidates. High for mid-level and senior candidates once you press on query generation, fetch behavior, and design tradeoffs.
This question belongs in a hiring toolkit, not a trivia list. Add a model answer, a coding task, and a rubric, and you get a clean read on who can build a persistence layer that stays fast after launch.
Your team ships a clean Spring API on Friday. By Monday, an admin endpoint is exposed, passwords are logged in plain text during a failed debug session, and somebody disabled CSRF because a form test kept failing. This question tells you whether the candidate prevents that mess or causes it.
Authentication proves identity. Authorization decides access. A serious candidate explains that difference fast, then maps it to Spring Security’s actual machinery: filter chain, SecurityContext, AuthenticationManager, UserDetailsService, password encoders, session handling, method security, and request authorization rules.
Spring Security gives you the tools to secure web apps and APIs without writing ad hoc security code that rots in six months. Good candidates should know common features such as form login, HTTP Basic, OAuth2 login, resource server support for JWTs, CSRF protection, CORS handling, session fixation protection, remember-me, role and authority checks, method-level annotations like @PreAuthorize, and password hashing with BCryptPasswordEncoder or an equivalent modern encoder.
Use this visual if you want a quick prompt into the topic:
A strong answer is architectural, not decorative. The candidate should explain how a request passes through the security filter chain, how authentication populates the SecurityContext, and how authorization checks happen at the URL level or method level. If they only recite annotations, you are talking to somebody who memorized tutorials.
They should also know the tradeoffs. Session-based authentication fits browser apps well. Token-based authentication fits distributed APIs and mobile clients better, but it shifts responsibility to token issuance, expiration, revocation strategy, and key management. JWT is useful, not magical. OAuth2 is an authorization framework, not a synonym for JWT and not a login shortcut for people who dislike reading specs.
Ask practical questions. How would they secure /public/**, /api/**, and /admin/** differently? How would they integrate with LDAP, OAuth2, or an external identity provider? What should go into audit logs, and what must never appear there? Good engineers mention failed login attempts, access-denied events, user identifiers, request context, and the rule that raw passwords, tokens, and secrets never belong in logs.
Hiring shortcut: If they have never debugged a broken filter chain, conflicting matcher rules, or a missing authority claim, they are still operating at demo level.
“Spring Security handles authentication by intercepting requests through a configured filter chain. The application validates credentials or tokens, creates an authenticated Authentication object, and stores it in the SecurityContext. Authorization then checks whether that authenticated principal has the required roles or authorities for a URL or method.
For browser apps, session-based auth is common because the server can track the authenticated user safely and apply CSRF protection. For stateless APIs, token-based auth is common, often with JWT used as the token format. Passwords must be hashed with a strong password encoder, never stored or compared in plain text. Method security such as @PreAuthorize adds another control layer, but it does not replace correct request rules, validation, or safe defaults.”
That answer shows they understand the flow, not just the annotations.
Give them a small API with these rules:
GET /public/info is open to everyoneGET /user/profile requires authenticationPOST /admin/users requires an ADMIN authorityThen ask them to sketch the security configuration and explain each choice. Strong candidates will configure request authorization clearly, disable session creation for a stateless API, explain whether CSRF should stay enabled or be disabled for that API style, and wire a password encoder without drama.
Weak candidates usually do one of three things. They permit everything by accident, confuse roles with authorities, or paste outdated WebSecurityConfigurerAdapter code and hope nobody notices.
Weak: Knows authentication means login and authorization means permissions, but cannot explain the filter chain, token flow, password encoding, or method security limits.
Solid: Explains authentication versus authorization correctly, knows common Spring Security features, can secure endpoints with request matchers and method annotations, and understands why password hashing matters.
Strong: Explains the request lifecycle through Spring Security, compares session and token approaches, understands JWT and OAuth2 boundaries, configures stateless APIs correctly, avoids common mistakes around CSRF and CORS, and can debug rule ordering or authority mapping problems under pressure.
Difficulty: Medium for junior candidates. High for mid-level and senior candidates once you push on filter-chain behavior, stateless API design, and real security tradeoffs.
This question belongs in a hiring toolkit, not a checkbox list. Use the model answer, coding task, and rubric, and you will spot the engineer who can secure production systems before they turn into incident tickets.
Your team deploys a new payment service. Ten minutes later, one instance crashes, another gets replaced, and traffic shifts. If a candidate still talks about fixed hostnames in config files, end the interview early.
Spring Cloud helps teams run microservices without wiring every ugly distributed-systems concern by hand. It covers service discovery, externalized configuration, inter-service communication, gateway patterns, tracing hooks, and resilience features. The core idea is simple. Services move, fail, restart, and scale. The platform has to keep up.
Service discovery is the mechanism that lets services register themselves and lets other services find them at runtime. Instead of hard-coding inventory-service.prod.internal:8080, a service asks the registry where inventory lives right now. In practice, that means fewer brittle environment-specific configs and a much better answer to autoscaling, rolling deployments, and instance churn.
Good candidates explain the moving parts cleanly. A service starts, registers with a discovery server such as Eureka, reports health, and becomes available to callers. Other services resolve it by logical name, not by a fixed IP. Then they should connect discovery to client-side load balancing, config management, timeouts, retries, and failure isolation. If they treat service discovery as a magic phone book and stop there, they are not ready for production.
A strong answer includes the tradeoffs, not just the feature list. Service discovery adds flexibility, but it also adds another system to operate. Spring Cloud can reduce boilerplate around common microservice patterns, but it does not remove the hard parts. Bad timeout settings still melt a dependency chain. Blind retries still turn a partial outage into a full one.
You also want judgment. Senior engineers know when Spring Cloud is useful and when it is extra machinery. If the team runs a small system on Kubernetes with stable platform primitives for discovery and config, the candidate should say so. If they insist every three-service app needs the full stack, they are selling fashion, not engineering.
“Spring Cloud supports microservices by providing tools for common distributed-system concerns such as service discovery, centralized configuration, API gateways, and resilience patterns. Service discovery lets services register themselves and be found dynamically by name instead of fixed network addresses. That matters because service instances change often in cloud environments. A solid design also needs health checks, timeouts, retries, and load balancing. Spring Cloud helps with those patterns, but teams still need to configure them carefully and avoid retry storms or hidden coupling.”
Difficulty: Medium
Ask: A service instance dies during active traffic. What should happen next?
Strong candidates mention health checks, deregistration or failed-instance removal, retry limits, timeouts, and load balancing to healthy instances.
Difficulty: Medium
Ask: How do you avoid hard-coded service endpoints across dev, staging, and production?
Strong candidates bring up service discovery, centralized config, environment-specific properties, and secret management.
Difficulty: High
Ask: When should a team skip Spring Cloud?
Strong candidates talk about platform-native alternatives, operational overhead, team size, system complexity, and whether the added abstraction solves a problem.
Coding task: High
Ask the candidate to sketch an order service calling inventory and payment in a dynamic environment.
Good answers include logical service names, timeout settings, failure handling, config separation, and observability. Weak answers say, “Kubernetes handles it,” and pray you do not ask a follow-up.
Weak: Knows microservices are split into smaller services, but cannot explain service registration, discovery flow, health checks, or failure handling.
Solid: Explains service discovery correctly, understands why dynamic lookup matters, and connects it to load balancing, configuration, and basic resilience controls.
Strong: Explains the runtime flow clearly, knows when to use Spring Cloud versus platform-native options, and can discuss real failure modes such as cascading retries, stale registrations, poor timeout strategy, and cross-service debugging.
This question separates people who have shipped distributed systems from people who have only drawn them on whiteboards. Use the model answer, coding task, difficulty labels, and rubric as part of the hiring toolkit, not as another trivia checkpoint.
| Topic | Implementation complexity | Resource requirements | Expected outcomes | Ideal use cases | Key advantages |
|---|---|---|---|---|---|
| What is the Spring Framework and what are its core modules? | Medium, modular architecture to understand | Knowledge of core modules (IoC, AOP, MVC), Java expertise | Assess architectural fundamentals for scalable backends | Enterprise backend systems, full?stack Java projects | Reveals DI/AOP concepts and modular design understanding |
| Explain dependency injection and inversion of control (IoC) in Spring | Low–Medium, conceptual but practical examples needed | Familiarity with DI patterns, annotations, testing frameworks | Gauge ability to produce testable, loosely coupled code | Microservices, unit-tested components, library design | Improves testability, loose coupling, adherence to SOLID |
| What are Spring Beans and how does the Bean lifecycle work? | Medium, lifecycle callbacks and scopes add complexity | Knowledge of scopes, config styles (XML/annotations/Java), lifecycle hooks | Evaluate resource/init/destroy handling and memory management | Long?running services, scheduled jobs, resource management | Ensures proper initialization, cleanup and predictable object lifecycle |
| Explain Spring MVC architecture and how the DispatcherServlet works | Medium–High, request flow and handler mapping concepts | Web dev skills, routing, controller/view knowledge | Assess REST API design and request/response handling | Web apps, REST APIs, complex routing scenarios | Demonstrates mastery of request routing and handler resolution |
| What are Spring Boot auto-configuration and starters, and how do they simplify development? | Low, simplifies setup but can hide internals | Familiarity with starters, properties, embedded servers | Measure ability to rapidly bootstrap and deploy apps | Prototyping, cloud?native services, quick client delivery | Reduces boilerplate, accelerates development and deployment |
| How does Spring handle transactions and what are ACID properties? | High, requires DB internals and concurrency knowledge | Deep DB/JPA knowledge, transaction APIs, testing environments | Assess data integrity, propagation and isolation choices | Financial systems, inventory, other mission?critical apps | Ensures consistency and safe concurrent data modifications |
| What is Spring AOP and how is it used? | High, abstract concepts (pointcuts, weaving) | Knowledge of AspectJ/Spring AOP, annotations, performance tradeoffs | Evaluate handling of cross?cutting concerns and modularity | Logging, security enforcement, performance monitoring | Reduces duplication, enforces separation of concerns |
| Explain Spring Data and how it simplifies database operations with repositories | Low–Medium, API is simple but query behavior matters | JPA/DB knowledge, repository interfaces, query conventions | Assess ability to speed up data access while avoiding inefficiencies | CRUD services, product catalogs, rapid iteration projects | Cuts boilerplate, supports multiple datastores, fast query scaffolding |
| What are Spring Security features and how does it manage authentication and authorization? | High, many options and subtle pitfalls | Security protocols (OAuth2, JWT), filter chains, compliance knowledge | Evaluate authentication/authorization design and risk mitigation | Customer?facing apps, PII handling, regulated systems | Comprehensive security controls and standards support |
| How does Spring Cloud support microservices architecture and what is service discovery? | High, distributed systems and operational complexity | Infrastructure/DevOps, registries (Eureka/Consul/K8s), monitoring tools | Assess design for resilience, dynamic discovery and scaling | Large?scale microservices, cloud deployments, resilient platforms | Enables service discovery, centralized config, fault tolerance |
Your backend lead resigns on Tuesday. By Wednesday, production is shaky, delivery slips, and by Friday you are interviewing people who call themselves “Spring experts” because they built one CRUD app with Spring Boot. That is how bad hiring burns a quarter.
Speed does not come from lowering the bar. It comes from building a process that rejects weak candidates fast.
Use this guide like an actual hiring toolkit, not blog filler. It gives you difficulty labels, model answers, short coding tasks, scoring rubrics, and role-specific question sets for different engineering jobs. That combination matters. A senior backend engineer, a full-stack developer, and a platform engineer should not face the same interview loop, and lazy teams that treat them the same usually hire poorly.
The bottleneck is not finding people who know Spring vocabulary. The market is full of those. The bottleneck is identifying who understands transaction boundaries, bean lifecycle failures, repository tradeoffs, security filter chains, and production debugging under pressure. Good interviews expose that in one structured pass. Bad interviews need four rounds, conflicting feedback, and a postmortem nobody enjoys.
Here is the recommendation. Keep the technical bar in-house. Outsource the grunt work.
Your senior engineers should evaluate architecture judgment, code quality, incident instincts, and ownership. They should not spend half the week filtering weak résumés, coordinating schedules, or chasing candidates who collapse the moment the conversation leaves annotations and enters system behavior.
The hiring machine matters too. Time zone overlap affects collaboration. Payroll and compliance slow down cross-border hiring. Replacements and admin overhead drain recruiting capacity. None of that helps you ship a better Spring service, but it absolutely slows hiring if your team handles every operational detail alone.
A hiring process that works is simple: start with a pre-filtered shortlist, run candidates through the questions and coding tasks in this guide, score them against a rubric, and decide quickly. Cut résumé theater. Cut vague “culture” rounds with no signal. Cut the marathon process that makes strong engineers walk away and weak ones linger.
If you need Spring developers who can do more than recite annotations, CloudDevs is a practical shortcut for sourcing pre-vetted LATAM talent while your team focuses on the technical judgment that predicts a good hire.
Let’s get one thing straight. An Employer of Record (EOR) is a third-party company that legally hires and pays people on your behalf in a country where you don’t have a business entity. Think of it as your get-out-of-jail-free card for international HR. They handle the nightmare stuff—contracts, payroll, taxes, and benefits—so you can actually...
Let's be honest: hiring remote developers is broken. You post a job, get buried in a mountain of irrelevant resumes, and waste weeks on candidates who, it turns out, can't actually code. The only alternative seems to be paying eye-watering US salaries that make your investors sweat. Turns out there’s more than one way to...
The different levels of engineers are best defined by their scope of impact—not just how many years they’ve been on the job. A junior engineer might focus on a single, specific task. A mid-level engineer takes ownership of a whole feature. A senior engineer is responsible for an entire system, with staff and principal engineers...
