What are the most asked Spring Boot interview questions for freshers?

What are the most asked Spring Boot interview questions for freshers?

Spring Boot fresher rounds assume you already know core Java, then they ask how an application starts, how a controller receives a request, and how a dependency is injected instead of being constructed with new everywhere. The questions that decide the round are practical: what @SpringBootApplication does, why constructor injection is preferred, how a repository talks to a database, and where configuration lives. Definitions of “inversion of control” matter only if you can point at them in your own project.

Use the Java interview questions page for equals, collections, and exceptions. Use this page when the panel says controller, bean, JPA, or application.properties. The notes are a preparation guide, not a claim that every company asks the same sequence.

What is inversion of control, and what is dependency injection?

Inversion of control means your class does not go and build every collaborator it needs. A container supplies them. Dependency injection is the usual way that happens in Spring: the class declares what it needs, and Spring passes those objects in. The fresher picture is a service that needs a repository. You do not write new OrderRepository() inside the service. You accept an OrderRepository in the constructor. Tests can pass a fake. Production passes the real one. That is the whole point. If you cannot say why the new keyword inside the service makes testing harder, the definition is unfinished.

Spring calls the managed objects beans. A bean is an object whose lifecycle Spring controls: it creates it, injects dependencies, and usually keeps one shared instance, the singleton scope. Singleton here means one instance per application context, not one instance per Java virtual machine forever, and not the Gang-of-Four singleton you hand-write. Prototype scope creates a new bean when asked. Most fresher services stay singleton. Say that, and say you would not store a user’s request data in a field of a singleton, because the next request would see it. That bug is worth more than a list of scopes you have never used.

What does @SpringBootApplication actually switch on?

It is a convenience annotation on the main class. It marks the class as a configuration source, it turns on auto-configuration, and it scans the package of that class and the packages below it for components. Auto-configuration looks at what you put on the classpath. Add a web starter and you get a web server and a dispatcher. Add a JPA starter and a database driver and you get a data source setup you can override. The interview sentence is: “Boot picks sensible defaults from the starters I included, and I override the ones I care about in configuration.”

Component scan has a boundary. A class outside the main class’s package tree will not be found unless you tell Spring where to look. Freshers hit this when they create a new top-level package and the controller returns 404 because it was never registered. The fix is to put the code under the application package or to set the scan base. Mention that 404 story if it happened to you. It sounds like experience because it is a mistake you corrected.

What is a starter?

A starter is a dependency bundle that brings a feature and the libraries it usually needs. spring-boot-starter-web brings the MVC stack and an embedded server. spring-boot-starter-data-jpa brings JPA and Hibernate pieces. You declare the starter, not twenty individual libraries, and Boot manages compatible versions through its parent bill of materials. You should be able to name the starters in your project and one library you still had to add yourself, such as a database driver if it was not already pulled in.

Do not say “starter means the application starts.” The word is about dependencies. The application starts because main calls SpringApplication.run. That call builds the context, creates the beans, and, for a web starter, starts the embedded server. Tomcat is the usual embedded server. You can say you did not install a separate Tomcat for a fresher project. You ran the jar.

How does a request reach your method?

A controller class marked RestController is a component that returns data, usually JSON, rather than a view name. RequestMapping or a shortcut such as GetMapping ties a path and a verb to a method. A path variable comes from the URL. A request body comes from JSON and is converted into a Java object if the types match. A query parameter comes from the query string. Say which of the three your project used. Then say what you return: a response entity with a status, or a plain object that becomes 200. Validation annotations on the object, plus Valid on the parameter, reject a bad payload before your business code runs.

Controller and RestController differ because RestController includes the response-body behaviour. A Controller without that returns a view name for a server-rendered page. Most fresher APIs want RestController. If you mix them up, you will be confused when a method returns a string and the browser shows the string instead of a template, or the reverse. State the one you used.

The follow-up is status codes. 200 is a successful read. 201 is a create. 400 is a bad client payload. 404 is a missing resource. 500 is an unexpected failure on your side. Do not return 200 with an error message hidden in the JSON if you can return a proper status. Panels listen for that habit.

Why do interviewers prefer constructor injection?

Constructor injection makes the dependency required and visible. The object cannot be built without its repository. Fields can be final. Tests call the constructor with fakes and do not need the Spring container. Field injection with Autowired hides the dependency and makes a unit test reach for the container or for reflection. Setter injection is useful when a dependency is optional, which is rarer than tutorials suggest. Say you use the constructor, you omit Autowired when there is only one constructor, and you keep the class small enough that the constructor is not a list of fifteen services. A huge constructor is a design smell, not a victory for injection style.

Circular dependencies are the follow-up. Two beans that require each other in their constructors will not start. The fix is to extract a third type or to rethink which class owns the call, not to switch to field injection so the cycle is hidden until runtime. If you have seen the cycle, describe the two classes. If you have not, describe the principle. Do not invent a startup log you never read.

How does a repository fit?

A Spring Data repository is an interface you declare, often extending JpaRepository, with the entity type and the id type. Spring provides the implementation. Method names such as findByEmail become queries. You can write a query annotation when the name would be unclear. The entity is a class mapped to a table. The id is the primary key. You still need to know the SQL ideas underneath: a find that joins badly can return duplicates, and a null column still needs a decision in Java. Point the interviewer at your SQL answers if they ask why a list came back longer than expected.

Transactions belong on the service method that must succeed or fail as a unit, not on every controller. If you save an order and a payment row, both belong in one transaction. Say what should roll back if the second save fails. That answer links Java exceptions to the database. A runtime exception typically rolls the transaction back in Spring’s default setup. A checked exception may not, unless you configure it. You do not need the full matrix. You need to say you would check, and you would not assume a half-written order is acceptable.

Where does configuration live?

application.properties or application.yml holds settings such as the server port and the database URL. Profiles, such as dev and prod, let the same code read different settings. Secrets do not belong in the git repository. A fresher project often uses a local properties file that is gitignored, or environment variables. Say which you did. If the password was committed, say you would remove it and rotate it, not that it was fine because the repo was private. Panels treat that as a habit question.

Actuator is the extra worth naming if you added it. It exposes operational endpoints such as health. You do not turn every endpoint on in public. Health is the one a fresher can justify. If you never used Actuator, do not claim you monitor production with it. Say you would add a health check before a real deployment.

How do you handle errors in an API?

A ControllerAdvice class can catch exceptions thrown from controllers and turn them into a consistent JSON error and a status code. A missing entity becomes 404. A validation failure becomes 400 with the field messages. An unexpected exception becomes 500 with a message that does not leak the database password or a stack trace to the client. Log the detail on the server. Return a short, safe body to the caller.

Freshers who try-catch inside every method and return a string “error” make the client guess. Central handling keeps the controller thin. Show one handler if you wrote one. If you did not, write the shape on the board: exception type, status, body. The panel is checking whether you have a plan, not whether you memorised the annotation spelling on the first try. You can correct a slightly wrong annotation name. You cannot correct a design that swallows exceptions.

How do you walk through a Spring Boot project?

Start at main. Name the starters. Open one controller method. Follow it into a service and then a repository. Show the entity and the table. Show one validation. Show one error status. Then show a test or say how you called the endpoint, with a browser, curl, or a REST client. The bug to mention might be a package outside component scan, a circular dependency, a password in git, or a transaction that saved only one of two tables. Pick a real one.

If the project never had a database, do not pretend JPA. A controller that returns a list from memory can still demonstrate routing and injection if a service sits between the controller and the list. Say what you would replace first: the list becomes a repository. That honesty is stronger than a diagram of microservices you did not build.

Prepare the Java underneath, because the panel will drop into equals or a transaction question without warning. Prepare SQL if the repository is real. Asmorix students can build this stack in Java training in Pondicherry and rehearse the walk-through before placement day. The training does not memorise the panel’s script. It gives you a project small enough to explain and solid enough to change when they say “add a field.”

What to revise the day before

Run the application. Hit one successful path and one failing path. Read your own controller once and mark the verb, the path, and the status codes. Be able to say why the service is a constructor argument. Be able to point at the properties file and say what is not committed. If a question leaves Boot and enters the language, switch pages in your head and answer the Java question directly. Candidates who drag every answer back to “in Spring we use annotations” sound like they cannot program without the framework. The framework is a tool. The Java is the skill it sits on.

How should a fresher describe the layers in a small API?

A controller accepts the HTTP request and chooses a status. A service holds the rule, such as “an order with no lines is rejected.” A repository talks to the database. The controller should not build a query. The repository should not decide the HTTP status. This split is what interviewers mean when they ask about a layered design, even in a project with six classes. If your project put SQL in the controller, say that plainly and say you would move it. The panel has seen that project a hundred times. They are listening for whether you know why it gets painful: every new caller repeats the query, and a test cannot check the rule without starting the server.

DTOs are the extra term worth using correctly. An entity is the database shape. A request or response DTO is the shape you show the client. They are allowed to differ. You might store a password hash and never return it. You might accept a create request without an id. If you return the entity directly, say what you would hide before a real user saw it. That answer is more mature than adding a second framework.

What is a fair fresher answer about testing a Spring API?

A unit test calls the service with a fake repository and checks the rule. It does not need the web server. A slice test can start the web layer and mock the service, to check the path and the status. An end-to-end test boots the app and a test database. You do not need all three on day one. You do need one test that fails when the rule is broken. If you have never written one, the honest plan is a unit test on the service method you are proud of, using a fake that returns a fixed order. Mention JUnit as the runner and a mock library only if you have used it. Do not claim a coverage percentage you have not measured.

The interviewer may ask what you would not mock. You would not mock the thing you are testing. You would not mock a one-line calculation that is easier to call for real. Mock the boundary you do not own, such as the database or an external payment call. That sentence shows you understand why tests exist.

How do you talk about logs without pretending you run production?

Use a logger, not a trail of System.out.println, once the project is an API someone else will run. Log the decision and the id, not the password and not the full card number. A 500 handler should log the stack on the server. The client should get a short message. If your project still uses println, say you would switch the error path to a logger before you called it finished. Levels are simple: error for a failed request you did not expect, info for a startup line, debug for detail you do not want in production every day. You do not need a log-aggregation product in a fresher interview. You need to show you would not print a secret.

What to click through on the morning of a Spring Boot round

Start the application and watch the log until the server port appears. Hit one GET that returns data and one POST that fails validation. Open the controller, the service constructor, and the repository interface, in that order, so the path is in your head. Confirm the password is not in the committed properties file. If a test exists, run it. If it does not, do not pretend. This tour takes twenty minutes and it prevents the specific failure of describing a project that is not the project on your laptop.

When a question is only an annotation, answer with the behaviour. “RestController maps a path and writes the return value as the body.” Then give your path. Annotations without a path are flashcards. A path without the status codes is incomplete. Add the status you return on success and the status you return when the id is missing. Those two numbers make the answer sound like an API you actually called, which is the standard a fresher can meet without production experience.

What to click through on the morning of a Spring Boot round

Start the application and watch the log until the server port appears. Hit one GET that returns data and one POST that fails validation. Open the controller, the service constructor, and the repository interface, in that order, so the path is in your head. Confirm the password is not in the committed properties file. If a test exists, run it. If it does not, do not pretend. This tour takes twenty minutes and it prevents the specific failure of describing a project that is not the project on your laptop.

When a question is only an annotation, answer with the behaviour. “RestController maps a path and writes the return value as the body.” Then give your path. Annotations without a path are flashcards. A path without the status codes is incomplete. Add the status you return on success and the status you return when the id is missing. Those two numbers make the answer sound like an API you actually called, which is the standard a fresher can meet without production experience.

How you would extend the API after the interview

If the panel asks what you would change with another week, pick one layer you blurred. Move a query out of the controller, add a validation message, or write the unit test you described. Do not promise microservices, a message bus, and a discovery server. A fresher API becomes more convincing when one boundary gets cleaner, not when the diagram grows. Say the week out loud as a sequence: day one the test, day two the validation, day three a second endpoint that reuses the service. That sequence shows you can extend the project they just saw. Mention the status code the new endpoint returns, and say which existing service method it calls so they can see you are not copying the controller. A second endpoint that duplicates SQL is not an extension. It is a second copy of the same problem. Name the shared method.

Related reading: Java interview questions, SQL interview questions, React JS interview questions, Most common interview questions.

These answers are a preparation guide for students and freshers, including learners at Asmorix in Pondicherry. A company may ask a different follow-up. This page is not a leaked paper and it is not a promise of a result. Say the short answer, show one example, and revise the same day any question you could not code or click.