Top 50 .NET & C# Interview Questions with Real Examples

Value types (int, double, bool, struct, enum) hold their data directly and are typically stored on the stack (or inline in the containing object); assigning one copies the value. Reference types (class, string, array, object, delegate) hold a reference to data on the managed heap; assigning copies the reference, so both variables point to the same object. This is the root of most 'why did my object change?' bugs.

Boxing wraps a value type in an object on the heap so it can be treated as a reference type (e.g., assigning an int to object). Unboxing extracts the value type back out, with a runtime type check and a copy. Both have performance and allocation cost. Generics (List<int> instead of ArrayList) and avoiding object parameters eliminate most boxing.

const is a compile-time constant — its value is baked into callers at compile time and must be a literal known then; it's implicitly static. readonly is a runtime constant — assigned at declaration or in the constructor, so it can be computed or differ per instance, and it can hold reference types. Rule: use const for true compile-time literals (Pi, MaxRetries); use readonly for values fixed at construction.

Both pass arguments by reference so the method can modify the caller's variable. ref requires the variable to be initialized before the call and the method may read it. out does NOT require prior initialization and the method MUST assign it before returning — used for returning extra values. Modern C# also has `in` (pass by reference, read-only).

string is immutable — every modification creates a new string object. Concatenating in a loop with + creates many temporary strings (O(n²) and heavy GC). StringBuilder is a mutable buffer; appending modifies it in place (amortized O(n)). Use string for a few fixed concatenations; use StringBuilder when building strings in loops or with many appends.

var is compile-time type inference — the type is fixed at compile time, fully type-checked, just less verbose. object is the base type of everything — strongly typed but you must cast to use members (boxing for value types). dynamic bypasses compile-time checking entirely; member resolution happens at runtime (DLR), so typos compile but throw at runtime. Prefer var; use dynamic only for interop (COM, JSON, reflection-heavy code).

IEnumerable<T> executes queries in-memory (LINQ to Objects) — data is fetched first, then filtering/sorting happens in your process. IQueryable<T> builds an expression tree that the provider (e.g., Entity Framework) translates to a backend query (SQL) so filtering happens at the database. For DB work use IQueryable so `Where`/`Take` run as SQL; switching to IEnumerable too early pulls the whole table into memory.

IEnumerable<T> is a read-only, forward-only abstraction for iterating a sequence — it may be lazily evaluated and doesn't expose Count or indexing. List<T> is a concrete, in-memory, indexable, mutable collection (Add/Remove/[]), and is itself an IEnumerable. Accept IEnumerable<T> in method parameters for flexibility; return/use List<T> when you need indexing, Count, or to materialize results once.

Extension methods let you add methods to an existing type (even sealed types or interfaces you don't own) without modifying it or subclassing. They are static methods in a static class whose first parameter is prefixed with `this`. The compiler lets you call them as if they were instance methods. The entire LINQ API (Where, Select, etc.) is extension methods on IEnumerable<T>.

A delegate is a type-safe function pointer — a variable that holds a reference to one or more methods. An event is a restricted wrapper around a delegate that only allows += (subscribe) and -= (unsubscribe) from outside the declaring class; subscribers can't invoke it or overwrite other subscribers. Events implement the publish-subscribe pattern safely; Action/Func are common delegate types.

async/await enables non-blocking asynchronous code that reads like synchronous code. An async method returns Task/Task<T> (or ValueTask). await suspends the method at an awaited operation, returns the thread to the pool, and resumes when the operation completes — so threads aren't blocked waiting on I/O. It improves scalability (more requests per thread), not raw speed. Use it for I/O (DB, HTTP, files); avoid async void except for event handlers.

.ToString() throws a NullReferenceException if the object is null, because you're calling an instance method on null. Convert.ToString() is null-safe — it returns an empty string (or null for the nullable overload) instead of throwing. For known non-null values both are equivalent; Convert.ToString() is safer when the value might be null.

A mutable object's state can change after creation (e.g., List<T>, StringBuilder, a class with public setters). An immutable object's state can't change once constructed (e.g., string, record types, a class with only readonly/init-only fields). Immutability gives thread safety (shareable without locks), predictability, and safe use as dictionary keys. C# `record` types and `init`-only setters make immutability easy.

The CLR is the execution engine of .NET. It runs your compiled code and provides core services: JIT compilation of IL to native code, automatic memory management (garbage collection), type safety, exception handling, security, and thread management. Any .NET language (C#, F#, VB) compiles to a common Intermediate Language (IL/MSIL) that the CLR executes — which is why they interoperate.

The Just-In-Time (JIT) compiler converts IL (Intermediate Language) into native machine code at runtime, method by method, the first time each method is called. Variants: standard JIT (compiles on demand), and Tiered Compilation (a quick tier first for fast startup, then a fully optimized tier for hot methods). AOT/ReadyToRun can precompile to cut startup cost.

The .NET GC automatically reclaims managed heap memory no longer referenced. It's generational: Gen 0 (new, short-lived objects — collected often and cheaply), Gen 1 (survivors — a buffer), and Gen 2 (long-lived objects — collected rarely). Large objects (≥85 KB) go on the Large Object Heap (LOH). Most objects die young, so collecting Gen 0 frequently is efficient. You don't free memory manually, but you must Dispose unmanaged resources.

Managed code runs under the CLR, which provides garbage collection, type safety and security (e.g., C#). Unmanaged code runs directly on the OS with no CLR services — you manage memory yourself (e.g., C/C++, Win32 APIs, COM). When managed code calls unmanaged resources (file handles, DB connections, native libraries via P/Invoke), you must release them explicitly with Dispose/using because the GC doesn't track them.

.NET Framework is the original Windows-only platform (legacy, max version 4.8). .NET Core is the cross-platform, open-source, high-performance rewrite. Since .NET 5 they unified into just '.NET' (one cross-platform runtime, current is .NET 8/9). .NET Standard was a shared API spec so libraries could target both worlds — now largely obsolete since everything converged on .NET. New projects should target modern .NET.

An assembly is the unit of deployment, versioning and security in .NET — a compiled .dll or .exe containing IL plus a manifest (metadata about types, versions and dependencies). A class library is a project type that produces a .dll assembly of reusable types with no entry point. So 'assembly' is the runtime/deployment concept; 'class library' is the project that builds one. Assemblies can be private (app folder) or shared (the GAC, in .NET Framework).

Encapsulation — hide state behind access modifiers and properties (private fields + public getters/setters). Inheritance — derive classes with `: BaseClass`. Polymorphism — virtual/override for runtime, overloading for compile-time. Abstraction — abstract classes and interfaces expose 'what' while hiding 'how'. Together they enable modular, reusable, maintainable code. For pure OOP depth see our OOP interview set.

Overloading: multiple methods with the same name but different parameter lists in the same class — resolved at COMPILE time (static binding). Overriding: a derived class redefines a base method marked virtual/abstract using the override keyword — resolved at RUNTIME (dynamic dispatch) based on the object's actual type. Overloading is compile-time polymorphism; overriding is runtime polymorphism.

virtual marks a base method as overridable; override replaces it with runtime dispatch; new HIDES the base method (compile-time, based on the reference type). If A.foo is virtual and B and C override it, then `A a = new C(); a.foo();` prints "C" — runtime dispatch follows the actual object (C). But if foo is NON-virtual (plain methods, hidden via new), `a.foo()` prints "A" — it binds to the reference type A at compile time. This exact trick is a classic .NET interview question.

An abstract class can have state (fields), constructors, and both abstract and concrete members; a class can inherit only ONE. An interface is a contract — historically members-only, but since C# 8 it can have default implementations; a class can implement MANY interfaces. Use an abstract class for a shared base with common state/behavior (is-a); use an interface to declare a capability multiple unrelated types can have (can-do).

Abstraction is about DESIGN — exposing only essential behavior and hiding complexity (achieved with interfaces/abstract classes). Encapsulation is about IMPLEMENTATION — bundling data with methods and restricting direct access to internal state (achieved with access modifiers and properties). Abstraction = hide complexity (what); encapsulation = hide data (how). They reinforce each other.

All describe 'has-a' relationships with increasing ownership. Association: objects know each other but have independent lifecycles (a Teacher and a Student). Aggregation: a 'whole' references 'parts' that can exist independently (a Department has Employees, but employees survive the department). Composition: the 'whole' owns the 'parts' and they die with it (a House has Rooms — destroy the house, the rooms are gone).

Five OOP design principles for maintainable code: S — Single Responsibility (a class has one reason to change). O — Open/Closed (open for extension, closed for modification). L — Liskov Substitution (subtypes must be usable wherever the base type is, without breaking behavior). I — Interface Segregation (many small interfaces over one fat one). D — Dependency Inversion (depend on abstractions, not concretions — the basis of DI).

ASP.NET Core is the cross-platform, open-source, high-performance framework for building web apps and APIs on modern .NET. Versus classic ASP.NET (Windows/IIS-only, System.Web): Core runs anywhere (Linux, containers), has a unified MVC + Web API + Razor Pages model, built-in dependency injection, a flexible middleware pipeline, configuration providers, and is far faster. It can self-host via Kestrel rather than requiring IIS.

MVC separates concerns: Model (data + business logic), View (UI), Controller (handles input, coordinates model and view). The ASP.NET MVC life cycle: routing maps the URL to a controller/action → controller instantiated → action filters run → action executes → it returns an ActionResult (View, JSON, Redirect) → the view engine renders → response sent. Understanding this pipeline is key to placing filters, model binding and validation correctly.

Convention-based routing defines URL patterns centrally (e.g., {controller}/{action}/{id?}) — concise for uniform apps but less explicit. Attribute routing places routes directly on controllers/actions with [Route("...")], [HttpGet("...")] — explicit, supports complex/RESTful URLs, versioning and parameter constraints per endpoint. Web APIs typically use attribute routing; you can mix both.

All pass data from controller to view, but: ViewData is a dictionary (ViewData["x"]) — requires casting, available for the current request. ViewBag is a dynamic wrapper over ViewData (ViewBag.x) — no casting, also current request only. TempData persists across ONE subsequent request (backed by session) — ideal for passing data through a redirect (e.g., a success message after POST-redirect-GET).

Filters inject logic into the request pipeline around action execution. Types (in order): Authorization filters (auth checks), Resource filters (caching, short-circuiting), Action filters (run before/after an action — logging, model tweaks), Exception filters (handle errors), Result filters (around result execution). They centralize cross-cutting concerns instead of repeating code in every action.

Middleware are components assembled into a pipeline that each handle an HTTP request and decide whether to pass it to the next component (via next()) or short-circuit. Order matters — they run top-down on the request and bottom-up on the response. Built-in middleware: routing, authentication, authorization, CORS, static files, exception handling. It's the Core replacement for HttpModules/HttpHandlers.

Both intercept requests in classic ASP.NET. An HttpHandler is the endpoint that PROCESSES a request and produces the response for a specific resource/extension (e.g., .ashx, an image generator) — one handler ultimately serves the request. HttpModules run for EVERY request and hook pipeline events (BeginRequest, AuthenticateRequest, EndRequest) for cross-cutting concerns like logging, auth, compression. In ASP.NET Core both are replaced by middleware.

A web farm is MULTIPLE servers (machines) hosting the same app behind a load balancer — for scale-out and high availability. A web garden is MULTIPLE worker processes (w3wp.exe) on a SINGLE server (IIS application pool set to >1 process) — for using multiple cores/process isolation on one box. Both break in-process session/state, so you need an external session store (SQL/Redis) in either.

Session stores per-user data across requests, keyed by a session ID (usually a cookie). Classic ASP.NET modes: InProc (in worker-process memory — fast but lost on recycle and not shared across a farm), StateServer (a separate Windows service), SQLServer (a database — durable, farm-safe), and Custom. ASP.NET Core uses IDistributedCache (in-memory, SQL, or Redis). For web farms/gardens use a distributed store, never InProc.

Authentication verifies WHO you are (identity) — login with credentials, tokens, OAuth. Authorization determines WHAT you're allowed to do (permissions/roles) — can this authenticated user access this resource? Authentication always comes first; authorization builds on it. In ASP.NET Core: `UseAuthentication()` then `UseAuthorization()`, with `[Authorize(Roles="Admin")]` enforcing access.

In IIS, an application pool is an isolation boundary; each pool is served by one or more worker processes (w3wp.exe) that actually run your app code. Isolation means a crash or memory leak in one app pool doesn't affect apps in other pools. Pools can recycle (restart) on schedules, memory limits or idle timeouts — which is why InProc session is fragile. A web garden = one pool with multiple worker processes.

REST (Representational State Transfer) is an architectural style for web APIs over HTTP. Principles: resources identified by URIs (/users/5), standard HTTP verbs (GET read, POST create, PUT replace, PATCH partial update, DELETE remove), statelessness (each request carries everything needed — no server session), proper status codes (200, 201, 404, 400, 401), and representations (usually JSON). It's resource-oriented, cacheable and uniform.

SOAP is a strict PROTOCOL: XML-only messages, a rigid envelope, WSDL contracts, built-in standards (WS-Security, transactions), works over multiple transports. REST is an architectural STYLE: typically JSON over HTTP, lightweight, flexible, uses HTTP verbs and status codes, easier to consume from browsers/mobile. SOAP suits enterprise/finance needing formal contracts and security; REST suits most modern web and mobile APIs.

An operation is idempotent if making the same request multiple times has the same effect as making it once. GET, PUT and DELETE are idempotent (PUT replaces with the same payload → same final state; DELETE twice → still deleted). POST is NOT idempotent (two POSTs create two resources). PATCH may or may not be. Idempotency matters for safe retries on network failures — clients can retry PUT/DELETE without side effects.

POST — create a new resource (server assigns the ID); not idempotent. PUT — create-or-replace a resource at a known URI with the FULL representation; idempotent. PATCH — apply a PARTIAL update (only changed fields) to an existing resource. Rule: POST to a collection (/orders) to create; PUT/PATCH to an item (/orders/42) to update — PUT for full replacement, PATCH for partial.

Historically ASP.NET MVC controllers returned Views (HTML) while Web API (ApiController) returned data (JSON/XML) for clients. In ASP.NET Core they unified — both derive from Controller/ControllerBase. An API controller uses [ApiController] + ControllerBase (no view support, automatic model-validation responses, attribute routing) and returns data via IActionResult/ActionResult<T>; an MVC controller adds view rendering. Same framework, different intent.

Entity Framework (EF Core) is Microsoft's ORM — it maps C# classes to database tables so you work with objects and LINQ instead of raw SQL. Approaches: Code First (write C# entities + DbContext, EF generates the schema via migrations — most popular for new apps), Database First (scaffold entities from an existing database), and the legacy Model First (design an EDMX visually). Code First with migrations is the modern default.

These control when related data is loaded. Eager loading fetches related entities up front in one query via .Include() — avoids extra round trips. Lazy loading defers loading related entities until you access the navigation property (each access fires a query) — convenient but causes the N+1 problem. Explicit loading loads related data on demand with .Entry().Collection().Load(). Prefer eager (.Include) for known needs; beware lazy loading in loops.

A LINQ query isn't executed when you define it — only when you ENUMERATE the results (foreach, ToList(), Count(), First()). The query is built as an expression and runs against the live data at iteration time, so changes to the source before enumeration are reflected. Operators like Where/Select/OrderBy are deferred; ToList/ToArray/Count/First force immediate execution. This enables query composition but can re-run a query if you enumerate twice.

Connected architecture keeps an open connection while reading data via a DataReader (SqlDataReader) — fast, forward-only, low memory, but holds the connection open the whole time. Disconnected architecture uses a DataAdapter to fill a DataSet/DataTable, then closes the connection; you work with the in-memory cache and reconcile changes later — better for scalability and offline edits, but uses more memory. EF Core builds on these concepts.

Singleton ensures a class has exactly one instance with a global access point. In C# the cleanest thread-safe implementation uses a static readonly field (or Lazy<T>) with a private constructor. In modern ASP.NET Core you rarely hand-roll it — you register a service with a singleton lifetime in the DI container (services.AddSingleton<IFoo, Foo>()), which manages the single instance for you.

Both give a single shared point of access, but: a static class can't be instantiated, can't implement interfaces or be injected, can't have instance state, and can't be mocked — it's a stateless utility holder. A Singleton is a real object (one instance) that CAN implement interfaces, be passed around, hold state, and be injected/mocked. Prefer a DI singleton over a static class when you need testability or polymorphism.

The Factory pattern delegates object creation to a separate method/class so callers depend on an abstraction, not concrete types. A Simple Factory has a method that returns instances based on input; the Factory Method pattern lets subclasses decide which class to instantiate; Abstract Factory creates families of related objects. It centralizes construction logic, decouples creation from use, and eases adding new types.

The Repository pattern abstracts data access behind an interface (IRepository<T> with Add/Get/Remove), so business logic doesn't depend on EF or SQL directly — improving testability and swap-ability. The Unit of Work pattern groups multiple repository operations into a single transaction and commits them together (one SaveChanges). EF Core's DbContext already IS a Unit of Work and DbSet IS a repository; you layer your own when you want stricter abstraction. Both are wired via Dependency Injection — register interfaces, inject them into services, and substitute mocks in tests (Dependency Inversion in action).