Most senior .NET resumes are entirely accurate. That is the problem.
Every true claim on the page is also an invitation, and the question that ends a round is almost never the hard one. It is the polite follow-up to a phrase you wrote at eleven at night, months ago, while updating your resume for the first time in four years and never once imagining it would be read back to you out loud.
Three ordinary lines, the questions each one opens, and what the interviewer is actually listening for.
1. The performance number
“Migrated a legacy ASP.NET application to .NET 8 — 40% performance improvement.”
“40% against what baseline?”
“Measured with what, and under what load?”
A percentage with no baseline behind it is the most common unforced error on a senior resume. The number is memorable; the measurement almost never is. Nobody records the “before” while they are busy putting out the fire, so six months later your brain helpfully invents a figure that feels about right.
What they are actually checking: not the figure. Whether you were close enough to the work to know what it was made of. “We never captured a formal baseline, but p95 on the reporting endpoint went from about four seconds to under one” lands better every time than a clean number that folds on the second question.
2. The architecture claim
“Designed a microservices architecture serving 2M+ requests per day.”
“Which service boundary did you define, and what evidence showed it was the right one?”
“Why services rather than modules?”
Service boundaries are the one part of a design you cannot reconstruct from the diagram afterwards. And anyone who has made this call knows the open secret: most boundaries follow the org chart, not the domain. Saying so is a much stronger answer than a tidy story about bounded contexts that nobody in the room believes.
What they are actually checking: whether you made the call or inherited it from someone who left. “Designed” claims authorship. The follow-up quietly tests the claim.
3. The leadership line
“Led a team of 8 engineers across two geographies.”
“Led how — design calls, or standups?”
“Name one decision that was yours, and one you disagreed with.”
“Led” is the most elastic word on any senior resume. It stretches from “I owned this architecture and defended it to a hostile room” all the way down to “I ran the standup,” and the document never says which. The second question separates them, because losing an argument and shipping the thing anyway is a specific memory nobody can improvise.
Why these questions get asked at all
An interviewer has forty minutes and a page full of claims. Following a chain from something you wrote yourself is simply the cheapest way to find out whether the experience is owned or merely adjacent.
It takes no preparation on their side, which is the elegant part. And it cannot be revised for on yours, because the questions are generated from your own document.
What to do before the interview
Read your own resume like someone who does not believe you. For every claim, ask the obvious next question, then the one after that. Wherever the second or third answer runs dry, you have found a gap to prepare — not a line to quietly delete.
Three things worth having ready for every claim that matters:
The mechanism. Not the outcome, the thing underneath it. The decision. What you chose, what you rejected, and why — including the one you got wrong. The exclusion. What you left behind, and what finishing it would cost today.
Most senior candidates can produce the first. Rounds are decided on the second and third.