What senior interviews measure

Two answers to the same question

"This endpoint is slow. What would you do?"

The first candidate lists techniques: add an index, cache the response, move the work into a background job. Nothing they say is wrong. The second candidate asks how slow, for whom and since when. Then they narrow it down. The invoice list sits at a p95 of 1.8 seconds, and it regressed after a release three weeks ago. The obvious index is already there, and the cost only shows up for accounts with more than fifty line items. So it's an N+1 that the seed data never produced. They also say what they wouldn't do: no cache here, because a cache would hide a bug that's about to get worse.

Both candidates know Rails. Only one of them made a decision.

What changes at this level

Earlier interviews ask whether you can build the thing. The problem arrives with its edges already drawn, and your job is to fill it in correctly.

Senior interviews ask whether you can decide what to build when nobody has drawn the edges, and be right often enough that a team can follow you.

The bottom two rows are where offers are won and lost. A candidate who waits to be told the constraints is answering a mid-level question, however good the code is.

The loop you should expect

At Rails shops hiring seniors, the process usually runs like this: a recruiter screen, a technical phone screen, then five or six rounds. Those rounds cover coding, system design, behavior and a deep dive on something you built. Two of them surprise people.

The first is code reading. You get a few hundred lines of unfamiliar real code, often carrying a defect someone already knows about. The interviewer isn't timing how fast you find it. They're watching how you move. Do you read the test first? Do you check what the callee returns before claiming the caller ignores it? Do you say out loud what you've ruled out and why?

The second is the architecture conversation: "Walk me through the hardest technical decision you made this year." This isn't storytelling. They want the alternatives you rejected, the thing you were wrong about and what you'd do differently now.

There's also a cross-functional round with product, design and sometimes support. It's a real scored round, and engineers who treat it as a formality lose offers in it.

The four signals

Behind whatever rubric the company uses, interviewers are listening for four things.

The first is scope. How much of the system do you reason about unprompted? Given a slow endpoint, do you stay inside the controller, or do you reach the queue, the replica lag and the deploy that caused it?

The second is ambiguity. What do you do with an underspecified problem? Strong candidates state their assumptions out loud and keep going. Weak candidates either freeze or pretend the ambiguity isn't there.

The third is direction. Can you say what should happen next, in what order and why that order? "We'd fix the N+1 first, because it's one day of work and removes the pressure to shard" is direction. "There are several options" isn't.

The fourth is judgment. Do your trade-offs hold up when pushed? This is the signal that separates rehearsed answers from real ones, because a rehearsed answer has no second layer.

Senior or staff?

Both titles get the same questions. The scoring differs.

A senior answer owns one complete production service end to end. It quantifies the workload, names the SLO, finds the bottleneck, handles failure and on-call and defends its trade-offs without waiting for the interviewer to hand over every constraint.

A staff answer keeps that depth and adds the part that crosses teams. That means where the boundary between services should sit, what the interface to the other three teams looks like, how the migration runs while the business keeps shipping and who has to adopt it for the work to matter.

If you're interviewing for staff and your answer never leaves one codebase, you're being scored as a senior.

Three ways qualified people lose these rounds

The first is answering the mid-level version of the question. Asked "how would you cache this?", a mid-level answer explains cache keys and expiry. A senior answer says whether the thing should be cached at all, and what breaks when the cache is wrong. The question sounds like it's about technique, but it's testing whether you noticed it was a decision.

The second is staying inside the code. A senior answer reaches deploys, migrations, on-call, the cost of the change and who else needs to know without being asked. An answer that never leaves the editor scores as a strong mid-level one.

The third is winning the argument. Interviewers push back on purpose, sometimes with something they know is wrong. Treat the push-back as information to weigh rather than a debate to win. Candidates lose rounds here that they had already passed on technical grounds.

Meridian: the system you'll be asked about

Every lesson here uses the same system, the way a real loop keeps circling back to one thing.

Meridian is a B2B invoicing SaaS. It runs Rails 8, PostgreSQL and Solid Queue for background work, with twelve engineers and around 4,000 business customers. Invoices are generated nightly per account, some accounts have hundreds of thousands of line items and the monthly close on the first business day brings four times normal traffic. The enterprise contracts carry an uptime commitment, and nobody has written down what it means.

That last sentence is deliberate. Most senior interview questions are one unwritten constraint wearing a technical costume.

What this course covers

1. What senior interviews measure: this lesson
2. Architecture questions and trade-offs: the four things every design round scores
3. Scaling Rails questions: replicas, shards, caches and when each one is the wrong answer
4. Observability and incident questions: SLOs, error budgets and the incident story you need ready
5. Technical debt and upgrade questions: making debt an engineering argument instead of a complaint
6. Answering "it depends" well: the most abused phrase at this level
7. Senior mock, putting it all together: a full loop against Meridian, scored

Start with the round that carries the most weight: the design conversation, where trade-off reasoning counts for more than the diagram.