If you are new to Java jobs, Spring sounds like a huge syllabus. In real companies it is simpler: Spring is the kitchen that cooks API requests for you.
Think of a restaurant
A user opening your app is a customer. They do not walk into the kitchen. They tell a waiter what they want.
- Browser / mobile app = the customer
- DispatcherServlet = the waiter who takes every order
- Controller = the menu item: “login”, “create order”, “get profile”
- Service = the kitchen: business rules (is the password correct?)
- Repository = the store room: talk to the database
- Database = the fridge where user rows actually live
You almost never talk to the fridge from the waiter. That is why we split Controller → Service → Repository. Freshers mix these layers and then bugs become hard to find.
Spring vs Spring Boot (the interview trap)
Spring Framework is the recipe book: dependency injection, web, security, data. You can assemble it yourself, but it takes many XML/Java config files.
Spring Boot is a restaurant that already has gas, plates, and a default kitchen. You write a main method, add starters like spring-boot-starter-web, and Tomcat starts for you. In 2026 almost every fresher job uses Boot, not raw Spring XML.
Realtime path: POST /login
Imagine the JSON body is {"email":"ria@company.com","password":"..."}.
- The waiter (DispatcherServlet) sees URL
/loginand HTTP POST. - A
@RestControllermethod matches that mapping and reads the JSON into a Java object. - The controller does not check the password. It calls
authService.login(...). - The service loads the user through a repository:
userRepository.findByEmail(email). - Hibernate/JPA turns that into SQL:
SELECT * FROM users WHERE email = ?. - The service compares the hashed password (never store plain text).
- If it matches, you return a session cookie or a JWT. If not, you return 401.
That is “Spring in production” for a login. Same pipeline for “place order”, “upload resume”, “fetch notifications”.
The magic word: Dependency Injection
Without Spring you would write new UserRepository() inside the service. Then the service is glued to one database and unit tests become painful.
Spring creates the repository once and hands it to the service. Like HR assigning you a laptop instead of you buying your own.
That is why you see constructors like this:
@Service
public class AuthService {
private final UserRepository users;
public AuthService(UserRepository users) {
this.users = users;
}
}
You did not call new AuthService. Spring did, at startup, and wired the pieces. That is Inversion of Control: you describe the beans, Spring owns the lifecycle.
What you actually type on day one
@SpringBootApplicationon the main class — start the kitchen@RestController+@PostMapping("/login")— a menu item@Service— kitchen logic@Repository+JpaRepository— fridge accessapplication.properties— DB URL, port 8080, profiles for dev vs prod
Annotations are not decoration. They are labels so Spring can find and wire your classes at startup. If a bean is missing, the app fails at boot, not in the middle of a user request. That fail-fast is a feature.
Fresher mistakes I see in real teams
- Putting SQL or password checks inside the controller — hard to test, easy to copy-paste bugs
- Using
newfor services instead of letting Spring inject them — you lose transactions and mocks - Returning the whole User entity (including password hash) in JSON — leak
- Forgetting
@Transactionalon a method that writes two tables — order saved, payment row missing - Running only on localhost, then wondering why prod cannot reach MySQL — config/profiles
How to practice this week
Build one tiny Boot app: register + login + “me” endpoint. Use Postgres or even H2 in memory. Hit it with Postman. Then add a second feature, like “create a note for the logged-in user”. If you can explain that flow on a whiteboard without memorizing the whole Spring docs, you are job-ready for a junior Java interview.
Spring is not 200 annotations to memorize. It is a waiter, a kitchen, and a fridge — and Boot starts the restaurant for you.
Comments (12)
We onboard freshers with the same restaurant analogy. It clicks faster than reading the Spring docs cover to cover.
In our team the login bug was always someone calling the repository from the controller. Splitting layers fixed it in one sprint.
Do you still recommend teaching XML config first, or jump straight to Spring Boot annotations for campus hires?
Worth adding that BCrypt password checks belong in the service layer, never in the controller returning raw SQL errors.
DispatcherServlet as the waiter is the best explanation I have seen for why every request hits one front door.
Our intern batch struggled until we mapped Controller → Service → Repository on a whiteboard. Same story here.
We return 401 vs 403 exactly like you described. Freshers confuse them until they see it in Postman once.
Tip: log the filter chain order in dev — students finally understood why CORS broke before auth in our project.
How do you explain @Autowired field injection vs constructor injection without scaring juniors on day one?
Spring Boot auto-config is the reason we stopped drawing ten XML boxes in interviews. Solid write-up.
I teach JWT the same way — token at the door, not in every kitchen recipe. Page 2 continues it nicely.
Add a note about session fixation in older apps; still a common fresher interview follow-up question.