.NET developer interview questions

Interviewers for .NET roles are specifically listening for whether your knowledge is current. The ecosystem changed substantially — nullable reference types, pattern matching, records, minimal APIs — and a candidate answering as though none of that happened reads as someone who stopped learning.

This matters more than in some ecosystems because so much .NET work is on long-lived codebases. The concern is not that you have maintained old code; it is whether you know what the modern equivalent would be.

The comfortable way to demonstrate it is to name the problem each feature solved rather than the feature. Saying that nullable reference types moved a whole class of runtime failure into the compiler shows understanding; listing features shows you read a release note.

Nearly every .NET interview covers async. The shallow answer — that it makes things run in the background — is wrong and gets caught immediately. Async is about not blocking a thread while waiting on input or output; it does not by itself make anything parallel.

Be ready for the common mistakes: blocking on a task with `.Result` or `.Wait()` and the deadlock that can cause, `async void` outside an event handler, and forgetting to await so exceptions vanish. Naming these unprompted signals real experience.

The scaling consequence is the part worth adding. Blocking a thread pool thread while waiting on a database call means the pool exhausts under load, and the service becomes unresponsive while doing almost no work — which is the real reason the guidance exists.

• Why async helps with I/O and does nothing for CPU-bound work
• What `.Result` and `.Wait()` can deadlock, and why
• Why `async void` is a trap outside event handlers
• What happens to an exception in a task nobody awaited
• When `ConfigureAwait(false)` matters, and where it no longer does

Expect questions about the stack and heap, value versus reference types, boxing, and garbage collection generations. These are asked less for trivia than to see whether you can reason about allocation in a hot path.

The strong answer connects it to something real: why a struct in a tight loop avoids allocations, or why string concatenation in a loop is a problem and what you would use instead. Definitions without a consequence read as revision.

Boxing is the one to be precise about. Being able to say where it happens silently — putting a value type into an untyped collection, or an interface call on a struct — and why that matters in a loop running millions of times is a concrete answer where most give an abstract one.

The classic question is deferred execution — why nothing runs until you enumerate, and what happens if you enumerate twice. Closely related is `IEnumerable` versus `IQueryable`, which is really a question about where the work happens.

That distinction is the one that matters in production: filtering an `IEnumerable` pulls the whole table into memory first, while an `IQueryable` translates the filter into SQL. Being able to explain a real performance incident caused by that confusion is a strong answer.

The other EF question worth preparing is the query issued once per row of a previous result. It is the most common performance defect in data access code, it is invisible until you look at the generated SQL, and naming it on sight signals someone who has profiled a slow endpoint rather than read about one.

Service lifetimes come up constantly, usually as a bug: what goes wrong when a scoped service is captured by a singleton. Being able to explain the captured-dependency problem rather than just listing the three lifetimes is what is being checked.

Expect broader design questions too — where you would put business logic, how you would test something coupled to a database, how you keep controllers thin. Opinions are fine here as long as you can defend the trade-off.

The database-coupling question has a trap in it. Answering that you would mock the data context is acceptable; answering that you would prefer an integration test against a real database for query-heavy logic, because mocking the query provider tests your mock rather than your query, is better and shows you know what the test is worth.

Many .NET loops include a small implementation task, often with a deliberate concurrency or resource angle — a cache, a rate limiter, something reading a file. What is assessed is disposal, error handling and whether you noticed the shared state.

Use `using` and dispose properly without being reminded, and say why. Resource handling is one of the clearest seniority signals in this ecosystem and it costs nothing to demonstrate.

If the task involves anything shared across requests, say the word thread-safe out loud and explain your choice even if you pick the simple option. Recognising the concern and deciding deliberately is scored well above silently getting away with it.

Spend most preparation on async and on EF query behaviour. Between them they account for a large share of questions and an even larger share of real production incidents, which is why interviewers keep returning to them.

Prepare one performance story: something that was slow, how you found the cause, what you changed and what the number became. That single story answers a surprising number of technical and behavioural questions at once.

Then spend an hour on what changed in the language recently. It is the cheapest way to avoid the dated-answer problem, and being able to mention a feature and the problem it solved leaves an impression out of proportion to the effort.