.NET Interview Questions: The 2026 Guide (300+ Real Questions)

.NET interview questions in 2026 are scenario questions, not definitions. No one good asks “what is dependency injection?” anymore - they ask “you injected a scoped service into a singleton and it works in dev but corrupts data in production, what happened?” This guide is the hub for the whole set: 20 cross-topic questions answered in full below, plus deep-dive pages with 300+ more across C#, EF Core, ASP.NET Core, and system design.

I’ve sat on both sides of the table plenty of times. What follows is the format that actually works in real interviews - a real scenario, how I’d answer it, the answer that gets you rejected, and the follow-up the interviewer chains next. Everything is current to .NET 10 and C# 14. Let’s get into it.

How .NET Interviews Actually Run in 2026

Before the questions, understand the shape of the interview - it tells you what each round is testing and how to prepare for it. Most .NET interviews at product companies run four rounds:

1. Screening / fundamentals - C# basics, value vs reference types, async/await, LINQ. This round filters out people who can’t code. Definitions are acceptable here, but even now the good screeners are scenario-based.
2. Technical deep-dive - ASP.NET Core internals, EF Core, the framework you’ll actually use. This is where scenario questions dominate and where most candidates are won or lost.
3. System design - “Design a rate limiter”, “Design a notification service”. Tests whether you can reason about scale, trade-offs, and failure. Weighted heavily for mid and senior roles.
4. Behavioral / judgment - “Tell me about a production incident”, “When did you push back on a technical decision?” Tests ownership and communication.

The thing that separates strong candidates across every round: they don’t recite, they reason. They start with a default, name the trade-off, and explain when they’d deviate. That single habit is what the questions below are built to train.

The .NET Interview Questions Cluster

This page covers the cross-topic greatest hits. For the full set on any topic, follow its deep-dive page. The cluster is growing - pages marked live are ready now, the rest are publishing through 2026.

C# Language Questions

These come up in the screening round. The trap is treating them as definitions - the good answers show you know the runtime behavior.

Q1. What’s the Difference Between a Record and a Class, and When Do You Use a Record?

Difficulty Mid

A record is a reference type like a class, but the compiler gives it value-based equality, a built-in ToString, and with-expression copying. Two records with the same property values are equal; two class instances are not unless you override Equals.

I reach for records when the type is defined by its data and is effectively immutable - DTOs, API request/response models, value objects, events. I use a class when the type has identity and mutable behavior, like an EF Core entity or a service.

Red flag answer: “Records are just shorter syntax for classes.” - Misses the value-equality semantics, which is the entire point.

Q2. What Happens When You Box a Value Type, and Why Should You Care?

Difficulty Mid

Boxing wraps a value type (an int, a struct) in an object on the heap so it can be treated as a reference type. It allocates, and unboxing copies the value back out. In a hot loop, repeated boxing creates GC pressure that shows up as latency spikes.

It happens more often than people think: storing structs in a non-generic collection, passing a struct where an object or interface is expected, or string-interpolating a value type. I care because in a high-throughput API it’s a silent allocation source, and generics or Span<T> usually avoid it.

Red flag answer: “Boxing doesn’t really matter, the GC handles it.” - True until you profile a hot path and find it’s half your allocations.

Q3. You See async void in a Code Review. Why Do You Flag It?

Difficulty Senior

async void is fire-and-forget you can’t await, so the caller has no way to know when it finishes or whether it failed. Worse, an exception thrown inside an async void method isn’t captured on a returned task - it’s raised on the synchronization context and typically crashes the process.

The only legitimate use is an event handler. Everywhere else it should be async Task. When I see async void outside an event handler, I assume there’s an unobserved exception waiting to take down the app.

Red flag answer: “It’s fine, it still runs.” - It runs right up until it throws and there’s nothing to catch it.

Follow-up: “Where is async void actually the correct choice?”

Async and Multithreading Questions

Q4. What Actually Happens When You Call .Result or .Wait() on a Task?

Difficulty Senior

You block the current thread until the task completes, which throws away the entire point of async. In a request-handling path it’s worse than wasteful: under load you tie up thread-pool threads waiting on I/O, the pool starves, and throughput collapses even though the CPU is idle. This is thread-pool starvation, and it usually presents as an API that’s fast under light load and falls over under real traffic.

My rule: async all the way down. If a method calls something async, it returns a task and is awaited by its caller. I don’t bridge sync and async with .Result.

Red flag answer: “I use .Result when I don’t want to make the method async.” - That’s how you ship an API that dies at scale.

Q5. What’s the Difference Between Task and Thread?

Difficulty Mid

A Thread is an OS-level thread - heavy, ~1 MB of stack, expensive to create. A Task is a higher-level abstraction representing work that may run on a thread-pool thread, complete asynchronously on I/O without holding a thread at all, or run inline. You almost never create a Thread directly in modern .NET; you use Task and async/await and let the runtime schedule it.

The distinction interviewers want: a Task is not “a thread.” An awaited I/O-bound task releases its thread back to the pool while it waits, which is why async scales.

Red flag answer: “They’re the same, a Task is just a thread.” - Then you can’t explain why async I/O scales better than spawning threads.

LINQ Questions

Q6. When Does a LINQ Query Actually Execute?

Difficulty Mid

LINQ uses deferred execution. Building a query with Where, Select, or OrderBy doesn’t run anything - it composes an expression. The query executes when you enumerate it: ToList, ToArray, Count, First, or a foreach. Until then it’s just a description of work.

This matters for two reasons. With EF Core, deferred execution is what lets the provider translate the whole chain into one SQL statement. And it’s a trap: if you enumerate the same query twice, it runs twice, hitting the database both times. When I need the results more than once, I materialize with ToList first.

Red flag answer: “The query runs as soon as I write the Where.” - Then you don’t understand why your query hit the database three times.

ASP.NET Core Questions

Q7. What’s the Correct Middleware Order for Routing, CORS, Authentication, and Authorization?

Difficulty Mid

Order is not cosmetic - each middleware depends on what ran before it. The correct sequence is UseRouting, then UseCors, then UseAuthentication, then UseAuthorization, then your endpoints (the middleware order docs lay out the full recommended pipeline). Authentication has to run before authorization because you can’t check what a user is allowed to do until you know who they are. CORS has to sit before the auth middleware so preflight requests get their headers.

The classic bug is registering CORS or authentication in the wrong place and getting silent 401s or missing CORS headers that look like framework bugs but are ordering mistakes.

Red flag answer: “Order doesn’t matter, ASP.NET Core figures it out.” - It absolutely matters, and this is a favorite interview trap.

Q8. You Inject a Scoped Service Into a Singleton. What Happens?

Difficulty Senior

That’s a captive dependency. The singleton is created once and lives for the app’s lifetime, so it captures the scoped service and holds the same instance forever - even though the scoped service was meant to be per-request. With a DbContext, that means one context shared across every request: thread-safety violations, stale data, and the change tracker growing without bound.

In .NET the DI container catches this at startup when scope validation is on (the default in development) and throws. The fix is to inject IServiceScopeFactory into the singleton and create a scope per unit of work.

Red flag answer: “Nothing, it just works.” - It works in a demo and corrupts data under concurrency.

Follow-up: “How does the built-in container detect this, and when does it not?”

EF Core Questions

EF Core is guaranteed in any .NET role that touches a database. These are the two that come up most; the full set is on the deep-dive.

Q9. Your Endpoint Returns 50 Rows but the Logs Show 51 Queries. What Happened?

Difficulty Senior

That’s the N+1 query problem: one query loads the 50 parent rows, then EF Core fires one more query per row to load a related navigation property - 50 extra round trips. It usually comes from lazy loading or iterating over a navigation property you forgot to Include.

I fix it by eager loading with Include, or better, projecting only the fields I need with Select so it’s a single query with no over-fetching. And I catch it early by turning on EF Core query logging in development so a burst of identical queries is visible.

Red flag answer: “I’d increase the connection pool size.” - That scales the symptom, not the cause.

Q10. When Do You Use AsNoTracking, and What’s the Catch?

Difficulty Mid

AsNoTracking skips creating change-tracking snapshots, which saves memory and CPU on read-only queries - so I use it for every GET-style query whose results I won’t modify. The catch interviewers probe: with no tracking, EF Core doesn’t do identity resolution by default, so the same row appearing twice in a join materializes as two separate objects. And you obviously can’t SaveChanges on an entity you didn’t track.

Red flag answer: “I put AsNoTracking on everything because it’s faster.” - Then how do your updates work?

System Design Questions

This round has almost no good free content, which makes it the differentiator. The format is open-ended scenarios - there’s no single right answer, only good reasoning about trade-offs.

Q11. Design a Rate Limiter for a Multi-Tenant API.

Difficulty Senior

I’d start by clarifying the dimensions: limit per tenant, per user, or per API key, and what the tiers are. Then I’d pick an algorithm - token bucket for smooth bursts, fixed or sliding window for simple quotas - and partition the limiter by the tenant identifier.

The key insight interviewers listen for: an in-memory limiter doesn’t work across multiple instances. Each replica would enforce the limit independently, so three instances means roughly triple the intended rate. For a distributed deployment the counter has to live in a shared store like Redis. I’d also return 429 with a Retry-After header so clients can back off correctly.

Red flag answer: “I’d use the built-in rate limiter middleware and I’m done.” - Fine for one instance; it silently breaks the limit the moment you scale out.

Follow-up: “What happens to your limiter when Redis goes down - fail open or fail closed?”

Q12. Your Background Job Processor Is 2 Million Messages Behind. What Do You Do?

Difficulty Senior

First I separate the immediate from the root cause. Immediate: is the consumer scaled to the work? I’d scale out consumers and check whether processing is CPU-bound, I/O-bound, or serialized on a lock or a single partition. A backlog often means one slow downstream dependency, not insufficient compute.

Then the structural fixes: make message handling idempotent so I can reprocess safely, batch where the downstream allows it, and add a dead-letter queue so poison messages don’t block the line. The reasoning matters more than any single fix - I’m showing I can diagnose a distributed bottleneck, not just “add more servers.”

Red flag answer: “I’d just spin up more consumers.” - Maybe, but if the bottleneck is a downstream database, more consumers make it worse.

Q13. How Do You Make a Payment API Endpoint Idempotent?

Difficulty Senior

Idempotency means the same request applied twice has the same effect as once - critical for payments, where a client retry must not charge twice. I’d have the client send an idempotency key (a GUID) with the request. On the server I store the key with the result; if the same key arrives again, I return the stored result instead of reprocessing.

The detail that separates a strong answer: the key has to be persisted atomically with the charge, in the same transaction, or a crash between charging and recording the key reopens the double-charge window.

Red flag answer: “I’d check if a payment already exists before inserting.” - That check-then-act has a race condition under concurrent retries.

Architecture and Judgment Questions

These appear in senior rounds. They have no single answer; they test whether you reason about trade-offs instead of reaching for the trendy choice.

Q14. When Would You NOT Use Microservices?

Difficulty Senior

Most teams. Microservices solve an organizational and scaling problem - independent deployment and scaling for large teams - not a code-quality problem. If you have a small team, a domain that’s still changing shape, no real independent-scaling pressure, and limited DevOps maturity, microservices add distributed-systems cost (network failures, eventual consistency, observability overhead) for benefits you don’t need yet.

My default is a modular monolith: clear module boundaries inside one deployable. You get most of the separation benefits and extract a service only when a specific, named pressure forces it.

Red flag answer: “Microservices are just the modern way to build, so always.” - That’s resume-driven design, and the follow-up about distributed transactions usually ends it.

Q15. Is CQRS Worth It, and When Would You Introduce It?

Difficulty Senior

CQRS - separating the read model from the write model - earns its keep when reads and writes have genuinely different shapes or scaling needs: a complex write domain with invariants, plus high-volume reads you want to serve from a denormalized or cached projection. It is not free; it adds moving parts and often eventual consistency between the two sides.

I would not introduce it on a straightforward CRUD service. I’d reach for it when the read and write paths start fighting each other - when the query model is being distorted to fit the command model or vice versa.

Red flag answer: “I always use CQRS with a mediator for clean architecture.” - Adding indirection to CRUD isn’t clean, it’s overhead.

Performance and Caching Questions

Q16. Two Hundred Requests Hit a Cold Cache Key at Once and All Go to the Database. What Is This and How Do You Stop It?

Difficulty Senior

That’s a cache stampede (or thundering herd): a popular key expires, and every concurrent request misses simultaneously and recomputes the same value against the database, spiking load exactly when the cache should be protecting it.

In .NET 10 I’d use HybridCache, which has built-in stampede protection - concurrent requests for the same missing key wait on a single computation instead of all stampeding the source. Before HybridCache you’d implement this yourself with a per-key lock around the cache-miss path.

Red flag answer: “I’d just set a longer cache expiry.” - That makes stampedes rarer, not impossible, and serves staler data.

Testing and Production Questions

Q17. How Do You Integration-Test an API That Hits a Real Database?

Difficulty Mid

I use WebApplicationFactory to spin up the app in-memory with the real pipeline, and point it at a real database running in a container via Testcontainers rather than an in-memory provider. The in-memory provider doesn’t enforce real SQL behavior - constraints, transactions, concurrency tokens - so tests pass against it and fail in production.

The combination gives me tests that exercise the actual request pipeline against the actual database engine, spun up and torn down per test run. That’s the level of confidence that catches the bugs unit tests miss.

Red flag answer: “I use the EF Core in-memory provider for integration tests.” - It doesn’t behave like a real database, so the test proves less than you think.

Q18. How Do You Handle Graceful Shutdown in a .NET API Running in Kubernetes?

Difficulty Senior

When the orchestrator sends SIGTERM, the app should stop accepting new requests, finish in-flight ones within a deadline, and release resources. ASP.NET Core wires into this through IHostApplicationLifetime and honors a shutdown timeout. For background work, the stoppingToken passed to a BackgroundService is the signal to wind down cleanly.

The detail that signals production experience: the readiness probe should flip to unhealthy before shutdown so the load balancer stops routing traffic, and you need the shutdown timeout to be longer than your longest reasonable request, or in-flight work gets killed mid-flight.

Red flag answer: “Kubernetes just kills and restarts the pod, so it doesn’t matter.” - That drops in-flight requests and corrupts work that wasn’t checkpointed.

Web API Questions

Q19. Your POST Creates a Resource and Triggers an Async Background Job. What Status Code Do You Return?

Difficulty Mid

It depends on what’s actually done when you respond. If the resource is created synchronously and the job is a side effect, return 201 Created with a Location header to the new resource. If the whole operation is queued and not yet complete, return 202 Accepted with a URL the client can poll for status. The one wrong answer is 200 OK - it tells the client nothing about what happened. My guide to HTTP status codes in ASP.NET Core covers when each code applies.

Red flag answer: “200, because it worked.” - For a creation endpoint that throws away all the semantic information the status code exists to convey.

Q20. What’s the Difference Between PUT and PATCH, and Which Do You Default To?

Difficulty Mid

PUT replaces the entire resource - the client sends the full representation. PATCH applies a partial update - just the fields that change. PATCH sounds better but adds real complexity: you have to distinguish “field set to null” from “field omitted”, and JSON Patch is awkward for clients.

My default for most internal APIs is PUT with the full object. It’s simpler and less error-prone, and it lines up with REST best practices. I reach for PATCH only when entities are large, bandwidth matters, or partial updates are a genuine requirement.

Red flag answer: “They’re interchangeable.” - They have different semantics, and conflating them produces APIs that behave unpredictably.

5 Interview Mistakes That Get .NET Developers Rejected

After interviewing plenty of .NET developers, these are the patterns that sink otherwise capable candidates - across every round, every topic:

1. Reciting definitions instead of reasoning. “Middleware is software that sits between request and response” tells me nothing. “I once had CORS registered after authentication and spent three hours on phantom 401s” tells me everything.
2. Saying “it depends” and stopping. Every senior answer can start with “it depends” - but the good ones immediately add “here’s my default, and here’s when I’d deviate.” Have a position.
3. Being stuck two versions back. If you mention Swashbuckle, IDistributedCache, EF6 lazy-loading defaults, or .NET 6 patterns in a 2026 interview, the interviewer assumes you stopped learning. Know what changed.
4. No production signals. Interviewers listen for “I’ve seen this fail when…”, “we had an incident where…”, “I benchmarked this.” If every answer is theoretical, you lose to the candidate with war stories.
5. Skipping the why. “I’d use output caching” is a C answer. “I’d use output caching because it supports tag-based invalidation, so I can evict on a write instead of waiting for a TTL” is an A answer.

Key Takeaways

• Scenario beats definition. Practice answering “what would you do when…” not “what is…”. Every question in this cluster is built that way.
• Every strong answer ends with a trade-off. State your default, name the cost, explain when you’d deviate.
• Know the red flags. If you catch yourself about to say “I’d just use .Result”, “always microservices”, or “200 OK for a create”, stop and go deeper.
• Stay current with .NET 10 and C# 14. HybridCache, named query filters, ExecuteUpdate, primary constructors, records, collection expressions - these come up constantly.
• The follow-up is where it’s won or lost. Prepare not just the answer, but the second-level question the interviewer chains next.

If a question here exposed a gap, the FREE .NET Web API Zero to Hero course teaches the full stack in order - C#, EF Core, ASP.NET Core, auth, caching, architecture, and deployment - with runnable code and no paywall. It’s the fastest way to turn shaky answers into confident ones.

Bookmark this page - it’s the hub I keep updated as new topic sets ship. Start with the .NET Web API and EF Core deep-dives, and share this with anyone prepping for a .NET interview.

Happy Coding :)