Spring Boot Interview Questions

Analogy categoryAnalogies

Core Concepts Interviewers Probe First

Most Spring Boot interviews open with foundational questions about auto-configuration and starters to gauge whether a candidate understands what Spring Boot actually does beyond 'it's Spring but easier.' Be ready to explain that @SpringBootApplication is a composite of @Configuration, @EnableAutoConfiguration, and @ComponentScan, and that auto-configuration works by inspecting the classpath and existing beans at startup — classes annotated @Conditional (like @ConditionalOnClass or @ConditionalOnMissingBean) in spring-boot-autoconfigure register beans only when their conditions are satisfied, which is why adding a dependency like spring-boot-starter-data-jpa 'just works' without manual DataSource wiring.

🏏

Cricket analogy: Auto-configuration is like a franchise's support staff automatically assembling the right training kit the moment they see a fast bowler on the squad list, without anyone filing a manual request.

Dependency Injection, Bean Scopes, and Lifecycle

Interviewers frequently ask candidates to compare constructor injection versus field injection, and the correct answer favors constructor injection: it makes dependencies explicit and final, enables immutability, fails fast at startup if a required bean is missing, and makes unit testing trivial without reflection-based mocking. Also expect questions on bean scopes — singleton (default, one instance per container), prototype (new instance per injection point), request/session (web-aware scopes) — and lifecycle callbacks like @PostConstruct/@PreDestroy or implementing InitializingBean/DisposableBean, which run after dependency injection completes and before the bean is destroyed respectively.

🏏

Cricket analogy: Constructor injection is like a player walking into the ground with all required gear (bat, pads, gloves) already in hand, versus field injection being handed items piecemeal mid-innings and hoping nothing's missing.

java

@Service
public class PaymentService {

    private final PaymentGatewayClient gatewayClient;

    // Constructor injection: immutable, testable, fails fast if bean is missing
    public PaymentService(PaymentGatewayClient gatewayClient) {
        this.gatewayClient = gatewayClient;
    }

    @PostConstruct
    void logStartup() {
        log.info("PaymentService ready with gateway: {}", gatewayClient.name());
    }
}

Common System-Design and Behavioral-Style Questions

Beyond syntax, interviewers test judgment with questions like 'how would you secure a REST API' (expect a discussion of Spring Security filter chains, JWT-based stateless auth via OncePerRequestFilter, and method-level @PreAuthorize), 'how do you handle a slow endpoint in production' (profiling with Micrometer/Actuator metrics, checking N+1 queries via Hibernate statistics, adding caching with @Cacheable), and 'how would you version a REST API' (URI versioning like /api/v1/orders, header versioning, or content negotiation). Strong candidates ground answers in Actuator endpoints they've actually used (/actuator/health, /actuator/metrics, /actuator/prometheus) rather than reciting theory, since interviewers probe follow-ups to distinguish memorized answers from real experience.

🏏

Cricket analogy: Diagnosing a slow endpoint is like a bowling coach reviewing a bowler's spell using ball-tracking data (Actuator metrics) to pinpoint exactly which delivery lost pace, rather than just guessing.

When asked to explain the difference between @Component, @Service, @Repository, and @Controller, the technically precise answer is that they are all @Component meta-annotations functionally equivalent for bean registration, but @Repository additionally enables Spring's persistence exception translation (wrapping JDBC/JPA exceptions into DataAccessException subclasses), and @Service/@Controller mainly communicate intent and enable role-specific tooling/AOP pointcuts.

A common interview trap is claiming @Transactional works on private methods or on self-invoked calls within the same class — it doesn't, because Spring's default proxy-based AOP can't intercept calls that don't go through the Spring-managed proxy, so a method calling another @Transactional method on this silently skips the transaction.

@SpringBootApplication combines @Configuration, @EnableAutoConfiguration, and @ComponentScan.
Auto-configuration uses @Conditional annotations to register beans based on classpath contents and existing beans.
Constructor injection is preferred over field injection for immutability, testability, and fail-fast startup validation.
Bean scopes include singleton (default), prototype, and web-aware request/session scopes.
@Repository enables persistence exception translation, distinguishing it functionally from @Service/@Controller.
@Transactional relies on proxy-based AOP and silently doesn't apply to private methods or same-class self-invocation.
Strong interview answers ground concepts in real Actuator/Micrometer observability experience, not just memorized theory.