Last updated 19 September 2026. Default examples are mid-level Spring and Java 17–21. Junior and senior sit in labeled sections so the first screen is not a fresher dump.
Spring Boot is how most teams start a Spring service: opinionated defaults, an embedded server, and starters that pull a tested dependency set. Interviews separate people who can draw Boot's auto-configuration from people who only remember @SpringBootApplication. This page is the Boot hub. Child question pages keep the long answers.
Junior
@SpringBootApplication is @SpringBootConfiguration plus @EnableAutoConfiguration plus @ComponentScan. The scan starts from the package of that class. Putting the application class in com.example.foo.app and entities in com.example.bar is a common junior mistake: the entities are never scanned unless you set scanBasePackages.
Starters are BOM-aligned dependency descriptors, not magic. spring-boot-starter-web brings Tomcat, Jackson, and spring-webmvc. You do not pick a random Jackson version next to a starter unless you enjoy classpath fights. The parent POM or the Boot BOM manages versions.
application.properties and application.yml are Environment sources. Profile-specific files overlay the defaults. Command-line arguments win. Never commit secrets there. Interviews still ask how to disable a single auto-configuration: exclude on @SpringBootApplication or spring.autoconfigure.exclude. That is not the same as excluding a package from component scan. We already rewrote those two SERP titles because people confuse them.
Actuator exposes health, info, and metrics. On a public network, lock it down. /health for the load balancer can stay; /env and /heapdump must not.
Mid-level
Auto-configuration classes live in auto-config jars and are registered via AutoConfiguration.imports (Boot 3) or spring.factories (older). Each class is a @Configuration with @Conditional* annotations. OnMissingBean means your bean wins if you define one of the same type. OnClass means the config is skipped if the class is absent. The conditions report is the way to prove why a DataSource was or was not created.
DevTools restarts on classpath changes using two classloaders. It is not a production dependency. Disable template caching in the IDE or you will think DevTools is broken. Embedded Tomcat vs Jetty vs Undertow is a starter swap, not a rewrite, until you rely on container-specific APIs.
Configuration properties should be @Validated @ConfigurationProperties records or classes, bound once, immutable if you can. Refreshing properties in place is a Cloud-only conversation. Mid-level candidates should know @RefreshScope exists and that it is not free.
Testing slices keep Boot tests honest. @WebMvcTest will not load your JPA repositories. If a test needs both, you are writing an integration test: name it that way and use Testcontainers for the database instead of H2 if production is PostgreSQL and you care about SQL dialect bugs.
Packaging: Boot fat jar with an embedded launcher. Layered jars help Docker cache. Do not explode the jar on Heroku-style slugs unless the buildpack already did that for you.
Senior
Senior Boot interviews go to custom starters: an auto-configuration class, a ConditionalOnMissingBean API, and a META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports file. Document the conditions. Provide a spring-configuration-metadata.json so IDEs complete your prefix.
GraalVM native image is a Boot 3 topic: reachability metadata, reflection config, and the fact that runtime proxies and random Class.forName calls die unless you hint them. Do not promise native image as a free memory win on a site that already R14s a 512MB dyno; measure RSS.
Virtual threads in Tomcat or Jetty: Boot 3.2+ can switch the request executor. Blocking JDBC still occupies a carrier if you pin. A senior answer names the executor, the pin risk, and the observability gap when thread dumps no longer look like one-thread-per-request.
Failure analysis: FailureAnalyzer turns a missing bean into a readable start failure. If you write a starter, write an analyzer for the failure you know users will hit. Production: readiness versus liveness, and why a DB-down liveness kill loop is worse than a failing readiness probe.
Probe yourself
What three annotations does @SpringBootApplication compose?
@SpringBootConfiguration, @EnableAutoConfiguration, and @ComponentScan.
How do you turn off one auto-configuration class without excluding a whole starter?
@SpringBootApplication(exclude=...) or spring.autoconfigure.exclude.
Why might @WebMvcTest fail to inject a JpaRepository?
The MVC slice does not load JPA. Mock the repository or use a broader test.
Related questions on this topic are linked below. Read the full answer on the question URL; this hub does not repeat those answers.
Pitfalls interviewers still use
Putting application.properties secrets in Git is still the most common Boot failure in take-home tests. Use env vars or a secret manager. Boot binds DATABASE_URL on Heroku if you write the binder; it will not invent a DataSource from a random KEY.
excludeFilters on @ComponentScan is not exclude= on @SpringBootApplication. The first hides your classes from the scan. The second turns off an auto-configuration class. Mixing them is how candidates disable JPA auto-config when they meant to skip a package of fixtures.
A custom Jackson ObjectMapper @Bean replaces Boot's builder and drops JavaTimeModule unless you copy the defaults. Prefer a Jackson2ObjectMapperBuilderCustomizer. Interviewers who have been burned will ask exactly this.
main() that is not in the root package, plus entities below it, plus @EntityScan missing, produces an empty repository and a passing test that used a slice you did not understand. Draw the packages on the whiteboard.
Actuator on 0.0.0.0 with sensitive endpoints is a security finding, not a convenience. Separate management port if you can. Never expose heapdump on the public internet.
For the room: explain one starter's auto-config class, its conditions, and how you would override one bean. That is Boot literacy. Reciting annotations is not.
How to answer in the room
Start Boot answers with the application class package. Everything else is a scan or auto-config story. If entities or @Configuration classes sit outside that package, say so before you debug a missing bean for twenty minutes. scanBasePackages is a deliberate widening, not a default.
Explain a starter as a curated classpath plus auto-configuration, not as a magic annotation. spring-boot-starter-web is Tomcat, Jackson, and MVC. You do not add a random Jackson version beside it. If a CVE forces a bump, use the Boot BOM property, not a wild <version> tag that drifts from the rest of the stack.
When they ask how to turn something off, split the two excludes: exclude an auto-configuration class, or exclude a package from component scan. Mixing those is the harvest SERP we already rewrote. Walk one example: you want your own DataSource, so you define the bean and rely on OnMissingBean, or you exclude DataSourceAutoConfiguration if you truly have no DataSource.
Actuator: health for the load balancer, never heapdump on the public internet. If you have a separate management port, say why. If you do not, say what you hide. This is a security answer dressed as Boot trivia.
Tests: name the slice. @WebMvcTest for a controller, @DataJpaTest for a repository, @SpringBootTest for a boot of the context you actually need. If a test loads the world to assert one JSON field, you will lose time and hide the real failure. Prefer Testcontainers when SQL dialect matters.
Packaging: fat jar, layered image, no exploded-jar folklore unless the buildpack already did it. Native image is a separate interview. Do not promise RSS wins on a 512MB dyno without a number. Virtual threads in the request executor are a Boot 3.2+ flag plus a pinning audit, not a checkbox.
Write custom starters only if you have two or more services sharing the same auto-config. One service does not need a starter; it needs a @Configuration you own. Interviewers use 'write a starter' to see if you know AutoConfiguration.imports and metadata JSON, not because every team should publish one.
