How we vet a senior Rails engineer

The strongest résumé we saw last quarter didn't make it past the first interview.

Ten years of Rails. A couple of apps you'd recognize. He could talk about Postgres query plans for an hour and mean all of it. Then we handed him a real controller from a real (anonymized) codebase, asked him to add a small feature, and he started typing in about fifteen seconds. Didn't open the model. Didn't look at the specs. Never asked what the thing was actually for. The code worked. It also quietly broke a callback he hadn't bothered to read.

We said no, and it wasn't close.

That gap — between someone who knows a lot of Rails and someone you'd actually hand your codebase to — almost never shows up in the knowledge. It shows up in the first two minutes with code they didn't write. So that's where we spend the interview.

Why the usual screen tells you nothing

Most technical interviews test a skill that has close to nothing to do with the job. You can grind algorithm puzzles for a month and still drop an N+1 into your busiest endpoint on day three, because invert a binary tree and notice this hits the database inside a loop are not the same muscle.

So we don't do puzzles. Everyone who ends up on our roster spends real time inside a real Rails app — one with the accumulated weirdness every production codebase has after a few years — and we watch how they move through it. Here's what we're paying attention to.

They read before they touch anything

Hand a strong senior an unfamiliar PlacementsController and they go quiet for a minute. They open the model, skim the callbacks, glance at the specs, poke at the schema. They're drawing a map before they change the territory. The question in their head is what will this break, not how do I make the failing test green.

Weaker candidates lock onto the first method that looks familiar and start editing. It feels productive. It's usually exactly how the callback bug gets in.

The ActiveRecord instinct you can't fake

This one's a clean filter. We show someone a page that loads slowly and ask them why. What I'm listening for isn't add an index — plenty of mediocre engineers have that reflex. It's whether they see the shape of it:

@placements = Placement.active

# ...and then, in the view, once per row:
@placements.each do |placement|
  placement.account.name   # a query per placement. the classic.
end

A senior calls it before you've finished describing the page. The boring fix writes itself:

@placements = Placement.active.includes(:account)

But the part I actually care about comes next, and it's the part nobody can memorize. They squint and ask whether we even need to load full Placement objects for a read-only table, or whether this wants a pluck or a thin query object instead. They're not tuning the query. They're questioning the premise. That reflex — do we need to be doing this at all — is most of what senior means, and it's most of what a whiteboard can't see.

Anyone can get the suite green. We're hunting for the person who's already thinking about whoever reads this code six months from now.

Tests are where the years show

Closely related, and just as revealing: do their tests describe behavior, or implementation? Good ones keep passing when you rename a private method and start screaming the instant the real contract breaks. When someone stubs three layers deep and asserts that a specific private method got called, it's a near-certain sign they've written a lot of code but haven't had to live with much of it. Maintenance teaches a kind of restraint you can't get any other way, and it leaks into everything.

The part everyone underrates

For most of your relationship with a remote engineer, they're a Slack message and a PR comment, often a few time zones off. So the whole way through the exercise, we're watching how they talk.

Do they say their assumptions out loud instead of guessing in silence? Do they surface a trade-off — I'd ship this for now, but I'd want to revisit it if traffic grows — without being asked? Can they push back on something we suggested without either folding or getting prickly about it?

A genuinely brilliant engineer who can't do that, async and in English, will cost a team more time than they save. We learned that one the expensive way, early on, which is why it's now a hard gate and not a bonus point.

What we don't care about

Not whether they've touched the newest gem. Not whether they'd write it the exact way we would. Not even whether they finished — a few of our best hires ran out of time because they spent it asking the right questions instead of rushing to done.

One thing, really: how they'd behave in your codebase on an ordinary Tuesday, when the ticket is dull and nobody's watching.

It's also why we can't do this at scale and don't pretend to. A vetting session like this takes a senior engineer the better part of an afternoon, and most candidates are a no. A small, hand-checked roster isn't us being precious about it. It's the only honest way we know to tell you the person showing up on your shortlist has actually cleared the bar.