"Walk me through a Rails request"

What the interviewer is actually checking

Most Rails developers can describe controllers and views. Far fewer can name Rack, walk the middleware stack, explain where the routing happens in the boot sequence, or describe what Active Record does between User.find(1) and the result coming back.

The interviewer is checking how much of the framework you can actually name. The depth signal is "how many distinct layers can you describe without prompting." A mid-level candidate covers three. A senior candidate covers seven or eight, in order, with at least one detail per layer that goes beyond the official tutorial.

This question also acts as a warm-up for follow-ups: "where would you put a global rate limit?", "how does session state survive across requests?", "what happens if the view raises?". A candidate who can sketch the full request path can answer those quickly. A candidate who skipped layers cannot.

The mid-level answer

The typical answer:

"The browser sends an HTTP request. Rails routes it to a controller action. The controller fetches data using Active Record, then renders a view. The view's HTML gets sent back to the browser."

Correct, but skips most of the actual framework. No Rack. No middleware. No mention of how routing is parsed. Nothing about asset serving, session loading, parameter parsing, view rendering, response building.

For a senior role this answer signals "treats the framework as a black box." It tells the interviewer the candidate would struggle to debug anything that does not happen in user code.

The senior answer

The senior version names eight layers in order.

1. The web server. "Puma (in 2026 Rails defaults) accepts the TCP connection, parses the HTTP request into a Rack env hash. Multiple threads serve requests in parallel inside one process; multiple processes scale horizontally."

2. Rack middleware. "The env hash flows down the middleware stack. bin/rails middleware lists them: things like ActionDispatch::HostAuthorization, Rack::Sendfile, ActionDispatch::Static, the cookies middleware, session middleware, then the Rails router. Each one wraps the next."

3. Routing. "The router walks config/routes.rb for the first match. It parses the path, sets params from URL segments and query string, identifies the controller class and action method to call. If nothing matches, a 404 comes back from the router."

4. Controller instantiation. "Rails instantiates the matched controller. before_action filters run in order. If one halts (renders or redirects), the action method never runs. Strong parameters get applied to whitelist permitted attributes."

5. The action body. "Application code runs. Most actions hit Active Record, which translates Ruby method calls into SQL via Arel and the database adapter, sends it to Postgres, hydrates the result into model objects. Connections come from a pool managed by ActiveRecord::ConnectionPool."

6. View rendering. "If the action does not explicitly render, Rails picks a template by convention (app/views/posts/show.html.erb for PostsController#show). The template is compiled to Ruby code once on first hit, cached. ERB or Hotwire stream templates render against the controller's instance variables. The result is a string of HTML."

7. Layout wrapping. "Unless disabled, the rendered template is yielded into the layout template (default app/views/layouts/application.html.erb). Layout fragments like the navbar and footer get rendered too. The final string is the full HTML response body."

8. Response and unwinding. "after_action filters run. The response (status, headers, body) flows back up through the middleware stack. Each middleware can transform it: setting cookies, adding security headers, compressing, logging. Puma writes the HTTP response to the socket."

Eight named layers, in order, with one detail per layer that goes beyond the rendered surface. That is a senior answer.

The follow-ups

Three common pressure-tests after the headline answer.

"Where would you add a global rate limit?" The right answer is middleware. rack-attack is the canonical gem. It sits in the middleware stack before the router, so rate-limited requests get a 429 without ever touching application code. A controller filter is the wrong answer because rate-limited traffic still incurs full controller dispatch.

"Walk me through what happens if the action raises." The right answer names the ActionDispatch::DebugExceptions and ActionDispatch::ShowExceptions middleware. In development, the debug exceptions page renders. In production, the show exceptions middleware catches the raise and renders the matching error page (404, 500). Bonus points for naming rescue_from in controllers as the application-level alternative.

"How does session state survive across requests?" The right answer names the session middleware and the default cookie store. The session is serialised, signed, and stored as a cookie on the browser; each request includes it; the middleware deserialises and verifies the signature. For larger session payloads or higher security, alternatives are the Active Record store (sessions in a database table) or Redis store.

What signals what

• "The router calls the controller." Mid-level. Skips middleware entirely.
• "There is some middleware stack..." Better. Acknowledges Rack but does not enumerate.
• "bin/rails middleware lists them; the first few I usually open during debugging are..." Senior. Has actually looked at the stack.
• "And the response flows back up through the stack, so middleware can modify it on the way out." Senior+. Knows that middleware is bidirectional.

The signal that matters: candidates who have debugged a Rails app in production, encountered "the request never reached my controller" or "the response had unexpected headers," and traced through the middleware stack to find the cause. That experience leaks into the answer naturally.

The principle at play

Rails is not magic. Every framework feature has a layer, a file, an interface. The senior version of any Rails answer is one that names the layer and the responsibility. The junior version is one that treats the layer as implicit.

For this question specifically: knowing the eight layers above gives you a vocabulary for almost every follow-up the interviewer can throw. Rate limiting, error handling, authentication, asset serving, CORS, security headers, websocket upgrades, response streaming. All of these have a specific layer where the answer lives. Name the layer, and the rest of the answer is easier to find.