Top 9 Senior Interview Questions

IoC concept

The framework creates and manages object lifecycles. You declare what you need; the container provides it. DI is the mechanism — dependencies are injected rather than created by the class itself.

Three injection types

// 1. Constructor injection — PREFERRED
@Service
public class PaymentService {
    private final AccountRepository repo;   // final — immutable, testable
    private final FraudChecker fraud;

    public PaymentService(AccountRepository repo, FraudChecker fraud) {
        this.repo = repo;
        this.fraud = fraud;
    }
}

// 2. Setter injection — for optional dependencies only
@Autowired(required = false)
public void setMetricsCollector(MetricsCollector collector) { ... }

// 3. Field injection — avoid. Hides dependencies, can't use final, not testable without Spring
@Autowired private AccountRepository repo; // BAD

Why constructor injection wins

• Dependencies are explicit — visible in the constructor signature.
• Fields can be final → immutable bean, thread-safe.
• Circular dependency fails fast at startup, not at runtime.
• Unit tests don't need Spring: just new PaymentService(mockRepo, mockFraud).

Proxy mechanics

• Spring wraps the bean in a proxy (JDK Dynamic Proxy if interface exists, CGLIB otherwise).
• External call to @Transactional method → proxy intercepts → opens transaction → calls real method → commits or rolls back.
• this.method() inside the same class bypasses the proxy entirely — no transaction.

Pitfall 1 — self-invocation

@Service
public class OrderService {
    public void processBatch(List<Order> orders) {
        orders.forEach(this::processOne); // BUG: 'this' bypasses proxy!
    }

    @Transactional
    public void processOne(Order o) { ... }
}

// Fix: extract to a separate bean, OR inject self:
@Autowired private OrderService self;
orders.forEach(self::processOne); // goes through proxy

Pitfall 2 — checked exceptions don't roll back

@Transactional  // default: rollback on RuntimeException only
public void transfer() throws BusinessException {
    debit();
    credit();
    throw new BusinessException("limit exceeded"); // does NOT roll back!
}

// Fix:
@Transactional(rollbackFor = BusinessException.class)

Pitfall 3 — REQUIRES_NEW deadlock

@Transactional
public void outer() {
    repo.lockRow(id);  // holds DB lock
    inner();           // opens NEW connection — same row, deadlock!
}

@Transactional(propagation = REQUIRES_NEW)
public void inner() {
    repo.readRow(id);  // waits for lock held by outer → deadlock
}

REQUIRES_NEW suspends the outer transaction and borrows a new DB connection. Two connections from the same thread fighting for the same row = deadlock.

Read-only optimisation

@Transactional(readOnly = true)
public List<Account> getAccounts() { ... }
// Hibernate skips dirty checking, can route to read replica, skips flush.
// Real performance impact at scale — not just documentation.

Core concepts

• Aspect: module containing cross-cutting logic.
• Pointcut: expression that matches join points (which methods to intercept).
• Advice: the code to run — Before, After, Around, AfterReturning, AfterThrowing.
• Join point: specific execution point (method call in Spring AOP).

Spring AOP uses proxies (not bytecode weaving like AspectJ). This means it only intercepts Spring-managed bean method calls — not constructor calls, field access, or private methods.

Around advice example — execution time logging

@Aspect
@Component
public class PerformanceAspect {

    @Around("@annotation(Monitored)")
    public Object measure(ProceedingJoinPoint pjp) throws Throwable {
        long start = System.currentTimeMillis();
        try {
            return pjp.proceed();
        } finally {
            long elapsed = System.currentTimeMillis() - start;
            log.info("{} took {}ms", pjp.getSignature().getName(), elapsed);
        }
    }
}

Practical use cases

• Audit logging: log who called what with what parameters — without polluting service code.
• Security checks: @PreAuthorize in Spring Security is AOP under the hood.
• Performance monitoring: method-level latency tracking for SLAs.
• Retry logic: @Retryable from Spring Retry is AOP.
• Caching: @Cacheable is AOP — intercepts, checks cache, calls method only on miss.

The startup sequence

1. @SpringBootApplication = @Configuration + @EnableAutoConfiguration + @ComponentScan.
2. @EnableAutoConfiguration imports AutoConfigurationImportSelector.
3. Selector reads META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports (Boot 3+) — a list of hundreds of auto-config classes.
4. Each class is evaluated with @Conditional annotations — only matching ones are loaded.

Conditional annotations

@AutoConfiguration
@ConditionalOnClass(DataSource.class)            // JDBC on classpath?
@ConditionalOnProperty("spring.datasource.url")  // URL configured?
public class DataSourceAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean  // user didn't define their own DataSource?
    public DataSource dataSource(DataSourceProperties props) {
        return new HikariDataSource(...);
    }
}

• @ConditionalOnMissingBean: your bean overrides the default. Auto-configs run after user @Configuration classes, so your beans are already registered when evaluated.
• @ConditionalOnClass: add a dependency to your POM → behaviour changes automatically.

How to debug auto-configuration

# Run with --debug flag to see what matched and what didn't:
java -jar app.jar --debug

# Or check the conditions report via Actuator:
GET /actuator/conditions

Excluding an auto-config

@SpringBootApplication(exclude = { DataSourceAutoConfiguration.class })
// Or in properties:
spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration

Lifecycle order

Constructor
  → @Autowired dependencies injected
  → @PostConstruct
  → InitializingBean.afterPropertiesSet()
  → @Bean(initMethod)
  → ApplicationReadyEvent / ApplicationRunner
  ─── SERVING TRAFFIC ───
  → @PreDestroy
  → DisposableBean.destroy()
  → @Bean(destroyMethod)

@PostConstruct use cases

@PostConstruct
public void init() {
    // Validate required config (fail fast before serving traffic)
    if (props.getApiKey().isBlank()) throw new IllegalStateException("API key required");

    // Warm up caches on startup
    cache.load(configRepo.findAll());
}

@PreDestroy use cases

@PreDestroy
public void shutdown() {
    // Flush in-flight Kafka messages before JVM exits
    producer.flush();
    producer.close();

    // Drain in-progress jobs
    executor.shutdown();
    executor.awaitTermination(30, TimeUnit.SECONDS);
}

SmartInitializingSingleton — the senior-level hook

@PostConstruct runs per-bean, as soon as that bean's dependencies are injected. But sometimes you need to run logic after all singleton beans are fully initialized — for example, registering beans that need to discover each other, or validating cross-bean configuration.

The correct hook is SmartInitializingSingleton.afterSingletonsInstantiated() — Spring calls it on every bean that implements the interface, after all singleton beans have been created and all @PostConstruct methods have run:

@Component
public class StrategyRegistry implements SmartInitializingSingleton {

    @Autowired
    private List<PaymentStrategy> strategies;  // all strategy beans injected

    @Override
    public void afterSingletonsInstantiated() {
        // Safe to iterate — all beans fully initialized by here
        strategies.forEach(s -> log.info("Registered: {}", s.getClass().getSimpleName()));
        // Validate that at least one strategy is available
        if (strategies.isEmpty()) throw new IllegalStateException("No payment strategies registered");
    }
}

The trap: doing this in @PostConstruct fails because the injected List<PaymentStrategy> may not be fully populated yet — some strategy beans may not have been created when this bean's @PostConstruct fires. SmartInitializingSingleton is the correct answer because Spring guarantees all singletons exist before calling it.

Bean scopes

Filter chain

Spring Security is a chain of Filters, registered as a DelegatingFilterProxy. Every HTTP request passes through the chain in order.

Modern SecurityFilterChain config

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    return http
        .csrf(csrf -> csrf.disable())           // stateless API — no CSRF needed
        .sessionManagement(s -> s.sessionCreationPolicy(STATELESS))
        .authorizeHttpRequests(auth -> auth
            .requestMatchers("/api/public/**").permitAll()
            .requestMatchers("/api/admin/**").hasRole("ADMIN")
            .anyRequest().authenticated()
        )
        .oauth2ResourceServer(o -> o.jwt(Customizer.withDefaults()))
        .build();
}

JWT flow

1. Client sends Authorization: Bearer <token>.
2. BearerTokenAuthenticationFilter extracts the token.
3. JwtDecoder validates signature + expiry.
4. Claims mapped to Authentication object → stored in SecurityContextHolder.
5. Downstream code uses @PreAuthorize("hasRole('ADMIN')") or SecurityContextHolder.getContext().getAuthentication().

@Value — one property at a time

@Value("${payment.gateway.url}")     private String url;
@Value("${payment.gateway.timeout:5000}") private int timeout; // with default

@ConfigurationProperties — typed, grouped, validated

@ConfigurationProperties(prefix = "payment.gateway")
@Validated
public class GatewayProperties {
    @NotBlank private String url;
    @Min(100) private int timeout = 5000;
    @Min(1)   private int retries = 3;
    private Map<String, String> headers = new HashMap<>();
}

Comparison

Property resolution priority

1. Command line args       --server.port=9090
2. OS env vars             SERVER_PORT=9090
3. application-{profile}.yml
4. application.yml
→ Secrets go in env vars / Vault, never in yml files committed to git.

Graceful shutdown

# application.yml
server:
  shutdown: graceful                      # stop accepting new requests
spring:
  lifecycle:
    timeout-per-shutdown-phase: 30s       # max wait for in-flight

On SIGTERM: Spring stops accepting new requests, waits for in-flight requests to complete (up to timeout), then shuts down. For Kafka consumers, implement SmartLifecycle to stop consuming before the timeout.

Health probes for Kubernetes

# application.yml
management:
  endpoint:
    health:
      probes:
        enabled: true       # enables /actuator/health/liveness and /readiness
  health:
    livenessState:
      enabled: true
    readinessState:
      enabled: true

• Liveness /actuator/health/liveness: "Is the process alive?" Fail → Kubernetes restarts the pod.
• Readiness /actuator/health/readiness: "Can it serve traffic?" Fail → removed from load balancer (used during startup and graceful shutdown).

Custom health indicator

@Component
public class KafkaHealthIndicator implements HealthIndicator {
    @Override
    public Health health() {
        try {
            kafkaAdmin.describeCluster();
            return Health.up().withDetail("broker", "reachable").build();
        } catch (Exception e) {
            return Health.down().withDetail("error", e.getMessage()).build();
        }
    }
}

@HttpExchange — declarative HTTP clients (no Feign needed)

Spring Boot 3.0 introduced @HttpExchange, a native alternative to OpenFeign. You define an interface with HTTP annotations; Spring generates the implementation backed by RestClient or WebClient.

// 1. Define the HTTP interface
@HttpExchange(url = "/users", accept = "application/json")
public interface UserServiceClient {

    @GetExchange("/{id}")
    UserDto getUser(@PathVariable Long id);

    @PostExchange
    UserDto createUser(@RequestBody CreateUserRequest request);

    @DeleteExchange("/{id}")
    void deleteUser(@PathVariable Long id);
}

// 2. Register the client as a bean
@Bean
public UserServiceClient userServiceClient() {
    RestClient restClient = RestClient.builder()
        .baseUrl("https://user-service.internal")
        .build();
    RestClientAdapter adapter = RestClientAdapter.create(restClient);
    HttpServiceProxyFactory factory = HttpServiceProxyFactory
        .builderFor(adapter).build();
    return factory.createClient(UserServiceClient.class);
}

// 3. Inject and use — looks identical to Feign
@Service
public class OrderService {
    private final UserServiceClient userClient;

    public Order placeOrder(Long userId, OrderRequest req) {
        UserDto user = userClient.getUser(userId);  // blocking, works with virtual threads
        // ...
    }
}

ProblemDetail — RFC 9457 standardized error responses

Before Spring Boot 3, every team invented their own error response JSON shape. Spring Boot 3 implements RFC 9457 (Problem Details for HTTP APIs) via ProblemDetail — a standard JSON structure that API consumers can rely on.

// Enable RFC 9457 problem detail format globally
spring.mvc.problemdetails.enabled=true  # Spring Boot 3.x

// Spring now returns this JSON for 4xx/5xx by default:
// {
//   "type": "about:blank",
//   "title": "Bad Request",
//   "status": 400,
//   "detail": "Failed to read request",
//   "instance": "/api/orders"
// }

// Custom exception → ProblemDetail in @ControllerAdvice
@ExceptionHandler(OrderNotFoundException.class)
public ProblemDetail handleOrderNotFound(OrderNotFoundException ex) {
    ProblemDetail problem = ProblemDetail
        .forStatusAndDetail(HttpStatus.NOT_FOUND, ex.getMessage());
    problem.setTitle("Order Not Found");
    problem.setType(URI.create("https://api.example.com/errors/order-not-found"));
    problem.setProperty("orderId", ex.getOrderId());  // custom extension fields
    return problem;
}

// Produces:
// {
//   "type": "https://api.example.com/errors/order-not-found",
//   "title": "Order Not Found",
//   "status": 404,
//   "detail": "No order with id 42",
//   "instance": "/api/orders/42",
//   "orderId": 42
// }

Virtual thread configuration — one property

# application.yml — enable virtual threads for Tomcat + async tasks
spring:
  threads:
    virtual:
      enabled: true   # Spring Boot 3.2+ — configures Tomcat + @Async executor

# What this does:
# - Tomcat uses virtual threads per request (replaces thread pool)
# - @Async methods run on virtual threads
# - Spring Security and @Transactional context propagation work correctly
# - No code changes needed — drop-in replacement

Before this property existed (Spring Boot 3.0–3.1), you needed a manual TomcatProtocolHandlerCustomizer bean. Spring Boot 3.2 made it a single config property.

Migration: javax.* → jakarta.* (the biggest Boot 3 pain point)

Spring Boot 3 requires Jakarta EE 9+. Every javax.* import becomes jakarta.*. This is a mechanical rename but touches hundreds of files in a real project.

// Spring Boot 2.x
import javax.persistence.Entity;
import javax.validation.constraints.NotNull;
import javax.servlet.http.HttpServletRequest;

// Spring Boot 3.x
import jakarta.persistence.Entity;
import jakarta.validation.constraints.NotNull;
import jakarta.servlet.http.HttpServletRequest;

// Migration tool: OpenRewrite recipe handles 90% automatically
// ./mvnw rewrite:run -Drewrite.recipeArtifactCoordinates=... \
//   -Drewrite.activeRecipes=org.openrewrite.java.spring.boot3.UpgradeSpringBoot_3_2