How to Vet Senior Engineers Before You Hire

The costly hiring mistake in software is rarely the junior who needs coaching. It is the engineer with a senior title who interviews well, is paid a senior rate, and then produces confident, plausible work with serious structural problems for months before anyone looks closely. This post describes an interview process built to tell the difference. Most of it costs nothing to adopt, and it treats candidates fairly: the same stages, the same questions and the same scoring for everyone.

Define What Senior Means First

Set aside years of experience, and seniority comes down to three capabilities.

• Judgment under constraint. Choosing the right solution for this deadline, this team and this legacy system, which is often not the textbook answer. Ten years of experience can mean ten years of growing judgment or one year repeated ten times, and a résumé cannot tell you which.
• Debugging as a discipline. Forming hypotheses, isolating variables, and reading source code when the documentation runs out. It transfers across every stack, and few interviews test it.
• Making the team better. Through code reviews, through planning questions that save weeks, through documentation nobody asked for. A brilliant engineer who slows everyone else down is not senior in the way your team needs.

Each stage below is meant to bring out one of these three. An interview activity that maps to none of them can go, which is why there are no algorithm puzzles here. Puzzle performance mostly reflects puzzle practice. A candidate can invert a binary tree on a whiteboard and still be unable to explain why their last production system failed, and the second question is the one your product depends on.

Stage One: The Past-Project Deep Dive

Ask the candidate to pick the system they know best, then spend a full hour going steadily deeper. The follow-up questions matter more than the structure. Four prompts do most of the work:

• “Walk me through the architecture, and why it looked that way.” Listen for constraints, not diagrams. A strong answer sounds like “we chose Postgres over a document store because our access patterns were relational and the team already knew it.” A weak one lists the stack.
• “What was your specific contribution?” Politely move the answer from “we” to “I”. Ask which piece of code was the hardest they personally wrote, then ask a detail question about it. Allow for confidentiality: some candidates cannot share specifics of an employer’s system, and they should be free to describe it in general terms.
• “What would you do differently now?” Every real system contains regrets. A candidate who defends every decision may not have made those decisions. Good answers are specific and a little uncomfortable, for example: “I built an event-driven pipeline where a scheduled job would have done, and the team maintained that extra complexity for two years.”
• “Tell me about the worst production incident on this system.” This tests debugging discipline, honesty and ownership together. Experienced engineers give you the timeline, the wrong hypotheses, the root cause and what changed afterwards, much as a blameless postmortem would. If incidents like this interest you, our post on what breaks when RAG goes to production is a worked example of the genre.

An hour like this usually tells you more than a take-home test. Depth that was borrowed from a teammate is hard to sustain through third-level follow-ups about the migration plan, the monitoring gaps and the on-call burden.

Stage Two: A Practical Exercise in a Realistic Codebase

If you test coding, use a small but realistic codebase: a few thousand lines with existing patterns, a test suite and one deliberately mediocre corner. A blank editor tells you much less. Make the task representative, such as fixing a subtle bug, adding a small feature that touches three layers, or reviewing a prepared pull request. Limit it to about 90 minutes, let candidates use their own machine, and allow search and AI assistants, because that is how the job is done. Keep it short out of respect for the candidate’s time, offer reasonable adjustments where someone needs them, and pay for anything longer.

What to grade, in order of weight:

1. Did they read before writing? Experienced engineers spend the first part of the session orienting: running the tests, tracing the data flow, finding the conventions.
2. Does the change fit the codebase? Look for changes that match existing patterns, even imperfect ones, and do not introduce a personal style in the middle of a file.
3. How do they review? Give them a pull request with one real bug, one performance problem and some cosmetic noise. A strong reviewer finds the bug, mentions the performance problem and lets the noise go with a light comment. Eleven comments about naming and none about the race condition tell you how their reviews will feel to your team. Google’s public code review guidelines are a good yardstick for what a useful review looks like.

Stage Three: System Design, Scoped to the Role

System design interviews go wrong when they become trivia about hyperscale infrastructure the candidate will never touch. Scope the problem to the candidate’s stated experience and to the actual role. For a B2B SaaS role, ask for a multi-tenant reporting feature, not a chat system for a billion users.

Signals to watch for:

• Requirements come before boxes. “How many users? How fresh does the data need to be? What is the write pattern?” A candidate who sketches microservices before asking anything is giving a rehearsed answer.
• Trade-offs are named without prompting. “Denormalizing here makes reads fast, and we pay for it on every update, which is acceptable because this is read-heavy.” Listen for the word “because”.
• The solution is sized to the problem. Offer a problem that a plain monolith and one database solve well, and see whether queues, caches and a service mesh appear anyway.
• They can go down a level as well as up. Ask one deep question: what happens to this index when writes spike, how this cache invalidates, what breaks first under load.

When Portfolio and Whiteboard Disagree

Sometimes a candidate has shipped, running products but gives an average whiteboard performance, while another designs hypothetical systems fluently and has shipped little. We give more weight to the shipped work. Shipping shows the whole loop: decisions made under constraint, edge cases handled, software operated after launch. Whiteboard fluency can come from preparation alone. Ask for links, repositories or write-ups, then ask deep-dive questions about them, because what needs verifying is the candidate’s own part in the work. Nerves are real too, so give people a second format in which to show what they know.

Warning Signs Worth a Follow-Up Question

None of these should end an interview by itself. Each one is a reason to ask another question.

• No mistake they can name. A long career without a single self-attributed failure suggests limited self-awareness or limited candor.
• Every previous team was incompetent. One bad employer is plausible. A pattern across several deserves a closer look.
• Identity tied to one tool. Candidates who see every problem through a single framework tend to bend problems toward it. Senior engineers hold tools loosely.
• No questions about your problem. Someone joining a product they know nothing about should be curious about the domain, the team and the codebase.
• Certainty without context. Sweeping rules (“use microservices”, “avoid ORMs”) before a single question about your situation. A good answer often starts with “it depends” and then says what it depends on. “It depends” with nothing after it is a warning sign of a different kind.

Keep the Process Fair and Consistent

Use the same stages, the same questions and a written scoring guide for every candidate, and have interviewers write their notes before they compare them. Structured interviews of this kind are what public bodies recommend: the US Office of Personnel Management publishes guidance on structured interviews, and the EEOC explains how employment tests and selection procedures must relate to the job and be applied consistently. Employment law differs by country, so check local rules before you add tests or reference checks.

Reference Checks: Ask Narrow Questions

With the candidate’s consent, ask references narrow questions. Broad ones get kind answers, and narrow ones get information. Skip “how was it working with them?” and ask: “What did they own end to end?” “When they disagreed with a technical decision, what did they do?” “Would you hire them again, and for the same role or a different one?”

What It Adds Up To

The whole process is an hour of conversation with real follow-ups, 90 minutes in a realistic codebase, a design discussion sized to the role, and a few narrow reference questions. That comes to roughly five hours of structured attention per serious candidate, a small cost next to months of rework from a poor senior hire. If you are still deciding between hiring and an outside team, our comparison of fixed-price and monthly engagement models covers the other side of that choice.

We use the same stages when we interview engineers for our staff augmentation service, and we encourage clients to run their own interviews as well. We send 2 to 3 developer profiles within 48 hours of the call, and if a developer is not the right fit in the first two weeks, we replace them at no cost. Request a call and we will tell you plainly whether augmentation fits your situation.