Hiring Senior Engineers 
An Interview Loop That Predicts Performance 

The senior engineering interview loop most companies run was assembled by copying the large tech firms, and it was designed for a problem those firms actually have: filtering enormous applicant volume at low cost per candidate, with an explicit tolerance for rejecting good people to avoid accepting bad ones. A forty-person company has the opposite problem. You see few enough candidates that every false negative is expensive, you're competing for attention rather than filtering for it, and you cannot afford a five-round process because good senior candidates will accept something else during round three. Yet the loop persists — an algorithm screen, two more algorithm rounds, a system design conversation, a culture interview — and it produces a hire whose main demonstrated skill is having recently practised for interviews.

What you are actually trying to predict

It's worth being precise about the prediction, because most interview formats are chosen without one. For a senior engineer at a growth-stage company, performance in the first year is largely determined by four things: whether they can get productive in an unfamiliar codebase without a lot of hand-holding, whether they make sound engineering judgment under ambiguity and time pressure, whether they raise the quality of the people around them, and whether they can be trusted to own something end to end including the parts that aren't fun. Notice what isn't on that list — recall of algorithms they'll never implement, and the ability to design a globally distributed system on a whiteboard in forty minutes when your actual system is a well-structured monolith. The formats you choose should map onto those four predictions, and any round that doesn't map onto one of them should be justified or removed. This exercise alone usually shortens a loop by a round, because someone will discover that the third coding interview exists to make the panel feel thorough rather than to answer a question.

The formats, and what each one really measures

Live algorithmic problems measure preparation and performance under observation, which correlate with seniority far more weakly than their popularity suggests, and they systematically disadvantage experienced engineers who have been doing the job rather than practising for interviews. Unpaid multi-day take-homes measure availability — the candidate with a demanding job and childcare responsibilities loses to the one between roles, and you have filtered on the wrong variable. Working with existing code is the format that best resembles the job: give the candidate a small realistic repository ahead of time, then spend an hour with them fixing a bug, adding a feature, or reviewing a pull request that contains deliberate problems. Code review as an interview is chronically underused and unusually informative, because spotting an N+1 query, a missing authorization check, and a concurrency bug in someone else's code is very close to what a senior engineer does all week. System design is valuable when it's about a problem in your domain at your scale, with real constraints and trade-offs to reason through, and close to worthless as a recital of a reference architecture. And the deep-dive conversation about something the candidate actually built — pushed to the point where you understand the decisions they made and what they'd do differently — remains the single highest-signal hour available, because depth is hard to fake and unprepared follow-up questions expose it quickly.

A loop that works

• A 30-minute conversation with the hiring manager: role, context, and whether the candidate's interests match the actual work. Not a screen — a two-way qualification.
• A 60-minute technical deep dive on something they built, with follow-up questions that go three levels past the summary.
• A 90-minute practical session in a realistic codebase: fix, extend, or review, pairing with an engineer they'd work alongside. Paid if it happens outside working hours or exceeds this length.
• A 45-minute design discussion grounded in a problem your team has genuinely faced, with the constraints that made it hard.
• A short conversation with a peer or stakeholder outside engineering, for collaboration signal and to give the candidate someone honest to ask questions of.
• A structured debrief within 48 hours where every interviewer submits their assessment before hearing anyone else's.
• Total: four to five hours of candidate time across no more than two weeks, with a decision within three days of the final round.

Where good candidates leave

Most hiring failures at this size aren't judgment failures, they're funnel failures, and they're almost all about latency. The gap between a candidate applying and hearing from you, the gap between rounds while you coordinate calendars, the week of silence after the final interview while a decision gets made — each of those is a window in which someone else makes an offer. Senior engineers in a functioning market are typically in three processes at once, and the one that moves decisively has a real structural advantage that has nothing to do with compensation. Two weeks end to end is achievable if you pre-block interview slots rather than scheduling them reactively, and it is worth more than most of the things teams do to improve their offer. The other leak is the experience itself: an interviewer who clearly hasn't read the CV, a take-home that goes unacknowledged for ten days, a panel that can't answer what the team is working on. Senior candidates read all of this as information about how the company operates, and they're right to. Finally, be careful about the reflex to run 'one more round' when the panel is uncertain — additional rounds rarely resolve genuine uncertainty and reliably lose candidates. If you're unsure after four hours, the useful move is to name what you're unsure about and design one conversation that addresses it, or to acknowledge that the answer is no.

Calibration, scorecards, and the debrief

Unstructured interviews are close to noise, and the fix is neither elaborate nor expensive: decide in advance what each round is assessing, have interviewers write their assessment against those specific criteria, and require them to submit before the group discusses. Independent assessments first, discussion second — otherwise the first confident voice in the room becomes the group's opinion, and you have run one interview with several witnesses. Ask for evidence rather than impressions: 'they identified the missing authorization check and explained the blast radius' is a data point, while 'strong engineer, good vibes' is a feeling. Calibrate the panel by having new interviewers shadow before they score, and periodically look back at your hires — the honest question is whether your interview assessments actually predicted who performed, and most teams have never checked, which means they don't know which of their rounds is load-bearing. Be alert to the specific bias this stage produces: interviewers reward candidates who resemble themselves, which in a small team compounds quickly into a monoculture that is less capable than the sum of its members. A structured rubric doesn't eliminate this, but it makes it visible enough to argue with.

When hiring isn't the answer

It's worth asking, before running the loop at all, whether a permanent hire is what the situation requires — because a senior hire is a nine-to-fifteen-month commitment before full productivity when you account for search, notice period, and ramp, and the fully loaded cost is substantially higher than the salary line suggests. If the driver is a specific roadmap that needs to ship this year, or a capability you need once (a compliance programme, a platform migration, an AI feature you'll then maintain), hiring is a slow instrument for a fast problem, and a fractional team or a scoped engagement gets there sooner without the exit risk. If the driver is that your existing engineers are spending half their time on toil, an honest look at your delivery metrics may reveal that you have a throughput problem rather than a headcount problem, and that two of your current engineers are worth more than three new ones. Hire permanently for the work that is your long-term strategic core and that you want owned by people who'll be here in five years. That's a real and common case — it's just not every case, and running an expensive loop to solve a problem hiring can't fix is a costly way to find out.

How Infiniti Tech Partners fits in

We're not a recruiter, and we don't run searches — but we sit on the other side of this decision often enough to have a view worth sharing. Most of our engagements start with a CTO weighing a hiring plan against a delivery deadline, and the useful conversation is usually about which parts of the roadmap genuinely need permanent owners and which parts need to ship. Where we help directly is the second category: a dedicated pod of senior engineers on your codebase, with a lead who runs the delivery and reports to you, on terms that flex as your permanent hiring catches up. Teams frequently use that as a bridge — we ship the thing that couldn't wait while they run a proper two-week loop for the roles that matter long-term, and we hand over to the engineers they hire, with documentation and a transition rather than a cliff. If you're currently sizing a hiring plan and want a candid second opinion on which of those roles you actually need, that's a conversation we're glad to have.