Why so many good senior .NET engineers are getting rejected right now

You know the one. You walk out thinking that went fine. You answered everything. Nobody was rude. Somebody even said “great question” when you asked about their deployment process, which felt promising at the time.

Four days later: we have decided to move forward with other candidates.

And the part that stings is not losing. It is that you have shipped more, fixed more, and been paged at 2am more than the person who interviewed you. You have carried systems they have only read about. So what exactly happened?

Here is the uncomfortable answer. Interviews do not test whether you are good. They test whether you can prove you are good, in about forty minutes, under mild pressure, using only your memory. Those are wildly different skills, and a long career quietly erodes the second one.

Six reasons this keeps happening.

Reason 01You said 40%. They said “against what?”

This is the friendliest question in any senior interview and it ends more rounds than anything else on this list.

Nobody measures the “before” while they are busy shipping the “after.” You were putting out a fire, not running a study. Then eighteen months later you need a number, and your brain helpfully invents one that feels about right.

Interviewers can hear an invented number the way you can hear a merge conflict resolved badly. “We never captured a formal baseline, but p95 on the reporting endpoint went from about four seconds to under one” beats a confident 40% every single time. Honesty with a shape to it sounds like memory. A clean round figure sounds like marketing.

Reason 02You have been saying “we” for twenty years

Enterprise work does this to people. You spend two decades in teams, being decent about credit, and “we migrated,” “we decided,” “we chose Kafka” becomes the only grammar you own.

It is generous. It is accurate. It is also completely useless to someone trying to hire exactly one of you.

“Led” is the most elastic word on any senior resume. It stretches from “I owned this architecture and defended it to a skeptical CTO” all the way down to “I ran the standup.” The interviewer cannot tell which, so they ask the question that separates them: name one call that was yours, and one you disagreed with.

That second half is the trap and the gift. Anyone can claim a decision. Only someone who was actually in the room remembers losing an argument and shipping the thing anyway.

Reason 03You prepared for question one. They asked question two.

You revised. You went through the list. You can define IDisposable, explain what await does to the call stack, describe change tracking in EF Core in your sleep.

So can everyone else who revised. That is the problem — question one is not a filter, it is a formality. Everyone clears it, and clearing it tells the interviewer nothing.

Then: tell me about a leak you traced. What was holding the reference?

No list prepares you for that. Either you have opened a memory dump at an unreasonable hour and found a static event handler quietly holding half your object graph hostage, or you have not. The follow-up is where the round is actually decided — and preparation that stops at the definition is just memorization with a deadline.

Reason 04Your resume lists forty-seven technologies

Twenty years touches a lot of stack. WCF, WebForms, MVC, Core, Azure, AWS somehow, a year of Angular you would rather not discuss, three message brokers, and something involving SharePoint that you have deliberately forgotten.

You listed it all, because it all happened. It reads as range. Unfortunately, past a certain length it starts to read as tourism — present for many things, accountable for none.

An interviewer would rather hear one migration described down to its worst week than fifteen technologies named. Depth in one place is evidence. Breadth everywhere is just a claim with more words.

Reason 05Nothing ever went wrong, apparently

Senior candidates tell suspiciously tidy stories. The migration went smoothly. The architecture held. The team delivered. Everyone got along, presumably over a lovely shared lunch.

Nobody believes this. Not because you are lying — because production does not work that way, and everyone in the room knows it.

Every migration of any size leaves something behind. Every architecture trades away something real. Naming the trade — what stayed on the old runtime, what that service boundary cost you in latency, which decision you would take back — is the single strongest signal available, precisely because nobody who was not there could invent it.

A story with no cost in it does not sound like something that happened. It sounds like something that was prepared.

Reason 06You wrote a job description, not a resume

Read your own bullets back. Most senior resumes describe scope: systems owned, teams managed, technologies used, regions covered.

Almost none describe judgment: what you chose, what you rejected, and why.

Scope is verifiable from a job title, which means it is worth roughly nothing in an interview. Judgment is the thing being bought at senior level, and if your resume does not offer any, the only conversation available is about scope. That conversation is pleasant, lasts forty minutes, and ends in a polite email.

So what actually fixes this?

Annoyingly, not studying. You already know the material — that was never the gap.

What closes it is going back through work you already did and recovering the parts nobody wrote down. For each significant thing on your resume, three items are worth digging up before anyone asks:

The mechanism. Not the outcome, the thing underneath it. Deployment dropped from four hours to twenty minutes — fine, but what were the four hours actually made of? If the answer is “mostly a bloke called Ramesh running smoke tests manually,” say that. It is a great answer.

The decision. What you picked, what you rejected, and on what basis. Include the one you got wrong. Especially the one you got wrong.

The exclusion. What you left behind, and what finishing it would cost today. Every real project has one. Pretending otherwise is how reason five happens.

Most senior candidates can produce the first. The round is decided on the second and third.