Spring Boot Interview Questions for 2 Years Experience

Two years into Spring Boot, interviewers stop asking what annotations mean and start asking how the framework behaves in the code you ship. This set covers the questions a 2-year developer actually gets — dependency injection, auto-configuration, REST endpoints, validation, exception handling and basic JPA — each with a spoken answer, code, and the follow-up trap.

Why interviewers ask experience-based questions at 2 years

At two years you are past the trainee stage, so the interviewer's real question is whether you understood the projects you worked on or just filled in the templates around you. Spring Boot hides a lot of machinery, and they want to know if you looked under the hood.

That is why the questions look ordinary. Anyone can add @Autowired; far fewer can explain why constructor injection is preferred, or what auto-configuration actually did when they added a starter. The depth of your "why" is the filter.

Expect three themes: the container (IoC, DI, beans), the web layer (REST controllers, validation, exception handling), and data access (Spring Data JPA). If the core feels thin, review dependency injection in Spring before rehearsing these answers.

How to answer at 2 years

Answer in three beats: a one-line definition, how it works in Spring specifically, and one thing you did with it in a real project. The project detail is what separates you from a fresher reciting docs.

Write code when you can — a five-line controller or repository interface earns more trust than a paragraph. And rehearse out loud: a 2-year interview is a speaking test as much as a knowledge test, and hesitation on your own stack reads as inflated experience.

Q1. What is dependency injection and why does Spring use it?

Dependency injection means an object receives its collaborators from outside instead of creating them. Spring's IoC container builds objects and injects their dependencies, so your classes stay loosely coupled and easy to test.

Without DI, a service that news its own repository is welded to a concrete class and impossible to mock. With DI you depend on an interface and Spring supplies the implementation.

@Service
public class OrderService {
    private final OrderRepository repo;
    public OrderService(OrderRepository repo) { // constructor injection
        this.repo = repo;
    }
}

Constructor injection makes the dependency mandatory and the field final, which is why it is preferred over field injection.

Interview note: Follow-up: "why prefer constructor over field injection?" It makes dependencies explicit, allows final fields, and lets you construct the object in a unit test without Spring.

Q2. What is the difference between Spring and Spring Boot?

Spring is the core framework providing IoC, DI and modules like MVC and Data. Spring Boot sits on top and removes boilerplate with auto-configuration, starter dependencies, an embedded server and sensible defaults, so you can run an app with almost no XML or manual setup.

The one-line version: Spring gives you the building blocks; Spring Boot wires them together with opinionated defaults so you skip the manual configuration.

Interview note: Trap: "does Spring Boot replace Spring?" No — it uses Spring underneath; it configures Spring for you.

Q3. How does auto-configuration work?

Auto-configuration inspects the classpath, existing beans and properties, then creates beans conditionally. Adding a starter puts libraries on the classpath, and @EnableAutoConfiguration triggers configuration classes that run only when their conditions are met.

For example, adding spring-boot-starter-web puts Tomcat and Spring MVC on the classpath, so Boot auto-configures an embedded server and a DispatcherServlet. Add a datasource dependency and it configures a DataSource from your properties.

@SpringBootApplication // includes @EnableAutoConfiguration
public class App {
    public static void main(String[] args) {
        SpringApplication.run(App.class, args);
    }
}

Interview note: Follow-up: "how do you override an auto-configured bean?" Define your own bean of the same type — conditional configuration backs off when you provide one.

Q4. What are Spring Boot starters?

Starters are curated dependency bundles. Instead of listing individual libraries and matching versions, you add one starter like spring-boot-starter-web and it pulls in a compatible set for a whole capability.

They solve dependency management and version conflicts. spring-boot-starter-data-jpa brings Hibernate, the JPA API and Spring Data together at versions known to work.

Interview note: Trap: "what does a starter contain besides jars?" Mostly transitive dependencies plus the auto-configuration that activates when those jars are present.

Q5. How do you build a REST endpoint and return the right status code?

Annotate a class with @RestController, map methods with @GetMapping/@PostMapping, and return ResponseEntity to control the status code and body. Use 201 for creation, 200 for reads, 404 when not found.

@RestController
@RequestMapping("/api/orders")
public class OrderController {
    private final OrderService service;
    public OrderController(OrderService service) { this.service = service; }

    @PostMapping
    public ResponseEntity<Order> create(@RequestBody @Valid OrderDto dto) {
        Order saved = service.create(dto);
        return ResponseEntity.status(HttpStatus.CREATED).body(saved);
    }
}

Correct status codes are a common review comment, so knowing them signals real API work. The REST API in Spring Boot tutorial covers the full CRUD set.

Interview note: Follow-up: "what is the difference between @Controller and @RestController?" @RestController is @Controller plus @ResponseBody, so methods return data serialized to JSON instead of a view name.

Q6. How do you validate request data?

Put Bean Validation annotations like @NotNull, @Size and @Email on the DTO fields, then add @Valid to the controller parameter. Spring validates before your method runs and throws MethodArgumentNotValidException on failure.

public class OrderDto {
    @NotBlank private String product;
    @Min(1)   private int quantity;
    // getters/setters
}

You then translate that exception into a clean 400 response with field-level messages, usually in a global handler.

Interview note: Trap: "where does validation actually run — controller or service?" With @Valid on the controller parameter it runs before the controller body; you can also validate in the service with @Validated.

Q7. How do you handle exceptions globally?

Use a @RestControllerAdvice class with @ExceptionHandler methods. It centralizes error handling so every controller returns a consistent error body and status instead of leaking stack traces.

@RestControllerAdvice
public class ApiExceptionHandler {
    @ExceptionHandler(OrderNotFoundException.class)
    public ResponseEntity<String> notFound(OrderNotFoundException ex) {
        return ResponseEntity.status(HttpStatus.NOT_FOUND).body(ex.getMessage());
    }
}

This keeps controllers focused on the happy path. Dig deeper in the REST exception handling guide.

Interview note: Follow-up: "difference between @ControllerAdvice and @RestControllerAdvice?" The Rest variant adds @ResponseBody, so handlers return JSON directly.

Q8. What is Spring Data JPA and how do repositories work?

Spring Data JPA lets you define a repository interface extending JpaRepository, and Spring generates the implementation at runtime. You get CRUD methods for free and can declare derived queries just by naming methods.

public interface OrderRepository extends JpaRepository<Order, Long> {
    List<Order> findByStatus(String status);        // derived query
    @Query("SELECT o FROM Order o WHERE o.amount > ?1")
    List<Order> findExpensive(double amount);       // JPQL
}

Learn the mechanics in the Spring Data JPA tutorial.

Interview note: Trap: "how does Spring implement an interface with no code?" It creates a dynamic proxy at startup and parses the method names into queries.

Q9. What is the difference between @Component, @Service and @Repository?

All three are stereotypes that register a bean in the container. @Component is the generic one; @Service marks business logic; @Repository marks a data-access bean and adds exception translation from persistence exceptions to Spring's DataAccessException.

Functionally they behave the same for scanning, but the names document intent and @Repository gives you the exception translation bonus.

Interview note: Follow-up: "does @Service do anything special at runtime?" No extra behaviour beyond being a @Component; it is a semantic marker.

Q10. What is the default bean scope, and when do you change it?

The default scope is singleton — one shared instance per container. You change it to prototype for a new instance per request, or to request/session scopes in web apps when state must not be shared.

Most Spring beans are stateless services, so singleton is correct and efficient. Trouble comes when you put mutable state in a singleton and share it across threads.

Interview note: Trap: "is a singleton bean thread-safe?" Not automatically — the container creates one instance; you must keep it stateless or synchronize shared state.

Q11. How do application.properties and profiles work?

application.properties (or YAML) externalizes configuration like ports, datasource URLs and custom values. Profiles let you keep environment-specific files such as application-dev.properties, activated with spring.profiles.active.

server.port=8081
spring.datasource.url=jdbc:mysql://localhost:3306/shop

You inject values with @Value or bind a group with @ConfigurationProperties, keeping environment differences out of the code.

Interview note: Follow-up: "how do you switch config between dev and prod?" Activate a profile; Boot loads application-<profile>.properties on top of the base file.

Q12. How do you test a Spring Boot application?

Use @SpringBootTest for full-context integration tests and slice annotations like @WebMvcTest for the web layer or @DataJpaTest for repositories. For pure unit tests, construct the class with mocked dependencies and no Spring context at all.

Constructor injection pays off here: you can new OrderService(mockRepo) in a plain JUnit test. Slice tests keep the context small and fast.

Interview note: Trap: "why not use @SpringBootTest for everything?" It boots the whole context and is slow; slice tests load only what the layer needs.

How to prepare

Build one small end-to-end feature yourself: a controller, a validated DTO, a service, a JPA repository and a global exception handler. Being able to produce that flow live answers half the questions above at once.

Spend your prep roughly 40% on the container and REST layer, 30% on JPA, and 30% re-reading your own project so you can defend one design choice. Then rehearse against the 3-years experience set to see where the bar rises and to add depth on transactions and performance. The Java Full Stack with AI course teaches each of these layers with the same interview-first framing.