Top 60 .NET Interview Questions (2026)

'.NET is a free, open-source developer platform for building web, desktop, mobile, cloud, and game apps. Its main language is C#, and one runtime plus one class library serve every app type.

Its popularity comes from strong tooling (Visual Studio, the dotnet CLI), a large standard library, static typing that catches errors early, and modern .NET running the same code on Windows, Linux, and macOS. Teams get performance and safety without giving up productivity.

C# is a programming language. .NET is the platform it runs on: the runtime (CLR), the base class libraries, and the tooling. You write C#, it compiles to IL, and .NET runs that IL.

The distinction matters because .NET supports other languages too (F#, Visual Basic), and all of them compile to the same IL and share the same libraries. So C# is one way to target .NET, not the whole thing.

The Common Language Runtime is .NET's execution engine. It loads your compiled IL, uses a just-in-time compiler to turn it into native machine code, and manages memory, garbage collection, exceptions, and type safety while the program runs.

Because the CLR provides these services, C# code doesn't manage memory manually or worry about the CPU it runs on. That's what 'managed code' means: code whose execution the CLR manages.

IL (Intermediate Language) is the CPU-independent code the C# compiler produces. It isn't machine code yet. JIT (just-in-time) compilation is when the CLR converts IL to native machine code at run time, method by method, the first time each method runs.

This two-stage model is why the same .dll runs on different processors: IL is portable, and the JIT targets whatever CPU is present. Ahead-of-time (AOT) compilation is an alternative that compiles to native code before run time for faster startup.

A value type (int, double, bool, struct, enum) holds its data directly and is copied on assignment. A reference type (class, string, array, delegate) holds a reference to data on the heap, so assignment copies the reference, not the object.

This drives real behavior: passing a struct to a method copies it, but passing a class passes a reference to the same object. It's the root of many 'why did my change not stick' and 'why did they both change' bugs.

Boxing converts a value type to a reference type by wrapping it in an object on the heap. Unboxing extracts the value type back out, with a run-time type check. Both cost a heap allocation and a copy.

Boxing happens implicitly when a value type is assigned to object or an interface. In hot loops it quietly hurts performance, which is why generics (List<int> instead of ArrayList) exist: they avoid boxing entirely.

Use a struct for small, immutable, value-like data that you copy cheaply: a point, a color, a money amount. Use a class for most things: entities with identity, larger objects, and anything you want to share by reference.

The guidance is size and semantics. Structs avoid heap allocation but get copied on every pass, so a large struct copied often is slower than a class. Microsoft's rule of thumb is roughly 16 bytes or smaller, immutable, and short-lived.

A string in .NET can't be changed after creation. Any operation that looks like it modifies a string actually allocates a new one. Immutability makes strings safe to share, hashable, and interned, but it means building a string with += in a loop allocates on every step.

Use StringBuilder when you're concatenating in a loop or assembling many pieces. It writes into a growable buffer and produces the final string once, turning O(n squared) work into O(n).

const is a compile-time constant: its value is baked into the callers at compile time and must be known then. readonly is a run-time constant: it can be set in a constructor, so its value can depend on run-time input, and it's evaluated when the object is built.

The practical trap: because const values are inlined into other assemblies at compile time, changing a public const in a library means dependents must recompile to see the new value. readonly avoids that.

static means a member belongs to the type itself, not to any instance. A static field is shared across all instances; a static method is called on the type (Math.Sqrt) without creating an object. A static class can't be instantiated and holds only static members.

Use static for utilities and shared constants. The caution: static mutable state is global state, which makes code hard to test and unsafe under concurrency unless you guard it.

public (visible everywhere), private (only within the same type), protected (the type and its subclasses), internal (anywhere in the same assembly), and protected internal and private protected, which combine the two.

The default for class members is private, and for top-level types it's internal. Choosing the tightest modifier that still works is the encapsulation habit interviewers look for.

An abstract class can hold fields, constructors, and fully implemented methods alongside abstract ones, but a class can inherit only one. An interface defines a contract of members that implementers must provide, and a class can implement many.

Use an abstract class for an 'is-a' hierarchy with shared state and behavior. Use an interface for a capability that unrelated types can share (IComparable, IDisposable). Since C# 8, interfaces can carry default method implementations, which narrows the gap.

Encapsulation (bundling data with the methods that guard it, exposing only what's needed), inheritance (a class deriving from a base to reuse and extend it), polymorphism (one interface, many implementations, via virtual/override), and abstraction (modeling with abstract classes and interfaces to hide detail).

The signal isn't reciting the four words. It's giving a one-line C# example of each: a private field with a public property, a base class, an overridden virtual method, and an interface.

Overloading is defining multiple methods with the same name but different parameter lists in the same type; the compiler picks one by arguments at compile time. Overriding is a derived class replacing a base class's virtual method; the correct version is chosen at run time by the object's actual type.

So overloading is compile-time polymorphism (by signature), overriding is run-time polymorphism (by type). Overriding needs virtual on the base and override on the derived method.

virtual marks a base method as replaceable. override replaces it in a derived class, and calls dispatch to the derived version even through a base-typed reference. new hides the base method instead of overriding it, so which version runs depends on the reference type, not the object.

The gotcha is new: it looks like override but breaks polymorphism. A base-typed variable calls the base method even when the object is the derived type. Interviewers use this to test whether you understand dispatch.

A nullable value type (int?) lets a value type also hold null, useful for 'no value yet' cases like an unset database column. Nullable reference types (a compiler feature you enable) flag possible nulls in reference types at compile time so you handle them before they crash.

With the feature on, string means 'never null' and string? means 'might be null', and the compiler warns when you dereference something possibly null. It turns a class of NullReferenceException bugs into compile-time warnings.

A field is a variable stored on an object. A property is an accessor with get and set methods that looks like a field to callers but can compute, validate, or restrict access behind the scenes. Auto-properties (public int Age { get; set; }) generate the backing field for you.

The reason to expose properties, not public fields, is evolution: you can add validation or make a property read-only later without breaking any caller. Public fields lock you in.

params lets a method accept a variable number of arguments as a single array parameter. Callers can pass a comma-separated list or an actual array, and the method sees an array either way.

It has to be the last parameter, and there can be only one. String.Format and Console.WriteLine use it, which is why you can pass any number of format arguments.

ref passes a variable by reference and requires it to be initialized first; the method can read and write it. out also passes by reference but the caller need not initialize it, and the method must assign it before returning. in passes by reference read-only, to avoid copying a large struct without allowing changes.

out is the classic for methods returning more than one value, like int.TryParse. Since C# 7 you can declare the out variable inline at the call site.

try holds code that may fail, catch handles specific exception types, and finally always runs for cleanup whether or not an exception was thrown. You throw with throw, and you should catch specific types (FileNotFoundException) rather than the base Exception.

Catching Exception too broadly hides bugs, and swallowing an exception with an empty catch turns a crash into silent corruption. the key signal is that awareness and for using finally (or using) for cleanup.

IDisposable is an interface with one method, Dispose(), that releases unmanaged resources like file handles, sockets, or database connections. The using statement calls Dispose() automatically when the block exits, even if an exception is thrown.

This matters because the garbage collector frees managed memory but doesn't promptly release unmanaged resources. using gives you deterministic cleanup. C# 8 added the using declaration (using var f = ...) that disposes at the end of the enclosing scope.

List<T> (a dynamic array, the default sequence), Dictionary<TKey,TValue> (O(1) average key lookup), HashSet<T> (unique elements, fast membership), Queue<T> and Stack<T> (FIFO and LIFO), and arrays for fixed-size data.

Reaching for the right one signals fluency: Dictionary for lookups, HashSet for de-duplication and O(1) Contains, Queue for order-of-arrival processing. Picking List and scanning it with Contains when you needed a HashSet is a common performance mistake.

The GC automatically frees managed objects no longer reachable from the program. It's generational: new objects start in Gen 0, and those that survive a collection are promoted to Gen 1, then Gen 2. Because most objects die young, collecting Gen 0 frequently is cheap and full Gen 2 collections are rare.

The GC also compacts the heap to reduce fragmentation, and large objects (over 85 KB) go on a separate Large Object Heap. You almost never call it manually; understanding generations is what lets you reason about allocation-heavy code.

Dispose() is called deterministically by you (or a using block) to release unmanaged resources right away. A finalizer (~ClassName) runs non-deterministically when the GC collects the object, as a safety net for resources nobody disposed. Objects with finalizers cost extra: they survive an extra GC pass.

The standard pattern implements IDisposable, calls GC.SuppressFinalize(this) in Dispose so a disposed object skips finalization, and keeps the finalizer only as a backstop. Most modern code uses SafeHandle and doesn't write finalizers at all.

An async method can use await to pause at an asynchronous operation and return control to the caller until that operation finishes, without blocking the thread. When the awaited work completes, execution resumes right after the await. Nothing runs in parallel by default; it's about not tying up a thread while waiting.

The compiler rewrites an async method into a state machine that tracks where to resume. This is what keeps a web server handling other requests while one waits on a database, and keeps a UI responsive during I/O.

A Thread is an OS-level thread, a heavyweight resource you manage directly. A Task is a higher-level promise of future work that usually runs on a pooled thread managed by the runtime, so you don't create or destroy OS threads yourself. Task is what async/await builds on.

Use Task and the thread pool for almost everything; the runtime reuses threads and scales them for you. Reach for a raw Thread only for rare cases like a long-running dedicated background loop where you want full control.

Calling .Result or .Wait() on a Task from a context that has a single-threaded synchronization context (classic UI or old ASP.NET) can deadlock: the caller blocks the one thread the continuation needs to resume on, so neither proceeds. It's the most common async bug.

The fix is to go async all the way: await instead of blocking, never mix blocking calls with async in a captured context, and use ConfigureAwait(false) in library code to not capture the context. Modern ASP.NET Core has no such context, which removes the classic trap, but the rule still holds.

A delegate is a type-safe reference to a method, so you can pass methods around, store them, and invoke them later. Action and Func are built-in generic delegates. An event is a delegate wrapped so that outside code can only subscribe (+=) and unsubscribe (-=), not raise it or overwrite the whole list.

Delegates power callbacks, LINQ, and the observer pattern. Events add encapsulation on top: the publisher controls when it fires, subscribers only get to listen. This is the foundation of the pub/sub model in .NET.

LINQ (Language Integrated Query) is a uniform query syntax over collections, databases, XML, and more, using methods like Where, Select, OrderBy, and GroupBy. You can write it in method syntax or the SQL-like query syntax; both compile to the same calls.

Most LINQ queries use deferred execution: building the query doesn't run it. It runs only when you enumerate the results (foreach, ToList, Count, First). That's efficient but has a gotcha: a deferred query re-runs every time you enumerate it, and captures variables by reference.

IEnumerable<T> represents an in-memory sequence: LINQ operators run as compiled C# over objects already loaded. IQueryable<T> represents a query that a provider (like Entity Framework) translates into another language, usually SQL, and runs at the data source.

The practical difference is where filtering happens. A Where on an IQueryable becomes a SQL WHERE, so the database returns only matching rows. The same Where after you've pulled data into IEnumerable filters in memory, after loading everything. Filtering on IQueryable before materializing is a common performance fix.

An extension method adds a method to an existing type without modifying it or subclassing it. You write a static method in a static class with this before the first parameter, and the compiler lets you call it as if it were an instance method of that type.

All of LINQ is extension methods on IEnumerable<T>. They're useful for adding readable helpers to types you don't own, like string or a third-party class. The caveat: they can't access private members, so they're syntactic sugar, not real member injection.

Generics let you write a class or method that works over a type parameter T, keeping type safety without duplicating code or boxing. List<T>, Dictionary<K,V>, and Task<T> are generic. Constraints (where T : ...) restrict what T can be, so the method can rely on those capabilities.

Common constraints: where T : class, where T : struct, where T : IComparable<T>, and where T : new() for a parameterless constructor. Constraints are what let a generic method call methods on T, since without them T is just object.

Dependency injection is a pattern where a class receives its dependencies from outside instead of creating them itself, usually through its constructor. That inverts control: a container builds the object graph and hands each class what it needs, which makes code testable and loosely coupled.

ASP.NET Core has a built-in DI container. You register services at startup and the framework injects them into controllers, pages, and other services. DI is core to the framework, not optional; middleware, logging, and configuration all flow through it.

Transient: a new instance every time the service is requested, for lightweight stateless services. Scoped: one instance per request (per HTTP request in a web app), the common choice for things like a database context. Singleton: one instance for the whole application lifetime, for stateless shared services and caches.

The classic bug is a captive dependency: injecting a scoped service into a singleton keeps that one scoped instance alive forever, which is wrong and can corrupt per-request state. Matching lifetimes correctly is what this question screens for.

Middleware is a chain of components that each get to inspect and modify an HTTP request on the way in and the response on the way out. Each component can handle the request or call the next one, so the pipeline is ordered and each piece wraps the rest.

Order matters: authentication runs before authorization, exception handling wraps everything so it catches downstream errors, and static files short-circuit early. Built-in middleware covers routing, CORS, and HTTPS redirection; you add custom middleware with app.Use.

Configuration is layered from multiple sources: appsettings.json, environment-specific files like appsettings.Production.json, environment variables, command-line arguments, and user secrets in development. Later sources override earlier ones, so environment variables can override the JSON file.

You read strongly typed settings with the options pattern: bind a config section to a class and inject IOptions<T>. That keeps configuration typed and testable instead of reading magic string keys throughout the code.

EF Core is .NET's object-relational mapper. It maps C# classes to database tables so you query with LINQ instead of raw SQL, and it tracks changes to loaded entities so SaveChanges generates the right INSERT, UPDATE, or DELETE. Migrations version your schema alongside your model.

The performance topics interviewers probe: the N+1 query problem (loading related data in a loop instead of with Include), change tracking overhead (AsNoTracking for read-only queries), and the difference between eager, lazy, and explicit loading of related data.

Override both together. Equals defines value equality by comparing the fields that make two objects the same. GetHashCode must return the same hash for any two objects that are equal, so hash the same fields you compare. Break that contract and objects go missing in dictionaries and sets.

The modern shortcut is a record, which generates value-based Equals, GetHashCode, and ToString for you. Write them by hand only when a record doesn't fit; otherwise records remove a whole class of subtle equality bugs.

A record is a reference type (or, as record struct, a value type) built for data: the compiler generates value-based equality, a readable ToString, and a with-expression for making a copy with a few changes. They're typically immutable via init-only properties.

Use records for DTOs, domain values, and anything defined by its data rather than identity. Use a regular class when the object has mutable state and behavior and identity matters. Records make immutability and value equality the easy default.

Pattern matching tests a value's shape and extracts data in one step, using is, switch expressions, and patterns for types, properties, tuples, and ranges. It replaces chains of type checks and casts with declarative branches.

Modern C# added switch expressions (a value-returning switch), property patterns, relational patterns (< 18), and list patterns. They make branching logic shorter and let the compiler check you've covered the cases.

The standard generic collections (List<T>, Dictionary<K,V>) are not thread-safe for concurrent writes; mutating one from multiple threads corrupts it. Options are to lock around access, or use the System.Collections.Concurrent types (ConcurrentDictionary, ConcurrentQueue, ConcurrentBag) built for concurrent access.

ConcurrentDictionary is the common answer for shared caches, with atomic methods like GetOrAdd and AddOrUpdate. For read-heavy, rarely-changing data, an immutable collection swapped atomically also works. The wrong answer is assuming the default collections are safe.

A CancellationToken is how you cooperatively cancel async or long-running work. A CancellationTokenSource issues the token; when it's cancelled, code that checks the token (or passes it to async APIs) stops promptly instead of running to completion. Cancellation is cooperative: the work has to observe the token.

It matters for responsiveness and resource use: a web request that the client abandoned should stop its database call, and a timeout should actually abort work. Threading CancellationToken through async methods is expected in production .NET code.

The C# compiler produces IL plus metadata in an assembly. At run time the CLR loads the assembly, verifies types, and the JIT compiles each method to native code the first time it's called, caching the result for later calls. The GC manages the heap while it runs, and the runtime handles exceptions and security.

Senior-level extras: tiered compilation JITs quickly first then re-JITs hot methods with more optimization; ReadyToRun images ship precompiled code for faster startup; and Native AOT compiles the whole app ahead of time with no JIT at all, trading some flexibility for startup and size.

The compiler rewrites an async method into a state machine struct. Each await splits the method into segments; the state machine records which segment to resume, hooks a continuation onto the awaited Task via its awaiter, and returns control. When the awaited work completes, the continuation runs the next segment, capturing the synchronization context unless ConfigureAwait(false) said otherwise.

The consequences that matter in production: an async method that never awaits runs synchronously and allocates needlessly; ValueTask avoids an allocation for the common already-completed case; and capturing the context on every await has a cost that ConfigureAwait(false) removes in library code.

Span<T> is a stack-only view over contiguous memory: an array, a stack buffer, or unmanaged memory. It lets you slice and process data without copying or allocating, which cuts garbage in hot paths. Because it's a ref struct, it can't live on the heap or cross an await. Memory<T> is the heap-friendly counterpart that can, at a small cost.

They exist for high-performance code that used to allocate substrings and arrays: parsing, serialization, and buffer processing. string.AsSpan().Slice() parses without allocating substrings. This is core to why modern .NET got faster.

lock (a Monitor) for simple mutual exclusion around a short critical section. SemaphoreSlim, including its async WaitAsync, to limit concurrency or guard async code where lock can't be held across await. Interlocked for lock-free atomic counters and swaps. ReaderWriterLockSlim when reads vastly outnumber writes.

The judgment is picking the cheapest correct tool and holding it briefly. lock is fine for most cases; you cannot await inside a lock, so async coordination uses SemaphoreSlim; and a single counter should use Interlocked.Increment rather than a lock.

Yes. The GC frees unreachable objects, but a managed leak keeps objects reachable forever: static collections that only grow, event handlers that pin subscribers (the classic one, since the publisher holds a reference to every subscriber), undisposed unmanaged resources, and captured variables in long-lived closures or timers.

Diagnosis: watch process memory and Gen 2 size over time, take heap snapshots with dotnet-gcdump or a profiler and diff them to find the growing type, and trace the GC root that keeps it alive. The fix is usually unsubscribing events, bounding caches, or disposing correctly.

Workstation GC is tuned for responsiveness on client apps: it uses fewer resources and, in its concurrent mode, keeps pauses short. Server GC uses a dedicated heap and GC thread per core, so it collects in parallel and maximizes throughput for multi-core servers handling many requests, at the cost of higher memory use.

ASP.NET Core defaults to server GC. The tuning conversation: server GC for throughput-heavy backends, workstation for memory-tight or latency-sensitive single-user apps, and you configure it in the project or runtime config. Knowing this is a real ops lever separates infra-aware candidates.

Single responsibility (a class has one reason to change), open/closed (extend without modifying, often via interfaces and DI), Liskov substitution (a subtype must honor the base contract), interface segregation (small focused interfaces over fat ones), and dependency inversion (depend on abstractions, which DI operationalizes).

In .NET these aren't abstract: interface segregation is why IReadOnlyList exists next to IList, dependency inversion is the entire ASP.NET Core DI container, and open/closed is how middleware and filters extend the pipeline. Tying each principle to a framework feature is The production-ready answer.

A repository abstracts data access behind a collection-like interface; a unit of work groups changes into one atomic commit. They isolate the rest of the app from the persistence detail and make swapping or mocking the data layer easier.

The nuance the question needs: EF Core's DbContext already is a unit of work, and DbSet already is a repository, so wrapping them in more layers is often redundant abstraction that hides useful features. The judgment call is whether the extra seam earns its cost, and many teams skip a generic repository over EF Core.

Minimal APIs map endpoints directly to handler methods with less ceremony, good for small services, microservices, and focused endpoints where controller scaffolding is overhead. Controllers give you a structured convention: attribute routing, filters, model binding, and grouping, which pays off in larger apps with many endpoints and cross-cutting concerns.

The trade-off is structure versus lightness. Minimal APIs have grown filters and route groups, closing the gap, so the honest answer is team preference and app size rather than a hard rule. Naming that they share the same pipeline underneath shows depth.

Throw specific exception types at the point of failure, catch only where you can act, and let everything else bubble to a central handler. In ASP.NET Core that's exception-handling middleware that maps exceptions to appropriate status codes and a consistent error body, with the full detail logged and only safe detail returned.

The principles: don't use exceptions for normal control flow, don't swallow them, preserve stack traces (throw; not throw ex;), chain inner exceptions for the root cause, and distinguish expected failures (validation returns a 400) from unexpected ones (a 500 that pages someone).

in-memory caching (IMemoryCache) for hot, read-heavy data on a single instance, then move to a distributed cache (IDistributedCache backed by Redis) when you run multiple instances that must share state comes first. Response caching and output caching handle whole HTTP responses at the edge of the pipeline.

The hard part isn't the API, it's invalidation and correctness: pick sensible expirations, guard against cache stampede (many callers recomputing at once) with a lock or single-flight, and never cache per-user data in a shared key. Saying 'the two hard problems are naming and invalidation' with a concrete invalidation plan is the production signal.

For in-process work, implement IHostedService or subclass BackgroundService for a long-running loop the host starts and stops cleanly, honoring the stopping token for graceful shutdown. For deferred work triggered by a request, a background task queue plus a hosted consumer keeps the request fast while work happens after the response.

The scaling caveat: in-process background work dies with the process and doesn't survive restarts or scale across instances. Once durability or retries matter, move to a real queue and worker (a message broker, or a library like Hangfire), which is the answer that shows you've hit the limits of the simple approach.

Unit tests with xUnit (or NUnit) for logic in isolation, mocking dependencies with Moq or NSubstitute against interfaces, which is another reason to depend on abstractions. Integration tests with WebApplicationFactory spin up the app in memory and hit real endpoints, often against a containerized database via Testcontainers.

The judgment is the pyramid: many fast unit tests, fewer integration tests that catch wiring and query bugs, a thin layer of end-to-end. Testing behavior over implementation, and mocking only true external boundaries (network, clock, database), is what keeps the suite from becoming brittle.

A request enters through the server (Kestrel), then flows through the middleware pipeline in order: exception handling, HTTPS redirection, routing, authentication, authorization, and finally endpoint execution. The endpoint (a controller action or minimal API handler) runs with its dependencies injected per request, produces a result, and the response flows back out through the same middleware in reverse.

Understanding this order explains real bugs: authentication before authorization, exception middleware outermost so it catches downstream, and static-file middleware early so it short-circuits before hitting your endpoints.

Authentication establishes who the caller is: validating a cookie, a JWT bearer token, or an external identity provider, and building a ClaimsPrincipal. Authorization decides what that identity is allowed to do: role checks, policy-based rules, or resource-based checks. Authentication runs first, authorization second.

ASP.NET Core wires this through middleware and DI: authentication handlers per scheme, and an authorization system of policies and requirements you apply with attributes or minimal-API extensions. JWT bearer tokens are the common choice for APIs; cookies for server-rendered apps.

Use ILogger<T> with structured logging so log entries carry named properties, not just interpolated strings, which lets you query them later. Configure providers (console, a file or aggregator, Application Insights) and set levels per category. For distributed systems, add tracing and metrics via OpenTelemetry, which .NET supports natively.

The senior points: log structured events with correlation IDs so you can follow one request across services, pick log levels deliberately (Information for the happy path, Warning and Error for problems), and treat metrics and traces as first-class, not an afterthought bolted on when something breaks.

Clarify the requirement: clients retry on timeouts, so the endpoint must be idempotent, charging once even if called twice. The standard approach is an idempotency key sent by the client (a header). On the first request you record the key with the result; on a retry with the same key you return the stored result instead of charging again.

Then cover the edges: store the key and outcome atomically with the charge (same transaction or an atomic store) so a crash mid-request can't double-charge, expire keys after a window, and return a clear conflict if the same key arrives with a different payload. Structuring it clarify, mechanism, storage, edges is what the question scores.

Measure first: dotnet-trace or dotnet-counters on the live process for CPU, allocations, and GC pauses; a profiler or BenchmarkDotNet for a specific hot path; and real workload, because intuition about bottlenecks is usually wrong. Then fix in impact order: better algorithms, batching and reducing I/O and database round-trips, caching, cutting allocations (Span, pooling, avoiding boxing), and only then parallelism.

The interviewer checks for the discipline (profile, don't guess) and the escalation ladder. Common .NET wins are fixing N+1 queries, removing sync-over-async blocking, and reducing GC pressure in hot loops, with a measurement before and after to prove the fix.