What I look for in senior engineers

The job title 'senior engineer' means almost nothing now.

In some organisations it lands at year three. In others it takes a decade. The same resume reads as 'senior' at one company and 'mid' at the next. The role has been inflated, deflated, and re-inflated so many times that the word does most of the work the interview ought to be doing.

I have interviewed enough engineers to know what I am actually listening for. I have hired some I should not have, and turned down a few I should have begged to join. Four signals have done most of the work. None of them sit on a standard interview rubric.

1. What they want to delete

Ask a candidate about a system or a piece of code they would remove tomorrow if they could.

Junior engineers, almost universally, talk about what they want to add. A feature missing from the framework. A capability the team has not built yet. A tool they wish existed.

The pattern flips somewhere around the eight-to-ten year mark, for the ones paying attention. They start talking about what they would remove. The legacy module that gets touched by every project but belongs to no one. The abstraction that was built for a use case the company no longer pursues. The cleverness in the deploy pipeline that nobody remembers writing and everyone is afraid to touch.

Most software harm is done by code that is still in production but no longer earns its keep. Senior engineers know this in their bones. They feel the weight of what is there.

If a candidate cannot think of a single thing they would delete from their last system, I notice. It is not a deal-breaker — they may have been on a young codebase, or simply not had the standing to make those calls. But I will probe further. I want to know whether the muscle exists.

2. How they describe past failure

Every senior candidate will be asked about a project that went wrong. Most will give some version of the same answer: blameless, structured, ending in a lesson learned.

I have read enough post-mortems to spot the rehearsed version. The one that frames the failure cleanly, attributes it to systemic causes, and pivots smartly to growth. It is not wrong, exactly. It just does not tell me what I want to know.

What I want to know is whether the person, on the inside of the failure, felt it. Whether they can still tell me what they thought at the moment they realised it was going wrong. Whether they remember what they said to the team. Whether they tried something that did not work, and what it cost.

I am listening for specifics that only someone who was actually there could supply. The wrong dashboard they were watching. The colleague they argued with. The Sunday they spent backfilling data. The decision they made at two in the morning that they would not make again.

This is not theatre. The point is not that I want people to suffer well. The point is that senior engineers carry the lived memory of their failures in a way that shapes everything they do afterwards. If the failure has been sanded smooth into a LinkedIn-ready story, I worry the learning has been sanded smooth with it.

3. What they did when they did not know

There is a question I ask in some form during every interview: tell me about a time you were responsible for something you did not understand.

The honest answer is hard to fake. It involves not knowing, knowing that you did not know, and having to act anyway. The shape of the response tells me a lot.

I am listening for:

• An admission of ignorance without performance. Not 'I had a lot to learn' but 'I genuinely had no idea what was going on'.
• A description of the search. Who they pulled in. What they read. Which assumptions they tested first.
• An honest reckoning with the cost of being wrong. What was at stake if their guess was off.
• The actual outcome, including any embarrassment.

The candidates I worry about are the ones whose answer subtly implies they always knew, even when they say they didn't. Seniority is partly the ability to operate in fog. Junior engineers are often paralysed by it. Mid-career engineers learn to fake their way through it. Senior engineers have made peace with it. They know how to move forward with incomplete information, and they know how to slow down when the cost of being wrong is high.

4. The trade-off they did not get to make

The last signal is about loss.

Every meaningful engineering decision has a trade-off. The interesting question is not 'tell me about a great decision you made' — the great-decision story is the most polished thing in any candidate's repertoire. The interesting question is: tell me about a decision your team made that went the other way from what you would have chosen. What did you do?

This separates people sharply.

Some get visibly upset, even years later. The grudge is still there. That tells me something about how they handle losing.

Some describe what they would have done with such fluency that I can tell they never actually said it out loud at the time. That tells me something about how they handle conflict.

The candidates I want describe the trade-off with calm specificity. They can articulate why the other path was reasonable, even if they disagreed. They tell me how they argued their case, what they conceded, and what they did after the decision went the other way — whether they got behind it, or quietly undermined it, or filed it as one of those things you learn to live with.

This last category is rare. It is also what I think 'senior' actually means.

What I have stopped testing for

For completeness, the things I no longer weigh heavily:

• Algorithmic puzzles. A senior engineer who has not implemented a balanced tree from memory in fifteen years is not a worse engineer. They are usually a better one.
• Framework knowledge. Frameworks rotate every few years. The person fluent in the current one this quarter is not necessarily the person you want choosing the next one.
• Whiteboard system design as performance. I want to see how someone thinks, not how rehearsed their cloud-architecture diagrams are. The best design conversations I have ever had in interviews started with 'I am not sure yet — can I ask a few questions first?'

None of those things are bad to know. They are just bad predictors.

What this actually selects for

What I am really looking for, across all four signals, is judgement that has been paid for.

Paid for with deleted code that someone had to argue should go. Paid for with a failure the person was in the room for. Paid for with the discomfort of acting without knowing. Paid for with a trade-off that did not go their way, and the maturity to live with it.

Years do not buy that. Titles do not buy that. The work does. The only way I have found to spot it is to ask questions the rehearsed answers cannot survive.