How to Vet Senior Engineers Before You Hire

The most expensive hiring mistake in software is not the junior who needs coaching — it is the "senior" engineer who interviews beautifully, commands a senior rate, and then spends six months producing confident, plausible, architecturally disastrous work before anyone senior enough to notice looks closely. We vet engineers for a living: every engineer we place through our staff augmentation practice goes through the process described below, and we reject a large majority of applicants who describe themselves as senior. This post is that process, shared openly, because most of it costs nothing to adopt.

First, Define What Senior Actually Means

Strip away the years-of-experience proxy and seniority is three capabilities:

• Judgment under constraint. Choosing the right solution given this deadline, this team, this legacy system — not the textbook-optimal one. Ten years of experience can be ten years of judgment or one year repeated ten times; the CV cannot tell you which.
• Debugging as a discipline. Seniors form hypotheses, isolate variables, and read source code when the docs run out. This is the single most transferable engineering skill and the least interviewed one.
• Force multiplication. A real senior makes the engineers around them faster — through reviews, through questions asked in planning that save weeks, through documentation nobody asked them to write. A brilliant engineer who degrades the team is a mid-level engineer with a negotiating advantage.

Every stage below is designed to surface one of these three. If an interview activity does not map to one of them, we cut it — which is why you will find no algorithm puzzles here. LeetCode performance measures preparation for LeetCode. We have interviewed engineers who could invert a binary tree on a whiteboard and could not explain why their last production system fell over, and we know which question the client cares about.

Stage One: The Past-Project Deep Dive (60 Minutes, Highest Signal)

Ask the candidate to pick the system they know best and spend a full hour going progressively deeper. The structure matters less than the follow-ups. What we probe:

• "Walk me through the architecture — and why it looked that way." Listen for constraints, not diagrams. A senior says "we chose Postgres over a document store because our access patterns were relational and the team already knew it." A performer recites the tech stack like a menu.
• "What was your specific contribution?" Push past "we" to "I" — politely, repeatedly. Vague ownership on a deep dive is the most common way inflated CVs come apart. Ask what the hardest code they personally wrote was, and then ask a detail question about it.
• "What would you do differently now?" Every real system contains regrets. A candidate who defends every decision either did not make the decisions or has not grown since. The best answers we hear are specific and a little painful: "I built an event-driven pipeline where a cron job would have done, and the team paid for my curiosity for two years."
• "Tell me about the worst production incident on this system." This is our single favourite question. It tests debugging discipline, honesty, and ownership at once. Seniors tell you the timeline, the wrong hypotheses they chased, the actual root cause, and what changed afterwards. Non-seniors tell you a story where they were the hero within ten minutes.

One hour of this beats any take-home. Fabricated depth collapses under third-level follow-ups — nobody can improvise the migration plan, the monitoring gaps, and the on-call pain of a system they did not really build.

Stage Two: A Practical Exercise in a Realistic Codebase

When we test coding at all, we do it in a small but realistic codebase — a few thousand lines, with existing patterns, a test suite, and one deliberately mediocre corner — not a blank editor. The task is representative: fix a subtle bug, add a small feature that touches three layers, or review a pull request we prepared. Time-boxed to 90 minutes, their own machine and tools, search and AI assistants allowed, because that is how the actual job works and pretending otherwise selects for the wrong skill.

What we grade, in order of weight:

1. Did they read before writing? Seniors spend the first twenty minutes orienting — running the tests, tracing the data flow, finding the existing conventions. Juniors start typing in minute two.
2. Does the change fit the codebase? Matching existing patterns, even imperfect ones, instead of introducing a personal style mid-file. Consistency is a senior instinct; novelty is a junior one.
3. The PR review variant is often the best test of all. Hand them a pull request containing one real bug, one performance smell, and some cosmetic noise. Seniors find the bug, mention the smell, and let the noise go with a light comment. Reviewers who write eleven comments about naming and miss the race condition have told you exactly what their code reviews will do to your team.

Stage Three: System Design, Scoped to Their Claims

System design interviews go wrong when they become trivia about hyperscale infrastructure the candidate will never touch. We scope the problem to the candidate's claimed experience and to the actual role: if they will build B2B SaaS, we ask them to design a multi-tenant reporting feature, not a global chat system for a billion users.

The discriminating moves we watch for:

• They interrogate requirements before drawing boxes. "How many users? How fresh does the data need to be? What is the write pattern?" A candidate who starts sketching microservices before asking a single question is showing you a rehearsed performance.
• They name trade-offs unprompted. "Denormalising here makes reads fast but we will pay for it on every update — acceptable because this is read-heavy." The word "because" is the sound of seniority.
• They scale the solution to the problem. Our favourite failure mode to probe: give a problem that a boring monolith and one database solve perfectly. Candidates who cannot resist adding queues, caches, and service meshes to it are telling you they design for their CV, not for your product.
• They can go down as well as up. Ask one deep question — what actually happens on this index when writes spike, how does this cache invalidate, what breaks first under load. Seniors have scars at the detail level; slide-ware architects do not.

Portfolio Versus System Design: Weigh the Portfolio

When the two conflict — a candidate with shipped, running products but an average whiteboard performance, versus a polished designer of hypothetical systems with a thin shipping record — we take the shipper, and it is not close. Shipping proves the whole loop: decisions made under constraint, edge cases survived, software operated after launch. Whiteboard fluency proves preparation. The ideal candidate has both, but production evidence is the one you cannot fake. Ask for links, repos, case studies — and then ask deep-dive questions about them, because attribution, not existence, is what needs verifying.

Red Flags That Override a Strong CV

• Cannot name a genuine mistake. Ten years without a self-attributed failure means low self-awareness or low honesty. Both are disqualifying in someone your team will trust by default.
• Every previous team was incompetent. One bad employer is plausible. Three consecutive ones means the common factor is in the room with you.
• Framework identity. Candidates who define themselves by a tool ("I am a React developer" as a worldview, not a skills summary) tend to bend every problem toward that tool. Seniors hold tools loosely.
• No questions about your problem. A senior engineer being hired into a product they know nothing about should be curious about it. A candidate with zero questions about the domain, the team, or the codebase is interviewing for any job, not this one.
• Certainty without context. Sweeping answers — "you should always use microservices," "never use an ORM" — before asking a single question about your situation. The senior answer to most engineering questions begins with "it depends," followed immediately by what it depends on. The first half without the second is a different red flag: vagueness dressed as wisdom.

Reference Checks: Ask Narrow Questions

References answer broad questions with kindness and narrow questions with information. Skip "how was it working with them?" and ask: "What did they own end to end?" "Would you put them alone in front of your most important client?" "When they disagreed with a technical decision, what did they do?" And the closer that actually works: "Would you hire them again — and for the same role or a different one?" The pause before that answer is data.

The Process Is the Product

None of this is exotic. It is a sixty-minute conversation with real follow-ups, ninety minutes in a realistic codebase, a right-sized design discussion, and three narrow questions to a reference — perhaps five hours of structured attention per serious candidate. Teams skip it because five hours feels expensive, and then spend six figures and six months on the alternative.

If you would rather start from a pool that has already been through this filter, our staff augmentation service places engineers who have passed exactly this process — and we always encourage clients to run their own interviews on top. Book a free consultation and we will tell you honestly whether augmentation even fits your situation.