Spring Boot 3 Interview Questions for Experienced Developers (2026 Edition)

Picture this: you’ve cleared the HR screen, you’re sitting in front of a senior architect at EPAM or a staff engineer at a well-funded startup, and they open with, “Tell me what actually changed when you migrated from Spring Boot 2 to Boot 3.” If your answer is “Jakarta namespace changes,” you’ve given them the textbook answer — and they’ll immediately go three levels deeper. That’s exactly where most experienced candidates stumble.

⏱️ 9 min read | 📚 Updated June 2026

This guide is for Java developers with 4+ years of experience preparing for companies like TCS Digital, Infosys Specialist Programmer, Wipro Elite, EPAM Systems, or product startups in 2026. You already know the basics. What you need is to understand why Spring Boot 3 is architecturally different, what interviewers are actually probing, and how to handle the follow-up questions confidently.

By the end, you’ll be able to explain native image tradeoffs, GraalVM observability limitations, the implications of Jakarta EE 9’s namespace shift, and when to use Java Records in high-volume data pipelines — all with enough depth to satisfy a skeptical interviewer.

Table of Contents

• What Experienced Interviewers Actually Test
• How the Interview Rounds Look
• Core Spring Boot 3 Concepts You Must Know Cold
• Native Image, GraalVM, and Observability
• Jakarta EE 9 Migration and Java Records in High-Volume APIs
• Common Wrong Answers and How to Fix Them
• Realistic 2-Week Prep Plan
• Frequently Asked Questions

What Experienced Interviewers Actually Test

At service companies like TCS and Infosys, the bar for “experienced” rounds is understanding production migration pain. They want to know if you’ve actually dealt with broken third-party libraries after a Spring Boot 3 upgrade, not just read about it. At EPAM and startups, expect deeper architecture discussions — “Why would you compile to a native image?” and “What do you lose when you do?”

The underlying thing every interviewer is checking: do you understand consequences? Anyone can list features. Experienced engineers talk about tradeoffs. When they ask about Spring Boot 3’s auto-configuration changes, they’re really asking whether you’d catch a broken spring.factories entry in code review.

Pro-tip: Before your interview, actually run ./mvnw spring-boot:build-image on a small project and examine what breaks. Hands-on pain is more convincing than memorized answers, and interviewers can tell the difference in 30 seconds.

How the Interview Rounds Look

Round	Duration	Topics Covered	Difficulty
Technical Screen (Phone/Video)	30–45 min	Spring Boot 3 basics, Java 17/21 features, REST design	Medium
Deep Technical (Architect)	60–90 min	Native image, observability, Jakarta migration, performance	Hard
System Design	60 min	Microservices, distributed tracing, resilience patterns	Hard
Coding Round	45–60 min	Live coding: REST endpoint with Records, exception handling	Medium–Hard
HR / Cultural Fit	30 min	Salary, notice period, scenario-based behavioural	Low

Core Spring Boot 3 Concepts You Must Know Cold

Auto-Configuration: The @AutoConfiguration Change

Spring Boot 3 deprecated spring.factories for auto-configuration registration. You now use META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports. This is not a trivial rename — it affects every custom starter your team has written.

// Spring Boot 3: correct registration file path
// META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

// One fully-qualified class name per line:
com.example.mylib.config.MyServiceAutoConfiguration

The old spring.factories key org.springframework.boot.autoconfigure.EnableAutoConfiguration is silently ignored in Boot 3. If you migrate a multi-module project and forget to update a shared library, features vanish with no error. That silent failure is exactly what interviewers probe — “How would you debug a bean that was auto-configured in Boot 2 but isn’t present in Boot 3?”

Spring Security 6: SecurityFilterChain is Mandatory

The old WebSecurityConfigurerAdapter is gone. You configure security by exposing a SecurityFilterChain bean. This confuses many mid-level developers who have been copying old config boilerplate for years.

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/api/public/**").permitAll()
                .anyRequest().authenticated()
            )
            .oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults()));
        return http.build();
    }
}

The follow-up they’ll ask: “What’s the difference between requestMatchers and the old antMatchers?” Answer: requestMatchers automatically selects the most appropriate matcher based on whether Spring MVC is present — safer and more accurate in mixed servlet/reactive environments.

Native Image, GraalVM, and Observability

This is where experienced candidates separate themselves. Spring Boot 3 added first-class support for GraalVM native images via the spring-boot-starter-native dependency and @NativeHint (now largely replaced by reachability metadata). The pitch is compelling: startup in milliseconds, tiny memory footprint — perfect for AWS Lambda or Kubernetes sidecars.

But here’s what interviewers want to hear you say: native images have real production costs. Build time balloons from seconds to 5–15 minutes. Dynamic class loading, reflection, and JNI require explicit configuration. And observability gets genuinely harder.

With a JVM app, you can attach a Java agent like the OpenTelemetry JAVAAGENT at runtime — zero code change. With a native image, agents don’t attach. You must instrument at build time using Micrometer’s native image support and the @Observed annotation introduced in Spring Boot 3 / Micrometer 1.10.

// Spring Boot 3 + Micrometer Observation API
@Service
public class OrderService {

    private final ObservationRegistry registry;

    public OrderService(ObservationRegistry registry) {
        this.registry = registry;
    }

    public Order processOrder(String orderId) {
        // Creates a span compatible with native image — no agent needed
        return Observation.createNotStarted("order.process", registry)
                .lowCardinalityKeyValue("region", "IN")
                .observe(() -> findAndProcess(orderId));
    }
}

The key point: Observation in Micrometer 1.10+ is the bridge between metrics AND tracing in one call. It works in native images because it’s compile-time instrumentation, not runtime bytecode manipulation. When an interviewer at a startup asks about native image observability, this is the answer they’re looking for — not “we use Prometheus.”

Pro-tip: GraalVM native image compilation fails silently on missing reflection config more often than it throws an obvious error. Always run your native image test suite in CI, not just the JVM test suite. Mention this in interviews — it signals production experience.

Jakarta EE 9 Migration and Java Records in High-Volume APIs

The javax → jakarta Namespace Shift

Spring Boot 3 requires Jakarta EE 9+ APIs, which means every javax.* import is now jakarta.*. javax.persistence.* → jakarta.persistence.*, javax.servlet.* → jakarta.servlet.*, and so on. This sounds trivial until you realize it breaks every third-party library that hasn’t updated — older versions of Hibernate Validator, MapStruct configs, and legacy SOAP stacks.

The migration tool spring-boot-migrator and OpenRewrite’s UpgradeSpringBoot_3_0 recipe handle most of this automatically. Mentioning OpenRewrite in an interview immediately signals that you’ve done a real migration, not just a toy project.

Java Records as DTOs in High-Volume Scenarios

Spring Boot 3 works beautifully with Java Records (stable since Java 16, commonly used with Java 17/21 baselines). In high-volume REST APIs processing thousands of requests per second, Records offer immutability, no-boilerplate DTOs, and slightly better JIT performance because the JVM can reason about immutable data more aggressively.

// Immutable DTO using Java Record — works with Jackson in Spring Boot 3
// Jackson 2.12+ supports Records natively; no extra annotation needed
public record OrderRequest(
    @NotBlank String customerId,
    @Positive BigDecimal amount,
    @NotNull String currency
) {}

// Controller — clean, no getters, no @Data boilerplate
@PostMapping("/orders")
public ResponseEntity create(
        @Valid @RequestBody OrderRequest request) {
    return ResponseEntity.ok(orderService.process(request));
}

The follow-up interviewers ask here is sharp: “Can you use Records with JPA entities?” The correct answer is no, not directly — JPA requires a no-arg constructor and mutable state for lazy loading. Records are final and have no no-arg constructor. Use Records for DTOs and response objects, keep @Entity classes as regular classes. Getting this wrong is a common mistake that signals someone read about Records but hasn’t used them in production.

Common Wrong Answers and How to Fix Them

Wrong: “Spring Boot 3 is just a rename from javax to jakarta.”
Fix: It’s a minimum Java 17 baseline, a new auto-configuration loading mechanism, Spring Security 6 with mandatory SecurityFilterChain, native image first-class support, and the unified Micrometer Observation API. The namespace change is one part of a broader modernization.

Wrong: “I’d use @SpringBootTest for all my tests.”
Fix: @SpringBootTest loads the entire context — expensive and slow. Use @WebMvcTest for controller slices, @DataJpaTest for repository layers, and @SpringBootTest only for integration tests. In a high-volume CI pipeline this distinction saves minutes per build.

Wrong: Using @Autowired field injection in new Boot 3 code.
Fix: Constructor injection is the Spring team’s recommendation and the standard in Boot 3 examples. It makes dependencies explicit, works with final fields, and plays nicely with Records-based design patterns. Field injection also makes unit testing harder without a Spring context.

Realistic 2-Week Prep Plan

Days 1–3: Set up a Spring Boot 3.3+ project (Java 21, GraalVM 21). Migrate one of your old Boot 2 projects using OpenRewrite. Feel the pain firsthand.

Days 4–6: Build a small REST API using Records as DTOs, Spring Security 6 with JWT, and @Observed for tracing. Wire it to a local Grafana/Tempo stack.

Days 7–9: Compile the same project to a native image. Document what breaks. Fix it. This exercise alone gives you material for 20 minutes of interview conversation.

Days 10–14: Review Spring Boot official native image documentation, study the Spring AOT processing reference, and do 5–6 LeetCode medium problems to warm up the coding round. Check our Java advanced topics guide for Java 21 virtual threads, which often come up in the same interview.

Also bookmark the Spring Boot Actuator documentation — Actuator endpoints, health groups, and custom metrics are almost always asked in experienced rounds. For foundational Java concepts that underpin Boot internals, our Java basics section has solid coverage of generics and reflection, both of which matter for understanding AOT compilation limits.

Frequently Asked Questions

Is Spring Boot 3 mandatory knowledge for experienced Java roles in 2026?

For roles at product companies and EPAM-style consultancies, yes — Boot 3 with Java 17/21 is the baseline expectation. TCS and Infosys still maintain large Boot 2 codebases, but they’ll ask about migration experience even if the live project hasn’t upgraded yet. Knowing Boot 3 well and explaining migration tradeoffs makes you stand out over candidates who know only Boot 2.

What Java version should I use to prepare for Spring Boot 3 interviews?

Use Java 21. Spring Boot 3.2+ officially supports Java 21, and virtual threads (Project Loom) are a frequent follow-up topic in architecture rounds. Java 17 is the minimum baseline but interviewers at product companies increasingly expect Java 21 familiarity in 2026.

How deep should I know GraalVM native images for an interview?

Deep enough to explain the tradeoffs honestly: fast startup and low memory vs. longer build times, no runtime reflection by default, and observability limitations with Java agents. You don’t need to have shipped a native image to production, but you should have compiled one locally and know what the reachability metadata JSON files do.

What’s the most commonly asked Spring Boot 3 question in TCS and Infosys interviews?

The javax-to-jakarta migration is asked most frequently at service companies because they have real migration projects running. Pair that answer with mentioning OpenRewrite automation and one production gotcha (like Hibernate Validator or an old Spring Security version blocking the upgrade) and you’ll sound credible.

Can I use Java Records with Spring Data JPA?

Not as entity classes — JPA requires a no-arg constructor, mutable fields, and non-final classes, none of which Records provide. You can absolutely use Records as projections with Spring Data’s interface-based or class-based projection queries, and as DTOs in the service/controller layer. This distinction is a common interview trap.

What is the Micrometer Observation API and why does it matter in Boot 3?

It’s a unified abstraction introduced in Micrometer 1.10 that generates both metrics and distributed trace spans from a single instrumentation point. It’s the preferred observability approach in Spring Boot 3 because it works in native images (unlike runtime Java agents) and avoids the split between Micrometer metrics and Spring Cloud Sleuth tracing that existed in Boot 2.