Senior engineer interview questions that actually work
On this page
Seniority is not years on a resume. It is judgment: knowing which corners to cut, which to never cut, and how to decide with incomplete information. You cannot test judgment with trivia, so every question below asks the candidate to reason about real decisions. For each, you get the question, what it reveals, and what strong versus weak answers sound like.
Architecture judgment
“Walk me through a system you designed. What would you change today?”
This reveals whether they made deliberate decisions or inherited defaults. A strong answer names constraints (team size, deadline, expected load), explains what the constraints ruled out, and offers a specific regret (“I would not have split the billing service so early, it doubled our deploy complexity for no benefit at that scale”). A weak answer recites the stack (“we used React, Node, and Postgres”) with no reasoning and no regrets.
“When would you choose a monolith over microservices?”
Strong: an answer keyed to team size and operational maturity, defaulting to the monolith and naming the specific pain that justifies splitting. Weak: a dogmatic answer in either direction, or vague appeals to “scalability” without a number attached.
Tradeoffs under constraints
“Tell me about a time you shipped something you knew was not the best technical solution.”
Every real senior has done this. Strong answers show a conscious tradeoff: what the deadline or business need was, what debt they took on, how they contained it, and whether they went back to fix it. Weak answers claim it never happened, or describe cut corners with no containment plan and no follow-up.
“Your team wants to rewrite a core module. How do you evaluate that?”
Strong: asks what the rewrite buys in measurable terms, considers an incremental path (strangler pattern, module-by-module), and weighs the feature freeze cost. Weak: enthusiasm for the rewrite itself, or a reflexive no without a framework for deciding.
Debugging and operational depth
“What is the hardest bug you ever chased? Take me through it step by step.”
The single highest-signal question on this list. Strong answers show method: reproducing the issue, narrowing the search space by halves, questioning assumptions, reading source of a dependency when the docs lied. The story has dead ends, because real debugging does. Weak answers are short, vague, or end with “someone else found it” and no lesson extracted.
“A production endpoint got 10x slower since last week. What do you do first?”
Strong: starts with what changed (deploys, traffic shape, data growth), checks metrics and traces before touching code, and forms a hypothesis before acting. Weak: jumps straight to “add caching” or “scale up” without diagnosis.
Collaboration and influence
“Tell me about a technical disagreement with a colleague. How did it end?”
Strong: they can state the other side’s position fairly, describe how the decision got made (prototype, data, deferring to the owner), and sometimes they lost and committed anyway. Weak: they were right, the other person was difficult, and the story has no ending or a bitter one.
“How do you review a large pull request from a junior engineer?”
Strong: separates blocking issues from preferences, explains the why on each comment, and knows when to pair instead of comment. Weak: describes nitpicking style, or admits they wave large PRs through.
Dealing with ambiguity
“You get a one-line feature request from a founder: ‘add teams support.’ What happens next?”
Strong: a list of sharp questions (what does a team own, who can invite, what changes for billing and permissions), then a thin first slice to validate before building the full model. Weak: starts designing database tables immediately, or waits passively for a full spec.
How to run the interview
Pick five to six questions across at least four of the themes above, not all of them. Let each answer run and ask “why” twice before moving on, because the second why is where rehearsed answers run out. Take notes on reasoning, not conclusions: a candidate can hold a different opinion than you and still show excellent judgment reaching it.
The shortcut
These questions work, but running them well takes calibrated interviewers and real hours per candidate. A vetted network has already run this screening before you see a profile, so your interview can focus on fit with your product and team. Whichever route you take, hire the reasoning, not the resume.
Frequently asked questions
Should senior engineer interviews include live coding?
A short practical exercise is useful, but for senior roles the conversation about past decisions matters more. A senior engineer's value is judgment under constraints, and you test that by probing real decisions they made, not by watching them invert a binary tree.
How many interview rounds does a senior engineer need?
Two to three focused rounds is enough: one deep technical conversation, one practical exercise or system-design session, and one on collaboration and working style. More rounds add cost and candidate dropout without adding signal.
What is the biggest red flag in a senior engineer interview?
No owned failures. A candidate who cannot name a decision they got wrong, a bug they caused, or a tradeoff they regret has either never carried real responsibility or will not be honest with you when it matters.