ASP.NET MVC Interview Questions

Analogy categoryAnalogies

Core MVC Concepts

Interviewers frequently start by asking you to explain the Model-View-Controller pattern and contrast it with Web Forms: MVC cleanly separates data (Model), presentation (View), and request-handling logic (Controller), giving full control over rendered HTML and testability, whereas Web Forms mixes markup and code-behind with a page lifecycle and view state that make unit testing much harder. Be ready to walk through the request lifecycle: routing matches the incoming URL to a controller and action, the controller executes business logic and selects a model, and the view engine (Razor) renders that model into HTML.

🏏

Cricket analogy: A team separates the roles of captain (strategy), coach (training), and analyst (data) rather than having one person do everything, similar to how MVC separates concerns into Model, View, and Controller instead of the tightly coupled code-behind approach of Web Forms.

Routing and Action Methods

A common question is to compare attribute routing, using [Route("products/{id}")] on an action method, with convention-based routing defined centrally in RouteConfig via the default {controller}/{action}/{id} pattern; attribute routing gives per-action precision while convention routing keeps a consistent site-wide URL scheme with less repetition. Interviewers also probe action selectors like [HttpPost], [HttpGet], and [ActionName("Delete")], which let you have two methods with the same route but different HTTP verbs, or expose a differently named C# method under a specific URL segment.

🏏

Cricket analogy: A ground announcer can call out a specific bowler by name (attribute routing style, precise and explicit) or rely on the standing batting order rotation (convention routing style, pattern-based), similar to how MVC supports [Route("products/{id}")] attribute routing alongside the default {controller}/{action}/{id} convention route.

csharp

[RoutePrefix("products")]
public class ProductsController : Controller
{
    [Route("{id:int}")]
    public ActionResult Details(int id) => View();

    [HttpPost]
    [ActionName("Delete")]
    [ValidateAntiForgeryToken]
    public ActionResult DeleteConfirmed(int id)
    {
        // deletes the product, then redirects
        return RedirectToAction("Index");
    }
}

Filters and Model Binding

Be ready to name and order MVC's filter types: Authorization filters run first (e.g., [Authorize]), then Action filters wrap the action's execution, then Result filters wrap the rendering of the result, with Exception filters able to intercept an unhandled error at any of those stages. Interviewers also ask about model binding — the DefaultModelBinder maps posted form fields to a strongly typed object's properties by name before the action executes, and you can write a custom IModelBinder to handle non-trivial mapping, such as binding a comma-separated query string into a collection.

🏏

Cricket analogy: The match-day sequence always runs toss, then national anthem, then first ball in a fixed order that can't be skipped, similar to how MVC filters execute in a fixed order: Authorization, then Action, then Result, with Exception filters able to intercept at any point.

A common wrong answer is confusing the [OutputCache] filter with browser caching headers. OutputCache caches the rendered output on the server (or a downstream proxy) so subsequent requests skip re-executing the action entirely, whereas cache-control headers merely instruct the browser whether to reuse its own local copy.

State Management and Validation

A classic interview question distinguishes ViewData, ViewBag, and TempData: ViewData is a dictionary and ViewBag its dynamic wrapper, both scoped to the current request only, while TempData persists just long enough to survive one redirect (typically backed by Session) before it's cleared, making it ideal for post-redirect-get success messages. Equally common is explaining validation attributes like [Required] and [StringLength] from System.ComponentModel.DataAnnotations, which drive both server-side ModelState validation and, combined with jquery.validate and jquery.validate.unobtrusive, client-side validation without writing manual JavaScript.

🏏

Cricket analogy: A team's team-sheet lasts only for the current match (like ViewData/ViewBag lasting one request) while a suspension carried over to the next match (like TempData surviving exactly one redirect) illustrates the classic interview question about state lifetime differences.

Interviewers often push past the definition and ask for a concrete lifetime scenario: 'If I set TempData in an action and the next request is a redirect followed by another request, is it still there?' The correct answer is no by default — TempData is removed after being read once, unless you call TempData.Keep() to preserve it for an additional request.

MVC cleanly separates Model, View, and Controller responsibilities, unlike Web Forms' mixed markup and code-behind.
Attribute routing ([Route]) offers per-action precision, while convention routing centralizes a site-wide URL pattern.
Action selectors like [HttpPost] and [ActionName] disambiguate methods sharing a route or expose a different URL segment.
MVC filters execute in a fixed order: Authorization, then Action, then Result, with Exception filters able to intercept at any stage.
The DefaultModelBinder maps posted form data to typed objects; custom IModelBinder implementations handle non-trivial cases.
ViewData/ViewBag last one request; TempData survives exactly one redirect and is cleared after being read, unless Keep() is called.
DataAnnotations validation attributes drive both server-side ModelState checks and unobtrusive client-side validation.