Practice free

Spring Boot Interview Questions for Freshers (2026) — with Answers

Updated August 2026

Almost every Spring Boot question a fresher gets is really one of three questions wearing different clothes. Who creates my objects and wires them together, how does a HTTP request find my method, and how does a Java class end up as a row in a table. Annotations are the surface — the interviewer is checking whether you know what the framework is doing on your behalf, because a candidate who has only copied annotations from a tutorial cannot say what breaks when one is missing.

The mechanism underneath is worth holding as one picture. At startup Spring builds a container: it scans your packages, creates an object for each class it recognises as a component, and hands each one the collaborators it declared it needs. Auto-configuration then adds the plumbing you did not write — a web server, a JSON converter, a datasource — based on what it finds on the classpath, and backs off wherever you have configured something yourself. Everything else in this list is a detail of that story, which is why an interviewer who is satisfied with your answer on dependency injection often skips half the annotation questions.

One thing to prepare separately, because it decides more fresher interviews than any annotation: your own project. Spring Boot is the framework most freshers list and the one they are least able to defend, so expect the conversation to move from definitions to "show me where you used that" within a few minutes. Have one project you can walk through end to end — a request arriving, the layers it passes through, the query it produces — and prepare the Java underneath too, since interviewers who go one question deeper find out quickly which candidates learned annotations without learning the language.

Frequently asked questions

What is Spring Boot, and how is it different from Spring?

Spring is the underlying framework — the dependency injection container plus modules for web, data access, security and so on. Spring Boot is a layer on top of it that removes the setup work: it brings opinionated starter dependencies, auto-configures beans based on what is on the classpath, embeds a web server so the application runs as a plain Java process, and externalises settings into a single properties or YAML file. The distinction interviewers are listening for is that Boot adds no new programming model. The beans, the annotations and the container are all Spring; Boot decides sensible defaults so you write configuration only where you disagree with them. Saying "Spring Boot removes boilerplate configuration, not Spring itself" is a cleaner answer than listing features.

What is inversion of control and dependency injection?

Inversion of control means your classes no longer create the things they depend on — the framework creates them and supplies them. Dependency injection is the specific way Spring does it: you declare what a class needs, usually as constructor parameters, and the container passes in an object that satisfies it. The value is not that you type fewer `new` keywords. It is that a class states what it needs rather than deciding which implementation it gets, so the wiring can change without touching the class, and in tests you can pass a fake instead of the real database-backed one. If you can name that testing consequence unprompted, the answer lands as understanding rather than definition.

What does @SpringBootApplication actually do?

It is a convenience annotation that combines three things. @SpringBootConfiguration marks the class as a source of bean definitions, @EnableAutoConfiguration turns on Boot's automatic configuration, and @ComponentScan tells Spring to scan for components starting from this class's package. The third part has a practical consequence worth volunteering: scanning begins at the package containing this class and goes downwards, so a component in a sibling or parent package is never found and you get a "no qualifying bean" failure at startup. That is the single most common structural mistake in a fresher project, and knowing why it happens is more useful than reciting the three annotations.

How does auto-configuration work?

Boot ships a set of configuration classes and, at startup, considers each one against conditions. The conditions ask what is present — @ConditionalOnClass checks whether a class is on the classpath, @ConditionalOnMissingBean checks whether you have already defined that bean yourself, and there are conditions on properties and on the kind of application being started. So adding the web starter puts Tomcat and Spring MVC on the classpath, the matching auto-configuration sees them and configures an embedded server and a JSON converter. The important half is the back-off: because of @ConditionalOnMissingBean, defining a bean of your own makes Boot step aside rather than conflict. If you want to see what was decided and why, run with the `debug` property and read the auto-configuration report.

What is a starter dependency?

A starter is a dependency that pulls in a curated, version-compatible set of libraries for one job — spring-boot-starter-web for REST APIs, spring-boot-starter-data-jpa for database access, spring-boot-starter-test for testing. It contains almost no code of its own; its purpose is the dependency list and the versions. That matters because the parent POM or the Boot dependency management manages versions centrally, so you declare a starter without a version and get combinations that are known to work together. The problem it solves is the one nobody misses until they hit it: incompatible library versions that compile fine and fail at runtime.

Difference between @Component, @Service, @Repository and @Controller?

All four register the class as a bean, and @Service, @Repository and @Controller are specialisations of @Component. Functionally they are close to interchangeable, with two exceptions worth naming. @Repository adds exception translation, converting persistence-technology exceptions into Spring's DataAccessException hierarchy so your code does not depend on the underlying provider. @Controller is genuinely different because Spring MVC treats it as a source of request-handling methods. The honest framing is that @Service is mostly documentation — it tells the reader this class holds business logic — and that using the right one keeps the layers legible rather than changing behaviour.

Constructor injection or field injection — which should you use, and why?

Constructor injection, and this is a question where the reason matters more than the choice. A constructor makes dependencies explicit and lets you declare the fields final, so the object cannot exist in a half-wired state and you can instantiate it directly in a unit test with no framework involved. Field injection with @Autowired on the field hides the dependencies from anyone reading the constructor, cannot be final, and forces reflection or a Spring context to construct the object in a test. There is also a mechanical detail worth adding: since Spring 4.3 a class with a single constructor does not need @Autowired at all, which is why modern code has constructors with no annotation on them.

What is the default bean scope, and when would you change it?

Singleton — one instance per application context, shared by everyone who depends on it. Note that this means one per container, not one per JVM in the classic singleton-pattern sense. The consequence interviewers probe is thread safety: because a single controller or service instance serves concurrent requests, mutable instance fields on a bean are a bug, and stateless beans are the norm for that reason. Prototype scope creates a new instance per injection point, and web applications add request and session scopes. In practice a fresher project almost never needs anything but singleton, and saying so with the thread-safety reason is a stronger answer than listing every scope.

What is the difference between @Controller and @RestController?

@RestController is @Controller combined with @ResponseBody. In a plain @Controller, the String a method returns is treated as a view name to be rendered by a template engine; with @ResponseBody, the return value is serialised straight into the response body, which for an object means JSON. So @RestController is what you want for an API and @Controller for a server-rendered page application. The failure mode this explains is worth mentioning: a REST method on a plain @Controller without @ResponseBody returns a 404 or a template-resolution error, because Spring is trying to find a view with the name you returned.

How do you map a request, and what is the difference between @PathVariable, @RequestParam and @RequestBody?

@RequestMapping maps a path and method, and @GetMapping, @PostMapping, @PutMapping and @DeleteMapping are shorthands for the common ones. The three parameter annotations read from three different places. @PathVariable extracts a value from the URL path itself, as in /users/{id}, and suits identifying a resource. @RequestParam reads a query-string parameter such as ?page=2, and suits optional filtering, paging and sorting; it is required by default, so give it a default value or mark it optional if it may be absent. @RequestBody deserialises the JSON body into an object, which is what a POST or PUT carries. Pairing each with the case it is for — identity, filter, payload — reads better than defining them separately.

How do you return proper status codes from a REST API?

Return ResponseEntity when the status varies, since it lets you set status, headers and body together — 201 with a Location header after a create, 204 with no body after a delete, 200 with a body otherwise. For a fixed status, @ResponseStatus on the method or on an exception class is more concise. What the question is really testing is whether you know the codes are part of the API contract rather than decoration: 400 means the client sent something invalid, 401 that it is unauthenticated, 403 that it is authenticated but not allowed, 404 that the resource does not exist, and 500 that your server broke. A candidate whose API returns 200 with an error message inside the body gets asked about this specifically.

How do you handle exceptions globally?

With a class annotated @RestControllerAdvice containing @ExceptionHandler methods, each declaring the exception type it handles and returning a ResponseEntity with an appropriate status and an error body. The advice applies across controllers, so error formatting lives in one place instead of being repeated in every method. The reasoning to offer alongside it: without this, either you wrap every controller method in try-catch, or unhandled exceptions surface as a generic 500 with whatever default body Boot produces — which leaks internal detail and gives the client nothing actionable. Mapping your own exceptions to statuses, so a not-found exception becomes a 404, is the pattern interviewers expect to hear described.

How does request validation work?

Put constraint annotations on the fields of your request object — @NotNull, @NotBlank, @Size, @Email, @Min and so on — then annotate the controller parameter with @Valid, which asks Spring to validate before the method body runs. Add the validation starter, since it is not on the classpath by default in current versions. A failed validation raises MethodArgumentNotValidException, which you handle in your advice class to return a 400 with the field errors, otherwise the default response is not very usable. Two details that show you have actually done this: validation annotations live in the jakarta.validation package in Spring Boot 3, having moved from javax, and validating a request object is not a substitute for checking business rules in the service layer.

How is configuration externalised, and what are profiles?

Settings live in application.properties or application.yml rather than in code, and you read them either with @Value on a single field or by binding a group of related properties into a typed class with @ConfigurationProperties — the second being better once there is more than a handful, because it is type-safe and testable. Values can be overridden at runtime by environment variables or command-line arguments, which is how the same build runs in different environments. Profiles name those environments: application-dev.properties and application-prod.properties are loaded according to the active profile, and @Profile can include or exclude whole beans. The point to make explicitly is that secrets belong in environment variables, not committed in a properties file — interviewers do ask, and a repository with a database password in it is a bad look.

What does Spring Data JPA give you over writing JDBC?

You define an interface extending JpaRepository and Spring generates the implementation at runtime, so the standard save, find, delete and paging operations exist without you writing them. Beyond that you get derived query methods — a method named findByEmailAndStatus is parsed into a query from its name — and @Query for anything more complex, in JPQL or native SQL. Underneath sits JPA and usually Hibernate, mapping objects to tables. The trade worth naming so the answer is not one-sided: you write far less repetitive code, but you are now several layers away from the SQL that actually runs, which is exactly how performance problems like N+1 queries get written without anyone noticing.

How do you map an entity, and what are the common relationship annotations?

@Entity marks the class, @Table names the table when it differs from the class name, @Id marks the primary key and @GeneratedValue says the database or provider assigns it, and @Column customises a mapping. Relationships are @OneToMany, @ManyToOne, @OneToOne and @ManyToMany, with mappedBy on the non-owning side and @JoinColumn naming the foreign key. Two things that separate a real answer from a memorised one: the owning side is the one holding the foreign key and is what actually persists the relationship, and the default fetch types differ — to-one associations default to eager and to-many to lazy. Also worth saying that ddl-auto generating your schema is convenient in development and not something to point at a production database.

What is the N+1 query problem?

You load a list of N entities with one query, then touch a lazily-loaded association on each one inside a loop, and each touch fires its own query — N additional round trips for what should have been one or two. It is the classic JPA performance bug precisely because nothing in the code looks wrong; the queries are generated somewhere you are not reading. Fixes are a join fetch in a @Query, an @EntityGraph on the repository method, or a batch-size setting so the association loads in groups. The habit that catches it is the answer to give: turn on SQL logging in development and look at what actually executes, rather than assuming the mapping did what you meant.

What does @Transactional do?

It wraps the method in a database transaction — begun before the method runs, committed when it returns, rolled back if it throws. The details interviewers probe are the surprising ones. Rollback happens by default only for unchecked exceptions, so a checked exception commits unless you say otherwise. And the annotation works through a proxy, which means a call from one method to another inside the same class bypasses it entirely and the transaction never starts — the single most common reason "my @Transactional does nothing". Placing it on service methods rather than repositories is the usual convention, because a business operation that writes to two tables is the unit that needs to succeed or fail together.

How does a Spring Boot application run without deploying to a server?

The web starter brings an embedded server — Tomcat by default, with Jetty and Undertow as alternatives — and the application starts it itself, so the process is an ordinary Java program rather than something deployed into an external container. The build plugin repackages your jar into an executable one containing your classes and every dependency, which is why `java -jar` is enough to run it. This is worth understanding rather than memorising because it is the reason Boot applications suit containers and cloud deployment: one artifact, one process, port and settings supplied by the environment. If asked, you can still build a WAR for a traditional server, but it is no longer the default path.

How should a Spring Boot project be structured?

The conventional layering is controller, service, repository: controllers deal with HTTP and nothing else, services hold business logic and transaction boundaries, repositories talk to the database. Alongside that, use separate DTO classes for request and response rather than exposing entities directly — the reason being that an entity is your database shape, and returning it couples your API to your schema, leaks fields you did not mean to expose, and invites lazy-loading serialisation errors. Keep everything under the package containing your main class so component scanning finds it. Describing why each boundary exists, rather than naming the folders, is what the question is for.

How do you test a Spring Boot application?

At the narrowest level, plain unit tests with mocked collaborators and no Spring context at all — which constructor injection makes easy. Above that, slice tests load only part of the context: @WebMvcTest starts the web layer and gives you MockMvc to fire requests at a controller with the service mocked out, and @DataJpaTest starts JPA against an in-memory or test database. @SpringBootTest loads the full context and is the slowest, so it suits a few end-to-end checks rather than everything. Mocked beans are supplied with @MockBean, or @MockitoBean in recent versions where the older annotation is deprecated. Even a rough version of this answer is above the fresher average, because most projects arrive with no tests at all.

The interviewer says "walk me through your Spring Boot project". What are they actually asking?

They are asking you to trace one request end to end and to justify a few decisions along the way, so prepare it as a path rather than as a feature list: a request arrives at this endpoint, the controller validates and delegates, the service does this work inside a transaction, the repository runs roughly this query, and this shape comes back with this status code. Then expect the follow-ups, which are predictable — why that database, what happens when this input is invalid, where the transaction boundary sits, what you would change if the table had a million rows, what broke while you were building it. That last one is worth having a genuine answer to. A specific bug you diagnosed is more convincing than any architecture description, and it is the part a copied project cannot supply.

Is Spring Boot worth learning for 2027-batch placements?

For Java backend and full-stack roles it is the standard framework in Indian enterprise and service-company work, so a working project is one of the more legible things a fresher resume can carry — and much of that hiring is Java-flavoured, which makes it a reasonable bet. Sequence it sensibly, though. Mass recruiters filter first on aptitude, one language you can code confidently in, SQL and core CS, and those come before any framework. Get comfortable with Java and with SQL, then build something small in Boot that actually persists data and exposes an API, and understand the layers rather than the annotations. One project you can defend line by line is worth more in the interview than a list of technologies you have touched.

Don't just read Spring Boot questions — get asked them

Phiny's AI interviews you on exactly these topics, follows up on weak answers, and tells you what a stronger answer looks like. Text interviews are free and unlimited.

Start a free AI mock interview

How to prepare

Where these questions get asked

Related guides