Senior .NET Developer Interview Questions and Scorecard
Six question sets for the owner or lead running the interview: core C# judgment, runtime and production behavior, application and data design, migration and release ownership, seniority and mentoring, plus a scoring rubric with red flags. Every question comes with why it is worth asking and what a good answer sounds like. Download as DOCX.
The problem with interviewing a senior .NET developer is that the standard questions have published answers. Anyone who spent an evening reading can define the dependency injection lifetimes, describe garbage collection in general terms, and explain what async and await do. You can run a full hour of that and learn almost nothing, because the gap between a strong mid-level developer and a real senior one does not live in the definitions.
At FirstHR we build for small businesses that hire without an HR department, where the owner or a single technical lead runs the entire process. These six question sets are written for that reader. Every question comes with the reason it is worth asking and what a good answer sounds like, plus an exercise that works even if you have never written a line of C# yourself, and a scorecard so the decision rests on written evidence.
One note before you start. Nothing on this page is written for the candidate. It is written for the person deciding what to ask, which is why each set explains what separates a lived answer from a rehearsed one instead of supplying model answers to memorize.
TL;DR
Interview a senior .NET developer on five things: C# judgment graded on reasons rather than definitions, runtime behavior under real load, application and data design, ownership of framework migrations and upgrades, and mentoring. Ask why that matters once after every answer. Federal wage data puts the software developer median at $135,980 a year.
What a Senior .NET Developer Owns
A senior .NET developer owns outcomes rather than tickets: choosing a design, defending it, keeping it running in production, and raising the level of whoever touches the code next. The C# itself is the smallest part of that. Judgment about systems, data, and people is what the seniority premium actually buys.
The distinction matters because the title travels loosely. Some candidates have spent eight years writing features inside a design someone else chose, with a platform team handling deployment and a rotation covering the nights. Others have owned an application end to end, including the evening it stopped responding. Both call themselves senior, and only one of them helps a team with no safety net underneath it.
At a small company the scope stretches further still. The same person usually picks the approach, writes the tests, owns the package and runtime upgrades, sets up deployment, reviews their own work, and explains tradeoffs to an owner who does not code. Our guide to technical recruitment covers finding these people; this page covers the interview itself.
Which Question Set to Use
Use the C# judgment, runtime, and design sets with every senior candidate, then add the migration set for anyone inheriting an existing application and the seniority set for anyone who will work without a peer reviewing their code. The scorecard is used with all of them.
Core C# Judgment
Every candidate
Async pitfalls, disposal, LINQ execution, nullable reference types, structs, and records, each graded on the reason behind the rule rather than the rule.
Runtime and Production
Predicts your weekends
Thread pool starvation, memory that never comes back, garbage collection modes, monitoring, and the last incident the candidate personally diagnosed.
Application and Data Design
Where cost accumulates
Dependency injection lifetimes, transaction boundaries, the N plus one query, schema changes without downtime, API versioning, and where secrets live.
Migration and Release
Most senior .NET work
Moving an older Framework application forward, upgrade versus rewrite, support cadence, package hygiene, and the real path a change takes to production.
Seniority and Mentoring
No coding knowledge needed
Decisions owned end to end, a decision that went wrong, a named developer they raised, review style, estimates, and explaining a tradeoff plainly.
Rubric and Red Flags
Rate, then decide
A six area scorecard with evidence lines, a mid-level versus senior guide, and a ten item red flag checklist. Use it with every set above.
If you are hiring at any level rather than specifically senior, the broader .NET developer question sets cover junior and mid-level candidates as well. The sets here assume you are paying a senior premium and want to find out whether you are getting one.
Ask Why That Matters, Once, After Every Answer
The highest value follow-up in a senior .NET interview is four words long: why does that matter? A prepared candidate delivers the textbook answer and stops, because the textbook stops there too. Someone who has maintained a .NET application for years keeps going into the consequence: the invoices that came out wrong, the endpoint that started timing out at lunchtime, the release that had to be pulled at nine at night. You are not testing whether they know the answer. You are testing whether they have lived with it. Use it after every question in every set below, and write down what comes back.
6 Question Sets to Download
Download all six as a single Word document, or copy the sets you need into your own notes. Each one follows the same structure: when to use it, the questions with the reason to ask and what a good answer sounds like, what to listen for, and space for notes. The last file is the scorecard.
Download All 6 Senior .NET Question Sets
Core C# judgment, runtime and production behavior, application and data design, migration and release work, seniority and mentoring, plus a scoring rubric with red flags. All in one DOCX.
Set 1: Core C# Judgment Questions
Familiar questions with a second layer built in: sync over async, what disposal really promises, where a LINQ query executes, nullable reference types, structs, async void, and records. Start here with every candidate.
Core C# Judgment Questions
SENIOR .NET DEVELOPER INTERVIEW: CORE C# JUDGMENT
Candidate: __
Interviewer: __
Date: __
WHEN TO USE THIS SET
Use this set in the first technical round with every senior candidate. The
questions look like ordinary C# questions on purpose. What you are grading is
the second layer: whether the candidate can say why the rule exists and what it
cost on a system they actually maintained. Ask "why does that matter" once after
every answer and write down what comes back.
QUESTIONS, WHY THEY ARE WORTH ASKING, AND WHAT A GOOD ANSWER SOUNDS LIKE
1. Someone calls an async method with .Result. What happens, and when?
Why ask: sync over async is the single most common way a .NET web application
dies under load, so a real senior has met it in production.
Good answer: it blocks the calling thread while waiting for a task that needs
a thread to finish, which starves the thread pool and turns a fast endpoint
into timeouts once traffic arrives. Mentions that it is intermittent and load
dependent, which is why it survives testing, and describes the fix as making
the call chain async the whole way rather than patching one method.
Weak answer: "it can deadlock" with no mechanism and no story attached.
2. What does IDisposable actually promise, and when do you write one?
Why ask: it separates people who release resources deliberately from people
who trust the garbage collector with things it never managed.
Good answer: it is a contract for releasing unmanaged or scarce resources
deterministically, files, sockets, database connections, timers, rather than
memory. Mentions using declarations, the danger of a long lived class holding
a disposable field, and that the garbage collector will not close a socket
for you on any schedule you can rely on.
Weak answer: "it frees memory," which is the opposite of what it does.
3. Where does a LINQ query actually run, and how has that surprised you?
Why ask: deferred execution and the IQueryable boundary quietly move work
from the database into the application, which is where slowness gets born.
Good answer: explains that the query does not run until it is enumerated, and
that crossing from IQueryable to IEnumerable pulls the rest of the work into
memory. Names a real case: a filter written after a ToList that dragged an
entire table across the wire, or a query enumerated twice inside a loop.
Weak answer: recites deferred execution as a definition and stops there.
4. What do nullable reference types solve, and what do they not solve?
Why ask: a senior has an opinion with a cost attached rather than a rule they
were handed.
Good answer: they move a whole class of null reference bugs from run time to
compile time and document intent at the API boundary, but they are analysis
rather than enforcement, so anything crossing a serialization, reflection, or
older library boundary can still arrive null. May mention turning them on
gradually on a large codebase rather than in one commit.
5. When have you actually reached for a struct instead of a class?
Why ask: the answer reveals whether performance claims come from measurement
or from folklore.
Good answer: small, short lived, immutable values in a hot path, with the
allocation pressure measured before and after. Knows that copying semantics
bite when the type grows, and that a mutable struct in a collection produces
bugs that read like magic. Says "I measured it" somewhere in the answer.
Weak answer: "structs are faster," offered as a general law.
6. An exception is thrown inside an async void method. What happens?
Why ask: it tests understanding of how work gets scheduled, not syntax.
Good answer: there is no task to carry the exception, so it is raised on the
synchronization context and typically takes the process down rather than
surfacing where the call was made. Adds that async void belongs only in event
handlers and that everything else returns Task, and mentions how they handle
exceptions in background and hosted services for the same reason.
7. When do you use a record instead of a class, and when does it backfire?
Why ask: a small question that reliably separates habit from judgment.
Good answer: records for value-like data where equality should compare
contents, data transfer objects, messages, query results. Notes that value
equality on a large object is not free, that mutation through with-expressions
copies, and that a record is a poor fit for an entity with identity and a
lifecycle. A weak answer treats it as a shorter way to write any class.
WHAT TO LISTEN FOR
The pattern matters more than any single answer. A senior candidate keeps going
after the definition into the consequence: what broke, how they found it, what
the fix cost. A rehearsed candidate delivers the textbook sentence and stops,
because the textbook stops there too.
NOTES
[Record the specific systems, numbers, and consequences the candidate named.]
Set 2: Runtime, Memory, and Production Behavior Questions
Thread pool starvation, memory that never comes back down, garbage collection modes, an incident they personally diagnosed, what they monitor, the large object heap, and surviving a process recycle.
Runtime, Memory, and Production Behavior Questions
SENIOR .NET DEVELOPER INTERVIEW: RUNTIME AND PRODUCTION BEHAVIOR
Candidate: __
Interviewer: __
Date: __
WHEN TO USE THIS SET
Use this set with anyone who will be responsible for a running system, which at
a small company is every senior hire. If this person will be your only .NET
developer, this set predicts your weekends more accurately than any other.
QUESTIONS, WHY THEY ARE WORTH ASKING, AND WHAT A GOOD ANSWER SOUNDS LIKE
1. The application crawls under load but processor usage is low. Where do you look?
Why ask: it is the exact shape of a thread pool starvation incident, and the
answer tells you whether the candidate has diagnosed one or only read about it.
Good answer: starts by asking what changed and when, then looks for blocking
calls on the request path, sync over async, lock contention, and connection
pool exhaustion. Names concrete instruments: thread pool queue length, the
number of threads, request duration percentiles, a dump taken while it is
happening. Low processor use with high latency means waiting, not computing.
Weak answer: proposes more servers or more memory before asking a question.
2. Memory climbs and never comes back down. How do you find out why?
Why ask: it is the most common long running .NET failure and the hardest to
fake, because the honest answer names tools.
Good answer: captures a heap snapshot or dump on the running process, compares
two snapshots taken minutes apart, and finds which type is growing. Names the
usual culprits: static collections and caches with no eviction, event handlers
never unsubscribed, HttpClient or connection instances created per request,
large object heap fragmentation. Fixes the cause rather than adding memory.
3. What is the difference between server and workstation garbage collection?
Why ask: it is a real hosting decision, not trivia, and it separates people
who configured a runtime from people who inherited one.
Good answer: server mode runs collections in parallel across cores for
throughput on a machine dedicated to the application, workstation mode favors
responsiveness and a smaller footprint, and the wrong choice on a small shared
container shows up as memory the operator did not expect. A senior answer
admits when the default is fine and says the decision should be measured.
4. Walk me through the last production incident you personally diagnosed.
Why ask: this is the highest yield question on the page. Nothing else so
reliably separates a maintainer from a feature writer.
Good answer: a specific system, a specific symptom, the order of the
investigation, the thing that turned out to be true, and what they changed
afterward so it could not recur silently. Times, counts, and durations arrive
without being asked for. Says what they got wrong along the way.
Weak answer: an incident that happened to the team, with no personal role in it.
5. What do you monitor on a .NET service, and what is allowed to wake you up?
Why ask: it reveals whether they think in symptoms the business feels or in
dashboards nobody reads.
Good answer: request rate, error rate, and latency percentiles rather than
averages, plus queue depth and dependency health. Structured logs with a
correlation identifier, health checks that actually test dependencies, and a
short list of alerts tied to user-visible failure. Explains what they chose
not to alert on and why, because alert fatigue is the real failure mode.
6. What ends up on the large object heap, and why should I care?
Why ask: a precise question that a candidate either has met or has not.
Good answer: allocations above roughly 85 kilobytes, which commonly means big
arrays, buffers, large strings, and serialized payloads. It is collected less
often and historically not compacted, so fragmentation grows and memory looks
worse than the live data. Mentions pooling buffers and streaming large
payloads instead of materializing them as the practical answers.
7. A request must not be lost when the process recycles. How do you handle it?
Why ask: it tests whether the candidate designs for a host that restarts,
which every host does.
Good answer: work that must survive goes to durable storage or a queue before
the response returns, with idempotent processing and retries, rather than
living in an in-process background task. Mentions graceful shutdown, draining
in-flight requests, and that a hosted service losing work on deployment is a
design choice rather than an accident.
WHAT TO LISTEN FOR
Order of investigation is the signal. A senior candidate gathers evidence before
proposing a fix and asks what changed and when. A weaker one starts suggesting
caches, indexes, and bigger machines in the first minute.
NOTES
[Record the tools named and whether the incident stories were personal.]
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
Set 3: ASP.NET Core, EF Core, and API Design Questions
Dependency injection lifetimes and the captive dependency bug, transaction boundaries, the N plus one query, schema changes without downtime, choosing a hosting model, API versioning, and where secrets live.
ASP.NET Core, EF Core, and API Design Questions
SENIOR .NET DEVELOPER INTERVIEW: APPLICATION AND DATA DESIGN
Candidate: __
Interviewer: __
Date: __
WHEN TO USE THIS SET
Use this set with every senior candidate, and swap the framework names for
whatever your application actually runs before you ask. If the system is a
fifteen year old internal application rather than a new service, ask the same
questions about that system instead.
QUESTIONS, WHY THEY ARE WORTH ASKING, AND WHAT A GOOD ANSWER SOUNDS LIKE
1. Explain the dependency injection lifetimes, then a bug caused by the wrong one.
Why ask: everyone can list transient, scoped, and singleton. The bug is the
part that only comes from experience.
Good answer: describes a captive dependency, a scoped database context
captured by a singleton, and what it looked like from the outside: stale data,
thread safety errors under concurrency, or an object disposed exception that
appeared only under load. Explains why the container cannot save you from it.
Weak answer: the three definitions delivered cleanly and nothing else.
2. Where does a transaction begin and end in the applications you have built?
Why ask: transaction boundaries are where correctness quietly goes wrong.
Good answer: one unit of work per request or per command, saved once, with the
boundary owned by the application rather than scattered through helpers.
Knows what a save actually commits, what happens when a call to another
service sits inside the transaction, and why a long transaction becomes a lock
problem before it becomes a performance problem.
3. How do you find an N plus one query, and when do you drop to raw SQL?
Why ask: object relational mappers make this failure invisible until it is
expensive, and small companies rarely have anyone else to catch it.
Good answer: turns on query logging or a profiler and looks at the count of
queries per request, not just the duration. Fixes it with an explicit include
or a projection rather than by loading everything, and reaches for raw SQL or
a stored procedure for set-based work and reporting, while keeping it in one
place and parameterized.
4. How do you ship a schema change without downtime?
Why ask: it is the difference between a developer who deploys and one who has
been blamed for an outage.
Good answer: expand then contract. Add the new column or table, deploy code
that writes both and reads the old, backfill, switch reads, then remove the
old shape in a later release. Mentions that a migration and a deployment are
two separate events, that a rename is two migrations, and that they have a
tested way back rather than a plan to write one under pressure.
5. Minimal APIs, controllers, Razor Pages, Blazor: how do you choose?
Why ask: a senior chooses with reasons and names the cost; a mid-level
candidate names the newest option.
Good answer: matches the choice to the consumer and the team. A service with
external callers, an internal admin screen, and a public site are different
answers. Mentions the cost of mixing several models in one small codebase and
asks who will maintain it after they leave.
6. How do you version an API that other people already call?
Why ask: it tests whether the candidate thinks past the next release.
Good answer: additive changes stay in place, breaking changes get a new
version, and both run side by side for an announced period. Knows what counts
as breaking, including a field that stops being returned and a validation rule
that tightens. Talks about telling callers before the change, not after.
7. Where do connection strings and secrets live in each environment?
Why ask: the cheapest security question there is, and small companies fail it
most often.
Good answer: never in source control, configuration layered per environment,
secrets in a managed store or the platform's secret facility, and rotation
that someone actually performs. Bonus for mentioning who currently has
production access and how that list gets reviewed.
WHAT TO LISTEN FOR
Listen for designs sized to your business rather than to a conference talk. A
senior candidate should be able to say what a pattern costs and when they would
not use it. Anyone who answers every question with more services and more layers
is designing for a company you do not have.
NOTES
[Record the tradeoffs named and whether the candidate asked about your system.]
Set 4: Legacy Migration, Upgrade, and Release Questions
A Framework migration they personally led, upgrade versus rewrite, the support cadence, package and vulnerability hygiene, the real path to production, testing a codebase with no tests, and shipping work too large for one release.
Legacy Migration, Upgrade, and Release Questions
SENIOR .NET DEVELOPER INTERVIEW: MIGRATION, UPGRADE, AND RELEASE
Candidate: __
Interviewer: __
Date: __
WHEN TO USE THIS SET
Use this set with anyone inheriting an existing system, which describes most
senior .NET hires at a small company. The .NET world has a long tail of older
applications still earning money, and the ability to move one forward safely is
often the actual job.
QUESTIONS, WHY THEY ARE WORTH ASKING, AND WHAT A GOOD ANSWER SOUNDS LIKE
1. Describe a migration from the older .NET Framework to modern .NET that you led.
Why ask: it is one of the hardest claims to fake and one of the most valuable
things to hear, because the work is unglamorous and specific.
Good answer: names what moved first and why, usually the parts with the fewest
dependencies and the clearest tests, and what stayed behind. Mentions the real
blockers: libraries with no modern equivalent, older service and messaging
stacks, configuration and identity differences, and code that assumed a
Windows-only host. Says how long it took and what they underestimated.
Weak answer: describes a migration the company did without a personal role.
2. When do you upgrade, and when do you rewrite?
Why ask: the answer tells you whether this person will protect your business
or use it to practice a rewrite.
Good answer: strongly biased toward incremental migration, moving one piece at
a time behind a stable boundary while the old system keeps running. Names the
narrow conditions where a rewrite is honest, and is explicit that a rewrite
restarts the bug count from zero rather than finishing at zero.
3. How do you handle the long term support release cadence?
Why ask: staying on a supported runtime is a security obligation, and it is
the first thing a small team lets slip.
Good answer: plans upgrades on the support calendar rather than when something
breaks, prefers long term support versions for a business application, and has
done at least one runtime upgrade end to end. Mentions checking dependencies
before the runtime and running both in a staging environment first.
4. How do you keep packages and known vulnerabilities under control?
Why ask: dependency hygiene is invisible work that only a senior does unasked.
Good answer: a routine rather than a reaction. Central package versions, an
automated vulnerability scan in the build, a regular slot for updates, and a
distinction between a security update that ships this week and a major version
bump that gets planned. Mentions locking versions so builds are reproducible.
5. Describe the path a change takes from your machine to production today.
Why ask: it exposes the real delivery maturity of every place they have worked.
Good answer: a concrete pipeline. Branch, review, automated build and tests,
an environment that resembles production, an approval, a deployment that can be
reversed, and monitoring watched afterward. If the current path is manual, a
senior candidate says so plainly and describes what they would fix first.
6. You inherit a codebase with no tests. What do you do in the first month?
Why ask: this is the actual situation at most small companies.
Good answer: does not propose full coverage. Puts characterization tests around
the parts that change most or hurt most when they break, adds tests with every
bug fix, and gets the build running reliably before anything else. Talks about
earning the right to refactor rather than asking permission for a rewrite.
7. How do you ship work that is too large for one release?
Why ask: it separates people who plan delivery from people who plan code.
Good answer: breaks it into shippable slices behind a feature flag or a
parallel path, keeps the old behavior working until the new one is proven, and
removes the flag afterward. Mentions the cost of long lived branches and of
flags that never get cleaned up.
WHAT TO LISTEN FOR
Enthusiasm for a rewrite is the warning sign. Enthusiasm for a boring,
reversible, incremental path is the hire. Ask what they left behind on purpose;
the ability to leave working code alone is a senior trait.
NOTES
[Record migration specifics: what moved, what stayed, how long it took.]
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
Set 5: Seniority, Code Review, and Mentoring Questions
Decisions owned end to end, a decision that turned out wrong, a named developer they raised, how they write a review comment on work they disagree with, explaining a tradeoff plainly, estimates, and what they would refuse to do.
Seniority, Code Review, and Mentoring Questions
SENIOR .NET DEVELOPER INTERVIEW: SENIORITY AND MENTORING
Candidate: __
Interviewer: __
Date: __
WHEN TO USE THIS SET
Use this set with anyone who will work without a peer reviewing their code, or
who will be the most experienced developer in the building. At a small company
that is usually the same person. These questions need no technical knowledge
from the interviewer.
QUESTIONS, WHY THEY ARE WORTH ASKING, AND WHAT A GOOD ANSWER SOUNDS LIKE
1. Tell me about a technical decision you owned from start to finish.
Why ask: seniority is scope, and scope claims are checkable.
Good answer: they chose, they defended the choice, they lived with the
consequence, and they can say what the alternative would have cost. Uses "I"
about the decision and "we" about the work, which is the right way round.
Weak answer: cannot separate their contribution from the team's, or describes
a decision made above them that they implemented.
2. Tell me about a decision that turned out to be wrong.
Why ask: the willingness to answer honestly is itself the signal.
Good answer: a real decision with a real cost, what the early warning was, how
long it took to admit it, and what changed in how they decide now. Candidates
who cannot produce one either have not owned much or will not tell you when
something is going wrong on your system.
3. Name a developer you raised, and tell me what changed for them.
Why ask: mentoring claims are common and specific evidence is rare.
Good answer: a named person, a described gap, what the candidate actually did
about it over weeks, and what that person can do now that they could not
before. Vague warmth about enjoying helping juniors is not evidence.
4. How do you write a review comment on work you disagree with?
Why ask: code review is where a senior either raises the team or exhausts it.
Good answer: separates what must change from preference, explains the reason
rather than issuing the instruction, and moves the conversation off the pull
request when the disagreement is real. Mentions that a review is the cheapest
teaching moment they get and treats it that way.
5. Explain a technical tradeoff to me as if I do not write code.
Why ask: at a small company the person deciding the budget is not technical,
and a senior developer who cannot explain a cost cannot be trusted with one.
Good answer: plain language, one concrete comparison, honest about the risk,
and no jargon used to end the conversation. Ask a follow-up question and see
whether they welcome it or get impatient.
6. How do you estimate, and what happens when the estimate is wrong?
Why ask: it predicts how the next six months of planning will feel.
Good answer: gives a range with the assumptions and the risks named, breaks
work down until the pieces are understandable, and raises the problem early
rather than at the deadline. Says what they do when they are halfway through
and can see the estimate was optimistic.
7. What would you refuse to do?
Why ask: it surfaces professional standards without asking about values in
the abstract.
Good answer: something concrete about safety, security, data, or honesty:
shipping without a way back, storing secrets or personal data carelessly,
promising a date they know is false. Explains how they raise it with a
non-technical owner without turning it into a fight.
WHAT TO LISTEN FOR
Every question here works even if you have never written a line of C#. Grade
specificity, ownership, and honesty. A senior candidate names people, systems,
and consequences. A weaker one describes philosophies.
NOTES
[Record named people and systems, and how the candidate handled disagreement.]
Set 6: Scoring Rubric, Seniority Guide, and Red Flags
A six area rubric scored 1 to 5 with evidence lines, a mid-level versus senior comparison, and a ten item red flag checklist, so candidates are compared on what they said rather than on who interviewed most smoothly.
Scoring Rubric, Seniority Guide, and Red Flags
SENIOR .NET DEVELOPER INTERVIEW SCORECARD
Candidate: __
Interviewer: __
Date: __
Role: __
Score each area from 1 to 5 and write the evidence next to it. Evidence means
something the candidate actually said, not an impression. Score alone, before
Ownership and plain-language communication Score: [ 1 2 3 4 5 ]
Evidence: __
Total: ______ / 30
Recommendation: [ ] Strong yes [ ] Yes [ ] No [ ] Strong no
WHAT A 5 LOOKS LIKE
C# judgment: gives the reason and the consequence, with a story from code they
maintained rather than a definition.
Runtime and production: has a repeatable method for diagnosing a live problem
and personally owned at least one incident end to end.
Application and data design: sizes the design to the business, is careful with
data changes, and names what each choice costs.
Migration and release: has led a real upgrade or framework migration, keeps
dependencies current as a routine, and has a tested way back.
Code review and mentoring: names a specific person they raised and reviews to
teach rather than to win.
Ownership and communication: owned a decision end to end and can explain a
tradeoff to someone who does not write code.
MID-LEVEL VERSUS SENIOR
Writes correct code from a given design Mid-level and senior both
Explains why a rule exists, not only the rule Senior
Chooses a design and names its cost out loud Senior
Follows a method when debugging under pressure Senior
Owns runtime and package upgrades unprompted Senior
Has specific evidence of raising a developer Senior
Gives a bounded estimate with risks named Senior
RED FLAGS
[ ] Every performance answer is "add a cache" or "add a server"
[ ] Cannot name a production incident they personally diagnosed
[ ] Wants to rewrite the existing system before understanding it
[ ] Scope claims get vaguer when you ask a follow-up question
[ ] Treats tests, backups, and rollbacks as someone else's job
[ ] Blames every previous employer with no share of the fault
[ ] Uses jargon to end a question rather than to answer it
[ ] No opinion on where secrets live or who has production access
[ ] Mentoring answers contain no named person and no described change
[ ] Cannot describe how a change reaches production anywhere they worked
NOTES
[Two sentences on the strongest evidence for and against hiring this person.]
How to Judge Answers If You Do Not Write C#
You do not have to grade the code. You have to tell a specific, reasoned answer from a rehearsed one, which is a skill you already use in every other kind of interview you run. The notes in each set give you the shape of a strong answer so you can listen for it without reading a line of C#.
The pattern holds across all six sets. Strong answers name a real system, describe how the person found the problem, and say what the fix cost. Weak answers stay at the level of the textbook and never reach a consequence. Three examples make the difference concrete.
Someone calls an async method with .Result. What happens, and when?
Strong answer: Names the mechanism, a blocked thread waiting on work that needs a thread, then the symptom you would actually see: a fast endpoint that starts timing out once real traffic arrives, intermittently, which is why it survived testing. Ends with the fix being the whole call chain rather than one method.
Weak answer: Says it can deadlock, offers no mechanism, and cannot say what it looks like from the outside.
Memory climbs and never comes back down. How do you find out why?
Strong answer: Reaches for evidence first: capture the running process, compare two snapshots minutes apart, find the type that is growing. Then names the usual causes, a cache with no eviction, an event handler never unsubscribed, connections created per request, and fixes the cause.
Weak answer: Suggests restarting on a schedule or raising the memory limit, without ever proposing to look at the heap.
Describe a migration off the older .NET Framework that you led.
Strong answer: Says what moved first and why, what stayed behind on purpose, which libraries had no modern equivalent, and how long it really took. The estimate they got wrong is in the answer without you having to ask for it.
Weak answer: Describes a migration the company completed, with no clear account of what this person decided or did.
Two habits do most of the work. Ask why that matters after every answer, and ask for the number: how slow, how many records, how long the fix took, how many customers noticed. Someone who lived the story produces that detail without effort, and someone who did not gets vague at precisely that point.
The Framework Migration Question
Ask every senior .NET candidate to describe a migration from the older .NET Framework to modern .NET that they personally led. It is one of the hardest claims to fake, and for most small companies it is closer to the real job than anything else on the page.
The .NET world carries a long tail of applications built a decade or more ago that still process orders, invoices, and payroll every day. If you are hiring a senior developer, there is a good chance you own one of them. The candidate you want is the one who can move it forward in pieces without stopping the business, not the one who wants to start again.
Listen for what moved first and why, what stayed behind on purpose, and which blockers were real: libraries with no modern equivalent, older service and messaging stacks, configuration and identity differences, code that assumed a Windows-only host. A candidate who was there volunteers the estimate they got wrong. A candidate who watched from a distance describes an outcome with no decisions in it.
Enthusiasm for a Rewrite Is a Warning Sign
A candidate who wants to replace your working application before they have read it is describing the project they want rather than the job you have. A rewrite restarts the bug count from zero instead of finishing at zero, and the version you already run has years of accumulated corrections buried in it that nobody wrote down. The senior answer is incremental and reversible: move one piece at a time behind a stable boundary while the existing system keeps earning. Ask what they would deliberately leave alone. The ability to leave working code alone is a senior trait, and it is rarer than it sounds.
What Separates Senior from Mid-Level
Seniority is scope and judgment, not years. A mid-level developer implements a design well; a senior developer chooses the design, defends it, and names its cost out loud. Interview for that difference directly rather than assuming a longer resume delivers it.
Signal
Mid-Level
Senior
Writes correct, working code from a design given to them
Explains why a language rule exists, not only the rule
Chooses a design and names what it costs
Follows a repeatable method when debugging under pressure
Owns runtime and package upgrades unprompted
Has specific evidence of raising another developer
Gives a bounded estimate with the risks named out loud
One warning about the calendar. A candidate with a decade inside a large platform team may never have chosen a database, run a migration alone, or explained a tradeoff to an owner, because the organization did those things for them. A candidate with five years across two small companies has often done all three. Interview the scope, not the years.
The .NET ecosystem adds a specific version of this trap. Long-lived applications create developers who are genuinely expert in a stack that stopped moving years ago. That is not disqualifying, and some of the best maintainers come from exactly there, but ask what they have read about or tried outside their employer's stack. Curiosity is the signal, not the version number on the resume.
The Timeout Under Load Exercise
Replace the algorithm puzzle with a diagnosis conversation. Describe a real endpoint from your own system that gets slow or starts timing out under load, ask the candidate to talk through what they would look at and in what order, and grade the first five minutes. It takes 20 to 25 minutes and needs no whiteboard, no compiler, and no technical skill from you.
Set the scene in two minutes
One of our endpoints answers in 200 milliseconds all morning, then starts timing out around lunchtime. The machine is barely busy. It clears if we restart it. What would you look at, and in what order?
Grade the first five minutes
A senior candidate asks what changed and when, how the traffic pattern differs at that hour, and what the logs and latency percentiles show before proposing anything at all.
Listen for evidence before fixes
The strong path is thread pool and queue metrics, a dump taken while it is failing, then blocking calls, lock contention, or connection pool limits. The weak path is add a cache, add memory, add a server.
Ask what they would change afterward
The best answers do not stop at the fix. They add an alert, a load test, or a review rule so the same failure cannot reach production silently a second time.
The exercise works for a non-technical interviewer because seniority shows up in the order of investigation, not in syntax. A senior candidate asks what changed and when, asks how the traffic differs at that hour, and wants timings before proposing anything. A weaker candidate starts offering fixes in the first minute: add a cache, add memory, add a server. That contrast is audible even when the underlying subject is opaque to you.
It also respects the candidate. Senior developers holding two other conversations will decline a four hour unpaid take-home project, and they are right to, but almost all of them will happily spend twenty five minutes debugging a real problem with you. That is a genuine advantage when you are the smaller name, as our guide to finding developers for a small company covers in more detail.
Skip the Timed Algorithm Puzzle
Copying a large technology company's screening format, with a timer and a whiteboard, tests something your job does not require. It measures recent interview drilling rather than the ability to keep a .NET application running, and it filters out exactly the experienced maintainers a small team needs, because someone who has shipped for fifteen years is the least likely to have spent last month practicing puzzles. Use the timeout exercise and the production questions instead, and reserve any written exercise for a short, realistic, paid task.
Red Flags Worth Acting On
Most red flags in a senior interview are about direction rather than content. Strong answers get more specific when you push; improvised ones get vaguer at exactly that point. Four patterns are worth stopping on, and each has a follow-up question that resolves it quickly.
The scope claim that shrinks
The candidate says they architected a platform, and when you ask who chose the database, who ran the migration, and who was called when it failed, the answer becomes a team. This is the most common exaggeration at senior level and it resolves in one follow-up. Ask what they personally decided, then confirm it during the reference check rather than arguing about it in the room.
Every answer is more infrastructure
Ask about a slow endpoint and hear add a cache. Ask about memory and hear give it more memory. Ask about load and hear add a server. A senior developer gathers evidence before spending money, because at a small company the money is yours and the underlying bug follows you onto the bigger machine.
The rewrite reflex
A candidate who wants to replace your working application before they have read it is describing the project they want rather than the job you have. Incremental migration behind a stable boundary is the senior answer. Ask what they would deliberately leave alone; the ability to leave working code alone is a real signal.
Operations belongs to someone else
Tests, backups, rollbacks, secrets, and monitoring get waved off as another team's responsibility. That can be honest history at a large employer, but you have no other team. Ask directly whether they want a role where those things are theirs, and take a hesitant answer seriously rather than talking them into it.
None of these is automatically disqualifying on its own, and one weak answer in an hour is normal. A pattern across a whole interview is different. When a scope claim does not survive the follow-up, write it down and confirm it during the reference check rather than arguing about it in the room.
Scoring the Interview
Score every candidate on the same rubric immediately after the interview, while the answers are still fresh. Rate six areas from 1 to 5 and anchor each score to something the candidate actually said, so you end up comparing evidence rather than comparing which conversation felt better.
Scoring area
What a 5 looks like
C# judgment
Gives reasons and consequences, with stories from code they maintained
Runtime and production behavior
A repeatable diagnostic method and ownership of a past incident
Application and data design
Designs sized to the business and real care with data changes
Migration, upgrade, release
Led a real migration, keeps packages current, has a tested way back
Code review and mentoring
Names a person they raised and reviews to teach, not to win
Ownership and communication
Owned a decision end to end and explains a tradeoff plainly
If two or three people interview, each should score alone before the group talks, otherwise the most technical voice anchors everyone else. The same questions and the same rubric for every candidate is the core of a structured interview, and it feeds cleanly into a shared evaluation form.
Keep the completed scorecards for every candidate together rather than scattered across three inboxes, so the comparison still holds up a month later when the next role opens. Applicant tracking is coming soon to FirstHR; until it ships, a shared folder and a consistent file name are enough for a small team.
Senior .NET Developer Pay
There is no separate federal occupation code for .NET, so benchmark against software developers and adjust upward for seniority. Treat the government figures as the floor of the conversation, then account for your metropolitan market, whether the role is remote, and how much scope one person will carry alone.
Median $135,980, Top 10 Percent Above $214,670 (BLS, May 2025)
According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), software developers had a median annual wage of $135,980, about $65.38 an hour. The lowest 10 percent earned less than $82,460 and the highest 10 percent more than $214,670 (U.S. Bureau of Labor Statistics). Senior roles sit in the upper half of that range.
Classification matters as much as the number. Under the Fair Labor Standards Act, the computer employee exemption can cover a software engineer or similarly skilled worker paid on a salary basis at no less than $684 per week, or hourly at no less than $27.63. Duties and pay decide it, not the title, and several states apply a stricter test.
Write the classification, the pay, and the remote expectations into the offer. There is no dedicated senior .NET developer job description in our library yet, so if the role is not written down, the software developer job description and the senior backend developer templates give you a starting point to adapt. This is general information, not legal or compensation advice.
Fair, Legal, and Structured Interviewing
A good technical interview is fair, legal, and structured, and the three reinforce each other. Asking every candidate the same job-related core questions keeps you compliant, reduces bias, and produces a better decision, which is the part almost every engineering question list leaves out.
Hold the question set steady, vary the follow-ups
A structured interview means every candidate answers the same core questions and is rated on the same scale. Technical interviews drift more than most, because a loose conversation naturally follows whatever the candidate happens to be strong at, and you end up comparing two different interviews instead of two candidates. Write the questions before the first call, ask them in the same order, and let only the follow-ups vary. The sets on this page are built to be used exactly that way, and the rubric gives you the same scale for everyone. This is general information, not legal advice.
Ask about the job, never about the person
Federal anti-discrimination law prohibits basing hiring decisions on protected characteristics, and a question that probes one creates risk even when it is asked as friendly small talk. Do not ask about age, race, religion, national origin, sex, pregnancy or family plans, disability, or genetic information. The senior technical interview has its own version of this trap: graduation dates, how long ago someone started programming, and comments about which generation learned which stack are all age proxies. Ask what the person has built and owned. This is general information, not legal advice.
Score alone before anyone discusses
When two or three people interview, each should complete the scorecard privately before the group talks. Otherwise the most technical voice in the room anchors everyone else, and the discussion becomes a negotiation about who felt strongest rather than a comparison of what candidates actually said. Anchor every score to a quote or a specific claim. If a score cannot be tied to something the candidate said, it is an impression, and impressions are exactly what a structured process is meant to filter out of the decision.
Interview for the role you actually have
A senior .NET developer keeping a long-lived internal application alive and one building a new customer-facing service are different hires with different question weights. Decide what this person must accomplish in their first ninety days, then weight the sets to match: migration and data for an inherited system, application design and runtime for something new. Interviewing for a generic senior engineer you cannot keep busy is how small companies hire someone impressive who leaves inside a year because the work was not what the interview implied.
Structure Beats a Free-Flowing Technical Chat
Federal hiring guidance describes the structured interview, in which every candidate answers the same questions and is rated on the same scale, as one of the most reliable and legally defensible selection methods available (U.S. Office of Personnel Management). Asking the same job-related questions of everyone also keeps you within the EEOC rules against basing decisions on protected characteristics.
Technical interviews drift more than most, because a loose conversation follows whatever the candidate happens to be good at. Writing the questions in advance and holding the set steady is the whole fix. For the general version of the discipline, see our guides on running an interview and on questions employers cannot ask.
Interviewing Without an HR Department
A large employer runs a senior .NET candidate through coordinated panels, with a recruiter managing the scorecards and a platform team ready to absorb mistakes after the hire starts. A small business has none of that, and the person you hire often becomes the entire engineering function. That reality should change how you run the interview.
The person you hire probably becomes the whole engineering function
A large employer runs a senior .NET candidate through coordinated panels, with a recruiter managing scorecards and a platform team ready to absorb whatever the new hire gets wrong. You have none of that. The person you choose will pick the design, write the tests, own the upgrades, deploy the application, and answer the phone when it stops responding. That should change the weighting of the interview: put runtime behavior, release ownership, and package hygiene above raw coding speed, because there is no second reviewer to catch what slips through.
You are interviewing for skills you cannot personally grade
Most owners hiring a senior .NET developer do not write C#, which is exactly why every question in these sets ships with the reason it is worth asking and the shape of a strong answer. You are not grading the code. You are telling a specific, reasoned, lived answer from a rehearsed one, which is a skill you already use in every other interview you run. Ask why that matters after each answer, then ask for the number: how slow, how many rows, how long the fix took. Someone who was there produces the detail without effort.
Senior candidates are interviewing you at the same time
An experienced .NET developer holding two other conversations will decline a four hour unpaid take-home project, and they are right to. They will almost always spend twenty five minutes debugging a real problem with you, which is why the exercise on this page is a conversation rather than a test. Move fast once you decide, and put the decision in writing the same day. FirstHR handles the part that follows: the offer sent for signature, the paperwork, the access checklist, and the signed documents stored on the employee profile. Applicant tracking is coming soon to FirstHR.
Two practical rules follow. Weight testing, documentation, and upgrade discipline above raw speed, because there is no second reviewer to catch what slips. And move fast once you decide, since the same candidate is almost always talking to other companies. More question sets for the rest of the team sit in the hiring templates library, including a backend engineer set if the next hire is broader than .NET.
From Interview to Onboarding
The interview is step one, and a strong hire who lands badly still leaves inside a year. Move quickly from decision to a written offer letter, run a reference check that confirms what the candidate personally built, and have access ready before day one.
Offer, IP assignment, and confidentiality
Put the role, pay, and classification in writing, and have the developer sign an intellectual property assignment and a confidentiality agreement before the first commit.
Accounts in the company name
Create the repository, hosting, database, domain, and monitoring accounts under the business, then grant access. Never inherit an account that belongs to a person.
Agree the reliability rules in week one
Source control, review, staging, backups, and who gets called during an outage, settled before the first incident rather than during it.
Keep the records together
Signed offer, IP assignment, confidentiality agreement, I-9, W-4, and policy acknowledgments, organized and easy to find when you need them.
Developer onboarding carries extra steps because of the access involved: repository, hosting, database, and deployment credentials, plus confidentiality and intellectual property paperwork signed before any of it is granted. Our guide to onboarding a developer walks through the sequence, and the standard new hire paperwork still applies on top of it.
FirstHR connects the offer, the e-signatures, the paperwork, and the access and policy checklist in one place, and keeps the signed documents on the employee profile, so a small business can run the whole hiring-to-onboarding path from a single system. FirstHR is an onboarding and HR platform, not a code hosting service or a technical assessment tool, so pair it with those. Applicant tracking is coming soon to FirstHR.
If you want the first ninety days written down rather than improvised, an onboarding template gives the new developer a real ramp: something small shipped in week one, ownership of one area by month two, and a written check-in at 30, 60, and 90 days.
Key Takeaways
Interview a senior .NET developer on judgment rather than recall: C# depth, runtime behavior, application and data design, migration ownership, and mentoring.
Ask why that matters once after every answer; the second layer is where a lived answer separates from a rehearsed one.
Replace the timed algorithm puzzle with a 20 to 25 minute walkthrough of a real endpoint that times out under load, and grade the order of investigation.
A migration off the older .NET Framework that the candidate personally led is one of the hardest claims to fake and one of the most useful to hear.
Seniority is scope and judgment, not years, so interview the decisions someone owned rather than the length of the resume.
Score six areas from 1 to 5 with written evidence, independently, before anyone in the group discusses the candidate.
Benchmark pay against the federal software developer figures: a $135,980 median in May 2025, with the top 10 percent above $214,670.
Frequently Asked Questions
What should I ask a senior .NET developer in an interview?
Ask questions that force a reason rather than a definition. Five areas cover the role: core C# judgment, where async pitfalls, disposal, and LINQ execution reveal whether the candidate has been burned by them; runtime behavior, where you ask how they diagnosed a real production incident; application and data design, covering dependency injection lifetimes, transaction boundaries, and schema changes without downtime; migration and release ownership, especially a move from the older .NET Framework to modern .NET that they personally led; and seniority, meaning decisions owned end to end and a named developer they raised. The most useful follow-up is four words long: why does that matter. A prepared candidate delivers the textbook sentence and stops. Someone who has maintained a .NET system for years keeps going into what it cost.
How do I interview a senior .NET developer if I do not write code?
You do not have to grade the code, only tell a specific, lived answer from a rehearsed one. Use question sets that state the reason each question is worth asking and the shape of a strong answer, then listen for that shape. Two habits do most of the work. Ask why does that matter after every answer, and ask for the number: how slow was it, how many records, how long did the fix take, how many people were affected. Someone who was actually there produces that detail without effort, and someone who read about it gets vague at exactly that point. The seniority and mentoring questions need no technical knowledge at all, and the timeout exercise on this page is graded on the order of investigation rather than on any code.
What separates a senior .NET developer from a mid-level one?
Scope and judgment, not years. A mid-level developer implements a design well. A senior one chooses the design, defends it, names what it costs, and lives with the consequence. In practice that shows up as explaining why a language rule exists rather than only stating it, following a repeatable method when debugging under pressure, owning runtime and package upgrades without being asked, having specific evidence of raising another developer, and giving a bounded estimate with the risks said out loud. Beware the calendar trap. Someone with ten years inside a large platform team may never have chosen a database, run a migration alone, or explained a tradeoff to an owner, because the organization did those things for them. Interview the decisions a person owned, not the length of the resume.
Should I ask a senior .NET candidate to complete a coding test?
Usually not in the form most companies use. A timed algorithm puzzle measures recent interview practice rather than the ability to keep a .NET application running, and it filters out exactly the experienced maintainers a small team needs, because someone who has shipped for fifteen years is the least likely to have spent last month drilling puzzles. Long unpaid take-home projects fail differently: strong candidates with other conversations in progress simply decline them. A diagnosis conversation works better. Describe a real problem from your own system, ask the candidate to talk through what they would investigate and in what order, and grade the first five minutes. If you want written work, keep it short, realistic, and paid.
How important is .NET Framework migration experience?
For most small companies it is one of the most valuable things a senior candidate can bring, because a large share of business-critical .NET applications were built on the older Framework and still earn money every day. Someone who has led a migration to modern .NET knows the parts that do not appear in tutorials: libraries with no modern equivalent, older service and messaging stacks, configuration and identity differences, and code that assumed a Windows-only host. Ask what they moved first, what they deliberately left behind, and how long it really took. The answer you want is incremental and reversible. Enthusiasm for a full rewrite before understanding the existing system is a warning sign, because a rewrite restarts the bug count from zero rather than finishing at zero.
How much does a senior .NET developer cost?
There is no separate federal occupation code for .NET, so benchmark against software developers and adjust upward for seniority. According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey for May 2025, software developers had a median annual wage of $135,980, about $65.38 an hour, with the lowest 10 percent under $82,460 and the highest 10 percent above $214,670. Senior roles sit in the upper half of that range, and a metropolitan market, a fully remote posting, or a role where one person carries the entire system alone all push the number. Treat the federal figures as the floor of the conversation rather than the answer. This is general information, not compensation or legal advice.
Is a senior .NET developer exempt from overtime?
Often, but the duties and the pay decide it rather than the title. Under the Fair Labor Standards Act, the computer employee exemption can apply to a computer systems analyst, programmer, software engineer, or similarly skilled worker who is paid on a salary basis at no less than $684 per week, or hourly at no less than $27.63, and whose primary duties involve systems analysis, design, development, or testing. Several states apply stricter tests and higher salary thresholds, so check your state rules as well as the federal ones. Write the classification into the offer letter along with the pay and the remote expectations, and keep the record. This is general information, not legal advice; consult a qualified advisor for your situation.
How many interview rounds does a senior .NET hire need?
Two or three is usually right for a small company, and more than that costs you candidates. A short first conversation confirms scope and interest and covers the seniority questions, which need no technical knowledge from you. A longer technical round covers core C# judgment, runtime behavior, and application design, and includes the diagnosis exercise. An optional third conversation covers the specific system this person will inherit, with whoever knows it best. Score after each round while the answers are fresh, and if more than one person interviews, have each score privately before the group discusses. Move quickly once you decide, because an experienced .NET developer is almost always talking to other companies at the same time.
