What I Look For When Interviewing Senior Engineers

A candidate once solved my system design question in about eight minutes. Clean data model, sensible partitioning, the right message broker, a cache in the right place. On paper it was the best answer I had seen all quarter. I did not extend an offer.

The reason is the whole point of this post. When I asked "what happens when this Kafka consumer falls three hours behind during a Black Friday spike," the answer was "we'd scale the consumers." When I asked what happens to the payment idempotency keys while it is behind, whether the downstream ledger can tolerate out-of-order settlement, and how on-call would even know, the confidence drained out of the room. The design was memorized. The judgment underneath it was not there.

I have interviewed for senior and staff roles at a fintech scaling through hypergrowth, a logistics platform moving real freight and real money, and a security SaaS where a bad deploy is a customer's incident. I have made good hires and I have made expensive mistakes. This is what I actually look for now, and how I probe for it. None of it is about whether you can invert a binary tree.

Seniority is a measure of blast radius, not years

The first thing I calibrate is what "senior" even means for the role, because the title is inflated everywhere and means nothing on its own. I do not care that you have ten years of experience. I care about the largest blast radius you have been trusted with and what you did with it.

Blast radius is the real ladder. A mid-level engineer owns a feature. A senior engineer owns a system and its failure modes. A staff engineer owns a decision that will constrain three teams for two years. The interview is my attempt to figure out, honestly, which of those you can be trusted with on day one, not which one your last title claimed.

So early on I ask a deceptively boring question: "Tell me about the most operationally significant thing you owned. Not built, owned. What broke, and what did you change so it stopped breaking?" The word "owned" is doing work. Plenty of people have been near a big system. I want the person who got paged for it, who felt the cost of their own design choices at 2 a.m., and who then went and fixed the design rather than the symptom.

The tell is specificity. Strong candidates get more precise as you push, not vaguer. They say "the p99 on the settlement endpoint was 400ms because we were doing a synchronous fraud check inline, so I moved it behind an async decision with a pending state and a reconciliation job." Weaker candidates go the other way. Under pressure they retreat into architecture-astronaut language: "we adopted an event-driven microservices approach to improve scalability." That sentence contains no information. Real ownership is remembered in specifics because you lived the specifics.

I want to see reasoning under an underspecified problem

Real engineering work almost never arrives specified. The ticket says "make checkout faster." The requirement behind it is a quarter of revenue. The job of a senior engineer is to turn ambiguity into a set of decisions with stated trade-offs, and I cannot evaluate that with a puzzle that has one correct answer.

So my design prompts are deliberately underspecified, and the first thing I am grading is whether you notice. I might say: "Design a system to charge customers for metered API usage." That is it. The candidates I want lead with questions, and the questions themselves are the signal.

"What is the billing granularity, per-request or aggregated? What is the acceptable delay between usage and the charge showing up? Are we the system of record for money, or is Stripe? What is our tolerance for double-charging versus under-charging, because those have very different costs?"

That last question is the one I am listening for. In a metered billing system, double-charging a customer is a support ticket and a refund. Under-charging silently is lost revenue that compounds for months before finance notices. A senior engineer knows those are not symmetric and designs for the expensive failure. A candidate who dives straight into "I'll use a time-series database" has skipped the only part of the problem that required judgment.

I will occasionally change a requirement mid-answer to see how someone handles it. "Actually, assume usage events can arrive up to 24 hours late and out of order." A brittle thinker treats this as an attack on their design and gets defensive. A strong one says "good, that kills my naive approach, here is what changes," and reworks it. Real requirements move. I need to know you can move with them without ego.

Depth in at least one thing, and honesty about the rest

I have a strong bias for T-shaped engineers, and I say so openly. I want genuine depth in at least one area, distributed systems, database internals, the JVM, networking, security, something, plus enough breadth to work across the stack without being helpless.

The depth matters because it is proof you have gone past the documentation at least once in your life. Anyone can wire up Postgres. I want to know if you have ever had to reason about why your SELECT ... FOR UPDATE was causing lock contention under load, or what actually happens during a VACUUM, or why your transaction isolation level let a race through that you swore was impossible. That experience does not transfer directly to the next problem, but the muscle of going deep does. Someone who has debugged one thing to the metal knows what "understanding a system" actually feels like, and will not stop at the surface of the next one.

To probe depth I pick whatever the candidate claims to know best and go down until we hit the bottom of their knowledge. This is not a trap. I tell them explicitly: "I'm going to keep asking why until you don't know, and that's fine, I just want to see where your edge is." Then we go. Postgres MVCC, how indexes interact with the query planner, what a bloated table does to your reads.

The moment I am really waiting for is when we hit the edge. What does the candidate do when they genuinely do not know? The answer I want is some version of "I don't know, but here's how I'd reason about it" or "I don't know, I'd go read the source." The answer that ends the conversation for me is confident fabrication. In fintech and security, an engineer who bluffs about something they do not understand is a liability with a keyboard. I would rather hire someone with a smaller circle of knowledge and a clear, honest boundary than someone with a large circle and fuzzy, dishonest edges. The honest boundary scales safely. The fuzzy one ships incidents.

How they treat the systems they inherited

You can learn a lot about a senior engineer from how they talk about code they did not write. The tell is whether they say "the previous team was incompetent" or "the previous team made reasonable calls under constraints I didn't have, and here's what I'd change now."

I ask directly: "Tell me about the worst piece of a codebase you inherited. Why was it bad, and what did you actually do about it?" There are two failure modes in the answer and both worry me.

The first is contempt. If every past system was garbage and every past team was stupid, the common denominator is sitting in front of me. More practically, contempt for existing systems predicts bad rewrites. The engineer who cannot see why the "obviously wrong" thing was built that way will rebuild it and rediscover every constraint the hard way, in production.

The second failure mode is the opposite: reverence. "I didn't want to touch it because it was working." A senior engineer is not paralyzed by a scary system. They have a method: characterize it with tests and metrics before changing anything, strangle it incrementally, keep the old path live behind a flag until the new one has earned trust. When I ask about a migration, I am listening for that method. I want to hear "I put the new path behind a feature flag at 1% and reconciled the outputs against the old path for a week before ramping." That sentence tells me you have been burned by a big-bang cutover and learned the lesson so you will not repeat it on my systems.

The best answer I ever got to this question was about a payments reconciliation job the candidate inherited that "worked" but silently dropped roughly 0.1% of records. They did not rewrite it. They added observability first, proved the drop rate, found the off-by-one in a pagination loop, fixed the one line, and only then discussed whether the architecture needed to change. That is exactly the sequencing I want: understand, measure, make the smallest correct change, then decide about the bigger one.

The failure conversation is the most important one

I spend real time, usually fifteen minutes, on a single failure. Not "tell me about a challenge," which invites a rehearsed non-answer. I ask: "Tell me about an outage or a serious bug that was your fault. What happened, what did you do in the moment, and what did you change afterward?"

The "your fault" part is non-negotiable and I hold the line on it. If someone cannot produce a single incident they caused, one of two things is true: they have not operated anything of consequence, or they cannot hold themselves accountable. Neither is what senior means. Everyone who has shipped meaningful systems has caused a meaningful failure. The good ones remember it in detail because it changed how they work.

I am grading three things in the answer.

First, the incident response itself. Did they stop the bleeding before diagnosing, or did they try to root-cause a live outage while customers were down? A senior engineer knows the order: mitigate, communicate, then diagnose. "I rolled back first even though I didn't know the cause yet, put a note in the incident channel, and started digging once the error rate was back to baseline." That is operational maturity. Trying to be clever during an active incident is not.

Second, blast-radius awareness. Did they understand who was affected and how badly? "It looked like a small bug but because it was in the shared auth middleware it was actually failing every service's health check" shows a person who thinks in terms of systems, not just their own component.

Third, and most important, the systemic fix. A junior engineer fixes the bug. A senior engineer fixes the class of bug. "I added a canary deploy stage so this category of change can never hit 100% of traffic again" is a senior answer. "I was more careful after that" is not an answer at all. The best candidates describe a change to the system, the process, or the guardrails such that the same mistake becomes structurally hard to repeat. That instinct, to convert a personal failure into a permanent systemic improvement, is close to the definition of the seniority I am hiring for.

Communication is a technical skill, and I test it as one

There is a myth that communication is the soft, secondary thing you evaluate after the "real" technical bar. For senior engineers it is a core technical skill, because the primary output of a senior engineer is not code, it is decisions that other people can understand, trust, and build on. A brilliant design that no one else can follow is a bus-factor of one, which is a liability, not an asset.

I test this concretely. At some point I will ask a candidate to explain something they know deeply to me as if I were a smart engineer from a different domain. Explain your fraud detection pipeline to someone who has never worked in payments. Or the reverse: explain a database concept to a product manager who needs to make a scoping decision and cannot parse jargon.

The signal is whether they can modulate the altitude of the explanation to the audience. Weak communicators have exactly one altitude and it is either uselessly abstract or drowning in detail. Strong communicators pick the right level, check for understanding, and use a concrete example instead of an abstraction when the abstraction is not landing. Watch how someone explains and you learn how they will run a design review, write an RFC, and mentor the engineers under them.

The other place communication shows up is disagreement. Late in a design discussion I will sometimes push back on a reasonable decision they made, pretending to prefer a worse alternative, to see what happens. I am not looking for someone who caves to the senior person in the room, because that person will cave to the loudest voice on my team and ship the wrong thing. I am also not looking for someone who digs in and defends their position by volume. I want the engineer who says "here's the trade-off, I chose X because of these two reasons, but if Y matters more to you than I assumed, X is wrong and we should do Y." That is a person who holds opinions strongly and loosely at the same time, which is exactly what you want in the people making your architectural decisions.

Pragmatism over purity, every time

I have a specific allergy I screen for: the engineer who reaches for the maximally sophisticated solution when a boring one would do. Resume-driven development is expensive, and it is most dangerous in senior engineers because they have the credibility to get the over-engineering approved.

So I probe for pragmatism directly. When a candidate proposes a heavy solution, I ask "what's the simplest thing that could possibly work here, and why isn't that enough?" The answer separates two kinds of engineer. One recognizes the simple version, names the specific condition under which it breaks, and adopts complexity only past that threshold. "A cron job hitting a table is fine up to a few thousand jobs; past that the polling and the lock contention hurt, and that's when I'd move to a queue." The other cannot articulate why the simple version fails, which means they were reaching for the complex thing out of habit or resume-building, not need.

I ask a version of the same question about scale. "How many users does this need to support?" If the honest answer is ten thousand and the candidate designed for a hundred million, that is not foresight, it is a failure to right-size that will cost my team months of unnecessary operational burden carrying infrastructure they do not need yet. YAGNI is a senior instinct, not a junior shortcut. The senior version of it is not laziness, it is knowing precisely where the current design's ceiling is and having a credible, low-drama plan to raise it exactly when the business actually hits it, and not a quarter before.

The related trait is knowing when good enough is genuinely good enough. Perfectionism reads as diligence in an interview and burns quarters in reality. I want the engineer who ships the 90% solution that solves the actual problem this week, is honest in the PR about the 10% they deferred and why, and files the ticket, over the one who spends a month gold-plating an edge case that affects four users. The former is how real systems get built under real constraints. The latter is how roadmaps slip.

What I deliberately do not weigh heavily

It is worth being explicit about what I ignore, because a lot of interview lore optimizes for the wrong things.

I do not weigh algorithmic puzzle performance much. I ask a coding question, but it looks like the job: here is a messy function with a concurrency bug, or an ambiguous spec, find the problem and talk me through the fix. I want to see how someone reasons about real code, edge cases, and testing, not whether they memorized the trick to a graph problem they will never see again. A senior engineer who has not touched dynamic programming since university but can debug a race condition in unfamiliar code is far more valuable to me than the reverse, and interviews that invert that priority hire the wrong people.

I do not weigh knowledge of my specific stack heavily either. If you are strong in Java and Spring and my platform is Kotlin and Micronaut, I am not worried. The concepts transfer in days and the syntax in weeks. I have watched strong engineers become productive in an unfamiliar stack faster than mediocre ones who already knew it, because depth of understanding transfers and surface familiarity does not. What I screen for is whether the depth is real, not whether the labels match my job description.

I try hard not to over-index on confidence and polish. The most articulate candidate is not always the best engineer, and interviewing is a skill that is somewhat separable from the job. This is where the specific, drill-down probing matters most. Confidence collapses under specificity if there is nothing behind it, and quiet competence reveals itself under the same pressure. So I keep pushing past the polished top layer of every answer until I hit either real substance or the bottom of a rehearsed script. The push is the whole test.

The actual bar

Strip away the specifics and every one of these probes is asking one question: when this person is alone with an ambiguous problem, real constraints, and no one watching, will they make a good decision?

Not the optimal decision. A good one, made with the information available, with the failure modes considered, communicated clearly enough that the rest of the team can trust it and build on it, and revisited honestly when it turns out to be wrong. Algorithms, stack familiarity, and years of experience are weak proxies for that. Judgment, ownership, intellectual honesty, and pragmatism are the thing itself.

The candidate who solved my design question in eight minutes had pattern-matched their way to a correct-looking diagram. What they could not do was reason about what happens when that diagram meets a bad day, which is the only environment senior engineers actually work in. Systems fail. Requirements shift under you. The person you hired is alone with the pager. The entire interview is my best attempt to find out, in an hour, whether that is a person I would trust with the thing when it is on fire and I am not in the room. Everything else is proxy.