Spring Boot Internals and Java 21 Features Behind a Machine Coding Solution

In a machine coding round you build a small but working application in Java with Spring Boot. The coding exercise itself is not reproduced here; the reported focus is what followed it: a detailed discussion of how the framework you used works and of the Java 21 language and runtime features you used or could have used. For practice, assume you have just built a small REST service with Spring Boot 3 on Java 21: a few endpoints, a service layer holding the business rules, a repository (in memory or backed by JPA), and some unit tests. Answer the interviewer's drill-down questions about it, using short code snippets where they help. ### Constraints and Clarifications - This is a discussion round; you do not need to rebuild the application, but your answers should refer to concrete code. - Be precise about versions: say which features are final in Java 21 and which arrived earlier or were still in preview. - Expect the interviewer to challenge design choices in your solution as well as test your framework knowledge. ### Clarifying Questions - Which Spring Boot version and which web stack (servlet-based Spring MVC or reactive WebFlux) is the discussion about? - Is persistence real, through JPA and a database, or in memory for the exercise? - Should the answers stay at the level of the code as written, or extend to production concerns such as configuration, observability and concurrency? ### Part 1 — What Spring Boot is doing for you Explain what happens between `main` and the first served request: how the application context is created, how auto-configuration decides which beans to create, how dependency injection wires your controller, service and repository, and what bean scopes and proxies mean for code such as `@Transactional` methods. ```hint Follow the annotations Trace what `@SpringBootApplication` expands to, and think about why calling an annotated method from inside the same class can behave differently from calling it through another bean. ``` #### What This Part Should Cover - Context startup, component scanning and conditional auto-configuration - Constructor injection and why it is preferred - Proxies behind transactional and similar annotations, including the self-invocation trap - How to override or exclude an auto-configured bean ### Part 2 — Java 21 features in your solution Pick the Java 21 features that would make the machine coding solution cleaner or more scalable, show where you would use each one, and explain what each one replaces. Be ready to say which features are final in Java 21 and which arrived in earlier releases. ```hint Model the domain first Think about how a closed set of domain outcomes, immutable data carriers and blocking I/O under heavy concurrency would each be expressed in modern Java. ``` #### What This Part Should Cover - Records and sealed hierarchies combined with pattern matching for switch and record patterns - Virtual threads: what they change for a thread-per-request server, and their caveats - Sequenced collections and similar API additions where they fit - Version awareness: final versus preview features ### Part 3 — Defending the design The interviewer challenges the structure of your solution: why each layer exists, how you would test it, and how it behaves under concurrent requests. Explain your choices and what you would change for production. ```hint Shared by every request Ask which objects in your application are singletons used by every request thread, and what state each of them holds. ``` #### What This Part Should Cover - Layering and interfaces justified by testability rather than habit - Thread safety of singleton beans and any shared state - A test strategy that mixes plain unit tests with slice and full-context tests - Validation and error handling at the API boundary ### What a Strong Answer Covers - Explains framework behavior through concrete mechanisms (scanning, conditions, proxies) instead of calling it magic - Accurate, version-aware knowledge of modern Java features and their trade-offs - Code-level examples that connect each feature to the machine coding solution - Awareness of concurrency, especially once virtual threads are enabled - Design choices defended with reasons, and honest acknowledgment of what would change in production ### Follow-up Questions - With virtual threads enabled, the database connection pool is far smaller than the number of concurrent requests. What happens, and how do you handle it? - How would you make the service's configuration differ across environments without changing code? - When would you still choose WebFlux over Spring MVC running on virtual threads? - How does Spring choose between two beans of the same type, and how do you control that choice?