Interview questions to ask senior engineer candidates

Eight questions for senior candidates

1. Tell me about a time you argued against doing something and lost. What happened next?
2. What have you chosen not to build, and why?
3. Describe a system you still owned a year after shipping it. What did you learn in that year?
4. How did you change someone's mind about a technical direction without being their manager?
5. What is the worst technical decision currently in production that you are responsible for?
6. How do you decide when something is worth refactoring?
7. Tell me about mentoring someone who was struggling.
8. What would you want to change about how your current team works?

Restraint is the clearest senior signal

Mid-level engineers are usually assessed on what they can build; senior engineers should be assessed on what they decline to build. Ask what they have chosen not to do, and listen for a real trade-off — a service they argued should stay a module, an abstraction they deliberately did not introduce until the third use case. Candidates who answer only with things they built, at increasing scale, are describing a longer mid-level career rather than seniority.

Influence without authority

Senior individual contributors have to change outcomes without reporting lines. Ask how they moved a decision: what they did when a first conversation failed, whether they wrote something down, who they brought in. Strong answers involve evidence, patience and a second attempt with a different framing. Weak ones end at “I raised it and they did not listen”, which describes an opinion rather than influence.

Living with consequences

• “A system you still owned a year later” separates people who ship from people who operate. The second group talk about on-call, migrations and the things that only surface at month nine.
• “The worst decision currently in production that is yours” is a question only a secure candidate answers well. The ones who do give you an honest map of their judgement.
• “When is refactoring worth it?” Good answers are conditional and reference cost of change, not aesthetics.

What looks senior and is not

• Breadth of technologies. A long list is exposure, not depth, and often means short tenures at each.
• Confidence and fluency. Strongly correlated with interview performance and weakly with engineering judgement.
• Title and headcount. Titles inflate at different rates across companies; scope is the comparable measure.
• Strong opinions about tooling. Having them is normal; being unable to describe when the opposite choice is right is not senior.

Calibrating level in the conversation

The practical test is what they can be trusted with unsupervised. Ask which decisions they make without asking, what would break if they left, and who reviews their work. Two candidates with identical titles routinely describe entirely different jobs, and these questions find the difference in five minutes. See how to run a hiring manager screen.

Adjust the technical round too

Senior candidates are often assessed with the same coding exercise as mid-level ones, which measures recent puzzle practice and penalises people who have spent four years operating systems rather than interviewing. For senior roles, a code review or a design discussion drawn from your real problems carries far more signal. See how to test coding skills without LeetCode and what to look for in a coding interview.

How to interview someone more senior than you

Hiring managers often avoid probing senior candidates on technical depth because they fear being out of their depth. The move that works is to stop asking about technologies and start asking about decisions. You do not need to know the domain to assess whether someone can state what they chose, what they gave up, and what would have changed their mind. If an answer is impenetrable, say so and ask them to explain it to someone who does not share their context — that is a real job requirement, and watching them do it is itself the assessment.

Mentoring is part of the role, so assess it

Ask about someone they mentored who was struggling, not someone who was already strong. The useful detail is what they changed about their own approach when the first attempt did not work. Senior engineers who describe mentoring purely as answering questions are describing availability rather than development.

Where Interviewer Mode fits

Disclosure: we make CoPilot Interview, which includes Interviewer Mode for the hiring side and a real-time assistant used by candidates. We have an interest in you using the first, and our view of the second is that interviews should be designed to measure something an assistant cannot fake. Weigh the advice below accordingly.

Frequently asked questions

What should I ask a senior engineer in an interview?

Ask what they have chosen not to build, a time they argued against something and lost, a system they still owned a year after shipping, and how they changed someone's mind without authority. Seniority shows up as restraint, influence and living with consequences.

How do I tell the difference between mid-level and senior?

Scope and restraint. Mid-level candidates describe what they built; senior candidates describe what they chose not to build and why, decisions they influenced without authority, and what they learned operating something long after launch.

What is the best question for a senior engineering candidate?

“Tell me about a time you argued against doing something and lost — what happened next?” It tests technical judgement, influence and professional behaviour when overruled in a single answer, and it is very hard to prepare convincingly.

Should senior candidates do the same coding exercise as everyone else?

Usually not. The standard exercise measures recent interview practice and penalises engineers who have spent years operating systems. A code review or a design discussion from your real problems carries far more signal at this level.