TL;DR
- Prepare Spring Boot interview answers around observable behavior: how a bean is selected, why a request fails and what a deployment needs to stay healthy.
- Explain auto-configuration with a dependency and a condition, then describe how you would inspect the actual configuration rather than guessing.
- For experienced roles, practise duplicate requests, transaction boundaries and failing downstream services using one small order-service example.
- Use the questions below as original practice exercises. They are not a claim about any employer's private interview bank.
Start with an order service you can explain
Imagine an order API with a controller, an order service, a repository and a payment client. The API receives a customer ID and a basket, validates them, creates an order and requests payment. This small system supports a much stronger interview conversation than a list of annotations recited without context.
Draw the request path before naming framework features. Mark where authentication happens, where the customer is authorized to act, which operation writes data and which call can fail outside your process. Then explain one successful request and one interrupted request. Keep the scenario consistent when answering the questions below.
Use a practice repository with its Java and Spring Boot versions recorded. Import paths and defaults can differ between releases. If a question names a different version, say what you would verify in that version's documentation instead of presenting a remembered default as universal.
What does Spring Boot auto-configuration actually do?
Auto-configuration attempts to supply configuration based on dependencies and conditions in the application. A useful answer names the evidence that activates a configuration and the evidence that makes it back off. Spring's example is a database dependency with no user-defined connection bean; defining a suitable bean can replace the default arrangement. The conditions report helps explain which choices were made. See the official auto-configuration reference.
For the order service, suppose a new dependency causes startup to expect a database that the developer never intended to use. Your answer should be an investigation:
- Reproduce with the same dependency set and active configuration as the failing build.
- Read the first meaningful startup failure, including the dependent bean chain.
- Inspect the conditions report and identify the configuration that matched.
- Decide whether to supply the intended configuration, remove the accidental dependency or explicitly exclude an unwanted configuration.
- Add a startup check that captures the intended behavior.
Excluding configuration immediately may hide the cause. Explain why your chosen fix matches the application, not merely why it makes the error disappear.
How would you design dependency injection for testability?
Give the order service its dependencies through its constructor. A payment-client abstraction lets the service be exercised with a deterministic fake. Keep request parsing in the web boundary and business decisions in the service, so a business-rule test does not need an HTTP server just to reject an empty basket.
The follow-up question is more revealing: what if two payment-client implementations are registered? Explain how the application chooses one intentionally, and how a configuration test would detect ambiguity. A fake that is accidentally active in production is a configuration defect, even if the unit tests are green.
Do not claim that dependency injection automatically creates clean architecture. A constructor with twelve dependencies may expose a service that owns too many responsibilities. Discuss whether payment initiation, stock reservation and customer notification need separate responsibilities and where coordination belongs.
Which tests would you write first?
Choose tests by the uncertainty they remove. Here is an original order-service test plan:
| Concern | Test setup | Meaningful assertion |
|---|---|---|
| Empty basket | Service with fake dependencies | No order or payment is created |
| Unknown customer | HTTP request with a controlled identity | The agreed response is returned without disclosing another customer's data |
| Repository constraint | Real test database | Concurrent duplicate attempts cannot create two logical orders |
| Payment timeout | Stubbed delayed dependency | The order has an explicit recoverable state |
| Deployment configuration | Application startup in the target configuration | Required dependencies resolve and diagnostic endpoints follow the intended exposure policy |
Explain what each test cannot establish. A mocked repository does not prove a database constraint. A successful startup does not prove payment recovery. A test that only repeats the implementation's internal method calls is weaker than one that verifies the business outcome.
How do you handle transactions and remote calls?
Ask the interviewer which outcome must be atomic. Creating an order record and its related database rows may belong in one local transaction. A remote payment provider does not become part of that transaction just because the calling method is annotated.
In the practice design, assign the order a stable identifier, record its state and make payment initiation retryable using the provider's supported idempotency mechanism. After a timeout, investigate whether the payment happened before issuing a new logical payment. A durable work record can separate committing the order from performing a remote side effect.
This is a design proposal, not a universal requirement for every CRUD endpoint. Discuss the extra worker, reconciliation and operational complexity. A senior answer weighs those costs against the consequences of duplicate charges or lost work. The backend engineer interview questions include a comparable prompt on processing a payment idempotently with a request ID.
What changes when the service becomes a microservice?
Network boundaries add failure modes, not just deployment flexibility. If the stock service takes eight seconds to respond, the order service needs a timeout budget and a defined user-visible state. Repeated retries from several layers can multiply load precisely when the dependency is struggling.
Walk through a failure timeline: the stock reservation succeeds, its response is lost, the order service retries, and a second instance receives the retry. Explain which identifier makes the operation recognizable and which component owns recovery. Then explain what telemetry would distinguish slow stock requests from exhausted database connections.
For broader architectural practice, use the system-design preparation material alongside this concrete request trace. Practise explaining assumptions and tradeoffs before introducing queues or circuit breakers.
How would you expose health and diagnostics safely?
Spring Boot Actuator provides operational endpoints, but availability, exposure and authorization are separate decisions. The current reference distinguishes permitted endpoint access from HTTP or JMX exposure; only health is exposed by default. Review your version and custom security configuration before making more endpoints reachable. The Actuator endpoint documentation is the source for the exact settings.
In the order-service exercise, define what a load balancer should learn and what only an operator should inspect. A diagnostic response should not disclose credentials, customer data or internal configuration to anonymous visitors. Test the public route as an unauthenticated client instead of relying only on a configuration review.
Practise a complete answer in ten minutes
Spend two minutes drawing the order flow, three explaining one failure, three choosing tests and two answering a tradeoff question. Record the explanation. On replay, mark statements such as “Spring handles it” and replace them with the actual mechanism or the evidence you would inspect.
For an experience-based question, describe something you actually built. If you use this exercise instead, call it a practice project. The STAR storytelling guide can help structure a genuine incident without turning a hypothetical scenario into a claimed work achievement.
Frequently asked questions
Which Spring Boot interview questions matter for experienced developers?Prepare to explain production failures, data consistency, testing boundaries, dependency behavior and operating the application. Definitions still matter, but connect each one to a decision and a way to verify it.
Is Spring Boot the same as microservices?No. It can be used for a single application or one service in a distributed system. Microservice architecture adds decisions about ownership, communication, deployment and failure recovery.
Should I memorize every annotation?Know the annotations you use, then practise tracing their effect in an application. Being able to diagnose a surprising bean or request mapping is more useful than naming an annotation without explaining its scope.
Can AI help me prepare these answers?Use it to propose follow-up questions or challenge a practice design. Verify framework claims against the documentation and run the tests yourself. Follow the employer's rules for any assistance during an actual assessment.