What Actually Comes Up in .NET Interviews
I went through three hiring cycles last year for backend roles, and the pattern was pretty consistent. Most candidates can recite textbook answers about dependency injection or explain what an interface is. Very few can actually talk through a real scenario where things broke and how they fixed it. That gap is where most interviews get decided. The questions you see advertised online tend to cover surface-level stuff: lifecycle methods, basic LINQ syntax, the difference between abstract classes and interfaces. Those matter, sure. But the questions that separate people who can build maintainable systems from people who just pass coding tests are usually more situational.
Net Developer Interview Questions That Actually Matter
Here is what I look for when I am screening people. Not the trivia. The stuff that shows someone has shipped code in production. One question that comes up a lot is about connection management in Entity Framework. Anyone can write a using block. What most people cannot explain clearly is what happens when you dispose a DbContext inside a Web API controller but the async method has not completed yet. I had a situation once where a service layer was leaking connections because the Dispose was being called before the HTTP response finished streaming data back to the client. The workaround was switching to a scoped lifetime registration and explicitly calling SaveChangesAsync before the action method returned, plus setting CommandTimeout appropriately on long-running queries. Another common one is around background processing. People will tell you to use IHostedService or BackgroundService for fire-and-forget tasks. That is correct but incomplete. The real question is how you handle graceful shutdown when the host is being terminated. I have seen multiple projects where queued jobs were mid-execution when the container received SIGTERM, and data ended up in an inconsistent state because nobody implemented CancellationToken propagation properly through the entire pipeline. The fix was wrapping each job in a try-catch with timeout checks and using IHostApplicationLifetime to coordinate shutdown sequencing.
Memory management is another area where candidates routinely miss details. Static collections that grow unbounded, event handlers that are never unsubscribed, or large object heap fragmentation from string concatenation in loops. I once traced a production memory leak to a caching layer that stored dictionary values as WeakReference<object> but never actually checked if the reference had been garbage collected before returning the value. The cache appeared full but was actually returning nulls constantly, which caused the caller to repeatedly recreate objects and overwrite the cache instead of reusing them. Took about two days of profiling with dotMemory to surface.
Get the Full Details
Topics You Should Be Ready To Discuss
Middleware pipeline ordering comes up constantly. Know why authentication middleware needs to sit before authorization, why CORS needs to be early in the pipeline, and what happens when you put UseEndpoints after UseStaticFiles incorrectly. People who understand the request delegate chain can troubleshoot issues in production without needing to check logs immediately. Async patterns are non-negotiable. Not just the syntax, but the actual mechanics. When does async void actually make sense? (Almost never, but there are a couple of legitimate use cases in UI event handlers.) What is the difference between ConfigureAwait(false) and not using it at all? Why does calling .Result or .Wait() on an async task risk deadlocking in certain synchronization contexts? Generic constraints and covariance get asked less often now, but when they do, they reveal whether someone understands the type system deeply or just copied Stack Overflow solutions. out vs in variance, why you cannot cast List<Derived> to IList<Base> but can to IEnumerable<Base>, and what the compiler is actually preventing. Knowing the answer matters more in code reviews than in interviews, but interviewers ask it because it filters out people who just type code without understanding types.
Transaction handling across distributed services is where things get interesting. Most candidates describe TransactionScope and stop there. The follow-up should be about what happens when that scope escalates to a distributed transaction, the performance cost of MSDTC, and why you should prefer compensating transactions or sagas for cross-service workflows instead. I recommended switching a team from TransactionScope to explicit Unit of Work patterns with Saga orchestration, and it cut our average database lock time from about 400ms per request down to under 50ms in high-concurrency scenarios.
What Most Candidates Get Wrong
The biggest mistake I see is answering questions as if they are written exams. When someone asks about dependency injection, describing the four lifestyle options is fine. But the useful answer includes knowing which lifestyle causes problems in singleton-resolved-per-request scenarios, or why registering a scoped service as transient will silently give you a new instance each time instead of the expected scope-behavior. Another common error is assuming ASP.NET Core behaves the same across all hosting models. Kestrel, IIS Express, Docker containers, Azure App Service — each has different defaults for request limits, timeout behavior, and process management. A configuration that works locally might silently fail in production because MaxRequestBodySize defaults differently, or because the server headers get rewritten by the IIS Integration layer. People also tend to over-index on framework features and under-index on fundamentals. Knowing every new C12 feature is nice. But being able to walk through how the garbage collector actually works — generations 0 through 2, the LOH, the SOH, how Span<T> avoids allocations on the managed heap — is far more valuable in practice. I have seen junior developers introduce subtle performance regressions simply because they did not understand that string interpolation still creates temporary buffers in certain hot paths.
How to Prepare Without Wasting Time
Writing a small project that actually breaks is more useful than reading another list of questions. Create an API that uses EF Core with multiple DbContexts, add a background service that processes messages from a queue, introduce a deliberate deadlock or memory issue, then spend time profiling and fixing it. The process of debugging your own problem teaches you more than memorizing answers ever will. Reviewing real pull requests from open-source .NET projects helps too. You see how experienced developers structure their code, where they put validation, how they handle errors in production. The aspnetcore repository on GitHub has thousands of merged PRs with discussions that reveal architectural decisions and tradeoffs you will not find in documentation. Practice explaining your decisions out loud. Record yourself answering a question like "describe a time you optimized a slow endpoint" and listen to it. If you spent more than three minutes before getting to the actual solution, you are rambling. The best answers are short, specific, and acknowledge what you did not know at the time. Saying "I initially thought the problem was the query but it turned out to be N+1 reads in the serialization layer" is more credible than a perfectly polished story with no uncertainty.
When Standard Answers Fall Apart
There are edge cases where the textbook approach simply does not work. For example, MediatR is commonly recommended for implementing the mediator pattern in .NET applications. It works well until you need centralized request timing, global exception handling, or caching across multiple handlers. I once had to replace an entire MediatR pipeline with a custom request dispatcher because the overhead of reflection-based handler resolution added roughly 15 milliseconds per request in a high-throughput service processing thousands of events per second. The custom version used precompiled Expression<Func> delegates instead, cutting that overhead to under 0.5 milliseconds. Similarly, minimal APIs are fine for simple CRUD endpoints. They fall apart quickly when you need complex middleware composition, attribute-based routing with custom constraints, or structured logging that depends on endpoint metadata. There is a point where the convenience of app.MapGet stops paying for itself. Entity Framework Core tracking queries versus no-tracking queries is another area where the standard advice does not always apply. The common guidance is to use NoTracking for read-only queries to improve performance. But in a multi-tenant application with row-level security enforced through filters, disabling tracking can cause unexpected behavior with query compounding and parameterization, leading to plan cache bloat and unpredictable performance degradation under load.
If you are preparing for interviews, focus on understanding the tradeoffs behind each decision rather than collecting answers. The questions will shift, frameworks will evolve, but the ability to reason through a problem when the textbook answer does not fit is what actually gets you hired.
