25 Spring Boot interview questions

Listen for: A strong answer starts with reproducing the request path using logs, metrics, traces, and realistic data volume, not guessing. They should mention checking database queries, connection pool saturation, downstream calls, serialization size, and JVM resource pressure. They should know how to use Actuator, Micrometer metrics, structured logs, and a profiler or APM when available.

Red flag: They immediately propose adding caching or rewriting the endpoint without first isolating the bottleneck.

Listen for: Look for separation by responsibility rather than rigid layering. Controllers should handle HTTP concerns and validation boundaries, services should express use cases and transaction scope, repositories should hide persistence details, and configuration should be explicit and environment-aware. They should avoid putting business logic in entities, controllers, or random utility classes.

Red flag: They say every project should follow the same package structure regardless of domain or complexity.

Listen for: They should distinguish unit tests from Spring integration tests. Good signals include using MockMvc or WebTestClient, Testcontainers for PostgreSQL or another real database, transaction-aware assertions, and verifying event publication through an abstraction. They should understand when mocks are useful and when they hide mapping, configuration, and persistence problems.

Red flag: They rely only on mocked repositories and consider that enough for database-writing behavior.

Listen for: Listen for reading the full startup exception, identifying the root cause rather than the top-level Spring wrapper, and checking bean names, profiles, conditional configuration, constructor dependencies, and configuration properties binding. They should know how to use the condition evaluation report and avoid solving circular dependencies with lazy injection by default.

Red flag: They suggest disabling auto-configuration or adding @Lazy without understanding the dependency graph.

Listen for: A good junior answer uses application.yml with profiles sparingly, environment variables or a secrets manager for sensitive values, and type-safe @ConfigurationProperties with validation. They should know not to commit secrets, should understand defaults versus required properties, and should mention documenting local setup through Docker Compose or similar tooling.

Red flag: They store production credentials in profile-specific files committed to the repository.

Listen for: They should review the API contract, validation, error responses, status codes, security annotations or authorization checks, transaction boundaries, persistence efficiency, and tests. Good candidates also check naming, logging without sensitive data, backward compatibility, and whether the implementation matches existing conventions without blindly copying bad patterns.

Red flag: They focus only on formatting and whether the endpoint returns the happy-path response.

Listen for: Strong candidates avoid keeping a database transaction open across a remote call. They discuss ordering, idempotency keys, outbox or saga patterns, compensation, and retry behavior. They should understand @Transactional propagation and isolation, but frame the answer around business consistency and failure modes rather than simply annotating a large method.

Red flag: They put @Transactional on the method and call the external API inside it without discussing partial failure.

Listen for: Listen for workload-based trade-offs. MVC with virtual threads on Java 21+ may be simpler for many blocking CRUD services. WebFlux can fit high-concurrency, non-blocking I/O when the whole stack is reactive. They should mention team familiarity, library compatibility, debugging complexity, backpressure, and avoiding mixed blocking calls in reactive pipelines.

Red flag: They claim WebFlux is always faster or more modern for every Spring Boot service.

Listen for: They should consider slow queries, missing indexes, transaction leaks, pool sizing versus database limits, thread pool behavior, N+1 queries, and long-running locks. Strong answers use Hikari metrics, database wait analysis, thread dumps, and request traces. They should resist blindly increasing the pool before understanding throughput and contention.

Red flag: They immediately increase maximumPoolSize because more connections must mean more capacity.

Listen for: A strong answer uses @ControllerAdvice or ProblemDetail support, stable error codes, clear validation errors, correlation IDs, and careful mapping of domain errors to HTTP statuses. They should distinguish client-safe messages from internal logs and discuss versioning or compatibility when existing clients depend on error shapes.

Red flag: They return raw exception messages to clients because it is easier to debug.

Listen for: They should ask about read/write patterns, data volatility, correctness requirements, invalidation strategy, key design, TTLs, cache stampede risk, serialization format, and observability. Good answers include measuring before and after, considering local versus distributed caches, and recognizing that caching can make stale data and incidents harder to reason about.

Red flag: They add @Cacheable everywhere and rely on long TTLs to solve performance issues.

Listen for: Look for Spring Security knowledge applied pragmatically: OAuth2/OIDC with authorization code plus PKCE for the SPA, JWT validation or token introspection for APIs, service-to-service authentication, method-level authorization, CORS configuration, CSRF considerations, and least-privilege scopes or claims. They should also discuss testing authorization paths.

Red flag: They disable CSRF and CORS globally and assume JWT presence means the user is authorized.

Listen for: They should mention Java version readiness, Jakarta namespace changes, dependency compatibility, Spring Security configuration updates, Hibernate changes, test updates, observability changes, and incremental CI validation. Good candidates plan a branch or sequence of PRs, use OpenRewrite where useful, and coordinate with deployment and rollback constraints.

Red flag: They treat it as only changing the parent version in pom.xml or the Gradle plugin.

Listen for: Strong answers discuss consumer contracts, additive changes, deprecation windows, schema evolution, versioning only when needed, contract tests, API documentation, and client communication. They should address both REST and event payloads, backward-compatible database changes, feature flags, and telemetry to know whether old fields or endpoints are still used.

Red flag: They introduce a new /v2 endpoint for every change without a compatibility strategy.

Listen for: Listen for OpenTelemetry, Micrometer, Actuator, structured JSON logs, trace and correlation IDs, RED or USE metrics, and service-level dashboards. They should standardize naming without hiding service-specific signals, protect sensitive data, and ensure alerts map to user impact rather than noisy JVM or host symptoms.

Red flag: They rely on log searching as the main production diagnostic strategy.

Listen for: They should start by characterizing conflict patterns with database logs, transaction traces, and workload analysis. Good answers include reducing transaction scope, consistent row access order, appropriate isolation, retry with limits for safe operations, aggregate redesign, queueing hot writes, and business-level decisions about contention rather than only ORM tuning.

Red flag: They disable locking or catch and ignore persistence exceptions to keep requests succeeding.

Listen for: Strong candidates weigh team ownership, deployment cadence, domain boundaries, data ownership, operational cost, latency, consistency, and failure isolation. They should mention modular monolith options using clear packages or Spring Modulith before extracting services, and they should avoid splitting around technical layers like controllers, services, and repositories.

Red flag: They equate more microservices with better architecture without considering ownership and operations.

Listen for: Look for building a small internal platform carefully: shared auto-configuration or starters for cross-cutting concerns, clear extension points, versioning, tests, and documentation. They should avoid creating a framework that blocks service autonomy. Good answers include migration strategy, ownership, dependency governance, and compatibility with Boot auto-configuration practices.

Red flag: They centralize all business logic into a shared library used by every service.

Listen for: They should prioritize mitigation: rollback, feature flag disablement, traffic shifting, or scaling only if it helps. Then they gather evidence through metrics, traces, logs, and recent changes. Good senior answers include clear incident roles, communication, preserving data integrity, post-incident learning, and improving tests or rollout strategy.

Red flag: They keep debugging in production while users are impacted and delay rollback because they want root cause first.

Listen for: A strong answer defines a test pyramid suited to services: fast unit tests for domain logic, slice tests where useful, integration tests with Testcontainers for persistence and messaging, contract tests for external APIs, and limited end-to-end tests. They should include CI runtime management, flakiness ownership, and meaningful coverage over raw percentages.

Red flag: They mandate full application context tests for nearly everything or dismiss integration tests as too slow.

Listen for: Strong answers define service boundaries, state transitions, idempotent commands, and failure handling. They should avoid distributed transactions, use outbox or saga-style coordination, and make retries safe. Listen for transaction boundaries, message broker choice such as Kafka or RabbitMQ, event schema evolution, reconciliation jobs, and operational visibility into stuck orders.

Red flag: They assume all steps can be wrapped in one ACID transaction across services.

Listen for: They should compare shared schema, schema-per-tenant, and database-per-tenant based on isolation, operations, and query needs. Good answers cover tenant resolution, authorization, preventing cross-tenant access, migrations with Flyway or Liquibase, caching keys, per-tenant rate limits, secrets, and tests that prove tenant isolation.

Red flag: They pass tenantId from the client and trust it in repository queries without enforcing authorization.

Listen for: Listen for asynchronous processing, streaming rather than loading full files, durable storage, job state, backpressure, and retryable validation steps. Spring Batch may fit if they explain chunking, restartability, and job metadata. Good answers include upload limits, malware scanning hooks, partial failures, status APIs, and observability for long-running jobs.

Red flag: They upload the file to a controller and process it synchronously in the request thread.

Listen for: Strong candidates separate write source of truth from search/read models, discuss indexing pipelines, eventual consistency, cache strategy, pagination, filtering, and fallback behavior. They should address schema evolution, reindexing, bulk updates, query performance, freshness expectations, and monitoring mismatches between PostgreSQL and the search index.

Red flag: They treat the search index as the only source of truth without a recovery or reindexing plan.

Listen for: A good design uses an external identity provider with OIDC/OAuth2, appropriate flows for each client, API gateway or resource server validation, and method-level authorization for business rules. They should cover token lifetimes, refresh, scopes versus roles, service accounts, mTLS where appropriate, audit logging, and testing denied paths.

Red flag: They build custom password storage and token logic inside each service.