Spring Boot interview questions — the ones that check understanding, not vocabulary

Spring Boot interviews have a specific failure mode: candidates who can name every annotation and explain none of them. "What does @Autowired do?" gets "it injects a dependency" every time — true, and not the answer that gets you hired, because the interviewer already knows what it does. They're checking whether you know what happens when it goes wrong.

Dependency injection — the question behind the question

What gets recited: Spring manages object creation and wires dependencies together, instead of your code doing new everywhere.

What actually gets tested: "Why is that better than just instantiating the object yourself?" The real answer is about testability and coupling — if OrderService constructs its own PaymentGateway internally, you can't swap in a mock during a unit test without touching production code. Inject it instead, and the test passes a fake implementation through the same constructor the real app uses. DI isn't a Spring feature you memorise, it's what makes the rest of the testing story possible.

Bean scopes — where the story usually falls apart

Everyone can name singleton and prototype. Few can explain what actually breaks when you pick the wrong one.

A singleton bean is created once and shared across the whole application context — which is exactly the problem if that bean holds per-request mutable state. Put a HttpServletRequest-scoped value in a singleton @Service, and you've built a bug that surfaces under concurrent load, not in your local testing with one browser tab open. The interviewer isn't asking you to define singleton. They're checking whether you'd catch that bug before it ships.

@Component vs @Bean vs @Configuration — the annotation soup

This trio confuses people because all three "register something with Spring," and the distinction between them looks academic until you hit a case where it isn't.

@Component (and its specialisations, @Service, @Repository, @Controller) is for classes you own — Spring finds them through classpath scanning. @Bean inside a @Configuration class is for objects you don't own, or ones that need constructor logic Spring's auto-wiring can't express — a third-party RestTemplate with custom timeout settings, for instance. Getting this backwards produces the classic symptom: "why isn't my bean being picked up," when the real answer is "you annotated a class you don't control, which Spring can't scan."

The N+1 query question, in disguise

This rarely gets asked directly as "what is the N+1 problem" — it shows up as "why is this endpoint slow" with a JPA entity graph behind it. A @OneToMany relationship fetched lazily inside a loop fires one query per iteration instead of one query total. The strong answer names the fix before being asked for it: @EntityGraph, a JOIN FETCH in the query, or switching the fetch type — and explains why each one avoids the extra round trips, not just that it does.

Exception handling — @ExceptionHandler vs @ControllerAdvice

Candidates who've only worked on one small service often haven't needed @ControllerAdvice and don't know why it exists. The honest answer: @ExceptionHandler inside a single controller only catches exceptions from that controller. The moment you have more than one controller and want consistent error responses — same JSON shape, same status code mapping — you need a @ControllerAdvice class centralising that logic once instead of copy-pasting the handler into every controller.

Why the follow-up always lands on "what breaks"

None of these are trick questions. They're a fast way to tell whether a candidate has actually shipped something with Spring Boot, or has read the documentation and can recite it convincingly. The definitions are identical either way — the follow-up about what breaks is where that difference becomes visible.

---

If you want to practice Spring Boot and Java questions with real follow-ups instead of a static list, try role-specific mock interviews for Java/Backend — free to start.