Spring MVC Interview Questions: 25 Answers for Screening Rounds

Use these Spring MVC interview questions to answer screening rounds with 25 model responses, follow-up probes, and backend examples.

Spring MVC looks familiar on paper right up until an interviewer starts asking why. Most candidates can name the annotations. Fewer can explain what actually happens between the moment a request hits the server and the moment a response leaves it. That gap is exactly where Spring MVC interview questions live — and this guide gives you a model answer, a follow-up question, and a real backend example for each core concept, so you're not reconstructing the framework under pressure.

The pattern you'll see in screening rounds is consistent: interviewers start with a definition, get a decent answer, and then probe one level deeper. "Okay, but what if validation fails? Where does the exception go? Why not just use Spring Boot and skip all this?" If you can tell the request story cleanly — DispatcherServlet to controller to view, with binding and exception handling in the right places — you pass. If you're patching holes as you go, you don't.

Spring MVC Basics That Sound Simple Until Someone Probes Them

What is Spring MVC, and how is it different from plain MVC and Spring Boot?

Spring MVC is Spring's implementation of the Model-View-Controller pattern for web applications. The pattern itself — separate your data model, your view rendering, and the controller that wires them — is decades old. Spring MVC takes that pattern and runs it on top of the Java Servlet API, with a central `DispatcherServlet` coordinating every incoming request.

The confused answer interviewers hear constantly is that Spring Boot and Spring MVC are the same thing, or that Boot replaces MVC. They don't. Spring Boot is an opinionated runtime layer: it auto-configures dependencies, embeds Tomcat or Jetty, and eliminates most of the XML you used to write. Spring MVC is still the web framework underneath. When you build a Boot application with a `@Controller` and a `@GetMapping`, you are writing Spring MVC code. Boot just removed the boilerplate that used to surround it.

A clean way to draw the line in an interview: if you build a login page with a form POST, the controller that handles the submission, binds the credentials to a model object, validates them, and either redirects to a dashboard or returns the form with errors — that is all Spring MVC. Spring Boot is what let you skip the `web.xml` and the servlet registration to get there.

Why do interviewers keep asking about Spring MVC instead of jumping straight to Spring Boot?

Because they're testing the web layer, not your ability to add starter dependencies. A candidate who only knows Spring Boot can wire up an endpoint in five minutes and have no idea what `HandlerMapping` does, why `ViewResolver` exists, or what happens when two controllers match the same path. Interviewers at mid-level and above want to know you understand the machinery, not just the shortcuts.

Modern apps built on Boot still behave exactly like Spring MVC applications at the controller level. The request lifecycle hasn't changed. The annotations haven't changed. Boot just hides the setup — and hiding setup from someone who doesn't understand it creates bugs that are very hard to debug.

What part of Spring MVC actually handles the request, and what part is just configuration?

The framework machinery is `DispatcherServlet`, `HandlerMapping`, `HandlerAdapter`, and `ViewResolver`. These are Spring's wiring. Your application code is the `@Controller` class, the method annotated with `@GetMapping` or `@PostMapping`, the model object you populate, and the view name you return.

A concrete example: you write a controller with `@GetMapping("/dashboard")` that adds a user object to the `Model` and returns the string `"dashboard"`. Spring MVC's `ViewResolver` takes that string and resolves it to `/WEB-INF/views/dashboard.html` or `templates/dashboard.html` depending on your configuration. You wrote the controller and the template. Spring MVC wrote everything in between.

Spring MVC Request Flow: The Part Interviewers Love to Turn Into a Whiteboard

Can you explain the Spring MVC request flow step by step, from DispatcherServlet to ViewResolver?

The Spring MVC request flow is the question interviewers draw on whiteboards, and the answer that holds up is one that sounds like a sequence of real decisions rather than a memorized diagram.

A login form POST hits the server. `DispatcherServlet` receives it first — it's the single front controller registered to handle all requests. It consults `HandlerMapping` to find which controller method matches the path and HTTP method. Once it has a match, `HandlerAdapter` invokes the method, handling argument resolution along the way (binding the form fields to your model object, injecting the `BindingResult`, etc.). Your controller method runs, adds data to the `Model`, and returns a view name — say, `"login-success"`. `ViewResolver` maps that name to a physical template. The template engine renders it with the model data, and `DispatcherServlet` writes the response.

The official Spring reference documentation covers each step in detail, but the version above is what interviewers want to hear: a narrative, not a glossary.

How does request mapping resolution work under the hood?

Spring resolves mappings in order of specificity. Path comes first, then HTTP method, then parameters and headers. A method annotated `@GetMapping("/users/{id}")` will win over a more generic mapping to `/users/**` when the request is a GET to `/users/42`. The common mistake is treating `@RequestMapping` like magic — writing a method, adding an annotation, and assuming Spring will figure out the rest. When two methods match the same request, Spring throws `AmbiguousHandlerMappingException`. That's not magic; that's a configuration error.

The follow-up interviewers often ask: "What if you have both a `@GetMapping("/users/{id}")` and a `@GetMapping("/users/search")`?" Spring resolves `search` as a literal path before treating it as a variable. Literal paths win over path variables.

What happens when Spring MVC cannot find a handler or a view?

If no handler matches, `DispatcherServlet` throws a `NoHandlerFoundException` — which, unless you've configured a handler for it, surfaces as a 404. If a handler is found but the view name it returns doesn't resolve to anything, you get a `ServletException` wrapping a view resolution failure. These are structurally different failures. The first is a routing problem. The second is a configuration problem — your controller ran fine, but you pointed at a template that doesn't exist.

The practical debugging path: check the request URL and method first, then check your `ViewResolver` prefix and suffix configuration. A log line from `DispatcherServlet` at DEBUG level will show you exactly which handlers were considered and rejected.

Spring MVC Annotations: The Ones You Actually Have to Know

Spring MVC annotation questions come up in nearly every screening round because annotations are the surface area most candidates interact with daily — and also the surface area most candidates have memorized without fully understanding.

When should you use @RequestParam instead of @PathVariable?

The intent is different, and that's what interviewers want to hear. `@PathVariable` is for identifying a resource. `@RequestParam` is for filtering or modifying how you interact with it. A resource lookup — `GET /products/42` — uses `@PathVariable` because `42` is the identity of the thing you're fetching. A search — `GET /products?category=books&sort=price` — uses `@RequestParam` because those values are query parameters that narrow a collection, not identify a single resource.

The follow-up: "What happens if the path variable is missing?" Spring throws a `MissingPathVariableException`. "What about a missing request param?" Spring throws `MissingServletRequestParameterException` unless you've marked it `required = false`.

Where does @ModelAttribute fit, and why do people misuse it?

`@ModelAttribute` is for binding an entire form submission to a Java object. When a user fills out a registration form with ten fields and hits submit, you want Spring to bind all those fields to a `UserRegistrationForm` object in one step. That's `@ModelAttribute`'s job.

The misuse happens in two ways. First, candidates use it for a single query value — `@ModelAttribute String searchTerm` — when `@RequestParam` is the right tool. Second, they use it when the client is sending JSON, which is `@RequestBody`'s domain. `@ModelAttribute` works on form-encoded data. JSON POST bodies are not form-encoded. Using `@ModelAttribute` on a JSON endpoint silently fails to bind anything, and the resulting null fields are genuinely confusing to debug.

When is @RequestBody the right answer, and when is it the wrong one?

`@RequestBody` is the right answer when the client sends a JSON or XML payload in the request body — a REST API endpoint receiving `Content-Type: application/json`. Spring uses Jackson (or your configured deserializer) to map the body to your Java object.

It's the wrong answer for a traditional HTML form POST. Form submissions send data as `application/x-www-form-urlencoded`, not JSON. If you put `@RequestBody` on a form handler, Spring will try to deserialize the form-encoded string as JSON and fail. Use `@ModelAttribute` for forms, `@RequestBody` for REST. This distinction comes up constantly in Spring MVC annotation questions.

The Spring MVC documentation on method arguments covers all four annotation types with their binding semantics.

Controllers, Views, and the Names People Mix Up in Interviews

What is the difference between @Controller and @RestController?

`@Controller` tells Spring this class handles web requests and, by default, returns view names. `@RestController` is a convenience annotation that combines `@Controller` and `@ResponseBody`, which means every method in the class writes directly to the HTTP response body — typically as JSON — instead of resolving a view.

A page-based app with Thymeleaf templates uses `@Controller`. A REST API uses `@RestController`. The interview trap is candidates who say `@RestController` is "newer" or "better." It's not better — it's appropriate for a different output shape.

Why would you still use a regular @Controller in a modern backend?

Server-rendered pages, form submissions, redirects, and hybrid applications are all legitimate reasons. If your app serves HTML — a CMS, an admin panel, an e-commerce checkout flow — `@Controller` is the right choice. Redirecting after a successful form POST requires returning `"redirect:/dashboard"`, which makes no sense in a pure REST context but is idiomatic in a view-based controller. The same applies to returning form pages with validation errors populated in the model.

What does ViewResolver actually do, and why does it matter?

`ViewResolver` turns a logical view name — the string your controller returns — into something the framework can render. A `ThymeleafViewResolver` configured with prefix `classpath:/templates/` and suffix `.html` will take the string `"dashboard"` and look for `classpath:/templates/dashboard.html`. Without `ViewResolver`, the string `"dashboard"` is just a string.

Candidates wave their hands here because they've always used Spring Boot's auto-configuration, which sets up `ViewResolver` automatically. Interviewers know this and ask about it specifically. The Thymeleaf integration guide documents exactly how view resolution is configured.

Validation, BindingResult, and the Bugs Candidates Usually Hand Wave Past

How do validation and BindingResult work together in Spring MVC?

The order matters and interviewers test it. Spring first binds the incoming request data to your model object, then runs validation against it (Bean Validation annotations like `@NotNull`, `@Size`, etc.), then populates `BindingResult` with any errors. Your controller method receives `BindingResult` immediately after the model object and checks whether it has errors before proceeding.

A user submits the registration form with an empty email field. Spring binds the empty string, `@Email` validation fails, `BindingResult` records the error, `result.hasErrors()` returns true, and the controller returns the form view so the user sees the error message. That's the full flow.

What are the most common interview mistakes around validation and binding?

Three mistakes come up repeatedly. First, putting `BindingResult` anywhere other than immediately after the model object — Spring will throw an exception at startup or silently skip the binding. Second, confusing binding errors (the value couldn't be converted to the target type — a string in a `Long` field) with validation errors (`@NotNull` failed). They're both in `BindingResult`, but they have different causes and different messages. Third, assuming `@Valid` runs automatically without annotating the parameter — validation only fires when you explicitly add `@Valid` or `@Validated`.

What is one production bug caused by bad binding, and how would you debug it?

A date field bound as a `String` instead of `LocalDate` because the frontend sends `"2024-03-15"` and the controller parameter is typed `String`. Everything works until someone tries to compare or sort dates — then the alphabetical sort of strings produces wrong results silently. The debugging path: check the request payload in your logs, check the controller parameter type, then check whether a `@DateTimeFormat` annotation is missing. The Bean Validation specification and Spring's binding documentation cover the type conversion layer that sits between raw request data and your Java objects.

Exception Handling and Model Objects: The Last Things Interviewers Press on

How do you handle exceptions in Spring MVC at the controller and global levels?

Local exception handling uses `@ExceptionHandler` methods inside the controller class. They catch exceptions thrown by that controller's methods and return an appropriate view or response. Global exception handling uses `@ControllerAdvice` — a class annotated with it applies its `@ExceptionHandler` methods across all controllers.

Form validation failures typically stay local — the controller already has the `BindingResult` and returns the form view directly. Not-found exceptions or unexpected runtime errors are better handled globally so you don't duplicate the same error logic in every controller.

What is the difference between Model, ModelMap, and ModelAndView?

`Model` is an interface that lets you add attributes to pass to the view. `ModelMap` is a concrete implementation with some extra convenience methods inherited from `LinkedHashMap`. In practice, they're interchangeable for the vast majority of use cases — inject `Model` in your method parameter and add attributes with `model.addAttribute()`.

`ModelAndView` is the choice when you want to set both the view name and the model attributes in one return object, rather than returning a view name string and populating a separate `Model` parameter. It's still useful in complex controllers where the view name is determined conditionally and you want to keep the data and the destination together.

How would you explain a clean error response for a view-based Spring MVC app?

For a view-based app, the error response is a rendered page, not a JSON payload. A clean approach uses `@ControllerAdvice` to catch known exception types and return specific error views with a human-readable message in the model. The trap is over-engineering this by building a structured error response object — that's appropriate for a REST API, not a server-rendered app where the user needs to see a page, not parse JSON.

The Follow-Ups That Separate a Memorized Answer from an Interview-Ready One

What are the most common follow-up questions interviewers ask after a basic Spring MVC answer?

The follow-ups are predictable once you know the pattern. After any annotation answer: "Why that annotation specifically? What would happen if you used a different one?" After any validation answer: "What if validation fails — where does the error go, and how does the user see it?" After any exception handling answer: "Where does the exception actually get caught — in the controller, in ControllerAdvice, or somewhere else?" After any Spring Boot vs Spring MVC answer: "If Boot handles the setup, what does the MVC part still do?"

Each of these probes for the same thing: do you understand the mechanism, or did you memorize the label?

How do you answer Spring MVC vs Spring Boot without sounding vague?

The crisp version: Spring Boot is the auto-configuration and embedded server layer. Spring MVC is the web framework. In a typical modern project, Boot starts the application and wires up Tomcat, but every `@Controller`, `@RequestMapping`, `HandlerMapping`, and `ViewResolver` is still Spring MVC. Boot makes it easier to configure. It does not replace it. A project that removes Boot but keeps Spring MVC still has a fully functional web layer — it just requires more manual configuration.

What should you say when the interviewer asks how you would test a Spring MVC controller?

MockMvc is the answer, and the follow-up is why. MockMvc lets you test the full web layer — request mapping, argument binding, validation, and exception handling — without starting a real server. A test that posts to `/register` with a missing email field, asserts that the response status is 200, and checks that the model contains a binding error is testing real Spring MVC behavior.

The Spring Test reference documentation covers MockMvc in full, including standalone setup for unit-style tests and full WebApplicationContext setup for integration tests.

Rapid-Fire Spring MVC Questions You Should Be Able to Answer Cold

What happens if two controllers match the same request?

Spring throws `AmbiguousHandlerMappingException` at request time. It cannot choose between two equally specific mappings. The fix is to make the mappings unambiguous — different paths, different HTTP methods, or different parameter conditions.

Can @RestController return a view?

Not in any meaningful sense. `@RestController` applies `@ResponseBody` to every method, which means the return value is written directly to the response body. If you return a string like `"dashboard"`, the client receives the literal string `"dashboard"` as the response body, not a rendered page. Use `@Controller` for view-returning endpoints.

Why does BindingResult have to come right after the model object?

It's a method signature contract. Spring's `HandlerMethodArgumentResolver` associates a `BindingResult` with the model object immediately preceding it. If you insert another parameter between them — say, an `HttpServletRequest` — Spring loses the association and throws a `BindException` instead of populating the `BindingResult`. The rule is simple: `BindingResult` immediately follows its `@ModelAttribute` or `@RequestBody` parameter, no exceptions.

Can you use @RequestBody and @ModelAttribute on the same endpoint?

No, and the reason is structural. `@RequestBody` reads the request body as a stream and deserializes it. `@ModelAttribute` reads form-encoded parameters. A single HTTP request has one body. You can't read it twice with two different strategies on the same method. If you need both, you have a design problem — the client is sending one kind of data, so pick the annotation that matches it.

What is the role of HandlerInterceptor in Spring MVC?

`HandlerInterceptor` lets you run code before a controller method executes (`preHandle`), after it executes but before the view renders (`postHandle`), and after the full request completes (`afterCompletion`). The canonical use cases are logging, authentication checks, and request timing. It's not a replacement for Spring Security, but it's useful for cross-cutting concerns that don't belong in every controller.

When would you choose ModelAndView over Model?

When the view name is determined conditionally inside the method and you want to pair it with the model data in one return object. If your method has three branches that return different views with different model data, `ModelAndView` keeps each branch self-contained. If every code path returns the same view name, returning a string and using a `Model` parameter is simpler.

How do you return a redirect in Spring MVC?

Return a view name prefixed with `redirect:` — `return "redirect:/dashboard"`. For preserving data across the redirect (a success message, for example), use `RedirectAttributes.addFlashAttribute()`. Flash attributes survive exactly one redirect and are gone after the next request, which is exactly what you want for a "your form was submitted successfully" message.

What is the difference between @ResponseBody and @RestController?

`@ResponseBody` on a single method tells Spring to write that method's return value directly to the HTTP response body. `@RestController` applies `@ResponseBody` to every method in the class by default. The difference is scope: one is per-method, the other is per-class. If you have a `@Controller` that mostly returns views but has one endpoint that returns JSON, annotate that one method with `@ResponseBody` rather than switching the whole class to `@RestController`.

How do you handle file uploads in Spring MVC?

Configure a `MultipartResolver` (Spring Boot auto-configures `StandardServletMultipartResolver`) and add a `@RequestParam MultipartFile` parameter to your controller method. The form must use `enctype="multipart/form-data"`. For a profile photo upload, the controller receives the `MultipartFile`, reads its bytes, and writes them to storage. The common interview follow-up is about file size limits — configured via `spring.servlet.multipart.max-file-size` in Boot, or directly on the `MultipartResolver` bean.

How would you explain Spring MVC to a junior developer in one minute?

A request comes in. `DispatcherServlet` receives it and finds the right controller method. The method reads the request data, does some work, adds results to a model, and returns a view name. Spring finds the template matching that name, fills it with the model data, and sends the rendered HTML back. Every annotation you use — `@GetMapping`, `@ModelAttribute`, `@Valid` — is just a way of telling Spring what to bind, when to validate, and where to route. The framework handles the wiring; you write the logic.

How Verve AI Can Help You Prepare for Your Interview With Spring MVC

The sequences that actually build interview confidence — "what if the interviewer follows up on exactly the part I glossed over?" — only work if the tool running them can hear your full answer and respond to what you actually said. Reciting answers to a static list doesn't prepare you for the moment an interviewer asks why you chose `@RequestBody` over `@ModelAttribute` and you have to reconstruct your reasoning live.

Verve AI Interview Copilot is built for that gap. It listens in real-time to the live conversation, responds to what's actually happening, and surfaces the follow-up context you need — the kind of probe that separates a memorized answer from a defensible one. When you're running through the Spring MVC request flow and you trail off at `ViewResolver`, Verve AI Interview Copilot doesn't just give you the next bullet point; it tracks where your answer broke down and helps you rebuild it. The desktop app stays invisible during screen share, so you're practicing in the same conditions as the real interview. If you want to work through the 25 questions in this guide with a tool that pushes back the way a real interviewer does, Verve AI Interview Copilot is the environment to do it in.

Conclusion

The difference between a candidate who passes a Spring MVC screening round and one who doesn't usually isn't the depth of their knowledge — it's whether they can tell the request story under pressure. DispatcherServlet receives the request, HandlerMapping finds the controller, the controller binds and validates the input, BindingResult holds any errors, the method returns a view name or a response body, and ViewResolver or the response writer finishes the job. That sequence, told confidently with one concrete example, is what interviewers are listening for.

Take the 25 questions in this guide and say the answers out loud. Not to yourself in your head — out loud, as if someone is listening and about to follow up. That's the practice that turns Spring MVC interview questions into interview answers you can actually use.