Most Spring Boot Developers Can’t Answer These Interview Questions. Can You?

Senior interviews don’t test whether you’ve used Spring Boot. They test whether you understand what happens underneath.

Most developers who say they know Spring Boot can build APIs, connect databases, configure security, and run applications without much trouble. The basics are genuinely well-documented and the framework makes them accessible.

Credits: Pexels

Senior-level interviews are usually not about any of that.

They’re about whether you understand why your application works — and more importantly, what happens when it doesn’t.

That’s where the questions become interesting.

Question 1: Why Does @Transactional Sometimes Not Work?

@Service
public class PaymentService {
    public void process() {
        savePayment(); // Is this transactional?
    }
    @Transactional
    public void savePayment() {
        // database operations
    }
}

What most people say: “It should work — savePayment() is annotated.”

What’s actually happening: No transaction. And no error to tell you that.

Spring’s transaction management works through proxy objects. When you inject PaymentService into another class and call process(), you’re calling it through a Spring-generated proxy that intercepts the call. But when process() calls this.savePayment(), it’s calling directly on the underlying object — bypassing the proxy entirely. No interception. No transaction.

The @Transactional annotation is present. The transaction is not.

This is one of the most common causes of silent data integrity bugs in Spring applications. The method executes, no exception is thrown, but if something fails mid-operation, nothing rolls back.

The fix: restructure so the transactional method is called through the proxy (inject the bean into itself, or refactor the method into a separate service), or use AopContext.currentProxy() — though the cleaner answer is always the redesign.

The deeper question a senior interviewer asks next: “What other annotations have the same proxy limitation?” — @Async and @Cacheable are the answers. All Spring AOP-based annotations fail silently on self-invocation.

Question 2: What Happens When @Async Is Called From the Same Class?

@Service
public class NotificationService {
    public void sendAll() {
        sendEmail(); // Is this asynchronous?
    }
    @Async
    public void sendEmail() {
        // supposed to run in a different thread
    }
}

What most people say: “It runs asynchronously — that’s what @Async does.”

What’s actually happening: It runs synchronously. On the same thread. In the same call stack. And Spring gives you no warning.

Same proxy problem as @Transactional. The @Async annotation only takes effect when the method is called through the Spring proxy — which happens when another bean calls it. Internal calls bypass the proxy, so @Async is silently ignored.

The dangerous part: the code appears to work in development and testing. Both paths execute. No exception. But under production load, the “async” tasks are blocking the calling thread — which can saturate your thread pool and introduce latency you can’t explain from the logs.

The fix: same as @Transactional — call through the proxy, not this. Which means the async method typically belongs in a separate component.

This question reveals whether a candidate understands Spring AOP as a concept or just knows a list of annotations.

Question 3: Why Does Spring Boot Fail on Circular Dependencies?

@Service
public class ServiceA {
    @Autowired
    private ServiceB serviceB;
}
@Service
public class ServiceB {
    @Autowired
    private ServiceA serviceA;
}

What most people say: “Circular dependency bad. Use @Lazy to fix it.”

What’s actually happening: Spring builds beans during container initialization. When it tries to create ServiceA, it needs ServiceB. When it tries to create ServiceB, it needs ServiceA. Neither can be fully constructed until the other exists.

For constructor injection, this is a hard deadlock — Spring throws BeanCurrentlyInCreationException immediately. For field injection, Spring can sometimes resolve it using partial bean references (which is exactly why field injection is dangerous — the problem may be masked).

The deeper insight: circular dependencies usually indicate a design problem, not a configuration problem. Two beans that need each other belong in one bean, or there’s a third concept that should be extracted. @Lazy breaks the cycle but doesn’t fix the design.

Most candidates stop at “circular dependency bad.” Strong candidates explain bean lifecycle, initialization order, and why the design needs rethinking.

Question 4: What Actually Makes Spring Boot Fast to Develop?

What most people say: “Starters and auto-configuration.”

What’s actually happening: Starters are just dependency bundles — they don’t configure anything themselves. The mechanism behind “fast” is auto-configuration, and understanding how it works is what separates engineers who use Spring Boot from engineers who understand it.

Auto-configuration classes are loaded via spring.factories (or AutoConfiguration.imports in newer versions). Each one uses @Conditional annotations to decide whether to activate:

@Configuration
@ConditionalOnClass(DataSource.class)
@ConditionalOnMissingBean(DataSource.class)
public class DataSourceAutoConfiguration {
    // configures datasource only if one isn't already defined
}

Add spring-boot-starter-data-jpa and Spring Boot automatically configures a DataSource, EntityManagerFactory, TransactionManager, and repositories — but only if you haven’t already defined your own. Your custom bean takes precedence.

Spring Boot is not magic. It’s convention-driven automation with intelligent fallbacks.

The follow-up that trips most engineers: “How would you debug why an auto-configuration isn’t applying?” — the answer is –debug flag or ConditionEvaluationReport, which shows every conditional evaluation and why it passed or failed.

Question 5: Are @Component, @Service, and @Repository Actually Different?

What most people say: “They’re all the same — just semantic conventions for readability.”

What’s actually happening: @Component and @Service are functionally identical. But @Repository does something different.

Spring adds automatic exception translation to @Repository beans. If a persistence layer throws a driver-specific exception — a SQLException, a HibernateException, a JPA-specific error — Spring wraps it in its DataAccessException hierarchy. Your service layer receives a portable, Spring-managed exception instead of a vendor-specific one.

@Repository
public class UserRepository {
    // SQLException here becomes DataAccessException
    // HibernateException here becomes DataAccessException
}

Without @Repository, these exceptions propagate as-is. Your service layer becomes coupled to the persistence technology — if you switch from Hibernate to JDBC, the exceptions change.

The annotation is not just semantic. It changes behavior.

The deeper question: “Why does this matter for production systems?” — because exception handling strategy and the ability to swap persistence implementations without changing service logic are real architectural concerns.

The Pattern Across All These Questions

Every question above tests the same thing: do you understand the framework as a set of contracts and mechanisms, or as a set of annotations to apply?

The proxy model underlies @Transactional, @Async, and @Cacheable. Bean lifecycle underlies circular dependencies, ApplicationContext behavior, and auto-configuration. Thread model underlies WebFlux vs MVC.

Production systems fail underneath abstractions. Senior engineers are expected to understand what’s underneath.

This is usually the difference between a mid-level and a senior-level interview performance. Not the ability to build features — the ability to reason about why the framework behaves the way it does when something goes wrong.

What Senior Interviewers Are Actually Looking For

The questions above surface whether you can:

  • Explain framework internals without looking them up
  • Connect implementation choices to production consequences
  • Identify failure modes before they occur
  • Reason about design trade-offs rather than just applying defaults

Because eventually, someone has to understand the thing behind the annotation.

Want to Go Deeper Before Your Next Interview?

If you’re preparing for Spring Boot interviews at senior level, I found this free sample useful for structured coverage of these patterns:

👉 Grokking the Spring Boot Interview — Free Sample

It covers practical Spring Boot interview patterns, architecture discussions, and senior-level concepts beyond basic annotation usage.

Part of a series on Java development, system design, and production engineering. Earlier posts cover concurrency traps, Hibernate production behavior, JVM internals, and how to debug latency when everything looks healthy.

Most Spring Boot Developers Can’t Answer These Interview Questions. Can You? was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post first appeared on Read More

Related Posts