The Senior Engineer Interview Loop That Actually Predicts Agency Performance

Hiring senior engineers for an agency is a different sport than hiring for a product company, and most teams don't notice until their third bad hire. The engineer who crushes a two-hour LeetCode gauntlet can still freeze on a Tuesday morning Slack message from a confused client PM. We've been refining our loop for years, and this is the version that actually predicts who will thrive.

Why agency hiring breaks when you copy FAANG

Product companies optimise for depth on a single codebase that an engineer will live inside for three to five years. Agencies optimise for something completely different: a senior engineer might touch four codebases this quarter, two of which they didn't architect, one of which uses a stack they last wrote in 2021, and all of which have a human on the other end asking why the staging link is broken.

That means the FAANG-style loop — algorithms, system design, behavioural, bar raiser — filters for the wrong signal. It rewards candidates who are good at interviewing in controlled conditions and penalises the ones who are good at the actual job: shipping under ambiguity, communicating trade-offs to non-technical stakeholders, and context-switching without losing quality.

We've hired both profiles. The pure algo-strong hires either quit within a year (bored, missing the clean problems) or quietly became net-negative because they couldn't talk to clients. The ones who stayed and compounded were almost always flagged as "a bit rough on the whiteboard but something feels right."

So we rebuilt the loop around what actually matters.

The five stages, and what each one is really testing

Our current loop has five stages. Total candidate time investment is roughly four to five hours, spread over two weeks. Total interviewer time per candidate is around six hours. That's deliberate — any shorter and you're guessing, any longer and good senior engineers drop out.

Stage 1: The 25-minute recruiter screen (filters for reality)

This isn't HR theatre. The person running it is a senior engineer or EM, not a recruiter, and the goal is to kill mismatches fast. We ask three things:

• What does your ideal week look like? (Looking for: tolerance for variety, not a request for a monastery.)
• Walk me through the last thing you shipped end-to-end, including what the business cared about.
• What's your read on agency work vs product work? Why us?

If a candidate can't articulate a business outcome from their last project, that's a flag. Not a kill — a flag. Senior engineers in agency work have to translate between "the migration is 60% done" and "we'll hit the launch date, here's what we're cutting."

Stage 2: The async code review (filters for taste)

We send a small, deliberately imperfect pull request against a public repo we maintain. It's about 200 lines of TypeScript with a mix of real bugs, questionable patterns, and perfectly fine code that a junior might "fix" out of habit. The candidate has 48 hours and roughly 45 minutes of actual work to leave review comments.

What we're reading:

• Do they distinguish "wrong" from "not how I'd do it"?
• Do they ask about context before prescribing?
• Can they prioritise — would they block merge on this, or leave a nit?

This stage tells us more about seniority than any live coding exercise. Juniors try to rewrite the PR. Mid-levels find the bugs. Seniors ask who the author is, what the deadline is, and whether the broken edge case is actually hit in production.

// Example snippet from our test PR
async function fetchUserOrders(userId: string) {
  const user = await db.users.findOne({ id: userId });
  const orders = await db.orders.find({ userId: user.id });
  return orders.map(o => ({
    ...o,
    total: o.items.reduce((s, i) => s + i.price * i.qty, 0)
  }));
}

There are at least four things to say about those eight lines. A senior spots the N+1 risk if this is called in a loop, the missing null check on user, the fact that total probably belongs in the database or a shared util, and — the one most candidates miss — asks whether price is already in the correct currency and precision. That last question is the tell.

Stage 3: The 90-minute pairing session (filters for how they actually work)

No whiteboard. We pair on a real-ish problem in a repo they can clone beforehand. The problem is scoped so that finishing it in 90 minutes is impossible on purpose. We want to see what they cut, what they ask, and how they behave when they're stuck.

The interviewer is explicitly told to act like a mildly distracted teammate, not a judge. If the candidate asks a reasonable question, answer it. If they go down a wrong path, let them for a few minutes, then nudge.

What kills candidates at this stage:

• Silent coding for 20 minutes straight
• Refusing to Google or check docs (we tell them it's fine; some don't believe us)
• Over-engineering a solution to a problem that was clearly scoped as "get it working"
• Under-engineering in a way that ignores obvious client-facing concerns (no error handling, no loading states, no thought about what happens when the API is slow)

Stage 4: The client simulation (filters for the part everyone else skips)

This is the stage that catches hires other agencies miss. One of our PMs or delivery leads role-plays a non-technical client. The scenario is written down and rotated regularly, but the shape is always the same: something has gone wrong, the client is anxious, and the engineer has to handle a 20-minute conversation.

A real example: "The checkout page was slow during a flash sale yesterday. The client has seen a drop in conversion and wants to know (a) what happened, (b) whose fault it is, and (c) what you're going to do. You have partial information — here's the Grafana screenshot and the last three Slack messages from the on-call engineer."

We're not looking for the right technical answer. We're looking for whether they can:

• Acknowledge the client's concern without grovelling or getting defensive
• Separate what they know from what they're guessing
• Commit to a next step with a timeline
• Avoid throwing a teammate under the bus even when it would be easy

This is the single highest-signal stage in our loop. We've killed offers for strong engineers here, and we've pushed through offers for engineers who were only okay in the pairing round because this stage was outstanding.

Stage 5: The reverse interview (filters for mutual fit)

The candidate meets a founder or principal for 45 minutes with no evaluation agenda. They drive. We answer honestly about pay bands, bench time, the worst client we've ever worked with, the last time payroll was tight, and what we got wrong on our most recent product bet.

Senior engineers in 2026 have options. If you're not willing to be candid at this stage, the ones you want will take the other offer.

What we deliberately don't test

We don't do take-homes longer than two hours. We don't do system design on a whiteboard — we do it in the pairing session, in context, on a real stack. We don't ask trivia. We don't ask about weaknesses. We don't have a "culture fit" round, because culture fit is what biased hiring looks like when you write it on the scorecard.

We also don't test for stack-specific knowledge beyond "can you read it." A senior engineer who's strong in Rails will be productive in our Node codebase in two weeks. Hiring for exact stack match is how you end up with a team that can't absorb a new client project.

Scoring without lying to yourselves

After the loop, the interviewers meet for 30 minutes. Each person gives a strong hire / hire / no hire / strong no hire, and — this is the important bit — writes their vote down before the discussion starts. Otherwise the loudest interviewer anchors the room.

A single strong no hire from someone who can defend it kills the offer. We've been burned enough times overriding a dissenter to know that gut-level "something is off" from a senior interviewer is usually right, even when they can't fully articulate it in the moment.

What we'd do if we were starting over

If you're building an agency hiring loop from scratch, start with stage 4 — the client simulation — and work backwards. That one stage will teach you more about what senior means in your specific business than any framework you'll read. Then add a pairing round, then an async code review, then the bookend conversations. Resist the urge to add stages. Every stage you add past five costs you candidates, and the ones you lose first are the ones with the most options.

If you want to see how we structure engineering teams around this kind of hiring, our services page walks through how we staff client work, and our blog has more on the agency-to-product transition that this hiring loop is designed to support.