How to tell if a candidate is truly senior or just experienced

The job title says "Senior Engineer." The resume shows eight years of experience. They've worked at companies you recognize. And yet — something feels off in the interview. You can't quite put your finger on it.

This is one of the most common problems in technical hiring: confusing seniority with tenure. Years on the job don't automatically produce senior-level thinking. And the interview process, if not designed carefully, won't catch the difference.

Here's what truly senior engineers actually look like — and the specific signals that reveal whether you're talking to one.

The core difference: scope of thinking

A senior engineer doesn't just write better code than a mid-level engineer. They think about different things. A mid-level engineer asks: "How do I build this?" A senior engineer asks: "Should we build this at all — and if yes, what's the right way to approach it given everything else we're dealing with?"

That shift in scope — from execution to judgment — is the clearest marker of true seniority. It shows up in how they talk about past projects, how they ask questions, and how they respond when you give them ambiguous problems.

Green flags: what truly senior engineers do

• They push back on the problem before solving it. A senior engineer who hears "build a real-time notifications system" will ask who needs it, how often, what latency is acceptable, and whether simpler polling could work. They're not trying to be difficult — they're doing the job correctly.
• They talk about failure as comfortably as success. Ask a senior engineer about a project that went wrong. A truly senior person will walk you through their own mistakes, what they missed, and what they learned. Someone who's just experienced will either blame external factors or struggle to recall a real failure.
• They explain complex things simply. The ability to communicate clearly to non-engineers — product managers, founders, clients — is a skill that takes years to develop and is almost always present in truly senior engineers.
• They've changed their mind. Ask them about a technical belief they held five years ago that they no longer hold. Senior engineers can point to specific shifts in thinking. This shows intellectual honesty and real learning over time.
• They mention the people they've mentored or unblocked. Seniority at the team level means multiplying your impact through others. If someone has eight years of experience but has never mentored anyone, helped onboard a junior, or done a technical review for a colleague — that's worth noting.

Red flags: what experienced-but-not-senior looks like

• They optimize for cleverness over clarity. Code that's technically elegant but hard for the team to maintain is a mid-level signature. Senior engineers write code for the next person who has to read it.
• They struggle with ambiguity. Give them an open-ended problem — "how would you approach improving the reliability of our checkout flow?" — and they immediately ask for more specs. Senior engineers are comfortable making assumptions explicit and working from there.
• Every answer is about what they built alone. If most of their stories start with "I built…" rather than "our team decided…" or "we ran into a disagreement about…", that's a signal. Senior engineers operate in context — teams, constraints, competing priorities.
• They've only ever worked in one stack. Eight years in one company, one codebase, one language doesn't produce the same seniority as eight years across multiple environments. Breadth of exposure matters.
• They can't articulate why they made a technical decision. "We used Kafka because it was the standard" is not a senior-level answer. "We evaluated Kafka vs. SQS for this specific use case and chose Kafka because of X, even though it introduced Y complexity" — that is.

The two interview questions that reveal the most

You don't need a long technical gauntlet to assess true seniority. Two questions, asked well, will tell you most of what you need to know.

1. "Tell me about a technically simple solution you chose over a more sophisticated one — and why."

Truly senior engineers can point to a moment where they deliberately held back. Where they recognized that the simpler approach was the right one, even if it wasn't the most impressive. This shows maturity, business judgment, and team awareness. Someone who can't answer this question has likely been optimizing for technical complexity rather than outcome.

2. "Describe a technical disagreement you had with a teammate. What happened?"

This reveals how they navigate conflict, whether they can hold a position without becoming defensive, and whether they can update their views when presented with good arguments. Senior engineers have these stories. They remember specific disagreements, how they resolved them, and what they learned. Mid-level engineers often either can't recall a real one or describe a situation where they were simply right and the other person came around.

What this means for your hiring process

If you're consistently having trouble leveling candidates accurately, the problem is usually in the interview design, not the candidate pool. A few practical fixes:

• Replace coding challenges with system design conversations. Whiteboard-style algorithm problems test preparation, not seniority. Ask them to design something real — a rate limiter, a search autocomplete, a simple payment flow — and focus on the questions they ask, not just the solution they arrive at.
• Add a structured behavioral round. Use the same two or three questions for every senior candidate. You'll quickly learn what "senior-level" answers actually sound like, which makes leveling much more accurate over time.
• Talk to their references — specifically. Ask the reference: "Was this person the kind of engineer others came to with questions?" and "Can you give me an example of a decision they made that surprised you?" Vague praise tells you nothing. Specific stories tell you everything.

The bottom line

Seniority is not a number of years. It's a pattern of thinking — about scope, tradeoffs, communication, and impact beyond your own keyboard. The engineers who embody it will show you, if you ask the right questions.

The ones who don't will give you a very impressive résumé and tell you, at length, about the systems they built. That's experience. It's not the same thing.