.NET is a free, open-source, cross-platform developer platform created by Microsoft for building applications across web, desktop, mobile, cloud, and IoT environments. It provides developers with a runtime environment, a comprehensive standard library, and language options like C#, F#, and Visual Basic to write modern applications that run on Windows, Linux, and macOS. How it works .NET operates on a managed execution model powered by the Common Language Runtime (CLR). When you write C# code, the compiler translates it into an intermediate language called Common Intermediate Language (CIL). When your application runs, the CLR's Just-In-Time (JIT) compiler converts CIL into native machine code specific to the operating system. This abstraction layer provides several benefits: automatic memory management through garbage collection, platform independence, and security features built into the runtime. .NET includes the Base Class Library (BCL) , a massive collection of pre-built types and APIs for common tasks like file I/O, networking, collections, and data processing. Modern .NET (versions 5+) is unified and cross-platform by default, making it easy to share code between a web server running on Linux and a desktop application on Windows. The SDK provides command-line tools, NuGet package management, and integration with Visual Studio for a complete development experience. Example using System; class Program { static void Main() { string message = "Hello, .NET!"; int version = 8; Console.WriteLine($"{message} Running on .NET {version}"); Console.WriteLine($"Timestamp: {DateTime.UtcNow:O}"); } } This simple console application demonstrates .NET fundamentals: it uses C# language features (string interpolation), the BCL (Console and DateTime), and outputs a message with the current timestamp—all managed by the runtime. Key points to mention Free and open-source: .NET is licensed under MIT and actively developed on GitHub, with contributions from Microsoft and the community. Cross-platform: Write once and run on Windows, Linux, and macOS without recompilation. Managed runtime: The CLR handles memory management, type safety, and security automatically. Unified platform: Use the same .NET runtime for web ( ASP.NET Core ), desktop (WinForms, WPF), mobile (MAUI), and cloud applications. Strong ecosystem: Access to NuGet packages, extensive documentation, and a large developer community. Common follow-up questions What is the difference between .NET Framework and modern .NET? How does garbage collection work in .NET? What is ASP.NET Core and how does it relate to .NET? Related interview questions What is ASP.NET Core? What is the Base Class Library (BCL)? What is method overriding?

The Common Language Runtime (CLR) is the virtual machine that executes all .NET code. It provides essential services like Just-In-Time (JIT) compilation, automatic memory management through garbage collection, type safety, exception handling, and security—all abstracted away from the developer. Without the CLR, you would need to manage these concerns manually, similar to writing in C++. How it works When you write C# code and compile it, the compiler doesn't produce machine code directly. Instead, it produces Intermediate Language (IL) bytecode that's platform-agnostic. This IL is stored in assemblies (.dll or .exe files) along with metadata describing types, methods, and dependencies. When your .NET application runs, the CLR takes over. It reads the IL from your assembly and uses the JIT compiler to translate it into native machine code specific to the processor architecture you're running on. This happens on-demand: the first time a method is called, it's compiled; subsequent calls use the cached compiled version. The CLR also manages memory through the garbage collector, which automatically tracks object references and frees memory that's no longer in use. It enforces type safety at runtime, ensuring you can't cast an object to an incompatible type without validation. It provides a unified exception handling model and a security framework that controls what code can do, such as file access or network operations. The CLR operates on a managed memory model where objects live on the heap and primitives or references live on the stack . This abstraction lets developers write code without worrying about memory corruption, pointer arithmetic, or manual cleanup—major sources of bugs in unmanaged languages. Example class Program { static void Main() { var person = new Person { Name = "Alice", Age = 30 }; Console.WriteLine($"{person.Name} is {person.Age}"); // CLR automatically manages memory; no delete needed } } class Person { public string Name { get; set; } public int Age { get; set; } } When this code runs, the CLR JIT-compiles the Main method, allocates the Person object on the heap, and automatically frees its memory when it's no longer referenced—all without explicit code. Key points to mention The CLR is a virtual machine that sits between your code and the operating system, providing platform independence. It performs JIT compilation: converting IL to native machine code at runtime, enabling optimizations based on actual usage patterns. Automatic garbage collection eliminates manual memory management and prevents memory leaks (though IDisposable is still used for unmanaged resources). Type safety and exception handling are enforced by the CLR, catching errors at runtime rather than causing undefined behavior. The CLR enables the "write once, run anywhere" philosophy: your IL works across Windows, Linux, and macOS with the appropriate .NET runtime installed. Common follow-up questions What's the difference between the CLR and the .NET Framework? The CLR is the runtime engine; .NET Framework is a larger ecosystem including the CLR, class libraries, and tools. Does .NET Core have a CLR? Yes. .NET Core (now just ".NET" in versions 5+) includes its own CLR optimized for cross-platform performance and cloud scenarios. How does the CLR handle different processor architectures? The JIT compiler generates native code specific to the current processor at runtime, so the same IL works on ARM, x86, and x64 without recompilation. Related interview questions What is IL (Intermediate Language)? What is the difference between stack and heap memory? What is IDisposable? Further reading Generics and constraints that pay off Exception handling anti-patterns

What is IL (Intermediate Language)?

IL (Intermediate Language) , also called MSIL or CIL, is a platform-agnostic instruction set that C# code compiles into. It sits between human-readable C# and machine code, allowing .NET programs to run across different operating systems and architectures. At runtime, the JIT compiler translates IL into native machine code specific to the current platform. How it works When you compile a C# project, the C# compiler doesn't produce native machine code directly. Instead, it produces IL instructions that are stored inside .NET assemblies (DLL or EXE files). These IL instructions are human-readable yet hardware-independent, similar to bytecode in Java. During runtime, the CLR's Just-In-Time (JIT) compiler reads the IL and converts it on-demand into native machine code that the CPU can execute. This happens method-by-method: the first time a method is called, its IL is compiled to native code and cached. Subsequent calls use the cached native code, avoiding recompilation. This two-stage compilation model gives .NET several advantages. First, it enables platform independence —the same IL assembly runs on Windows, Linux, and macOS because each platform has its own JIT compiler. Second, it allows for runtime optimizations —the JIT can apply optimizations based on actual runtime behavior and CPU architecture. Third, it enables security and verification—IL can be inspected and validated before execution. Example public class Calculator { public int Add(int a, int b) { return a + b; } } var calc = new Calculator(); int result = calc.Add(5, 3); When you compile this C#, the Add method is converted to IL instructions (such as ldarg.0 , ldarg.1 , add , ret ). When the program runs and calls Add(5, 3) , the JIT compiler translates those IL instructions into native x86 or ARM machine code that executes on your specific CPU. Key points to mention Platform independence: IL is the same across Windows, Linux, and macOS; only the JIT compiler is platform-specific. JIT compilation: IL is compiled to native code at runtime by the CLR, not ahead of time (though Native AOT and ReadyToRun are alternatives). Verifiable and secure: IL can be inspected for type safety and security violations before execution. Stored in assemblies: IL lives in DLL and EXE files alongside metadata about types, methods, and resources. Performance trade-off: JIT compilation adds startup latency but allows runtime optimizations that can exceed pre-compiled code performance. Common follow-up questions What is the CLR (Common Language Runtime) ? Can I see the IL that my C# code compiles to? How does IL differ from native code compilation in C++? Related interview questions What is the CLR? What is ReadyToRun? What is Native AOT?

What is JIT compilation?

JIT (Just-In-Time) compilation is the process where the .NET runtime converts Intermediate Language (IL) code into native machine code at runtime, just before a method is executed for the first time. This allows .NET to be both platform-independent (IL runs anywhere) and performance-optimized (native code is fast). Modern .NET uses tiered compilation , which starts with quick compilation and later recompiles frequently-used methods with aggressive optimizations. How it works When you write C# and compile it, the compiler produces IL (Intermediate Language), not native machine code. This IL is stored in your assembly. When your program runs and calls a method for the first time, the JIT compiler kicks in: The runtime detects the method hasn't been compiled yet. The JIT compiler reads the IL for that method. It compiles the IL into native code optimized for the current CPU architecture. The native code is cached in memory. Future calls to that method execute the cached native code directly—no recompilation. In modern .NET, tiered compilation makes this even smarter. Tier 0 (quick JIT) compiles with minimal optimization to get the method running fast. If the method is called frequently, Tier 1 (optimizing JIT) recompiles it with full optimizations like inlining and loop unrolling. This balance means your app starts quickly but still gets peak performance for hot code paths. Example public class Program { public static void Main() { // First call: JIT compiles Calculate to native code int result1 = Calculate(5); Console.WriteLine($"Result: {result1}"); // Subsequent calls: use cached native code int result2 = Calculate(10); Console.WriteLine($"Result: {result2}"); } public static int Calculate(int x) { // On first invocation, IL here is converted to native machine code return x * x + x; } } The first call to Calculate(5) triggers JIT compilation; the runtime converts its IL to native code. The second call to Calculate(10) reuses that already-compiled native code without recompilation. Key points to mention Startup delay: JIT compilation adds a small delay the first time each method runs (warm-up time), but this is typically negligible for modern applications. Platform independence: Because compilation happens at runtime, the same IL works on Windows, Linux, and macOS—the JIT produces platform-specific native code automatically. Optimization opportunities: The JIT can optimize based on actual runtime data—it knows which CPU you're on, actual data types flowing through methods, and call patterns, enabling smarter optimizations than static ahead-of-time compilers. Tiered compilation: .NET 5+ defaults to tiered compilation, balancing startup speed (Tier 0) with peak performance (Tier 1) automatically. Caching: Compiled native code is cached in memory for the lifetime of the process; it's never re-JIT'd unless explicitly requested by the runtime. Common follow-up questions Can we pre-compile IL to native code? Yes— ReadyToRun (R2R) and NativeAOT allow ahead-of-time compilation to eliminate JIT overhead and improve startup time. What's the performance difference between Tier 0 and Tier 1? Tier 0 compiles very quickly (sometimes in microseconds) but produces less-optimized code. Tier 1 takes longer to compile but produces code that can be 10–30% faster for compute-intensive workloads. How does JIT affect cold startup? In cold applications, you pay JIT cost for every method called during startup. For typical web services, this is under 100ms; for CLI tools, it can be noticeable. This is why NativeAOT is gaining adoption for trimmed, fast-startup scenarios. Related interview questions What is tiered compilation? What is ReadyToRun? What is the sealed keyword? Further reading Optimistic UI

What is an assembly in .NET?

An assembly is the compiled unit of deployment in .NET, typically a .dll (dynamic link library) or .exe (executable) file. It contains Intermediate Language (IL) code, metadata describing all types and members, and a manifest that specifies the assembly's version, name, and dependencies on other assemblies. How it works When you compile a C# project, the compiler translates your source code into IL—a platform-independent intermediate representation. This IL, along with rich metadata about classes, methods, properties, and other type information, is packaged into an assembly file. The assembly also includes a manifest—a metadata table that describes the assembly itself: its identity (name, version, culture), the types it exports, and which other assemblies it depends on. When the .NET runtime loads an assembly, it reads the manifest to understand what's inside and how to resolve dependencies. Assemblies are the unit of versioning, security, and deployment. You can share assemblies across applications, place them in the Global Assembly Cache (in .NET Framework), or bundle them with your application. Each assembly is independently versionable, so you can update one assembly without recompiling the entire application. The runtime uses a process called Just-In-Time (JIT) compilation to convert IL code to native machine code when the assembly executes. This allows the same IL assembly to run on different platforms (Windows, Linux, macOS) as long as the appropriate .NET runtime is installed. Example // MathLibrary.csproj – a class library assembly <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net8.0</TargetFramework> <AssemblyName>MathLibrary</AssemblyName> <Version>1.0.0</Version> </PropertyGroup> </Project> // MathLibrary.cs – code in the assembly namespace MathLibrary { public class Calculator { public int Add(int a, int b) => a + b; } } // Program.cs – consumer project using MathLibrary; var calc = new Calculator(); Console.WriteLine(calc.Add(5, 3)); // 8 When you build MathLibrary , the compiler produces MathLibrary.dll —the assembly. The manifest inside records that it's version 1.0.0, contains the Calculator type, and depends on System.Runtime . Your Program.cs project references this assembly; at runtime, the .NET loader reads the manifest and executes the IL code. Key points to mention Assemblies are files ( .dll or .exe ) containing IL code and metadata; they're the output of compilation. The manifest is metadata inside the assembly that describes the assembly's identity, exported types, and dependencies—it's how the runtime resolves what to load. Assemblies are independently versioned and deployed; a single project can reference assemblies of different versions. IL is platform-independent; the JIT compiler converts it to native code at runtime, enabling cross-platform execution. The Base Class Library (BCL) itself is distributed as a set of assemblies that the runtime loads automatically. Common follow-up questions What is the difference between a private assembly and a shared assembly? What is the Global Assembly Cache (GAC), and why is it rarely used in modern .NET? How does the runtime resolve assembly dependencies, and what is assembly binding? Related interview questions What is the .NET SDK vs the .NET runtime? What is the Base Class Library (BCL)?

What is the Base Class Library (BCL)?

The Base Class Library (BCL) is the standard library that ships with .NET , providing fundamental types and functionality for building applications. It includes namespaces like System, System.Collections, System.IO, System.Net, and System.Text, among hundreds of others. Every .NET application relies on the BCL to perform core operations such as file I/O, string manipulation, threading, networking, and data structures. How it works The BCL is a collection of managed assemblies (compiled code) that are part of the .NET runtime distribution. When you install .NET, the BCL assemblies are installed alongside it, making them immediately available to any application you build. You access BCL functionality by referencing namespaces in your code—for example, using System; or using System.Collections.Generic; —and then calling the types and methods defined in those namespaces. The BCL is organized hierarchically by namespace, grouping related functionality together. For instance, System.IO contains file and directory operations, System.Net handles networking, System.Collections.Generic provides type-safe collections, and System.Text.Json handles JSON serialization. These namespaces wrap the underlying operating system capabilities and provide a consistent, object-oriented interface that works across Windows, Linux, and macOS. The BCL also includes modern features like LINQ , which allows you to query collections with a SQL-like syntax, and System.Text.Json for parsing and generating JSON without external dependencies. The BCL is continuously updated with each .NET release, adding new types, methods, and performance improvements while maintaining backward compatibility. Example using System; using System.Collections.Generic; using System.IO; using System.Linq; using System.Text.Json; // BCL example: Collections, LINQ, File I/O, JSON var numbers = new List<int> { 1, 2, 3, 4, 5 }; var evenNumbers = numbers.Where(n => n % 2 == 0).ToList(); Console.WriteLine($"Even numbers: {string.Join(", ", evenNumbers)}"); // File I/O from System.IO var path = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Desktop), "data.json"); File.WriteAllText(path, JsonSerializer.Serialize(evenNumbers)); // Read it back var readContent = File.ReadAllText(path); var parsed = JsonSerializer.Deserialize<List<int>>(readContent); Console.WriteLine($"Parsed from file: {string.Join(", ", parsed ?? [])}"); This example demonstrates BCL usage: creating a typed collection, using LINQ.Where() to filter, writing to a file with System.IO.File , serializing to JSON with System.Text.Json , and reading it back—all from the BCL with no external packages. Key points to mention The BCL is built-in and free ; no installation or NuGet packages required for basic functionality. It provides cross-platform abstractions , so code written for Windows works on Linux and macOS without changes. Common namespaces include System (core types), System.Collections.Generic (dictionaries, lists), System.IO (files), System.Linq (querying), System.Net (networking), and System.Text.Json (serialization). The BCL is always available in every .NET project; you only need to add using statements to access it. It is designed for performance and is heavily optimized; many operations delegate to the runtime or operating system. Common follow-up questions How does the BCL differ from NuGet packages? The BCL is built-in and maintained by Microsoft; NuGet packages are third-party libraries you install separately to extend functionality. What happens if I use BCL types in .NET Framework vs. .NET 8+? Some newer BCL types (like JsonSerializer) are only available in newer .NET versions; you must target the appropriate framework or use compatibility packages. Can I override or extend BCL classes? Yes, many BCL classes are designed to be inherited (e.g., collections, exceptions); sealed classes cannot be extended intentionally. Related interview questions What is LINQ? What is .NET? What is a BackgroundService? Further reading Entities and aggregates

What is the .NET SDK vs the .NET runtime?

The .NET SDK (Software Development Kit) contains everything you need to develop and build .NET applications, including compilers, the dotnet CLI, and project templates. The .NET runtime is a minimal package that contains only what is necessary to execute already-compiled .NET applications. Think of it this way: developers install the SDK, but end users only need the runtime. How it works When you develop a .NET application, you use the SDK, which includes the C# compiler, the dotnet command-line tool, NuGet package manager, and pre-built project templates. The SDK is a superset that enables you to write code, compile it into Intermediate Language (IL), and create assemblies . Once your application is compiled and ready for deployment, end users do not need the compiler or development tools. They only need the .NET runtime, which provides the Just-In-Time (JIT) compiler to convert IL to machine code at runtime, the garbage collector, the type system, and the base class library necessary to execute your application. For deployment scenarios, you have flexibility: you can deploy your app to machines with the runtime installed, or you can create self-contained deployments where the runtime is bundled with your application. When containerizing an ASP.NET Core app , you often use a lightweight runtime image as the base rather than the full SDK. Example // Program.cs - requires SDK to compile using System; class Program { static void Main() { Console.WriteLine("Hello from .NET!"); Console.WriteLine($"Runtime: {System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription}"); } } To build this, you run dotnet build (SDK required). To run it, you execute dotnet run or ./bin/Release/net8.0/Program.exe (runtime required). End users only need the runtime to execute the compiled DLL. Key points to mention SDK is for development: Includes compiler, CLI tools, debugger, templates, and everything needed to create applications. Runtime is for execution: Minimal footprint with JIT compiler, garbage collector, and runtime libraries to execute compiled code. Size difference: The SDK is significantly larger (500+ MB) compared to the runtime (50-150 MB), which matters for production deployments. Separate downloads: Both are available separately from microsoft.com; you choose based on your use case (development vs. deployment). Version alignment: Applications compiled with SDK version X.Y should run on runtime version X.Y or newer (generally backward compatible within a major version). Common follow-up questions Can you run a .NET application without installing the SDK? Yes, if the runtime is installed or the application is self-contained with the runtime bundled. What is the difference between SDK versions and runtime versions? The SDK is used at compile time; the runtime version is what your deployed application targets and what end-user machines need. Should production servers have the SDK installed? Generally no—install only the runtime to reduce surface area and system complexity. The SDK is for development machines. Related interview questions How do you containerize an ASP.NET Core app? What is .NET? What is an assembly in .NET?

What does the dotnet CLI do?

The dotnet CLI (Command Line Interface) is a cross-platform tool that allows developers to create, build, run, test, and publish .NET applications directly from the command line. It's the foundation for modern .NET development, eliminating the need to rely solely on Visual Studio and enabling automation in CI/CD pipelines. How it works The dotnet CLI is installed as part of the .NET SDK and provides a unified command structure for managing your entire project lifecycle. When you run a command like dotnet build , the CLI parses your project file (typically a .csproj), restores NuGet dependencies, compiles your code, and produces output artifacts. Each command follows a predictable pattern: dotnet [command] [arguments] [options] . The CLI works with project files to understand your application's structure, dependencies, and configuration. It supports multiple project types—console applications, class libraries, ASP.NET Core web applications, and more. The CLI also integrates with the NuGet package manager, allowing you to add, update, and remove dependencies seamlessly. One of the most powerful aspects is its cross-platform nature. The same commands work identically on Windows, macOS, and Linux, making it ideal for DevOps teams and developers working in mixed environments. The CLI also powers many higher-level tools, including Visual Studio and Visual Studio Code, which use it behind the scenes. Example // Program.cs - Simple console application Console.WriteLine("Hello from dotnet CLI!"); var greeting = GetGreeting("World"); Console.WriteLine(greeting); static string GetGreeting(string name) => $"Welcome, {name}!"; To execute this, you'd use dotnet run in the terminal, which restores dependencies, compiles the code, and executes the program without manually creating build artifacts. Key points to mention Core commands: dotnet new (creates projects), dotnet build (compiles), dotnet run (executes), dotnet test (runs unit tests), dotnet publish (creates deployment packages) Dependency management: Use dotnet add package and dotnet remove package to manage NuGet packages without editing .csproj files manually Project agnostic: Works with any .NET project type—console apps, libraries, web applications, and more—using the same fundamental commands CI/CD integration: Perfect for automation scripts and continuous integration pipelines since it's scriptable and cross-platform Restore and clean: dotnet restore downloads dependencies, while dotnet clean removes build artifacts Common follow-up questions What's the difference between dotnet build and dotnet publish ? (Build compiles for development; publish prepares for deployment) How do you run integration tests for ASP.NET Core using the CLI? What does dotnet restore do, and when is it necessary? Related interview questions What is xUnit? How do you write integration tests for ASP.NET Core? How do you test code that depends on time? Further reading Integration tests with WebApplicationFactory Test data builders

NuGet is the package manager for .NET that enables developers to discover, download, and manage reusable libraries and dependencies in their projects. Packages are defined in your project file and automatically restored from nuget.org (the public feed) or private feeds during the build process, making dependency management centralized and version-controlled. How it works NuGet operates as a centralized repository system. When you add a package reference to your .csproj file , NuGet resolves that package and all its transitive dependencies from configured feeds. During build time, NuGet restores these packages to a local cache (typically in ~/.nuget/packages ) and makes the assemblies available to your project. You interact with NuGet through multiple interfaces: the dotnet CLI (e.g., dotnet add package ), Visual Studio's Package Manager UI, the Package Manager Console, or by directly editing your project file. The packages.lock.json file (when enabled) ensures deterministic restores by locking exact versions across team members. Private NuGet feeds allow organizations to host internal packages securely, enabling code sharing across teams while maintaining intellectual property protection. Authentication can be configured per feed, supporting various credential types. Example // After installing NuGet package "Newtonsoft.Json" via: // dotnet add package Newtonsoft.Json using Newtonsoft.Json; var jsonString = "{\"name\": \"Alice\", \"age\": 30}"; var person = JsonConvert.DeserializeObject<dynamic>(jsonString); Console.WriteLine($"{person.name} is {person.age} years old"); // Output: Alice is 30 years old This code uses the popular Newtonsoft.Json NuGet package to deserialize JSON without writing custom parsing logic—demonstrating how NuGet packages provide reusable functionality. Key points to mention Central repository: nuget.org hosts millions of open-source packages; organizations can also host private feeds Declarative dependency management: Package references in the .csproj file make dependencies explicit and version-controlled Transitive dependency resolution: NuGet automatically downloads dependencies of your dependencies, resolving version conflicts Version control: Lock files ensure reproducible builds and consistent versions across development teams Package metadata: Each package includes version information, license, dependencies, and documentation for informed selection Common follow-up questions How do you handle version conflicts when two packages require different versions of the same dependency? What's the difference between a NuGet package and a local project reference? How do you create and publish your own NuGet package? Related interview questions What is a .csproj file? What does the dotnet CLI do?

What is a .csproj file?

A .csproj file is the MSBuild project file for C# projects. It is an XML configuration file that defines how your project should be built, including the target framework, dependencies, output type, and build settings. Modern .NET projects use the compact SDK-style format rather than the verbose .NET Framework format. How it works When you build a C# project, MSBuild reads the .csproj file to understand what to compile, which NuGet packages to restore, what the target framework is, and which compilation options to apply. The file is XML-based and contains property groups, item groups, and targets that instruct MSBuild how to orchestrate the build process. The SDK-style format (introduced with .NET Core) automatically includes sensible defaults and globs common file patterns like *.cs files in the project directory. This means you rarely need to explicitly list every source file. The file can also reference property files, define custom build steps, and configure package metadata for NuGet publishing. The .csproj file works hand-in-hand with the .sln (solution) file when managing multiple projects. The solution file references one or more .csproj files, enabling you to build and manage them as a cohesive unit. Example <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net8.0</TargetFramework> <OutputType>Exe</OutputType> <LangVersion>latest</LangVersion> <Nullable>enable</Nullable> </PropertyGroup> <ItemGroup> <PackageReference Include="Newtonsoft.Json" Version="13.0.3" /> </ItemGroup> </Project> This minimal .csproj declares a console application targeting .NET 8.0 with nullable reference types enabled and a dependency on Newtonsoft.Json; MSBuild automatically discovers all .cs files in the directory and compiles them. Key points to mention PropertyGroup: Contains metadata like TargetFramework , OutputType (Exe, Library), and compiler settings such as Nullable and LangVersion . ItemGroup: Lists package references (NuGet dependencies), project references, and other files to include in the build. SDK-style format: The modern, concise format used by .NET 5+; older .NET Framework projects used verbose formats that explicitly listed every file. Automatic file discovery: SDK projects automatically include all .cs files in the directory tree without explicit declarations. TargetFramework: Specifies which .NET runtime your project targets (e.g., net8.0, net48, net6.0-windows). Common follow-up questions What is the difference between a .csproj file and a .sln file? A .csproj file defines a single project; a .sln file is a container that references multiple .csproj files to organize them into a solution. How do you add a NuGet package to a .csproj file? You can either use dotnet add package from the CLI, or manually add a <PackageReference> entry to the <ItemGroup> section and restore with dotnet restore . What is the .csproj.user file? It is a local, machine-specific file that stores user preferences (like debug settings or breakpoints) and is typically not checked into source control. Related interview questions What is NuGet? What are global using directives? What is the .NET SDK vs the .NET runtime?

What is the difference between a value type and a reference type?

Value types hold their data directly in memory and are copied entirely when assigned to another variable, meaning each copy is independent. Reference types store only a reference (pointer) to an object on the managed heap, so multiple variables can point to the same object. This fundamental distinction affects memory allocation, performance, and how changes to data are observed across your application. How it works When you declare a value type variable like int or struct , the runtime allocates memory on the stack to store the actual value. When you assign a value type to another variable, the entire data is copied, creating two independent copies. Changes to one copy do not affect the other. Reference types like class , string , and arrays work differently. The variable doesn't hold the actual data; it holds a reference (memory address) to an object stored on the managed heap. When you assign a reference type to another variable, you're copying the reference, not the object itself. Both variables now point to the same object in memory. Any modification through either variable affects the shared object. The garbage collector automatically manages heap memory for reference types, cleaning up objects that no longer have any references. Value types on the stack are automatically freed when they go out of scope, making them more efficient for small, short-lived data. Example // Value type example int a = 5; int b = a; b = 10; Console.WriteLine($"a: {a}, b: {b}"); // Output: a: 5, b: 10 // Reference type example var list1 = new List<int> { 1, 2, 3 }; var list2 = list1; list2.Add(4); Console.WriteLine($"list1.Count: {list1.Count}"); // Output: list1.Count: 4 // Struct (value type) example struct Point { public int X, Y; } var p1 = new Point { X = 1, Y = 2 }; var p2 = p1; p2.X = 10; Console.WriteLine($"p1.X: {p1.X}, p2.X: {p2.X}"); // Output: p1.X: 1, p2.X: 10 In the value type example, changing b doesn't affect a because they're independent copies. In the reference type example, list1 and list2 reference the same list, so adding to list2 is visible through list1 . The struct example demonstrates that structs are value types, so copying creates independent instances. Key points to mention Memory location: Value types live on the stack; reference types live on the managed heap. Copying behavior: Value types are deep-copied on assignment; reference types share the same object. Common value types: Primitives ( int , double , bool ), struct , and enum . Common reference types: class , string , arrays, delegates, and interfaces. Performance implications: Value types are generally faster for small data due to stack allocation; large value types can harm performance if copied frequently. Common follow-up questions What is the difference between class and struct in C# ? What are nullable value types ? Why should you avoid large structs, and when should you prefer a class over a struct? Related interview questions What is the difference between class and struct in C#? What is the difference between record class and record struct? What are nullable value types? Further reading Nullable reference types Value objects

What is the difference between stack and heap memory?

The stack stores method frames and local value types (like integers and structs) and is automatically cleaned up when methods return, while the heap stores reference types (objects, strings, arrays) and is managed by the garbage collector. Stack allocation is faster but limited in size, while heap allocation is flexible but requires garbage collection overhead. How it works Memory in .NET is divided into two main regions: the stack and the heap. When a method is called, a new frame is created on the stack containing space for all local variables and method parameters. Value types (like int , bool , struct ) are stored directly in this stack frame. When the method returns, the entire frame is popped off the stack, and all local variables are immediately destroyed—no garbage collection needed. The heap, by contrast, is a large pool of memory where reference types live. When you use the new keyword to create an object, the object is allocated on the heap, and a reference (pointer) to that object is returned. This reference is typically stored on the stack (if it's a local variable) or in another object on the heap (if it's a field). Because objects can outlive the method that created them and can be referenced from multiple places, the heap cannot be cleaned up as simply as the stack. Instead, the garbage collector periodically scans the heap, identifies objects that are no longer referenced, and reclaims their memory. Stack memory is also more efficient—allocation and deallocation are O(1) operations that just move a pointer. Heap allocation and garbage collection introduce overhead. However, the stack is limited in size (typically a few megabytes per thread), while the heap can grow much larger. Example public class Program { public static void Main() { int age = 25; // Stack: value type stored directly string name = "Alice"; // Stack: reference to string object // Heap: "Alice" string object stored here Person person = new Person(); // Stack: reference to Person object // Heap: Person object stored here person.Name = "Bob"; } } public class Person { public string Name { get; set; } // Field reference stored in Person object on heap } In this example, age (an int ) is stored directly on the stack, while name and person are stack references pointing to objects on the heap. When Main returns, the stack frame is destroyed, references are lost, and the heap objects become candidates for garbage collection. Key points to mention Stack is automatic and deterministic —memory is freed instantly when a method returns; predictable performance with no GC pauses. Heap requires garbage collection —the CLR must identify unreachable objects and reclaim memory, which can cause temporary pauses. Value types live on the stack (when local), while reference types live on the heap —understanding this distinction is crucial for value types vs. reference types . Stack is thread-local ; each thread gets its own stack, preventing race conditions for local variables. Stack size is limited , making it unsuitable for large data structures; this is why collections are reference types stored on the heap. Common follow-up questions Why are structs sometimes stored on the stack but can also end up on the heap? Can I force memory to be freed immediately instead of waiting for garbage collection? How do I know if my code is causing excessive garbage collection? Related interview questions What is garbage collection? What is the difference between a value type and a reference type? What is the CLR? Further reading Value objects Creational patterns overview

What is boxing and unboxing?

Boxing is the process of wrapping a value type (like int , struct ) in an object reference on the heap. Unboxing is extracting that value type back out. Both operations carry performance costs—heap allocation for boxing, and validation plus copying for unboxing—so modern C# encourages generics and value types to avoid them in performance-critical code paths. How it works When you assign a value type to an object variable or pass it to a method expecting object , the runtime allocates memory on the heap, copies the value there, and gives you a reference to that heap object. This is boxing. The original value type remains on the stack; the boxed copy lives on the heap until garbage collected. Unboxing reverses this: you extract the value back from the heap object and copy it onto the stack (or into a local variable). The runtime validates that the boxed type matches the target type—unboxing an int box into a long variable throws an InvalidCastException . Because value types are stored on the stack (fast, automatic cleanup) but reference types live on the heap (requiring GC), boxing trades performance for the convenience of treating all values uniformly through the object interface. This was especially common in pre-generic .NET; today, generics like List<T> eliminate most boxing scenarios. Example // Boxing and unboxing example int number = 42; // Boxing: value type → object reference object boxed = number; // Allocates heap memory, copies value // Unboxing: object reference → value type int unboxed = (int)boxed; // Validates type, copies from heap Console.WriteLine(unboxed); // 42 // Common mistake: implicit boxing in collections ArrayList list = new ArrayList(); list.Add(100); // Boxing occurs here int value = (int)list[0]; // Unboxing occurs here // Modern approach: use generics to avoid boxing List<int> genericList = new List<int>(); genericList.Add(100); // No boxing int value2 = genericList[0]; // No unboxing The first section demonstrates explicit boxing (assigning int to object ) and explicit unboxing (casting back). The second half shows how old non-generic collections forced boxing on every value; generics eliminate this by storing actual int instances. Key points to mention Performance cost: Boxing allocates heap memory and copies the value; unboxing validates type and copies back. Both are expensive in tight loops. Generics eliminate boxing: List<int> stores integers directly without boxing, unlike the old non-generic ArrayList . Type safety on unbox: Unboxing validates that the boxed type matches exactly—you cannot unbox an int box as long without a cast that may fail. Reference equality after boxing: Each boxing creates a new heap object, so two boxed copies of the same value are different objects: object a = 5; object b = 5; a == b is false . Nullable value types: Boxing a nullable value type like int? boxes the underlying value if it has one, or null if it doesn't. Common follow-up questions Why does boxing happen implicitly in some cases? When you pass a value type to a method expecting object or an interface the value type implements, the runtime automatically boxes it for you. How do structs avoid boxing? Record structs and regular structs are value types, so using generics with them avoids boxing entirely compared to reference type wrappers. Can you unbox to a different type? No—unboxing requires an exact type match or an exception is thrown. You must unbox to the original type or use Convert class methods instead. Related interview questions What are IValueTaskSource and pooled ValueTasks? What is the difference between record class and record struct? What is high-performance logging with LoggerMessage? Further reading Reducing allocations in hot paths Compiled queries for hot paths

What is the difference between class and struct in C#?

Classes are reference types that live on the heap and support inheritance, making them ideal for complex objects. Structs are value types that live on the stack and are copied on assignment, making them best for small, immutable data structures like coordinates or currency values. How it works The fundamental difference lies in how classes and structs are stored and passed in memory. Value types like structs store their data directly on the stack , while reference types like classes store a reference on the stack that points to data on the heap. When you assign a struct to another variable or pass it as a parameter, the entire value is copied. When you assign a class, only the reference is copied—both variables point to the same object. Classes support inheritance, allowing you to create hierarchies and use polymorphism. Structs do not support inheritance (except from interfaces) and cannot be abstract. Classes can have null values; structs have default values for each field. Classes require explicit initialization; structs are automatically initialized with default values. Performance and memory characteristics differ significantly. Structs are allocated on the stack, making them faster to create and destroy, but copying large structs repeatedly can be expensive. Classes have heap allocation overhead but avoid copying when passed around. For small, simple data, structs are often more efficient; for complex, frequently-used objects, classes are typically better. Example // Struct: value type, best for small immutable data public struct Point { public int X { get; set; } public int Y { get; set; } public Point(int x, int y) => (X, Y) = (x, y); } // Class: reference type, supports inheritance public class Person { public string Name { get; set; } public int Age { get; set; } public Person(string name, int age) => (Name, Age) = (name, age); } // Usage demonstrating value vs reference behavior var point1 = new Point(10, 20); var point2 = point1; point2.X = 30; Console.WriteLine(point1.X); // Output: 10 (struct was copied) var person1 = new Person("Alice", 30); var person2 = person1; person2.Name = "Bob"; Console.WriteLine(person1.Name); // Output: Bob (both reference same object) This example shows how modifying a copied struct leaves the original unchanged, while modifying through a class reference affects the original because both variables point to the same object. Key points to mention Memory allocation: Structs are stack-allocated (faster creation/destruction), classes are heap-allocated (more memory overhead but better for complex objects) Value vs reference semantics: Structs are copied on assignment; classes pass references, so modifications affect the original Inheritance: Classes support inheritance and polymorphism; structs only implement interfaces Nullability: Class variables can be null; struct variables have default values and cannot be null (without nullable reference types) Use cases: Use structs for small, immutable data (Point, Size, Color); use classes for complex, mutable objects with shared state (Person, Customer, Service) Common follow-up questions When would you choose a struct over a class, and when would you choose a class? What is a record, and how does it differ from a class or struct? ( See record class vs record struct ) What happens when you box a struct, and why is it important to know? Related interview questions What is the difference between a value type and a reference type? What is the difference between record class and record struct? What is the difference between an abstract class and an interface? Further reading Value objects Nullable reference types

What is a record in C#?

A record is a C# type that provides value-based equality, automatic ToString generation, and non-destructive mutation through the with keyword. Introduced in C# 9, records are reference types (or value types if declared as record struct ) designed primarily for immutable data transfer objects, events, and domain objects where structural equality matters more than reference equality. How it works Records automatically generate several members for you: Value-based equality : Two records are equal if all their properties have the same values, not because they reference the same object in memory. The compiler generates Equals , GetHashCode , and equality operators. ToString override : Records automatically generate a readable ToString that displays the type name and all properties, making debugging easier. Copy-with-mutation : The with expression creates a shallow copy of a record with specified properties changed. This is non-destructive—the original record remains unchanged. Positional parameters : Records support positional syntax in declarations, creating properties and a primary constructor automatically. Records are immutable by convention, though not enforced by the compiler unless you explicitly use init -only properties. This makes them safe for multi-threaded scenarios and reliable as dictionary keys. Example // Positional record—generates properties, constructor, and equality members public record Person(string Name, int Age); // Usage var person1 = new Person("Alice", 30); var person2 = new Person("Alice", 30); // Value-based equality Console.WriteLine(person1 == person2); // true // Automatic ToString Console.WriteLine(person1); // Person { Name = Alice, Age = 30 } // Non-destructive mutation with 'with' var person3 = person1 with { Age = 31 }; Console.WriteLine(person3); // Person { Name = Alice, Age = 31 } Console.WriteLine(person1.Age); // 30 (original unchanged) This example demonstrates how a record makes data-carrying types concise: a single line replaces dozens of lines of boilerplate code for equality and ToString, and the with expression elegantly handles immutable updates. Key points to mention Records are reference types by default —they inherit from object , not struct . Use record struct for value semantics . Equality is based on property values , not reference identity, making records suitable as dictionary keys and safe for comparison. Records are immutable by design convention —use init -only properties to enforce compile-time immutability and prevent accidental mutation. Perfect for DTOs, events, and command/query objects where you need lightweight, immutable data containers without ceremony. The with keyword provides non-destructive mutation , enabling functional-style programming patterns in C#. Common follow-up questions What is the difference between record class and record struct ? How does record equality differ from class equality, and why should I use init -only properties? Can records inherit from other records or classes? (Yes—records can inherit from other records; inheritance chains work, but be cautious with equality semantics.) Related interview questions What is the difference between record class and record struct? What is the difference between a value type and a reference type? What is the difference between class and struct in C#? Further reading Use records for DTOs Validation with FluentValidation

What is the difference between record class and record struct?

A record class is a reference type stored on the heap with value-based equality, while a record struct is a value type stored on the stack with the same conveniences. Both provide positional deconstruction, immutability support, and compiler-generated equality, but they differ in memory allocation and performance characteristics. The choice depends on whether you need reference semantics (class) or value semantics (struct). How it works Records were introduced in C# 9 to simplify immutable data types. Both record class and record struct automatically generate constructors, equality methods ( Equals , GetHashCode , == , != ), and a ToString method based on the declared properties. A record class is a reference type that inherits from System.Object . Two instances are equal if their property values are equal, even if they occupy different memory locations. It supports inheritance and polymorphism. A record struct is a value type that lives on the stack (unless boxed). Two instances are equal based on value comparison. Record structs are useful for small, immutable data structures where avoiding heap allocation improves performance. Unlike regular structs, record structs support the with keyword for non-destructive mutation and cleaner copying. Example // Record class (reference type) public record Person(string Name, int Age); // Record struct (value type) public record struct Point(double X, double Y); var person1 = new Person("Alice", 30); var person2 = new Person("Alice", 30); Console.WriteLine(person1 == person2); // True (value equality) var point1 = new Point(1.0, 2.0); var point2 = new Point(1.0, 2.0); Console.WriteLine(point1 == point2); // True (value equality) // Both support 'with' for creating modified copies var person3 = person1 with { Age = 31 }; var point3 = point1 with { X = 2.0 }; This demonstrates that both record class and record struct support value-based equality and the convenient with keyword for immutable updates, regardless of their storage location. Key points to mention Memory allocation: Record classes allocate on the heap (reference type); record structs allocate on the stack (value type), making structs faster for small data but requiring care with boxing. Equality semantics: Both use structural (value-based) equality by default, not reference equality like mutable classes. Immutability: Both support init-only properties and the with keyword for clean, immutable patterns. Inheritance: Record classes support inheritance; record structs do not (structs cannot inherit from other structs in C#). Performance: Record structs avoid heap allocations and garbage collection pressure, making them ideal for high-frequency data structures like coordinates or measurements. Common follow-up questions Can a record struct be mutable? Yes, record structs can have settable properties, but this goes against the intent; records are designed for immutability. Mutable value types can cause subtle bugs. Should I always use record struct instead of record class for performance? No—record structs have trade-offs. Stack allocation is faster, but copying a struct (parameter passing, return values) copies all data. For large types or when you need reference semantics, use record class. How does a record struct differ from a regular struct? Record structs automatically generate equality methods and the with keyword support; regular structs require manual implementation or inherit broken default equality from ValueType . Related interview questions What is the difference between a value type and a reference type? What is the difference between class and struct in C#? What is a record in C#? Further reading Single Responsibility, practically Data Mapper vs Active Record

What are the access modifiers in C#?

C# has six access modifiers— public , private , protected , internal , protected internal , and private protected —that control the visibility and accessibility of classes, methods, properties, and fields. They define which code can access a member, from anywhere in your application down to only within the declaring class or assembly. The best practice is to use the most restrictive modifier that still allows your code to function correctly. How it works Access modifiers restrict visibility by defining scope boundaries. Public members are accessible from anywhere, making them part of your public API. Private members (the default for class members) are accessible only within the declaring class, hiding implementation details. Protected members are accessible within the class and any derived classes, useful for inheritance hierarchies. Internal members are accessible anywhere within the same assembly, allowing internal collaboration without exposing to external consumers. Protected internal (union) allows access within the same assembly or from derived classes in other assemblies. Private protected (intersection) is the most restrictive combination, allowing access only within the same class or derived classes in the same assembly. The key principle is encapsulation: expose only what clients need, and hide everything else. This protects your implementation from unintended misuse and makes refactoring safer. Example public class BankAccount { private decimal _balance; // Only accessible within this class protected string AccountNumber { get; set; } // Accessible in derived classes public decimal GetBalance() // Part of the public API { return _balance; } internal void LogTransaction(string details) // Used within the assembly { Console.WriteLine($"Transaction: {details}"); } private void ValidatePin(string pin) // Hidden implementation detail { // Validation logic } protected internal decimal ApplyInterest(decimal rate) { return _balance *= (1 + rate); // Accessible across assemblies or in derived classes } private protected void ResetInternalState() // Only in this class or derived classes in same assembly { _balance = 0; } } This example demonstrates how different modifiers create layers of visibility: private hides the balance and validation, protected and internal control inheritance and assembly access, and public defines the safe interface for external code. Key points to mention The default access modifier for class members is private ; for top-level types it is internal —always be explicit to avoid surprises. Use public sparingly for your public API; prefer private or protected for internal implementation details to reduce coupling. Protected is for inheritance scenarios; use it when derived classes need to override or access behavior, such as in template method patterns. Internal is ideal for multi-project solutions where you want code sharing within your own assemblies but not external consumers. Protected internal and private protected are advanced modifiers; use them when you need precise control over inheritance and assembly boundaries. Access modifiers apply to classes, structs, interfaces, methods, properties, and fields , and even nested types. Common follow-up questions What is the default access modifier in C#? — For class members, it is private ; for top-level types (classes, interfaces, structs), it is internal . Why should I avoid making everything public? — Public members become part of your contract, making them hard to change later. Private members are implementation details you can refactor freely without breaking clients. When would I use protected internal vs. private protected? — Use protected internal (union) when derived classes or assembly-internal code need access; use private protected (intersection) only when both conditions must be true—rarely needed in practice. Related interview questions What is the difference between a field and a property? When would you choose gRPC over REST? Further reading Permission-based authorization

What is the difference between const and readonly?

const is a compile-time constant whose value is baked directly into every place it's referenced, while readonly is a field that can only be assigned once—either at declaration or in the constructor—and its value is determined at runtime. Use const for true constants that never change across versions; use readonly for values that should be immutable but may vary per instance or need runtime initialization. How it works When you declare a const field, the C# compiler replaces every reference to that constant with its literal value during compilation. This means the value is "baked in" to the calling assembly. If you later change the constant value and recompile only the library—but not the calling code—callers will still see the old value until they recompile. readonly fields, by contrast, are resolved at runtime. The field can be assigned a value during initialization (at declaration) or inside any constructor, but nowhere else. Once assigned, it cannot be modified. Because the value is looked up at runtime rather than baked in, changing a readonly field's value and recompiling will immediately affect all callers without them needing to recompile. const is implicitly static and must be assigned a compile-time constant expression (a literal or another constant). readonly can be instance-level or static, and can be assigned the result of a method call or any expression that runs at initialization time. Example public class Configuration { // Compile-time constant: value is baked into calling code public const int MaxRetries = 3; // Runtime constant: value is resolved when accessed public readonly string AppVersion; public readonly DateTime StartupTime; public Configuration(string version) { AppVersion = version; // Can only assign once StartupTime = DateTime.UtcNow; // Runtime value } } // Usage var config = new Configuration("1.0.0"); Console.WriteLine(Configuration.MaxRetries); // 3 (compiled into IL) Console.WriteLine(config.AppVersion); // "1.0.0" (runtime lookup) Console.WriteLine(config.StartupTime); // Current UTC time The MaxRetries constant is compiled into the calling code's IL, while AppVersion and StartupTime are set once during construction and cannot change afterward. Key points to mention const is implicitly static , so there is only one value shared across all instances; readonly can be instance-level or static. const must be assigned a compile-time constant expression; readonly can be assigned at runtime (in a constructor or initializer). Changing a const value requires recompiling all dependent code; changing readonly only requires recompiling the assembly that defines it. const applies only to primitives and strings; readonly can hold any type, including reference types (though the reference itself becomes immutable, not the object it points to). readonly is the safer default for most scenarios because it provides versioning safety and allows runtime flexibility. Common follow-up questions Can you make a readonly reference type truly immutable? The field reference is immutable, but the object it points to can still be modified. To prevent that, use an immutable collection or readonly struct . What happens if a library changes a const value? Callers see the old value until they recompile, which can cause version mismatch bugs. This is why readonly is preferred for public constants. Can you use readonly with properties? Yes, modern C# allows readonly properties and init accessors for similar immutability semantics. Related interview questions What are readonly structs and why do they matter? What is method overloading? What is an enum? Further reading Source generators in C#

What is a static class?

A static class is a sealed class that cannot be instantiated and contains only static members (methods, properties, and fields). It serves as a container for utility functions and extension methods, and is loaded into memory only once by the CLR when first accessed. How it works When you declare a class as static , the compiler enforces several rules: no instance can be created (the constructor is private by default), all members must be static, and the class is implicitly sealed and abstract. This means you cannot inherit from a static class. Static classes are ideal for grouping related functionality that doesn't require object state—think of them as organized collections of utility functions. The CLR loads a static class the first time any of its members are accessed, initializing static fields and running the static constructor if one exists. All subsequent calls to static members reference the same data in memory, making static classes efficient for shared utilities. Static classes are commonly used in the .NET Framework itself—examples include Math , String , File , and Console . They're also the natural home for extension methods , which must be declared in static classes in C#. Example public static class StringHelper { public static bool IsValidEmail(string email) { return email != null && email.Contains("@"); } public static string Reverse(string input) { return new string(input.Reverse().ToArray()); } } // Usage class Program { static void Main() { string email = "user@example.com"; if (StringHelper.IsValidEmail(email)) { Console.WriteLine("Valid email"); } string reversed = StringHelper.Reverse("Hello"); Console.WriteLine(reversed); // "olleH" } } This example shows a static utility class that provides string validation and manipulation methods. All members are accessed directly on the class name without creating an instance. Key points to mention No instantiation: You cannot use new to create an instance; the compiler will throw an error. All members must be static: Instance members, instance constructors (other than the private static constructor), and instance fields are not allowed. Sealed and abstract: A static class cannot be inherited from, making it impossible to extend its behavior through inheritance. Memory efficiency: Static members are loaded once and shared across the entire application lifetime, reducing memory overhead compared to creating multiple instances. Thread-safe initialization: The CLR guarantees that static constructors run only once and are thread-safe, making static classes reliable for singleton-like patterns. Common follow-up questions How do static classes differ from the Singleton pattern? (Static classes are simpler and thread-safe by default, while Singleton requires manual implementation and instantiation.) Can you use a static class as a base class? (No, static classes are implicitly sealed.) What is the difference between a static class and a regular class with all static members? (A static class is explicitly sealed by the compiler and cannot be instantiated, while a regular class with static members can still be instantiated, though it would be wasteful.) Related interview questions What is an extension method? What is the difference between an abstract class and an interface? What are generic constraints? Further reading Extension methods done right

What is a constructor?

A constructor is a special method that runs automatically when you create an instance of a class or struct, allowing you to initialize the object's state. C# supports several constructor types: parameterless (default), parameterized, static, and primary constructors , each serving different initialization needs. How it works When you use the new keyword to instantiate a class or struct, the runtime automatically invokes the constructor before the object is returned to you. Constructors have the same name as the class and no return type (not even void ). They initialize fields, properties, and perform any setup logic the object needs to function correctly. Constructors are useful for enforcing invariants—ensuring that an object never exists in an invalid state. For example, you might require certain fields to be set or validated before the object is ready to use. If you don't define a constructor, C# provides a default parameterless constructor, but defining your own gives you control over initialization. You can have multiple constructors with different parameters (constructor overloading). Constructors can also call other constructors using the this() keyword, allowing you to reuse initialization logic and reduce code duplication. Example public class Person { public string Name { get; set; } public int Age { get; set; } // Parameterless constructor public Person() { Name = "Unknown"; Age = 0; } // Parameterized constructor public Person(string name, int age) { Name = name; Age = age; } // Constructor calling another constructor public Person(string name) : this(name, 0) { } // Static constructor (runs once for the class) static Person() { Console.WriteLine("Person class initialized"); } } // Usage Person p1 = new Person(); // Uses parameterless constructor Person p2 = new Person("Alice", 30); // Uses parameterized constructor Person p3 = new Person("Bob"); // Calls parameterized with default age This example demonstrates a class with multiple constructors: a default one, a parameterized one, one that chains to another constructor, and a static constructor that initializes class-level data. Key points to mention Constructors must have the same name as the class and no return type You can overload constructors with different parameter lists Use this() to call another constructor in the same class (constructor chaining) Static constructors run once before any instance is created and cannot have parameters Classes and structs both support constructors, though structs have special rules for parameterless constructors Common follow-up questions What is the difference between a constructor and a finalizer/destructor? Can a constructor be private, and if so, why would you do that? What happens if you don't define a constructor? Related interview questions What is a primary constructor in C# 12? What is the difference between class and struct in C#? What is an interface? Further reading Primary constructors in C# 12

What is a primary constructor in C# 12?

A primary constructor is a C# 12 feature that allows you to declare constructor parameters directly in the class declaration. These parameters are automatically available as fields throughout the entire class, eliminating the need for manual field declarations and assignments. This reduces boilerplate code, particularly for dependency injection scenarios. How it works In C# 12, you can append parameter declarations directly to the class name using parentheses, similar to how method signatures work. The parameters become implicitly captured and accessible throughout the class scope without requiring explicit backing fields or properties. The compiler generates the constructor logic automatically. When you declare a primary constructor parameter, it has class scope and can be used in field initializers, property initializers, and all instance methods. The parameters are read-only by default, ensuring immutability and thread safety. If you need custom constructor logic beyond parameter capture, you can still define an explicit constructor body using a colon syntax. Primary constructors work seamlessly with inheritance, record types, and both reference and value types. They integrate naturally with nullable reference types and property initialization patterns, making them ideal for dependency injection, data carrier classes, and services that depend on external components. Example // Without primary constructor (traditional approach) public class OrderService { private readonly IOrderRepository _repository; private readonly ILogger<OrderService> _logger; public OrderService(IOrderRepository repository, ILogger<OrderService> logger) { _repository = repository; _logger = logger; } public async Task<Order?> GetOrderAsync(int id) { _logger.LogInformation("Fetching order {OrderId}", id); return await _repository.GetByIdAsync(id); } } // With primary constructor (C# 12) public class OrderService(IOrderRepository repository, ILogger<OrderService> logger) { public async Task<Order?> GetOrderAsync(int id) { logger.LogInformation("Fetching order {OrderId}", id); return await _repository.GetByIdAsync(id); } } In the primary constructor version, the repository and logger parameters are automatically available throughout the class without declaring backing fields or assignment statements. Key points to mention Reduced boilerplate: Primary constructors eliminate repetitive field declarations and assignments, making code more concise, especially for dependency injection scenarios. Class-scoped parameters: Parameters are implicitly available throughout the entire class, including in property initializers, field initializers, and all methods. Read-only by default: Primary constructor parameters are read-only, promoting immutability and thread safety without additional effort. Inheritance support: Derived classes must explicitly call the base class primary constructor, maintaining clear dependency flow in inheritance hierarchies. Optional explicit constructor body: You can still add custom constructor logic using explicit constructor syntax if needed beyond parameter capture. Common follow-up questions Can primary constructors have default values? Yes, you can use default parameter values in primary constructors just like regular method parameters, but this pattern is less common since most frameworks expect all dependencies to be explicitly provided. How do primary constructors interact with inheritance? Derived classes must explicitly invoke the base class primary constructor using the base() syntax; parameters are not inherited automatically. Are primary constructor parameters the same as properties? No; they are implicitly captured as class-scoped variables. If you need public access, you must explicitly declare properties in addition to the primary constructor. Related interview questions What is dependency injection? What is a constructor? How do you prevent SQL injection in .NET? Further reading Primary constructors in C# 12 Dependency injection is a pattern too

What are properties in C#?

Properties are members of a class that expose controlled access to data through getter and setter accessors. They provide a clean, object-oriented way to read and write values while maintaining encapsulation. Auto-properties simplify syntax by automatically generating backing fields, and the init accessor allows values to be set only during object initialization, supporting immutability patterns. How it works Properties bridge the gap between fields and methods. When you access a property, you're actually calling methods (get and set accessors) behind the scenes, but the syntax looks like direct field access. This allows you to add validation, logging, or other logic without changing the public interface. A property has two main accessors: get returns a value and set assigns a value. You can control access levels independently—for example, a public getter with a private setter. Auto-properties (introduced in C# 3.0) automatically create a hidden backing field, eliminating boilerplate code. The init accessor (C# 9.0+) restricts assignment to the initialization phase, enabling immutable object patterns. Properties are part of encapsulation , a core principle of object-oriented design. Example public class Person { // Auto-property with private setter public string Name { get; private set; } // Full property with validation private int _age; public int Age { get { return _age; } set { _age = value >= 0 ? value : throw new ArgumentException("Age cannot be negative"); } } // Init-only property (immutable after construction) public string Email { get; init; } public Person(string name, string email) { Name = name; Email = email; } } // Usage var person = new Person("Alice", "alice@example.com") { Email = "newemail@example.com" }; // person.Email = "another@example.com"; // Error: init-only property cannot be set person.Age = 25; // Valid // person.Age = -5; // Error: throws ArgumentException This example demonstrates three property patterns: an auto-property with a private setter for controlled initialization, a full property with validation logic in the setter, and an init-only property for immutable data after construction. Key points to mention Properties provide encapsulation by allowing you to control read/write access and add logic without exposing internal implementation details. Auto-properties simplify syntax when no special logic is needed; the compiler generates a private backing field automatically. get and set can have different access levels (e.g., public get , private set ) to enforce controlled mutation. The init accessor (C# 9+) enables immutability by allowing assignment only during object initialization, supporting modern patterns like immutable records. Properties are different from fields ; properties are computed/controlled access points, while fields are raw data storage. Common follow-up questions When would you use a property versus a field? Always prefer properties for public members because they provide encapsulation and allow future validation without breaking the API. Can a property be abstract or virtual? Yes, properties can be declared as abstract or virtual in base classes to force or allow derived classes to override their behavior. What is the performance difference between properties and fields? Modern .NET compilers optimize auto-properties to near-field performance; any difference is negligible in real applications. Related interview questions What is the difference between a field and a property? What is encapsulation? What is the difference between a value type and a reference type? Further reading The pipeline pattern

What is the difference between a field and a property?

A field is a raw data member that directly stores a value, while a property is a wrapper around field access that provides controlled get and set accessors. Properties allow you to add logic, validation, and change implementation without breaking your public API, making them the preferred choice for class members in modern C#. How it works A field is simply a variable declared directly in a class or struct. It holds data and nothing more. When you access a field, you are directly reading from or writing to that memory location. A property is a member that wraps field access through accessor methods called get and set . The get accessor runs when you read the property; the set accessor runs when you assign a value. This indirection allows you to: Add validation logic before accepting a new value Perform side effects (logging, notifying observers, updating related fields) Compute a value on-the-fly without storing it Change the internal implementation without changing the public interface Implement data binding in UI frameworks Because properties feel syntactically like fields (you use dot notation to access them), they provide a clean abstraction while maintaining encapsulation—a core object-oriented principle. Example public class User { // Raw field – direct access, no control private int _age; // Property wrapping the field with validation public int Age { get { return _age; } set { if (value < 0 || value > 150) throw new ArgumentException("Age must be between 0 and 150"); _age = value; } } // Auto-property – no explicit backing field needed public string Name { get; set; } // Computed property – no backing field, returns a calculated value public bool IsAdult => Age >= 18; } // Usage var user = new User { Name = "Alice" }; user.Age = 25; // Validation runs Console.WriteLine(user.IsAdult); // True – computed on access This example demonstrates that properties provide a single, consistent interface for accessing data while hiding validation and computation logic from the caller. Key points to mention Encapsulation: Properties enforce the principle that internal state should be protected and accessed only through controlled interfaces API stability: You can change a field to a property without recompiling consuming code, but changing a property's name or removing it is a breaking change Flexibility: A property can be read-only ( get only), write-only ( set only), or use different access levels for each accessor (e.g., public get; private set; ) Auto-properties: C# 3.0+ introduced auto-properties like public string Name { get; set; } , which eliminate boilerplate while still providing property benefits Best practice: Expose public data members as properties, not fields—fields are typically private and often back a public property Common follow-up questions What is an auto-property, and when would you use one? How do access modifiers apply to properties? Can you have a read-only property, and how would you implement it? Related interview questions What are properties in C#? What are the access modifiers in C#? What are generics?

What is method overloading?

Method overloading is a feature that allows you to define multiple methods with the same name but different parameter lists (signatures). The compiler determines which method to call at compile time based on the arguments you pass. This is a form of compile-time (static) polymorphism. How it works When you overload a method, you create several versions of it that differ by their parameters. The differences can be: Number of parameters: Calculate(int a) vs. Calculate(int a, int b) Type of parameters: Display(string text) vs. Display(int number) Order of parameters: Combine(string first, int second) vs. Combine(int first, string second) The return type alone cannot be used to differentiate overloaded methods—the compiler wouldn't know which version to call when it sees only the method name. At compile time, the C# compiler analyzes the argument types and counts to select the most specific matching method. If no exact match exists, it attempts implicit conversions to find a suitable candidate. Example public class Calculator { // Overload 1: Two integers public int Add(int a, int b) { return a + b; } // Overload 2: Three integers public int Add(int a, int b, int c) { return a + b + c; } // Overload 3: Two doubles public double Add(double a, double b) { return a + b; } // Overload 4: Parameter array (variable length) public int Add(params int[] numbers) { return numbers.Sum(); } } // Usage var calc = new Calculator(); Console.WriteLine(calc.Add(5, 10)); // Calls Overload 1 → 15 Console.WriteLine(calc.Add(5, 10, 15)); // Calls Overload 2 → 30 Console.WriteLine(calc.Add(5.5, 10.5)); // Calls Overload 3 → 16.0 Console.WriteLine(calc.Add(1, 2, 3, 4, 5)); // Calls Overload 4 → 15 The compiler selects the correct Add method based on the argument types and count, making the API more intuitive and readable. Key points to mention Overloading is resolved at compile time , not runtime—this differs from method overriding , which uses runtime polymorphism. The method signature (name + parameters) must be unique; return type alone does not create a valid overload. Overloading improves code readability and maintainability by using a single, intuitive method name for related operations. Use optional parameters and default values carefully alongside overloading to avoid redundant method definitions. Overloading works with constructors, operators, and regular methods. Common follow-up questions What's the difference between overloading and overriding? — Overloading creates multiple methods with the same name but different signatures (compile-time); overriding replaces a base class method in a derived class (runtime polymorphism). Can you overload a method based only on return type? — No, the compiler cannot determine which overload to call when it sees only the method name and arguments, making return-type-only differences invalid. How does the compiler choose the best overload match? — The compiler performs overload resolution by finding the most specific match: exact type match first, then implicit conversions, then params arrays as a last resort. Related interview questions What is the difference between LINQ query syntax and method syntax? What is JIT compilation? What is an extension method? Further reading Source generators in C#

What is method overriding?

Method overriding is a mechanism that allows a derived class to provide a different implementation of a method that already exists in its base class. The derived class uses the override keyword to replace a virtual or abstract base method, enabling runtime polymorphism where the correct method is called based on the actual object type, not the reference type. How it works When you declare a method as virtual in a base class, you're signaling that derived classes are permitted to override it with their own implementation. The derived class then uses the override keyword to replace that method. At runtime, when you call the method through a base class reference pointing to a derived class object, .NET uses dynamic dispatch to invoke the overridden method in the derived class, not the base class version. This is different from method overloading, which creates multiple methods with the same name but different signatures in the same class. Overriding specifically replaces an inherited method with a new implementation. For virtual, abstract, and override , the relationship is clear: virtual provides a default implementation that can be overridden, abstract requires derived classes to provide an implementation, and override is how you provide that implementation in the derived class. Example public class Animal { public virtual void MakeSound() { Console.WriteLine("Some generic sound"); } } public class Dog : Animal { public override void MakeSound() { Console.WriteLine("Woof!"); } } public class Cat : Animal { public override void MakeSound() { Console.WriteLine("Meow!"); } } // Usage Animal myPet = new Dog(); myPet.MakeSound(); // Output: Woof! myPet = new Cat(); myPet.MakeSound(); // Output: Meow! This example demonstrates polymorphism in action: the same method call produces different results depending on the actual object type, not the reference type. Key points to mention The base method must be marked virtual or abstract to be overridable; you cannot override a non-virtual method. The overridden method must have the same signature (name, parameters, and return type) as the base method. Overriding enables runtime polymorphism through late binding—the correct method is resolved at runtime based on the actual object type. You can use the sealed keyword to prevent further overriding in derived classes, or mark a method as sealed override to block overriding in subclasses while still overriding the base method. The base keyword allows you to call the base class implementation from within the overridden method if needed. Common follow-up questions What is the difference between overriding and overloading? Can you override a static method? (Answer: No, static methods are resolved by reference type, not runtime type.) What happens if you forget the virtual keyword in the base class? (Answer: The method cannot be overridden; it will be hidden if you use a similar method name in the derived class.) Related interview questions What is the difference between virtual, abstract and override? What is polymorphism? What is .NET? Further reading Factory method

What is the difference between virtual, abstract and override?

Virtual allows derived classes to optionally override a method while providing a default implementation in the base class. Abstract requires derived classes to implement a method—there is no default implementation. Override is the keyword used in derived classes to replace a virtual or abstract method with a new implementation. How it works Virtual methods enable polymorphic behavior with a safety net. When you mark a method as virtual , you're saying "derived classes may override this, but they don't have to." The base class provides working code, so if a derived class doesn't override it, the base implementation runs. This is useful when you have sensible default behavior that some subclasses might customize. Abstract methods are the opposite. They define a contract that every derived class must fulfill. An abstract method has no body—it's purely a signature. The derived class is forced to provide an implementation using the override keyword. Abstract methods must live inside an abstract class, and you cannot instantiate an abstract class directly. Override is the mechanism that fulfills the contract. When a derived class implements a virtual or abstract method, it uses the override keyword to signal that it's intentionally replacing the base class behavior. Without override , you're just creating a new method that hides the base method—which is usually a mistake. Example abstract class Animal { // Virtual: optional to override, has default behavior public virtual void MakeSound() { Console.WriteLine("Some generic animal sound"); } // Abstract: must override, no implementation public abstract void Move(); } class Dog : Animal { // Override virtual method public override void MakeSound() { Console.WriteLine("Woof!"); } // Must override abstract method public override void Move() { Console.WriteLine("Dog runs on four legs"); } } class Bird : Animal { // Don't override MakeSound—uses base implementation implicitly // But could override if needed // Must override abstract Move public override void Move() { Console.WriteLine("Bird flies with wings"); } } // Usage Animal myDog = new Dog(); myDog.MakeSound(); // Output: Woof! myDog.Move(); // Output: Dog runs on four legs Animal myBird = new Bird(); myBird.MakeSound(); // Output: Some generic animal sound myBird.Move(); // Output: Bird flies with wings This example demonstrates that Dog overrides both methods, while Bird only overrides Move and inherits the default MakeSound —showing the difference between mandatory (abstract) and optional (virtual) overrides. Key points to mention Virtual = optional override: Provides default behavior; derived classes can customize but don't have to. Abstract = mandatory override: No implementation provided; every derived class must implement it. Override keyword = fulfillment: Used in derived classes to replace base behavior and avoid the accidental method hiding that occurs without it. Abstract classes only: Abstract methods can only exist inside abstract classes; you cannot instantiate abstract classes directly. Polymorphism enabler: Both virtual and abstract enable runtime polymorphism—the correct override is called based on the actual object type, not the reference type. See method overriding for more details. Common follow-up questions Can you use override without virtual or abstract? No—you can only override a virtual or abstract member. If you define a new method with the same signature without override , you're hiding (shadowing) the base method, which is usually unintended. What's the difference between abstract classes and interfaces? See abstract class vs. interface . In short: abstract classes can have state and constructors; interfaces define contracts only. Can an abstract class have non-abstract methods? Yes—abstract classes can mix abstract methods (that must be overridden) with virtual or concrete methods (that provide default behavior). Related interview questions What is method overriding? What is the difference between an abstract class and an interface? What is the difference between == and Equals?

What is an interface?

An interface defines a contract that specifies which members (methods, properties, events, and indexers) a type must implement. Classes and structs can implement one or more interfaces, allowing you to define a blueprint for behavior without providing implementation details. Interfaces enable loose coupling, polymorphism, and make code more testable and maintainable. How it works An interface is declared using the interface keyword and contains only member signatures—no implementation. When a class or struct implements an interface, it must provide concrete implementations for all members defined by that interface. This creates a contract: "if you claim to implement this interface, you must provide these capabilities." Interfaces support multiple inheritance—a single type can implement multiple interfaces simultaneously. This is one of the key differences from abstract classes , which allow only single inheritance. Interfaces promote loose coupling because code can depend on an interface rather than a concrete implementation, making it easier to swap implementations and write unit tests with mock objects. Starting with C# 8.0, interfaces can include default implementations for methods, allowing you to add new members to an interface without breaking existing implementations. However, the core purpose remains defining a contract. Example // Define an interface contract public interface IPaymentProcessor { decimal ProcessPayment(decimal amount); string GetStatus(); } // Implement the interface in a class public class CreditCardProcessor : IPaymentProcessor { public decimal ProcessPayment(decimal amount) { Console.WriteLine($"Processing credit card payment: ${amount}"); return amount; } public string GetStatus() { return "Credit card ready"; } } // Another implementation of the same interface public class PayPalProcessor : IPaymentProcessor { public decimal ProcessPayment(decimal amount) { Console.WriteLine($"Processing PayPal payment: ${amount}"); return amount * 0.99m; // 1% fee } public string GetStatus() { return "PayPal connected"; } } // Use any implementation through the interface class Program { static void Main() { IPaymentProcessor processor = new CreditCardProcessor(); processor.ProcessPayment(100); processor = new PayPalProcessor(); processor.ProcessPayment(100); } } This example demonstrates how two different classes implement the same IPaymentProcessor interface, providing their own versions of payment processing. Code using the interface doesn't need to know which implementation it's working with—it only depends on the contract. Key points to mention Contract definition: Interfaces define what members must exist, not how they work. Multiple implementation: A class can implement multiple interfaces, unlike abstract classes which support only single inheritance. Loose coupling: Code depending on interfaces rather than concrete classes is more flexible, testable, and maintainable. Polymorphism: Different implementations can be used interchangeably wherever the interface type is expected. Default implementations (C# 8+): Interfaces can now include method bodies, though this is optional and less common. Common follow-up questions What is the difference between an interface and an abstract class ? Can a struct implement an interface ? What's the purpose of using interfaces in dependency injection? Related interview questions What is the difference between an abstract class and an interface? What is the difference between class and struct in C#? What is a constructor?

What is the difference between an abstract class and an interface?

Abstract classes define a base template for derived classes with shared state and logic, allowing only single inheritance. Interfaces define contracts that classes must implement and support multiple inheritance, making them ideal for defining capabilities without enforcing implementation details. In modern C#, the distinction has blurred somewhat with default interface methods, but the intent remains: abstract classes represent "is-a" relationships, while interfaces represent "can-do" capabilities. How it works An abstract class serves as a blueprint for a family of related classes. It can contain abstract methods (which must be overridden), concrete methods (with implementations), fields, constructors, and access modifiers like protected or private. When a class inherits from an abstract class, it commits to implementing all abstract members and gains access to shared logic and state. However, C# allows a class to inherit from only one abstract class. An interface, by contrast, is a contract that specifies what methods and properties a class must provide, but not necessarily how . Interfaces cannot hold state (no instance fields) and traditionally contained only method signatures. Since C# 8.0, interfaces can include default implementations and static members, giving them more flexibility. Critically, a class can implement multiple interfaces, allowing it to adopt many different contracts simultaneously. Use abstract classes when you have a clear hierarchy with shared code, constructor logic, or state management. Use interfaces when you want to define a capability that unrelated classes should provide, or when you need multiple inheritance of contract. Example // Abstract class: represents a family of animals with shared behavior public abstract class Animal { protected string Name { get; set; } // State protected Animal(string name) { Name = name; // Constructor logic } // Abstract method: derived classes must implement public abstract void Speak(); // Concrete method: shared logic public void Sleep() { Console.WriteLine($"{Name} is sleeping."); } } // Interface: represents the capability to fly public interface IFlyable { void Fly(); void Land(); } // Concrete class: inherits from one abstract class, implements multiple interfaces public class Bird : Animal, IFlyable { public Bird(string name) : base(name) { } public override void Speak() { Console.WriteLine($"{Name} chirps."); } public void Fly() { Console.WriteLine($"{Name} is flying."); } public void Land() { Console.WriteLine($"{Name} lands."); } } // Usage var bird = new Bird("Sparrow"); bird.Speak(); // Output: Sparrow chirps. bird.Sleep(); // Output: Sparrow is sleeping. bird.Fly(); // Output: Sparrow is flying. This example shows that Bird inherits from Animal (gaining state and shared logic) and implements IFlyable (satisfying a capability contract). It can do this because C# supports multiple interface implementation but single class inheritance. Key points to mention Inheritance model: Abstract classes support single inheritance; interfaces support multiple implementation. State management: Abstract classes can hold instance fields and maintain state; interfaces cannot hold instance state (though they can have constants and, since C# 8, static fields). Constructors: Abstract classes can have constructors to initialize state; interfaces cannot. Access modifiers: Abstract class members can be private, protected, internal, or public; interface members are implicitly public (with private implementation in C# 8+). Purpose: Abstract classes model "is-a" hierarchies with shared behavior; interfaces define "can-do" capabilities independent of hierarchy. Common follow-up questions Can an interface have constructors? (No, but a class implementing an interface can.) Can an abstract class implement an interface? (Yes, and often does to define default behavior for that interface.) What is the difference between a virtual method in a base class and a method in an interface? (Virtual methods provide optional overrides with a default implementation; interface methods enforce a contract, though C# 8+ defaults blur this distinction.) Related interview questions What is the difference between class and struct in C#? What is an interface? What is the difference between AddTransient services that hold state and stateless services? Further reading Primary constructors in C# 12 Single Responsibility, practically

What are the four pillars of OOP?

The four pillars of Object-Oriented Programming are encapsulation, abstraction, inheritance, and polymorphism. These foundational concepts enable developers to write maintainable, scalable, and reusable code by organizing data and behavior into logical, self-contained units. Together, they form the backbone of how we design and structure applications in languages like C#. How it works Encapsulation bundles data (fields) and methods together into a class, hiding internal implementation details behind access modifiers (private, protected, public). This protects the object's state from unintended external modification and allows controlled access through properties or methods. Abstraction exposes only the essential features of an object while concealing complex implementation details. It allows you to interact with objects at a high level without needing to understand how they work internally. Abstract classes and interfaces are key tools for achieving abstraction. Inheritance enables a class (derived class) to inherit properties and methods from another class (base class), promoting code reuse and establishing hierarchical relationships. A child class can extend or override parent behavior, reducing duplication and improving maintainability. Polymorphism allows objects of different types to be treated through a common interface or base class. This enables flexible, extensible code where the specific implementation is determined at runtime based on the actual object type, supporting both method overriding and method overloading. Example // Encapsulation: private fields, public property // Abstraction: abstract base class hides implementation details public abstract class Animal { private string _name; public string Name { get => _name; set => _name = value; } // Abstraction: abstract method defines contract public abstract void MakeSound(); } // Inheritance: Dog inherits from Animal public class Dog : Animal { // Polymorphism: override abstract method public override void MakeSound() { Console.WriteLine($"{Name} barks!"); } } public class Cat : Animal { public override void MakeSound() { Console.WriteLine($"{Name} meows!"); } } // Usage Animal dog = new Dog { Name = "Buddy" }; Animal cat = new Cat { Name = "Whiskers" }; dog.MakeSound(); // Output: Buddy barks! cat.MakeSound(); // Output: Whiskers meows! This example demonstrates all four pillars: encapsulation via the private _name field and public Name property, abstraction through the Animal abstract class, inheritance with Dog and Cat extending Animal , and polymorphism by calling MakeSound() on different animal types through the common Animal interface. Key points to mention Encapsulation protects object integrity by controlling access to internal state, reducing bugs and unintended side effects. Abstraction simplifies code by hiding complexity, making systems easier to understand and maintain. Inheritance promotes the DRY (Don't Repeat Yourself) principle, allowing shared functionality to be defined once in a base class. Polymorphism enables flexible, loosely-coupled designs where new types can be added without changing existing code that uses the base interface. These pillars work together: encapsulation and abstraction reduce complexity, inheritance enables code reuse, and polymorphism creates extensibility. Common follow-up questions What is the difference between method overloading and method overriding? (Both are forms of polymorphism; overloading occurs at compile-time, overriding at runtime.) How do abstract classes differ from interfaces in achieving abstraction? (See this related question for a detailed comparison.) Can you explain the SOLID principles in relation to OOP pillars? (SOLID builds on these pillars to create even more maintainable designs.) Related interview questions What is polymorphism? What is encapsulation? What is the difference between an abstract class and an interface? Further reading Flyweight pattern

What is encapsulation?

Encapsulation is the practice of bundling data (fields) and behavior (methods) together while hiding internal implementation details behind a public interface. It protects an object's state from unauthorized or invalid changes by controlling access through properties and methods, making code more maintainable and reducing unintended side effects. How it works Encapsulation operates on the principle of information hiding . You declare fields as private so external code cannot directly access or modify them. Instead, you expose controlled access through public properties, methods, or events. This creates a boundary between the internal state of an object and the outside world. The key benefit is protecting invariants —the rules that must always be true for your object to work correctly. For example, a bank account balance should never be negative. By hiding the balance field and only allowing withdrawals through a validated method, you guarantee this invariant is maintained. If the balance were public, any code could set it to an invalid value. Encapsulation also makes code easier to refactor. If the internal implementation changes—say you switch from storing a single balance to storing transactions and computing balance on-demand—external code doesn't break because it only depends on the public interface, not the private details. Example public class BankAccount { private decimal _balance; public string AccountHolder { get; } public decimal Balance { get => _balance; private set => _balance = value; } public BankAccount(string accountHolder, decimal initialBalance) { AccountHolder = accountHolder; Balance = initialBalance; } public void Deposit(decimal amount) { if (amount <= 0) throw new ArgumentException("Deposit must be positive"); Balance += amount; } public bool Withdraw(decimal amount) { if (amount <= 0 || amount > Balance) return false; Balance -= amount; return true; } } The _balance field is private and can only change through validated Deposit and Withdraw methods, ensuring the balance never becomes invalid. The Balance property has a private setter so external code cannot bypass these rules. Key points to mention Encapsulation is one of the four pillars of OOP , alongside inheritance, polymorphism, and abstraction. Use access modifiers ( private , public , protected ) to control visibility and enforce boundaries. Properties with getters and setters provide a cleaner syntax than traditional getter/setter methods while still allowing validation logic. Encapsulation protects object invariants and reduces coupling between classes, making code more maintainable and testable. It enables you to change internal implementation without affecting code that depends on the public interface. Common follow-up questions Why use properties instead of just public fields? How does encapsulation relate to enforcing aggregate invariants in domain-driven design? What is the difference between encapsulation and abstraction? Related interview questions How do you enforce aggregate invariants? What are the four pillars of OOP? What are properties in C#? Further reading Validation with FluentValidation SOLID in one carousel

What is polymorphism?

Polymorphism is the ability of objects to take on multiple forms and allows you to write code that can work with objects of different types through a common base type or interface. At runtime, the actual object's type determines which method implementation is executed, enabling flexible and extensible code design. How it works Polymorphism operates through the principle that a variable of a base class or interface type can reference objects of derived classes. When you call a method on that variable, the CLR (Common Language Runtime) uses late binding to determine which implementation to execute based on the actual runtime type of the object, not the variable's declared type. There are two main forms of polymorphism in C#: Compile-time (Static) Polymorphism: Method overloading, where multiple methods share the same name but have different parameters. The compiler resolves which method to call based on the arguments provided. Runtime (Dynamic) Polymorphism: Method overriding, where a derived class provides a different implementation of a base class method marked as virtual . The runtime determines which implementation to execute. Polymorphism works hand-in-hand with method overriding to create extensible and maintainable code that adheres to the Open/Closed Principle—open for extension through inheritance, closed for modification. Example using System; abstract class Animal { public virtual void Speak() { Console.WriteLine("Animal makes a sound"); } } class Dog : Animal { public override void Speak() { Console.WriteLine("Dog barks: Woof!"); } } class Cat : Animal { public override void Speak() { Console.WriteLine("Cat meows: Meow!"); } } class Program { static void Main() { Animal dog = new Dog(); Animal cat = new Cat(); dog.Speak(); // Outputs: Dog barks: Woof! cat.Speak(); // Outputs: Cat meows: Meow! // Process any animal ProcessAnimal(dog); ProcessAnimal(cat); } static void ProcessAnimal(Animal animal) { animal.Speak(); // Correct method called based on actual type } } This example shows runtime polymorphism: variables of type Animal hold Dog and Cat objects, and calling Speak() executes the correct overridden method for each actual type. Key points to mention Polymorphism requires a base class or interface; derived classes override or implement methods to provide specific behavior. The actual runtime type of the object determines which method implementation executes, not the variable's declared type. Polymorphism reduces code duplication and makes code more flexible—you can add new types without changing existing code that uses the base type. Use virtual keyword in the base class and override in derived classes to enable runtime polymorphism. Interfaces are a powerful way to achieve polymorphism without inheritance; multiple types can implement the same interface differently. Common follow-up questions What's the difference between virtual and abstract methods? (Abstract forces implementation in derived classes; virtual provides a default that can be overridden.) How does polymorphism relate to the four pillars of OOP ? (It's one of the core pillars; the others are encapsulation, inheritance, and abstraction.) Can you use polymorphism with interfaces? (Yes, interfaces are even more flexible than base classes for achieving polymorphic behavior.) Related interview questions What are the four pillars of OOP? What is method overriding? What is the CLR? Further reading Compound components

What is the sealed keyword?

The sealed keyword prevents a class from being inherited or a method from being overridden further. It explicitly communicates that a type is not designed for extension and can unlock small JIT compilation optimizations by allowing devirtualization. How it works When you mark a class as sealed , the compiler prevents any derived class from inheriting it. When you mark a method (or property) as sealed , you prevent further overrides in subclasses—though the method must already be marked virtual or override to seal it. The sealed keyword serves two purposes. First, it clarifies design intent: the author is saying "this class is complete and not meant to be extended." This makes code easier to reason about and safer to refactor. Second, it enables the JIT compiler to devirtualize method calls and apply inlining more aggressively, since there's no possibility of a derived implementation being called at runtime. Most .NET framework classes are sealed by default (like string , int , DateTime ) for both safety and performance reasons. You should consider sealing your own classes unless you explicitly design them for inheritance. Example // Sealed class—cannot be inherited public sealed class PaymentProcessor { public virtual void Process(decimal amount) { } } // This will not compile // public class CreditCardProcessor : PaymentProcessor { } // Error! // Sealed method—prevents further override in subclasses public class DataService { public virtual void Fetch() { } } public class CachedDataService : DataService { public sealed override void Fetch() { // This is the final implementation; no subclass can override it } } // This will not compile // public class LoggedCachedDataService : CachedDataService // { // public override void Fetch() { } // Error! // } The first class prevents any inheritance; the sealed method in the subclass prevents further overrides down the chain, while still allowing the class itself to be inherited. Key points to mention sealed class prevents inheritance entirely; sealed override prevents further overrides of a specific method in derived types. Sealing enables JIT optimizations by removing the possibility of polymorphic dispatch, allowing devirtualization and inlining . Most built-in .NET types (String, DateTime, Int32) are sealed to protect their invariants and improve performance. Seal by default unless you explicitly design a class for inheritance; this follows the principle of "make it hard to misuse." Sealed does not affect static members, constructors, or internal implementation—only inheritance and override relationships. Common follow-up questions Why would you seal a method but not the class? — To allow subclasses to exist and override some members, but lock down a specific method that has no safe alternative implementation path. Does sealing improve performance in all cases? — Not dramatically in everyday code, but it removes a source of virtual dispatch overhead and signals to the JIT that devirtualization is safe, which matters in hot paths. Can you seal a static member or constructor? — No, static members and constructors are not virtual by nature, so sealing does not apply to them. Related interview questions What is JIT compilation? What is inlining and how do you influence it? What is method overriding? Further reading Factory method

A namespace is a container that organizes types (classes, interfaces, structs, enums, delegates) and prevents naming conflicts by creating a logical hierarchy. In C#, namespaces allow you to group related code and avoid collisions when multiple developers or libraries define types with the same name. Modern C# (7.10+) supports file-scoped namespaces, which eliminate excessive indentation. How it works Namespaces create a fully qualified name for each type by prefixing it with the namespace path. For example, a class User in the namespace Company.Services is fully qualified as Company.Services.User . Two different namespaces can both contain a User class without conflict because they are distinguishable by their full names. You access types in a namespace either by using their fully qualified name or by importing the namespace with a using directive at the top of your file. Namespaces can be nested, creating a hierarchical organization that mirrors your project structure. The .NET Framework itself uses deep namespace hierarchies—for example, System.Collections.Generic or Microsoft.AspNetCore.Mvc —to organize its vast library of types. File-scoped namespaces, introduced in C# 11, simplify syntax by allowing you to declare a single namespace for an entire file with namespace MyNamespace; instead of wrapping all code in braces. This reduces indentation and improves readability, especially for single-namespace files. Example // File-scoped namespace (C# 11+) namespace Company.Services; public class UserService { public void CreateUser(string name) { Console.WriteLine($"Creating user: {name}"); } } // Another file namespace Company.Data; public class UserRepository { public void SaveUser(string name) { Console.WriteLine($"Saving user: {name}"); } } // Usage in main program using Company.Services; using Company.Data; var service = new UserService(); var repo = new UserRepository(); service.CreateUser("Alice"); repo.SaveUser("Alice"); This example demonstrates two separate namespaces ( Company.Services and Company.Data ) each containing different types, and how using directives make them accessible without fully qualified names. Key points to mention Namespaces prevent naming collisions—multiple libraries can define a Logger class as long as they are in different namespaces. The fully qualified name includes the complete namespace path; using directives allow you to omit the prefix for brevity. Namespaces are hierarchical and typically mirror your project folder structure for maintainability (e.g., MyApp.Features.Auth.Services ). File-scoped namespaces (C# 11+) use namespace X; syntax and apply to the entire file, reducing nesting and indentation. Namespaces are purely a logical organization tool; they do not affect runtime performance or memory usage. Common follow-up questions What is the difference between a namespace and a class? A namespace is a logical grouping container; a class is a type that can be instantiated and contains members. How do global using directives work? They allow you to import a namespace once in a central file so it is available to all files in your project. Can namespaces span multiple files? Yes; you can declare the same namespace in several files, and all types from those files are considered part of that namespace. Related interview questions What are global using directives? What is the sealed keyword? Further reading Program.cs, line by line

What are global using directives?

Global using directives are a C# 10+ feature that imports a namespace for your entire project, eliminating the need to repeat using statements in every file. In SDK-style projects (the modern standard), implicit usings automatically add common namespaces like System , System.Linq , and System.Collections.Generic without you writing anything at all. How it works When you declare a global using directive with the global keyword, the compiler makes that namespace available throughout your entire project. You typically place these in a dedicated file (often called GlobalUsings.cs or Usings.cs ) rather than scattering them across multiple files. Implicit usings go a step further. When you create a new SDK-style project (which uses a modern .csproj file ), the project is configured with <ImplicitUsings>enable</ImplicitUsings> . This automatically adds a set of common namespaces based on your project type. For example, a console application automatically includes System , System.IO , System.Threading , and others—you don't have to write them. You can see exactly which namespaces are implicitly included by examining the generated *.GlobalUsings.g.cs file in your obj folder. This feature reduces boilerplate and makes code cleaner, especially in larger projects where the same namespaces appear in every file. Example // GlobalUsings.cs global using System; global using System.Collections.Generic; global using System.Linq; global using MyProject.Models; global using MyProject.Services; // Program.cs (no using statements needed!) var items = new List<string> { "apple", "banana", "cherry" }; var filtered = items.Where(x => x.Length > 5).ToList(); Console.WriteLine($"Found {filtered.Count} items"); The GlobalUsings.cs file declares all namespaces once for the entire project, so Program.cs can use List<T> , LINQ methods, and custom project namespaces without any using statements. Key points to mention C# 10+ feature: Global usings are only available in .NET 6+ projects; they don't work in older Framework projects. Implicit usings are default: New SDK-style projects have implicit usings enabled by default, so you automatically get System , System.Linq , and other common namespaces without writing anything. Centralized management: Putting all global usings in one file makes it easy to see and manage project-wide dependencies. Can be disabled: If you prefer explicit control, you can set <ImplicitUsings>disable</ImplicitUsings> in your .csproj . Scope is project-wide: Global usings apply only to the project they're declared in; they don't leak to other projects that reference it. Common follow-up questions Can I disable implicit usings? Yes—add <ImplicitUsings>disable</ImplicitUsings> to your .csproj if you want full control over every namespace. How do I see what namespaces are implicitly included? Build your project and look at obj/Debug/net8.0/ProjectName.GlobalUsings.g.cs (the exact path depends on your target framework). Are global usings the same as using static ? No— global using imports a namespace, while using static imports static members from a specific type. Related interview questions What is a .csproj file? What does the dotnet CLI do? What is a namespace? Further reading Project to DTOs with Select

What is the difference between == and Equals?

The core difference is that == is an operator that compares references by default for reference types, while Equals() is a virtual method that can be overridden to implement custom equality logic. For value types , == and Equals() both compare values, but strings and records override both operators to compare by value despite being reference types. How it works == is an operator defined on specific types. For most reference types like classes, it performs reference equality by default—checking if both variables point to the same object in memory. However, the behavior of == can be overloaded, and many built-in types do override it. For example, string overloads == to compare the actual text content rather than object references. Equals() is a virtual method inherited from System.Object . By default, it performs reference equality for classes and value equality for structs. Unlike == , Equals() can always be overridden in derived classes to implement custom comparison logic. This makes it more flexible for defining what "equality" means in your domain. Strings override both == and Equals() to compare content. Records, introduced in C# 9, automatically override both to provide value-based equality by comparing their properties rather than their references. Example // Reference type (class) class Person { public string Name { get; set; } public override bool Equals(object obj) { return obj is Person p && p.Name == Name; } public override int GetHashCode() => Name.GetHashCode(); } // Test var person1 = new Person { Name = "Alice" }; var person2 = new Person { Name = "Alice" }; var person3 = person1; // Different references, same content Console.WriteLine(person1 == person2); // False (different objects) Console.WriteLine(person1.Equals(person2)); // True (overridden for value equality) // Same reference Console.WriteLine(person1 == person3); // True (same object) Console.WriteLine(person1.Equals(person3)); // True // String comparison (overloaded == and Equals) var str1 = new string(new[] { 'A', 'B' }); var str2 = new string(new[] { 'A', 'B' }); Console.WriteLine(str1 == str2); // True (content comparison) Console.WriteLine(str1.Equals(str2)); // True This example shows how == defaults to reference equality for custom classes, while Equals() can be overridden to compare by value. Strings behave differently due to their overloaded operators. Key points to mention == is an operator that can be overloaded; by default it compares references for classes and values for structs. Equals() is a virtual method from object that can always be overridden to define custom equality regardless of type. Strings and records override both == and Equals() to provide value-based comparison. If you override Equals() , you should also override GetHashCode() and consider overloading == for consistency. Equals() is safer for polymorphic comparisons because it's virtual and cannot cause unexpected behavior through operator overloading. Common follow-up questions Why should you override GetHashCode() when you override Equals() ? What's the difference between Equals() and ReferenceEquals() ? How do classes and structs differ in their default equality behavior? Related interview questions What is the difference between a value type and a reference type? What is the difference between class and struct in C#? What is a record in C#? Further reading Nullable reference types Value objects

Why are strings immutable in .NET?

Strings in .NET are immutable because once created, their value cannot be changed. Every operation that appears to modify a string actually creates a new string object. This design choice provides significant benefits including thread safety, performance optimization through interning, and safe usage as dictionary keys without worrying about value changes. How it works When you declare a string in .NET, it's stored in memory with a fixed character sequence. The System.String class is sealed and its internal character array cannot be modified after creation. This is enforced at the CLR level—there are no public methods that allow you to change a string's content in place. When you perform operations like concatenation, substring extraction, or case conversion, the CLR creates an entirely new string object with the result and returns a reference to it. The original string remains unchanged in memory. This immutability guarantee means multiple references can safely point to the same string without fear that one caller might change it for another. The .NET runtime also implements string interning —a optimization where identical string literals and many string values are stored only once in the intern pool. Since strings cannot change, the runtime can confidently reuse the same memory location for multiple references, reducing memory pressure and improving performance. Example string original = "Hello"; string modified = original.ToUpper(); Console.WriteLine(original); // Output: Hello (unchanged) Console.WriteLine(modified); // Output: HELLO (new string) // Each operation creates a new string string s1 = "dotnet"; string s2 = s1 + " rocks"; string s3 = s1 + " rocks"; Console.WriteLine(ReferenceEquals(s2, s3)); // Output: True (interned) Console.WriteLine(ReferenceEquals(s1, s2)); // Output: False (different strings) This demonstrates that ToUpper() returns a new string while the original remains "Hello", and identical strings may share the same memory through interning. Key points to mention Thread safety —multiple threads can safely access the same string reference without synchronization because no thread can modify it. Dictionary key safety —strings can be reliably used as dictionary keys since their hash code won't change unexpectedly during the key's lifetime. Performance cost —frequent string modifications through concatenation create many intermediate objects; use StringBuilder for heavy concatenation to avoid this overhead. Memory efficiency —string interning means duplicate strings share memory, reducing overall allocation. Predictable behavior —immutability eliminates entire classes of bugs where unexpected string mutations cause hard-to-trace issues. Common follow-up questions What is the difference between string and StringBuilder , and when should each be used? How does string interning work, and can you control it programmatically? If strings are immutable, why can string interpolation appear to modify a string? Related interview questions When should you use StringBuilder? How do you run tasks in parallel safely? What is string interpolation? Further reading Strings: StringBuilder and interpolation Raw SQL in EF Core, safely

When should you use StringBuilder?

Use StringBuilder when concatenating strings in loops or combining many string pieces. Since strings are immutable in .NET , each concatenation creates a new string object. StringBuilder buffers changes in memory and builds the final string once, dramatically reducing memory allocations and improving performance. How it works Strings in .NET are immutable, meaning once created, they cannot be changed. When you use the + operator or string concatenation, the runtime creates a brand new string object containing the combined result. This is inefficient when done repeatedly because each operation allocates memory, copies data, and discards the old string. StringBuilder, part of the System.Text namespace, maintains an internal character buffer that can grow dynamically. Instead of creating new objects with each addition, StringBuilder appends content to this mutable buffer. Only when you call ToString() does it create the final immutable string. This approach minimizes allocations and garbage collection pressure, resulting in significant performance gains for operations involving many concatenations. Example // Bad: Creates 100 string objects string result = ""; for (int i = 0; i < 100; i++) { result += "Item " + i + ", "; } // Good: Uses StringBuilder efficiently var sb = new StringBuilder(); for (int i = 0; i < 100; i++) { sb.Append("Item ").Append(i).Append(", "); } string result = sb.ToString(); The StringBuilder version performs the same loop but creates only one final string object, while the concatenation version creates approximately 100 intermediate strings that must be garbage collected. Key points to mention StringBuilder is most beneficial in loops where you perform many concatenations; for simple one-time operations, the performance difference is negligible. StringBuilder maintains a resizable internal buffer (capacity) that grows as needed; you can optimize by setting initial capacity if you know the approximate final length. StringBuilder provides Append() , Insert() , Remove() , and Replace() methods for flexible string manipulation before converting to a final string. Modern string interpolation with $"" syntax is optimized by the compiler and can be nearly as efficient as StringBuilder in many cases, but StringBuilder is still preferred for complex loops. StringBuilder is not thread-safe; use lock statements or other synchronization if accessed from multiple threads. Common follow-up questions When should I set StringBuilder's capacity? If you know the approximate final string length beforehand, set capacity in the constructor to avoid internal buffer resizing: new StringBuilder(1000) . Is StringBuilder necessary with string interpolation? String interpolation is compiler-optimized and adequate for most scenarios, but StringBuilder remains superior for dynamic loops where the number of concatenations is unknown or large. What's the performance difference? With 1000+ concatenations, StringBuilder can be orders of magnitude faster; with small operations (2-3 concatenations), the difference is imperceptible. Related interview questions Why are strings immutable in .NET? What is the Base Class Library (BCL)? What is string interpolation? Further reading Strings: StringBuilder and interpolation

What is string interpolation?

String interpolation is a C# feature that lets you embed expressions directly inside string literals using the $ prefix and curly braces {} . For example, $"Hello {name}" produces a cleaner, more readable alternative to older string concatenation or formatting methods. The compiler optimizes interpolated strings at compile time, making them both performant and expressive. How it works When you prefix a string with the $ symbol, the C# compiler treats the string as a template. Any expression inside curly braces {} is evaluated at runtime and its result is inserted into the string. Behind the scenes, the compiler generates efficient code—often calling string.Format() or using interpolated string handlers in modern .NET versions for optimal performance. You can embed simple variables, object properties, method calls, arithmetic expressions, and even complex logic inside the braces. The compiler also supports format specifiers (like {price:C2} for currency) and alignment (like {name,10} for padding). String interpolation respects string immutability in .NET —each interpolated string creates a new string object. Example string name = "Alice"; int age = 30; decimal salary = 75000m; DateTime startDate = new DateTime(2023, 1, 15); // Basic interpolation string greeting = $"Hello, {name}!"; Console.WriteLine(greeting); // Output: Hello, Alice! // Multiple expressions and format specifiers string profile = $"{name} is {age} years old and earns {salary:C2} annually."; Console.WriteLine(profile); // Output: Alice is 30 years old and earns $75,000.00 annually. // Expressions inside braces string summary = $"In {DateTime.Now.Year}, {name} will be {age + 1}."; Console.WriteLine(summary); // Output: In 2024, Alice will be 31. // Alignment and padding string aligned = $"|{name,15}| {age,3}|"; Console.WriteLine(aligned); // Output: | Alice| 30| This example demonstrates basic interpolation, format specifiers like :C2 for currency, embedded expressions like age + 1 , and alignment padding with ,10 syntax. Key points to mention Readability: Interpolation is far more readable than string concatenation ( + ) or string.Format() , reducing cognitive load and errors. Compiler optimization: Modern .NET uses interpolated string handlers to avoid allocating intermediate objects, improving performance compared to older formatting methods. Format specifiers: You can use format specifiers like {price:F2} , {date:yyyy-MM-dd} , or {value:P} for precise formatting without additional method calls. Expression support: Any valid C# expression can go inside braces—method calls, ternary operators, LINQ queries, and arithmetic all work seamlessly. Null-coalescing and null-conditional: You can combine interpolation with null operators like {user?.Name ?? "Guest"} for safe, concise null handling. Common follow-up questions How does string interpolation compare to string.Format() or StringBuilder ? String interpolation is more readable and compile-time optimized; use StringBuilder when building strings in loops to avoid excessive allocations. Can you use interpolation in older .NET versions? String interpolation was introduced in C# 6.0 (.NET Framework 4.6 and .NET Core). Earlier versions require string.Format() or concatenation. What happens if you use $@ together? The $@ prefix combines interpolation ( $ ) with verbatim strings ( @ , which ignore escape sequences), allowing multi-line interpolated strings with literal backslashes and newlines. Related interview questions What is method overloading? Why are strings immutable in .NET? When should you use StringBuilder? Further reading Strings: StringBuilder and interpolation Modern pattern matching in C#

What are nullable value types?

Nullable value types allow value types like int , bool , and DateTime to hold a null value in addition to their normal range of values. The syntax int? is shorthand for Nullable<int> , and you can check whether a value is present using the HasValue property or use the null-coalescing operator ?? to provide a default when null is encountered. How it works By default, value types cannot be null —they always contain a value. For example, an int defaults to 0 , and a bool defaults to false . However, in many real-world scenarios, you need to represent the absence of a value (not just a default). This is where nullable value types come in. When you declare a variable as int? , you're actually creating an instance of the generic struct Nullable<T> . This struct wraps the value type and adds a boolean flag that indicates whether a value is present. Internally, Nullable<int> contains two fields: a bool HasValue property and a int Value property. You interact with nullable value types in three main ways: checking HasValue before accessing Value , using the null-coalescing operator ?? to supply a default, or relying on implicit unwrapping when you're confident a value exists. Boxing a nullable value type with a null value results in a null reference; boxing a nullable value type with a value results in a boxed version of the underlying value (not the Nullable<T> wrapper). Example int? age = null; string? name = null; DateTime? birthDate = new DateTime(1990, 5, 15); // Checking HasValue if (age.HasValue) { Console.WriteLine($"Age: {age.Value}"); } else { Console.WriteLine("Age is unknown"); } // Using null-coalescing operator int displayAge = age ?? 0; Console.WriteLine($"Display age: {displayAge}"); // Using GetValueOrDefault int safeAge = age.GetValueOrDefault(18); Console.WriteLine($"Safe age: {safeAge}"); // Direct comparison with null if (birthDate != null) { Console.WriteLine($"Birth date: {birthDate}"); } This example demonstrates declaring nullable value types, checking for null with HasValue , providing defaults with ?? , and using GetValueOrDefault() to safely extract values. Key points to mention int? is syntactic sugar for Nullable<T> , a generic struct that wraps a value type and a boolean flag. Always check HasValue or use the ?? operator before assuming a nullable value type contains a value; accessing Value when HasValue is false throws an InvalidOperationException . Nullable value types are still value types—they live on the stack (when local variables) and are passed by value, unlike nullable reference types . You can use GetValueOrDefault() to safely extract a value with a fallback, or use pattern matching in C# 7+ with if (age is int ageValue) . Boxing a nullable value type with null produces a null reference; boxing a nullable value type with a value produces a boxed instance of the underlying type. Common follow-up questions What is the difference between int? and int in terms of memory or performance? — A nullable int requires 5 bytes (4 bytes for the int plus 1 byte for the boolean flag), versus 4 bytes for a regular int . The performance cost is minimal but noticeable in performance-critical scenarios or large collections. Can I use nullable value types with null in LINQ or database queries? — Yes, nullable value types are essential for ORM frameworks like Entity Framework; they allow you to model optional columns in databases where a value may genuinely be missing. How do nullable value types differ from null reference types? — Nullable value types are opt-in per variable and use the Nullable<T> wrapper, while nullable reference types (C# 8+) are a static analysis feature that helps prevent null reference exceptions on reference types. Related interview questions What is the difference between a value type and a reference type? What are nullable reference types? What is the difference between stack and heap memory? Further reading Nullable reference types Value objects

What are nullable reference types?

Nullable reference types (NRTs) are a C# feature that enables the compiler to track and warn about potential null reference exceptions before runtime. By enabling this feature, you can annotate reference types with ? to indicate they may be null, while unmarked references are treated as non-nullable and should never be null. This shifts null-safety checking from runtime to compile-time. How it works Nullable reference types were introduced in C# 8.0 as an optional feature and became enabled by default in .NET 6+. When enabled (via the <nullable>enable</nullable> project setting or #nullable enable directive), the compiler performs static analysis to detect when you might dereference a null reference. The system works as follows: a variable declared as string name is considered non-nullable , meaning the compiler expects it to never be null and will warn if you assign null to it or pass it where a non-nullable string is expected. In contrast, string? optionalName is nullable , signaling that the variable may contain null, and the compiler requires you to null-check before dereferencing it. This is purely a compile-time safety mechanism. At runtime, the ? annotation has no effect—it does not prevent null from being assigned. Rather, it communicates intent to the compiler and serves as documentation for other developers. The compiler uses flow analysis to understand when a nullable variable has been checked and is safe to use. Example #nullable enable public class UserService { public void ProcessUser(string? email) { // Compiler warning: Cannot convert null literal to non-nullable string type // string name = email; // ❌ Error // Compiler accepts this after null-check if (email != null) { string name = email; // ✓ Safe Console.WriteLine(name.Length); } // Without null-check, compiler warns // Console.WriteLine(email.Length); // ⚠️ Warning: possible null reference } public string GetUserEmail(User? user) { // Requires null-check before accessing property return user?.Email ?? "unknown@example.com"; } } public class User { public required string Id { get; init; } // Non-nullable, must be provided public string? Email { get; set; } // Nullable, may be null } This example shows how the compiler warns when assigning a nullable reference to a non-nullable variable without a null-check, and how the null-conditional operator ?. safely handles potential null values. Key points to mention Compile-time feature: NRTs are a static analysis tool; they do not affect runtime behavior or IL code generation. Opt-in (historically): While enabled by default in newer templates, projects can enable or disable NRTs per file or project-wide via the <nullable> project setting. Flow-sensitive: The compiler tracks whether a nullable variable has been null-checked within a code path, allowing you to use it safely after the check without additional casts. Works with nullable value types : NRTs apply similar logic to reference types that nullable value types provide for structs. Helps prevent NullReferenceException: By catching potential null dereferences at compile-time, NRTs reduce a common class of runtime errors. Common follow-up questions Can you disable nullable reference types in a .NET 6+ project, and why might you want to? How do nullable reference types interact with inheritance and interface implementation? What is the difference between the null-coalescing operator ?? and the null-conditional operator ?. when working with NRTs? Related interview questions What is the difference between a value type and a reference type? What are nullable value types? What is the difference between class and struct in C#? Further reading Nullable reference types

What do the ?. and ?? operators do?

The ?. operator (null-conditional operator) safely accesses members on an object only when that object is not null, returning null if the object is null. The ?? operator (null-coalescing operator) returns a fallback value when the left operand is null, and ??= (null-coalescing assignment) assigns a value only when the variable is currently null. Together, these operators provide a concise, readable way to handle null scenarios without explicit null checks. How it works The ?. operator allows you to chain member access (properties, methods, indexers) without throwing a NullReferenceException . If the object is null, the entire expression short-circuits and returns null. This is especially useful when working with nested objects or method chains where any level might be null. The ?? operator evaluates the right operand only if the left operand is null. This is called null coalescing and provides a clean syntax for supplying default values. It works with both reference and nullable value types. The ??= operator (introduced in C# 8.0) combines assignment with null coalescing. It assigns the right-hand value to the left-hand variable only if that variable is currently null, useful for lazy initialization patterns. Example public class User { public string? Name { get; set; } public Address? Address { get; set; } } public class Address { public string? City { get; set; } } // Usage User? user = GetUser(); // might be null // ?. operator - safe navigation string? city = user?.Address?.City; // Returns null if user or Address is null // ?? operator - null coalescing string displayName = user?.Name ?? "Unknown"; // ??= operator - null coalescing assignment user ??= new User { Name = "Guest" }; // Assigns only if user is null // Combining them string message = user?.Address?.City ?? "No city available"; Console.WriteLine(message); // Prints city name or "No city available" This example demonstrates all three operators: safely accessing nested properties with ?. , providing fallback values with ?? , and conditionally assigning with ??= . Key points to mention The ?. operator returns null if the object is null; otherwise, it proceeds with the member access. It prevents NullReferenceException from being thrown. The ?? operator is right-associative, so a ?? b ?? c evaluates as a ?? (b ?? c) , allowing easy chaining of fallback values. The ??= operator only assigns if the left side is null, making it perfect for lazy initialization and default value setup patterns. These operators work with nullable reference types (available with the nullable reference types feature in C# 8.0+), improving code safety by distinguishing between nullable and non-nullable references at compile time. You can combine ?. with indexers and methods: list?[0] or person?.GetName() are both valid. Common follow-up questions What is the difference between ?? and the ternary operator? (The ternary operator requires an explicit condition, while ?? specifically checks for null.) Can you use ?. with methods that have side effects? (Yes, but be cautious—the method only executes if the object is not null.) What does user?.Method()?. Property do? (It calls Method() on user if user is not null, then accesses Property only if the returned object is not null.) Related interview questions What is the difference between First and FirstOrDefault? What is an enum? Further reading Null object pattern

An enum (enumeration) is a named set of integral constants that allows you to define a group of related constant values with meaningful names. Instead of using magic numbers or strings throughout your code, enums provide type safety, readability, and maintainability. They are value types (structs) that inherit from System.Enum and are compiled into integer values at runtime. How it works When you declare an enum, you define a new type with a fixed set of named constants. Each constant has an underlying integral value—by default, an int starting at 0 and incrementing. The compiler treats each enum member as a constant and enforces that only valid enum values can be used in code. Enums provide several benefits: they replace magic numbers with self-documenting names, enable compile-time validation (you can't accidentally pass an invalid status), and work seamlessly with switch statements. For combinable values (like permissions or flags), the [Flags] attribute lets you combine multiple enum values using bitwise operations, treating each member as a power of two. Under the hood, enums are just syntactic sugar over integers. When you reference an enum member, the compiler substitutes its underlying integer value. This makes enums both type-safe at compile time and efficient at runtime. Example // Simple enum for order status public enum OrderStatus { Pending = 0, Processing = 1, Shipped = 2, Delivered = 3, Cancelled = 4 } // Flags enum for file permissions [Flags] public enum FilePermissions { None = 0, Read = 1, Write = 2, Execute = 4, Delete = 8 } class Program { static void Main() { // Simple enum usage OrderStatus status = OrderStatus.Processing; Console.WriteLine($"Order status: {status}"); // Output: Order status: Processing // Switch with enum if (status == OrderStatus.Processing) Console.WriteLine("Your order is being processed."); // Flags enum usage FilePermissions perms = FilePermissions.Read | FilePermissions.Write; Console.WriteLine($"Has read: {perms.HasFlag(FilePermissions.Read)}"); // Output: True Console.WriteLine($"Has execute: {perms.HasFlag(FilePermissions.Execute)}"); // Output: False } } This example shows a simple enum for order statuses and a [Flags] enum for file permissions that can be combined using bitwise OR and checked with HasFlag() . Key points to mention Enums are value types derived from System.Enum with an underlying integral type (default is int ); you can also use byte , short , long , etc. They provide type safety—the compiler prevents invalid values and makes code self-documenting compared to magic numbers or strings. Use [Flags] attribute for enums representing combinable bit flags; each value should be a power of two (1, 2, 4, 8, etc.). Enums work efficiently in switch statements and can be converted to/from their underlying integer values with casting or Enum.Parse() . Unlike const fields, enum members are implicitly static and cannot be changed after compilation. Common follow-up questions Can you change an enum's underlying type, and why would you? What is the difference between a simple enum and a [Flags] enum? How do you parse a string into an enum value, and how do you convert an enum to a string? Related interview questions What is the difference between const and readonly? What are generics?

Generics are a language feature that allows you to write type-safe, reusable code by using type parameters (placeholders) instead of specific types. A generic class or method works with any data type while maintaining compile-time type checking and avoiding the need for casting or boxing and unboxing . How it works Generics use angle brackets with a type parameter (usually T , but can be any name) to define a placeholder for a concrete type. When you create an instance or call a method, you specify what type should replace that parameter. The compiler generates type-specific code at compile time, so you get both flexibility and safety. Instead of writing separate classes for ListOfInts , ListOfStrings , and ListOfObjects , you write one generic List<T> . The runtime and compiler handle the rest. This eliminates: Casting: No need to cast retrieved items back to their original type. Boxing overhead: Value types don't get boxed when stored in generic containers. Type errors: The compiler catches type mismatches at build time, not runtime. You can constrain generics too. For example, <T where T : IComparable> ensures T implements IComparable , so you can safely call comparison methods. Example // Generic class that works with any type public class Container<T> { private T _value; public void Set(T value) => _value = value; public T Get() => _value; } // Generic method public static void PrintArray<T>(T[] items) { foreach (var item in items) Console.WriteLine(item); } // Usage var intContainer = new Container<int>(); intContainer.Set(42); Console.WriteLine(intContainer.Get()); // Output: 42 var stringContainer = new Container<string>(); stringContainer.Set("Hello"); Console.WriteLine(stringContainer.Get()); // Output: Hello PrintArray(new[] { 1, 2, 3 }); PrintArray(new[] { "a", "b", "c" }); The Container<T> class works with any type—integers, strings, objects—without casting. When you create Container<int> , the compiler generates type-safe code just for integers. Key points to mention Generics provide type safety at compile time, catching errors early rather than at runtime. They eliminate casting —you retrieve items in their original type without as or (Type) . They improve performance by avoiding boxing of value types; an int in a List<int> stays on the stack or inline in memory. Generics work with constraints (e.g., <T where T : class> , <T where T : struct> , <T where T : IComparable> ) to restrict what types can be used. List<T> , Dictionary<TKey, TValue> , and IEnumerable<T> are built-in generic types you use constantly in .NET. Common follow-up questions What is the difference between generics and object ? — Using object requires casting every time you retrieve a value and causes boxing for value types, losing type safety and performance. Generics avoid both. Can you have multiple type parameters? — Yes: Dictionary<TKey, TValue> or Tuple<T1, T2, T3> use multiple parameters separated by commas. What is covariance and contravariance? — Advanced topic: out T (covariance) allows IEnumerable<Derived> to be used where IEnumerable<Base> is expected; in T (contravariance) does the opposite. Related interview questions What is boxing and unboxing? What is ReadyToRun? What is the difference between record class and record struct? Further reading Generics and constraints that pay off Health checks that mean something

What are generic constraints?

Generic constraints are restrictions placed on type parameters in generic classes, methods, or interfaces that specify what types are allowed to be substituted. They enable you to write type-safe generic code by ensuring that only types meeting certain criteria can be used, allowing the compiler to verify that specific operations or member accesses are valid. Common constraints include where T : class , where T : struct , where T : new() , and where T : SomeInterface . How it works Without constraints, a generic type parameter T is treated as the most basic type possible—essentially object . This means you can only call methods that exist on object (like ToString() , GetHashCode() , etc.). Constraints tell the compiler and developers what assumptions can be safely made about T . When you apply a constraint using the where keyword, the compiler enforces it at compile time. If someone tries to use a type that doesn't satisfy the constraint, they'll get a compilation error rather than a runtime failure. This allows you to call methods specific to the constrained type without casting or reflection. Multiple constraints can be combined. For example, where T : class, IComparable, new() means T must be a reference type that implements IComparable and has a parameterless constructor. There are also base type constraints (like where T : Animal ) and unmanaged constraints for low-level programming. Example // Generic repository with constraints public class Repository<T> where T : class, new() { private List<T> _items = new(); public void Add(T item) { if (item != null) _items.Add(item); } public T CreateNew() { return new T(); // Valid because of new() constraint } } public class User { public string Name { get; set; } } // Usage var userRepo = new Repository<User>(); var newUser = userRepo.CreateNew(); // Works fine // var stringRepo = new Repository<string>(); // Compiler error: string doesn't satisfy constraints (can't instantiate with new()) This example demonstrates a repository pattern where T must be a reference type with a parameterless constructor, allowing us to safely call new T() and work with objects predictably. Key points to mention Compile-time safety: Constraint violations are caught at compilation, not at runtime, preventing type-related errors before deployment. Reference vs. value types: The class constraint restricts to reference types , while struct restricts to value types, giving you control over object allocation and behavior. Interface and base type constraints: You can require that T implements a specific interface (e.g., where T : IComparable ) or derives from a base class, enabling you to call interface or base class methods confidently. Constructor constraint: new() ensures T has a parameterless constructor, allowing the generic code to instantiate new instances. Multiple constraints: Constraints are combined with commas and follow a specific order: base type/class/struct first, then interfaces, then new() last. Common follow-up questions Can you have multiple constraints on a single type parameter? Yes, you can combine them (e.g., where T : class, IDisposable, new() ), but the order matters and there are limitations—for example, you cannot have both class and struct constraints together. What is the difference between where T : class and where T : struct ? class restricts to reference types, while struct restricts to value types , affecting memory allocation and null-ability. Can you use constraints with multiple type parameters? Yes, each type parameter can have its own set of constraints; for example, public class Pair<T, U> where T : class where U : struct applies different constraints to different parameters. Related interview questions What is the difference between a value type and a reference type? What is the difference between class and struct in C#? What is a static class?

What is the difference between an array and a List ?

Arrays have a fixed size determined at creation and are slightly faster due to direct memory allocation, while List<T> is a dynamic collection that grows automatically as you add elements. List<T> provides convenient methods like Add , Remove , and Insert , whereas arrays require manual index management. For most modern C# applications, List<T> is the preferred choice because its dynamic nature and rich API outweigh the minor performance difference. How it works An array is a contiguous block of memory with a predetermined length. Once created, its size cannot change—if you need more space, you must create a new array and copy all elements over manually. This fixed nature makes array access extremely fast because the runtime can calculate the memory address of any element in constant time. List<T> is a generic wrapper around an internal array. When you create a List<T> , it allocates an internal array with initial capacity (typically 4 elements). As you add items beyond this capacity, List<T> automatically creates a larger internal array (usually doubling the capacity) and copies elements to it. This dynamic resizing incurs a small overhead, but it happens infrequently enough that most operations remain very efficient. Both arrays and List<T> maintain elements in memory sequentially, providing fast index-based access. The key difference lies in flexibility: arrays demand that you know the exact size upfront, while List<T> adapts to your needs. Example // Array: fixed size int[] numbers = new int[5]; // Must specify size upfront numbers[0] = 10; numbers[1] = 20; // numbers[5] = 30; // IndexOutOfRangeException! // List: dynamic size List numbersList = new(); // No size needed numbersList.Add(10); numbersList.Add(20); numbersList.Add(30); // Grows automatically numbersList.Insert(1, 15); // Easy to insert at specific position numbersList.Remove(20); // Easy to remove by value Console.WriteLine($"Array length: {numbers.Length}"); // 5 Console.WriteLine($"List count: {numbersList.Count}"); // 4 This example shows that arrays require you to specify length upfront and crash if you exceed bounds, while List<T> grows seamlessly and provides convenient methods for common operations. Key points to mention Fixed vs. Dynamic: Arrays have immutable length; List<T> grows and shrinks automatically. Performance: Arrays are marginally faster for pure access patterns; List<T> adds minimal overhead through internal resizing, which is amortized across many operations. API: List<T> offers rich methods ( Add , Remove , Insert , Contains , ForEach ) that require manual loops with arrays. Memory efficiency: Arrays use only as much memory as needed; List<T> may allocate more internal capacity than current item count to reduce resizing frequency. Use cases: Use arrays when size is truly fixed (e.g., a deck of 52 cards); use List<T> for collections of unknown or variable size. Common follow-up questions "What happens internally when a List exceeds its capacity?" The list doubles its internal array capacity, allocates a new array, copies all elements, and discards the old array. This is an O(n) operation, but it happens rarely enough that the amortized cost per Add is still O(1) . "When would you use an array instead of List<T>?" Use arrays for fixed-size collections, performance-critical code paths where the small overhead matters, interop scenarios, or when working with legacy code. Modern C# favors List<T> or IEnumerable<T> for flexibility. "How does List<T> compare to other collections like Dictionary or HashSet?" List<T> maintains insertion order and allows duplicates with fast index access; Dictionary<K, V> uses key-value pairs; HashSet<T> removes duplicates and offers fast lookups. Choose based on your access patterns. Related interview questions What is inlining and how do you influence it? What is the role of EndpointDataSource? How do you manage zero-downtime database migrations?

What is a Dictionary ?

A Dictionary<TKey, TValue> is a generic, hash-based collection that stores key-value pairs and provides O(1) average-time lookups by key. It is part of the System.Collections.Generic namespace and is the most commonly used collection for fast data retrieval when you need to associate unique keys with values. Unlike HashSet<T> , which stores only keys, a Dictionary stores both a key and its corresponding value. How it works A Dictionary uses a hash table internally. When you add a key-value pair, the key is passed through a hash function to compute a hash code, which determines where in an internal array the pair is stored. This hash-based approach enables constant-time (O(1)) average lookup, insertion, and deletion. The dictionary maintains an array of "buckets." If two different keys hash to the same bucket (a hash collision), the dictionary uses chaining or linear probing to store both entries. Modern implementations typically use chaining with linked lists or similar techniques. Keys must be unique; attempting to add a duplicate key will throw an ArgumentException . Values, however, can be duplicated. The dictionary is mutable—you can add, remove, or update entries after creation. For thread-safe scenarios, consider using ConcurrentDictionary<TKey, TValue> from System.Collections.Concurrent . Example var users = new Dictionary<int, string> { { 1, "Alice" }, { 2, "Bob" }, { 3, "Charlie" } }; // Lookup by key (may throw KeyNotFoundException) string name = users[1]; // "Alice" // Safe lookup using TryGetValue if (users.TryGetValue(2, out string? value)) { Console.WriteLine($"Found: {value}"); } // Add or update users[4] = "Diana"; users[1] = "Alicia"; // Updates existing key // Iterate over key-value pairs foreach (var kvp in users) { Console.WriteLine($"{kvp.Key}: {kvp.Value}"); } // Remove users.Remove(2); This example creates a dictionary mapping user IDs to names, demonstrates safe lookups with TryGetValue , shows updates, iteration, and removal. Key points to mention O(1) average lookup: Fast key-based retrieval makes dictionaries ideal for caches, lookups, and associations. Use TryGetValue to avoid exceptions: Indexer access ( dict[key] ) throws KeyNotFoundException if the key is missing; TryGetValue(key, out var value) is safer. Keys must be unique and override GetHashCode/Equals: Keys must implement meaningful GetHashCode() and Equals() for correct behavior with custom types. Mutable and not thread-safe: Modifying a dictionary while iterating throws InvalidOperationException ; use ConcurrentDictionary<TKey, TValue> for multi-threaded scenarios. Common follow-up questions What is the difference between Dictionary and Hashtable? Hashtable is a non-generic, legacy collection that requires boxing/unboxing. Dictionary is generic, type-safe, and faster. How do hash collisions affect performance? Excessive collisions degrade average lookup time. A good hash function minimizes collisions; the dictionary automatically resizes when load factor exceeds a threshold. Can I use a custom class as a key? Yes, but it must override GetHashCode() and Equals() correctly. Immutable types are safer for keys to prevent hash code changes after insertion. Related interview questions What are keyed services in .NET 8? Why are strings immutable in .NET? What is a HashSet<T>?

What is the difference between IEnumerable and IList?

IEnumerable<T> is a contract for forward-only iteration through a collection, while IList<T> extends that capability with random access via indexing, a Count property, and the ability to add, remove, or modify elements. In other words, every IList<T> is an IEnumerable<T>, but not every IEnumerable<T> is an IList<T>. How it works IEnumerable<T> defines a single method: GetEnumerator() , which returns an IEnumerator<T>. This enumerator lets you move forward through items one at a time using MoveNext() and Current . You cannot go backward, jump to a specific position, or modify the collection during iteration (in most cases). This minimal interface is lightweight and can represent virtually any data source: arrays, lists, database queries, files, or even infinite streams. IList<T>, on the other hand, inherits from IEnumerable<T>> and ICollection<T>, adding: this[int index] — get or set an element by position int IndexOf(T item) — find an element's position void Insert(int index, T item) — insert at a specific position void RemoveAt(int index) — remove by position Count property — know how many elements exist The trade-off is clear: IEnumerable<T> is simpler and more flexible (it can wrap lazy-evaluated streams), while IList<T> is more powerful but requires the underlying collection to support random access and modification. Example // IEnumerable - iteration only IEnumerable<int> numbers = GetNumbers(); foreach (var n in numbers) { Console.WriteLine(n); // Works } // var first = numbers[0]; // ❌ Compile error: no indexer // numbers.Add(5); // ❌ Compile error: no Add method // IList - full control IList<int> list = new List<int> { 1, 2, 3 }; Console.WriteLine(list[0]); // ✅ 1 - direct access list.Add(4); // ✅ Now { 1, 2, 3, 4 } list.RemoveAt(1); // ✅ Now { 1, 3, 4 } foreach (var n in list) // ✅ IList is also IEnumerable { Console.WriteLine(n); } IEnumerable<int> GetNumbers() => Enumerable.Range(1, 3); // Deferred execution This example shows that IList gives you indexing and modification, while IEnumerable only lets you iterate; IList is always usable where IEnumerable is expected. Key points to mention IEnumerable<T> is the base contract; IList<T> inherits from it and adds indexing and modification capabilities. Use IEnumerable<T> when you only need to read and iterate; it's cheaper and works with LINQ queries, lazy sequences, and streams. Use IList<T> when you need random access, counting, inserting, or removing elements; concrete types like List<T> and array implementations support it. IEnumerable<T> does not guarantee the collection is re-enumerable; some sources (like query results) may be consumed once. Methods accepting IEnumerable<T> are more flexible and reusable; methods accepting IList<T> are more specialized but more powerful. Common follow-up questions What about ICollection<T>? — It sits between them, adding Count, Add, Remove, and Contains, but no indexing. IList inherits from both ICollection and IEnumerable. Can I use LINQ on both? — Yes, both work with LINQ because LINQ extension methods target IEnumerable<T>. However, .ToList() materializes the sequence into an IList<T>. What about HashSet<T> ? — It implements IEnumerable<T> and ICollection<T>, but not IList<T> (no indexing, no guaranteed order). Related interview questions What is a HashSet<T>? What is a Dictionary<TKey,TValue>?

A HashSet<T> is an unordered collection of unique elements that uses a hash table for fast lookups and insertions. It enforces uniqueness automatically and provides O(1) average-case performance for Contains, Add, and Remove operations, making it ideal for deduplication and membership testing. How it works HashSet<T> uses a hash table data structure internally. When you add an item, it computes a hash code for that item and stores it in a bucket based on that hash. When you check if an item exists (Contains), it computes the same hash code and checks that bucket—without scanning the entire collection. This gives you constant-time lookups. The key characteristic is uniqueness . If you try to add a duplicate item, the Add method returns false and the item is not added again. Equality is determined by the item's GetHashCode() and Equals() methods. Two objects are considered the same if they have the same hash code and return true from Equals(). Unlike Dictionary<TKey,TValue> , a HashSet has no key-value pairs—it just stores values. It's also unordered, so you cannot rely on iteration order. Example // Deduplication and membership testing HashSet<int> uniqueNumbers = new HashSet<int> { 1, 2, 3, 4, 5 }; // Fast Contains check if (uniqueNumbers.Contains(3)) { Console.WriteLine("3 is in the set"); } // Add only adds if not present uniqueNumbers.Add(3); // Returns false, not added uniqueNumbers.Add(6); // Returns true, added // Remove uniqueNumbers.Remove(5); // Set operations HashSet<int> other = new HashSet<int> { 3, 6, 7 }; uniqueNumbers.IntersectWith(other); // Keep only common elements Console.WriteLine(string.Join(", ", uniqueNumbers)); // Output: 3, 6 This example demonstrates adding unique numbers, checking membership in constant time, and performing set operations like intersection—all operations that would be inefficient with a List. Key points to mention HashSet enforces uniqueness; duplicate adds are silently ignored (Add returns false) Provides O(1) average-case performance for Add, Remove, and Contains—much faster than List for membership tests Unordered collection; iteration order is not guaranteed and may change as the set is modified Supports efficient set operations: Union, Intersect, Except, SymmetricExcept, IsSubsetOf, IsSupersetOf Items must implement GetHashCode() and Equals() correctly for proper behavior; custom types should override both methods Common follow-up questions How does HashSet handle hash collisions? — Multiple items with the same hash code are stored in the same bucket using a linked list or chain; Equals() is used to find the exact item within the bucket. What's the difference between HashSet and List for checking if an item exists? — HashSet.Contains() is O(1) average; List.Contains() is O(n) because it must scan every element. For large collections and frequent lookups, HashSet is far superior. When should I use HashSet versus Dictionary? — Use HashSet when you only need to store and check for unique values; use Dictionary when you need to store key-value pairs and look up values by key. Related interview questions What is a Dictionary<TKey,TValue>? How do you use the Channel-based background queue pattern? Further reading Unit testing with xUnit

LINQ (Language Integrated Query) is a .NET feature that provides a unified, strongly-typed syntax for querying data from any source—collections, databases, XML, or web services. It introduces standard query operators like Where, Select, GroupBy, and OrderBy directly into the C# language, eliminating the need to learn different query syntaxes for different data sources. How it works LINQ bridges the gap between the imperative world of C# and the declarative world of data queries. When you write a LINQ query, the compiler translates it into method calls on objects that implement specific interfaces like IEnumerable or IQueryable . For in-memory collections, LINQ to Objects works directly with IEnumerable<T> . For databases, LINQ providers (such as Entity Framework Core) translate your query into SQL before executing it on the server. The key benefit is that you write the same query syntax regardless of the underlying data source—the provider handles the translation. LINQ supports two syntaxes: query syntax (resembling SQL) and method syntax (using lambda expressions and extension methods). Both are equally powerful; the choice depends on readability and preference. You can also learn more about deferred execution in LINQ , which means queries often don't execute until you enumerate the results. Example var employees = new List<Employee> { new(1, "Alice", 75000), new(2, "Bob", 65000), new(3, "Charlie", 85000) }; // Query syntax var highEarners = from emp in employees where emp.Salary > 70000 orderby emp.Name select emp.Name; // Method syntax (equivalent) var highEarnersMethod = employees .Where(e => e.Salary > 70000) .OrderBy(e => e.Name) .Select(e => e.Name); foreach (var name in highEarners) Console.WriteLine(name); // Output: Alice, Charlie record Employee(int Id, string Name, decimal Salary); This example demonstrates querying an in-memory list to find employees earning more than £70,000, ordered by name, returning only their names. Key points to mention Language integration: LINQ is built into C# syntax, not a separate library, making queries feel natural and IntelliSense-friendly. Provider-based: Different LINQ providers handle different data sources—LINQ to Objects, LINQ to SQL, Entity Framework (Entity Framework Core), LINQ to XML—using the same query syntax. Strongly typed: Queries are checked at compile time, catching errors early and enabling refactoring with confidence. Composable: You can chain multiple operators together, building complex queries incrementally. Query and method syntax are interchangeable : Choose whichever reads better for your use case. Common follow-up questions What is the difference between IEnumerable and IQueryable in LINQ? How does LINQ to SQL differ from LINQ to Objects? What are deferred execution and eager execution in LINQ, and when would you use ToList() or ToArray() ? Related interview questions What is the Base Class Library (BCL)? What is the difference between LINQ query syntax and method syntax? What is deferred execution in LINQ? Further reading LINQ performance traps

What is the difference between LINQ query syntax and method syntax?

LINQ query syntax and method syntax are two different ways to write the same LINQ queries. Query syntax resembles SQL with keywords like from , where , and select , while method syntax chains extension methods like Where() , Select() , and OrderBy() . Both compile to identical IL code—the compiler translates query syntax into method calls behind the scenes. How it works Query syntax is a declarative language integrated into C# that mimics SQL. It uses contextual keywords and reads naturally from left to right, making complex queries more readable. The compiler parses this syntax and converts it into method calls at compile time. Method syntax (also called fluent syntax) chains extension methods directly on collections. Each method returns an IEnumerable or IQueryable , allowing you to chain operations. This approach is more functional and gives you access to every overload of each method. Both syntaxes ultimately generate the same delegates and lambda expressions. The choice between them is largely about readability and personal preference. Method syntax offers more flexibility because you can use any extension method available, while query syntax is limited to keywords the compiler recognizes. Many developers mix both approaches in the same codebase—using query syntax for simple filters and method syntax for complex operations. Example var employees = new List<Employee> { new Employee { Id = 1, Name = "Alice", Department = "IT", Salary = 75000 }, new Employee { Id = 2, Name = "Bob", Department = "HR", Salary = 55000 }, new Employee { Id = 3, Name = "Charlie", Department = "IT", Salary = 85000 } }; // Query syntax var queryResult = from emp in employees where emp.Department == "IT" orderby emp.Salary descending select new { emp.Name, emp.Salary }; // Method syntax (identical result) var methodResult = employees .Where(emp => emp.Department == "IT") .OrderByDescending(emp => emp.Salary) .Select(emp => new { emp.Name, emp.Salary }); foreach (var item in queryResult) { Console.WriteLine($"{item.Name}: ${item.Salary}"); } Both approaches filter IT employees, sort by salary in descending order, and project only the name and salary—they compile to identical executable code. Key points to mention Query syntax and method syntax produce the same compiled IL code; the difference is purely syntactic. Query syntax reads more like SQL and is often preferred for complex filtering and joins; method syntax provides more control and flexibility. LINQ deferred execution applies to both syntaxes—the query doesn't run until enumerated. Method syntax allows access to all overloads and gives you granular control; query syntax is limited to recognized keywords. Most real-world codebases mix both styles depending on what makes the code more readable in context. Common follow-up questions Can you mix query and method syntax in one LINQ statement? Yes—you can start with query syntax and chain method calls, or vice versa. The compiler will handle the mix seamlessly. Which syntax performs better? Both compile to identical code, so there is no performance difference. The choice is purely about readability and maintainability. When should I use one over the other? Use query syntax for readable, multi-step filtering and joins; use method syntax for complex transformations, grouping, or when you need specific method overloads. Related interview questions What is method overloading? What is LINQ? What is an extension method? Further reading LINQ performance traps Extension methods done right

320 questions · Backend Engineering

300+ .NET Interview Questions and Answers

Prepare with 320 .NET interview questions, detailed answers, C# code examples and diagrams, ordered from beginner through experienced to expert.

#.NET #Csharp #aspnetcore #interview

300+ .NET Interview Questions and Answers

This guide collects 320 .NET interview questions with answers, from the basics every junior developer should know to the runtime internals and architecture topics asked in senior and lead interviews. Every answer is written to be said out loud in an interview: a clear explanation first, then an example in C#, then the follow-ups interviewers usually ask.

How the questions are organized

Questions are numbered in order of difficulty, so you can work from the top or jump straight to your level.

Beginner — questions 1–110 (110)
Experienced — questions 111–220 (110)
Expert — questions 221–320 (100)

Topics covered

Performance and memory (59 questions) — start with What is the CLR?
ASP.NET Core (56 questions) — start with What is ASP.NET Core?
Async and concurrency (43 questions) — start with What is the Base Class Library (BCL)?
Architecture and design (39 questions) — start with What is a record in C#?
Entity Framework Core (38 questions) — start with What is the difference between LINQ query syntax and method syntax?
Security (30 questions) — start with What is the CLR?
Testing (15 questions) — start with What does the dotnet CLI do?
Deployment and containers (14 questions) — start with What is an assembly in .NET?
Dependency injection (12 questions) — start with What is a primary constructor in C# 12?
LINQ (7 questions) — start with What is the Base Class Library (BCL)?
Real-time and gRPC (4 questions) — start with What is SignalR?

How to use this guide

Answer each question aloud before reading the answer, then compare.
Run the code examples in a scratch project — interviewers often ask you to change them.
Follow the related-question links at the end of each answer to cover a topic end to end.
For senior roles, prepare a real example from your own work for every architecture and performance question.

Go deeper on the blog

01What is .NET?
Beginner
.NET is a free, open-source, cross-platform developer platform created by Microsoft for building applications across web, desktop, mobile, cloud, and IoT environments. It provides developers with a runtime environment, a comprehensive standard library, and language options like C#, F#, and Visual Basic to write modern applications that run on Windows, Linux, and macOS.

How it works

.NET operates on a managed execution model powered by the Common Language Runtime (CLR). When you write C# code, the compiler translates it into an intermediate language called Common Intermediate Language (CIL). When your application runs, the CLR's Just-In-Time (JIT) compiler converts CIL into native machine code specific to the operating system. This abstraction layer provides several benefits: automatic memory management through garbage collection, platform independence, and security features built into the runtime.

.NET includes the Base Class Library (BCL), a massive collection of pre-built types and APIs for common tasks like file I/O, networking, collections, and data processing. Modern .NET (versions 5+) is unified and cross-platform by default, making it easy to share code between a web server running on Linux and a desktop application on Windows. The SDK provides command-line tools, NuGet package management, and integration with Visual Studio for a complete development experience.

Example
csharp
```
using System;

class Program
{
    static void Main()
    {
        string message = "Hello, .NET!";
        int version = 8;
        
        Console.WriteLine($"{message} Running on .NET {version}");
        Console.WriteLine($"Timestamp: {DateTime.UtcNow:O}");
    }
}
```
This simple console application demonstrates .NET fundamentals: it uses C# language features (string interpolation), the BCL (Console and DateTime), and outputs a message with the current timestamp—all managed by the runtime.

Key points to mention
- Free and open-source: .NET is licensed under MIT and actively developed on GitHub, with contributions from Microsoft and the community.
- Cross-platform: Write once and run on Windows, Linux, and macOS without recompilation.
- Managed runtime: The CLR handles memory management, type safety, and security automatically.
- Unified platform: Use the same .NET runtime for web (ASP.NET Core), desktop (WinForms, WPF), mobile (MAUI), and cloud applications.
- Strong ecosystem: Access to NuGet packages, extensive documentation, and a large developer community.
Common follow-up questions
- What is the difference between .NET Framework and modern .NET?
- How does garbage collection work in .NET?
- What is ASP.NET Core and how does it relate to .NET?
Related interview questions
.NETCsharp

02What is the difference between .NET Framework, .NET Core and modern .NET?

Beginner

Direct Answer: .NET Framework is the original Windows-only runtime released in 2002. .NET Core, launched in 2016, was Microsoft's cross-platform rewrite. Starting with .NET 5 (2020), they unified into one platform simply called ".NET" with annual releases, LTS support every two years, and full cross-platform support for Windows, Linux, and macOS.

How it works

.NET Framework was tightly integrated with Windows and relied on the Windows Runtime environment. This made it powerful for Windows desktop and server applications but impossible to run on other operating systems.

Microsoft recognized the industry shift toward cloud, containerization, and cross-platform development. In 2016, they created .NET Core as a ground-up rewrite: open-source, modular, and designed to run on any OS. For several years, both platforms coexisted—enterprises stayed on Framework for legacy systems while new projects chose Core for flexibility.

By 2020, .NET Core had matured enough to become the single, unified ".NET" platform. .NET Framework is now in maintenance mode (no new features, security updates only). Modern .NET emphasizes fast iteration with yearly releases, LTS versions every two years for production stability, and a lean, composable toolchain.

Today, all new .NET development uses modern .NET (currently .NET 8 or 9), which includes ASP.NET Core, Entity Framework Core, and a rich ecosystem of NuGet packages.

Example

csharp

// Modern .NET (8+) – works on Windows, Linux, macOS
using System;

var message = "Hello from .NET 8!";
Console.WriteLine(message);
Console.WriteLine($"OS: {System.Runtime.InteropServices.RuntimeInformation.OSDescription}");
Console.WriteLine($"Runtime: {System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription}");

This code runs identically on any platform—try it on Windows PowerShell, a Linux terminal, or macOS. .NET Framework code would only work on Windows; .NET Core 3.1 would work cross-platform but with older APIs.

Key points to mention

.NET Framework (2002–present): Windows-only, in maintenance mode, used for legacy enterprise systems.
.NET Core (2016–2019): The experimental, open-source cross-platform foundation that proved the concept.
Modern .NET (5+): Unified platform with yearly releases, LTS versions, cloud-native tooling, and full OS support.
Migration path: Framework → Core → modern .NET; most new production code targets .NET 8 LTS or .NET 9 STS.
.NET Framework will receive security patches indefinitely but no new features; modern .NET is the strategic investment.

Comparison table

Aspect	.NET Framework	.NET Core (3.1)	Modern .NET (5+)
OS Support	Windows only	Windows, Linux, macOS	Windows, Linux, macOS
Release Model	Infrequent major versions	Annual releases	Annual releases + LTS every 2 years
Open Source	Partial	Full (GitHub)	Full (GitHub)
Status	Maintenance mode	End of life (Jan 2022)	Active development
Cloud Ready	Legacy approach	Modern containers	Cloud-native, optimized
Performance	Good for Windows	Fast startup	Industry-leading speed

What is the difference between .NET Framework, .NET Core and modern .NET diagram

Common follow-up questions

"Should we migrate our .NET Framework app?" – Yes, if it's actively used. Modern .NET offers better performance, security, and cloud support. Plan for refactoring, especially UI code (Windows Forms works, but WPF requires careful porting).
"What's the difference between .NET 8 and .NET 9?" – .NET 8 is LTS (supported until Nov 2026); .NET 9 is STS (18 months). Pick LTS for production stability, STS if you want cutting-edge features.
"Can .NET Framework and modern .NET coexist?" – Yes, on the same machine. They're separate runtimes. Legacy services can stay on Framework while new microservices run on modern .NET.

03What is the CLR?
Beginner
The Common Language Runtime (CLR) is the virtual machine that executes all .NET code. It provides essential services like Just-In-Time (JIT) compilation, automatic memory management through garbage collection, type safety, exception handling, and security—all abstracted away from the developer. Without the CLR, you would need to manage these concerns manually, similar to writing in C++.

How it works

When you write C# code and compile it, the compiler doesn't produce machine code directly. Instead, it produces Intermediate Language (IL) bytecode that's platform-agnostic. This IL is stored in assemblies (.dll or .exe files) along with metadata describing types, methods, and dependencies.

When your .NET application runs, the CLR takes over. It reads the IL from your assembly and uses the JIT compiler to translate it into native machine code specific to the processor architecture you're running on. This happens on-demand: the first time a method is called, it's compiled; subsequent calls use the cached compiled version.

The CLR also manages memory through the garbage collector, which automatically tracks object references and frees memory that's no longer in use. It enforces type safety at runtime, ensuring you can't cast an object to an incompatible type without validation. It provides a unified exception handling model and a security framework that controls what code can do, such as file access or network operations.

The CLR operates on a managed memory model where objects live on the heap and primitives or references live on the stack. This abstraction lets developers write code without worrying about memory corruption, pointer arithmetic, or manual cleanup—major sources of bugs in unmanaged languages.

Example
csharp
```
class Program
{
    static void Main()
    {
        var person = new Person { Name = "Alice", Age = 30 };
        Console.WriteLine($"{person.Name} is {person.Age}");
        // CLR automatically manages memory; no delete needed
    }
}

class Person
{
    public string Name { get; set; }
    public int Age { get; set; }
}
```
When this code runs, the CLR JIT-compiles the Main method, allocates the Person object on the heap, and automatically frees its memory when it's no longer referenced—all without explicit code.

Key points to mention
- The CLR is a virtual machine that sits between your code and the operating system, providing platform independence.
- It performs JIT compilation: converting IL to native machine code at runtime, enabling optimizations based on actual usage patterns.
- Automatic garbage collection eliminates manual memory management and prevents memory leaks (though IDisposable is still used for unmanaged resources).
- Type safety and exception handling are enforced by the CLR, catching errors at runtime rather than causing undefined behavior.
- The CLR enables the "write once, run anywhere" philosophy: your IL works across Windows, Linux, and macOS with the appropriate .NET runtime installed.
Common follow-up questions
- What's the difference between the CLR and the .NET Framework? The CLR is the runtime engine; .NET Framework is a larger ecosystem including the CLR, class libraries, and tools.
- Does .NET Core have a CLR? Yes. .NET Core (now just ".NET" in versions 5+) includes its own CLR optimized for cross-platform performance and cloud scenarios.
- How does the CLR handle different processor architectures? The JIT compiler generates native code specific to the current processor at runtime, so the same IL works on ARM, x86, and x64 without recompilation.
Related interview questions
Further reading
- Generics and constraints that pay off
- Exception handling anti-patterns
.NETCsharpPerformanceSecurity
04What is IL (Intermediate Language)?
Beginner
IL (Intermediate Language), also called MSIL or CIL, is a platform-agnostic instruction set that C# code compiles into. It sits between human-readable C# and machine code, allowing .NET programs to run across different operating systems and architectures. At runtime, the JIT compiler translates IL into native machine code specific to the current platform.

How it works

When you compile a C# project, the C# compiler doesn't produce native machine code directly. Instead, it produces IL instructions that are stored inside .NET assemblies (DLL or EXE files). These IL instructions are human-readable yet hardware-independent, similar to bytecode in Java.

During runtime, the CLR's Just-In-Time (JIT) compiler reads the IL and converts it on-demand into native machine code that the CPU can execute. This happens method-by-method: the first time a method is called, its IL is compiled to native code and cached. Subsequent calls use the cached native code, avoiding recompilation.

This two-stage compilation model gives .NET several advantages. First, it enables platform independence—the same IL assembly runs on Windows, Linux, and macOS because each platform has its own JIT compiler. Second, it allows for runtime optimizations—the JIT can apply optimizations based on actual runtime behavior and CPU architecture. Third, it enables security and verification—IL can be inspected and validated before execution.

Example
csharp
```
public class Calculator
{
    public int Add(int a, int b)
    {
        return a + b;
    }
}

var calc = new Calculator();
int result = calc.Add(5, 3);
```
When you compile this C#, the Add method is converted to IL instructions (such as ldarg.0, ldarg.1, add, ret). When the program runs and calls Add(5, 3), the JIT compiler translates those IL instructions into native x86 or ARM machine code that executes on your specific CPU.

Key points to mention
- Platform independence: IL is the same across Windows, Linux, and macOS; only the JIT compiler is platform-specific.
- JIT compilation: IL is compiled to native code at runtime by the CLR, not ahead of time (though Native AOT and ReadyToRun are alternatives).
- Verifiable and secure: IL can be inspected for type safety and security violations before execution.
- Stored in assemblies: IL lives in DLL and EXE files alongside metadata about types, methods, and resources.
- Performance trade-off: JIT compilation adds startup latency but allows runtime optimizations that can exceed pre-compiled code performance.
Common follow-up questions
- What is the CLR (Common Language Runtime)?
- Can I see the IL that my C# code compiles to?
- How does IL differ from native code compilation in C++?
Related interview questions
.NETCsharpPerformance
05What is JIT compilation?
Beginner
JIT (Just-In-Time) compilation is the process where the .NET runtime converts Intermediate Language (IL) code into native machine code at runtime, just before a method is executed for the first time. This allows .NET to be both platform-independent (IL runs anywhere) and performance-optimized (native code is fast). Modern .NET uses tiered compilation, which starts with quick compilation and later recompiles frequently-used methods with aggressive optimizations.

How it works

When you write C# and compile it, the compiler produces IL (Intermediate Language), not native machine code. This IL is stored in your assembly. When your program runs and calls a method for the first time, the JIT compiler kicks in:
1. The runtime detects the method hasn't been compiled yet.
2. The JIT compiler reads the IL for that method.
3. It compiles the IL into native code optimized for the current CPU architecture.
4. The native code is cached in memory.
5. Future calls to that method execute the cached native code directly—no recompilation.
In modern .NET, tiered compilation makes this even smarter. Tier 0 (quick JIT) compiles with minimal optimization to get the method running fast. If the method is called frequently, Tier 1 (optimizing JIT) recompiles it with full optimizations like inlining and loop unrolling. This balance means your app starts quickly but still gets peak performance for hot code paths.

Example
csharp
```
public class Program
{
    public static void Main()
    {
        // First call: JIT compiles Calculate to native code
        int result1 = Calculate(5);
        Console.WriteLine($"Result: {result1}");

        // Subsequent calls: use cached native code
        int result2 = Calculate(10);
        Console.WriteLine($"Result: {result2}");
    }

    public static int Calculate(int x)
    {
        // On first invocation, IL here is converted to native machine code
        return x * x + x;
    }
}
```
The first call to Calculate(5) triggers JIT compilation; the runtime converts its IL to native code. The second call to Calculate(10) reuses that already-compiled native code without recompilation.

Key points to mention
- Startup delay: JIT compilation adds a small delay the first time each method runs (warm-up time), but this is typically negligible for modern applications.
- Platform independence: Because compilation happens at runtime, the same IL works on Windows, Linux, and macOS—the JIT produces platform-specific native code automatically.
- Optimization opportunities: The JIT can optimize based on actual runtime data—it knows which CPU you're on, actual data types flowing through methods, and call patterns, enabling smarter optimizations than static ahead-of-time compilers.
- Tiered compilation: .NET 5+ defaults to tiered compilation, balancing startup speed (Tier 0) with peak performance (Tier 1) automatically.
- Caching: Compiled native code is cached in memory for the lifetime of the process; it's never re-JIT'd unless explicitly requested by the runtime.
Common follow-up questions
- Can we pre-compile IL to native code? Yes—ReadyToRun (R2R) and NativeAOT allow ahead-of-time compilation to eliminate JIT overhead and improve startup time.
- What's the performance difference between Tier 0 and Tier 1? Tier 0 compiles very quickly (sometimes in microseconds) but produces less-optimized code. Tier 1 takes longer to compile but produces code that can be 10–30% faster for compute-intensive workloads.
- How does JIT affect cold startup? In cold applications, you pay JIT cost for every method called during startup. For typical web services, this is under 100ms; for CLI tools, it can be noticeable. This is why NativeAOT is gaining adoption for trimmed, fast-startup scenarios.
Related interview questions
Further reading
- Optimistic UI
.NETCsharpPerformance
06What is an assembly in .NET?
Beginner
An assembly is the compiled unit of deployment in .NET, typically a .dll (dynamic link library) or .exe (executable) file. It contains Intermediate Language (IL) code, metadata describing all types and members, and a manifest that specifies the assembly's version, name, and dependencies on other assemblies.

How it works

When you compile a C# project, the compiler translates your source code into IL—a platform-independent intermediate representation. This IL, along with rich metadata about classes, methods, properties, and other type information, is packaged into an assembly file.

The assembly also includes a manifest—a metadata table that describes the assembly itself: its identity (name, version, culture), the types it exports, and which other assemblies it depends on. When the .NET runtime loads an assembly, it reads the manifest to understand what's inside and how to resolve dependencies.

Assemblies are the unit of versioning, security, and deployment. You can share assemblies across applications, place them in the Global Assembly Cache (in .NET Framework), or bundle them with your application. Each assembly is independently versionable, so you can update one assembly without recompiling the entire application.

The runtime uses a process called Just-In-Time (JIT) compilation to convert IL code to native machine code when the assembly executes. This allows the same IL assembly to run on different platforms (Windows, Linux, macOS) as long as the appropriate .NET runtime is installed.

Example
csharp
```
// MathLibrary.csproj – a class library assembly
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AssemblyName>MathLibrary</AssemblyName>
    <Version>1.0.0</Version>
  </PropertyGroup>
</Project>

// MathLibrary.cs – code in the assembly
namespace MathLibrary
{
    public class Calculator
    {
        public int Add(int a, int b) => a + b;
    }
}

// Program.cs – consumer project
using MathLibrary;

var calc = new Calculator();
Console.WriteLine(calc.Add(5, 3)); // 8
```
When you build MathLibrary, the compiler produces MathLibrary.dll—the assembly. The manifest inside records that it's version 1.0.0, contains the Calculator type, and depends on System.Runtime. Your Program.cs project references this assembly; at runtime, the .NET loader reads the manifest and executes the IL code.

Key points to mention
- Assemblies are files (.dll or .exe) containing IL code and metadata; they're the output of compilation.
- The manifest is metadata inside the assembly that describes the assembly's identity, exported types, and dependencies—it's how the runtime resolves what to load.
- Assemblies are independently versioned and deployed; a single project can reference assemblies of different versions.
- IL is platform-independent; the JIT compiler converts it to native code at runtime, enabling cross-platform execution.
- The Base Class Library (BCL) itself is distributed as a set of assemblies that the runtime loads automatically.
Common follow-up questions
- What is the difference between a private assembly and a shared assembly?
- What is the Global Assembly Cache (GAC), and why is it rarely used in modern .NET?
- How does the runtime resolve assembly dependencies, and what is assembly binding?
Related interview questions
- What is the .NET SDK vs the .NET runtime?
- What is the Base Class Library (BCL)?
.NETCsharpDevOps
07What is the Base Class Library (BCL)?
Beginner
The Base Class Library (BCL) is the standard library that ships with .NET, providing fundamental types and functionality for building applications. It includes namespaces like System, System.Collections, System.IO, System.Net, and System.Text, among hundreds of others. Every .NET application relies on the BCL to perform core operations such as file I/O, string manipulation, threading, networking, and data structures.

How it works

The BCL is a collection of managed assemblies (compiled code) that are part of the .NET runtime distribution. When you install .NET, the BCL assemblies are installed alongside it, making them immediately available to any application you build. You access BCL functionality by referencing namespaces in your code—for example, using System; or using System.Collections.Generic;—and then calling the types and methods defined in those namespaces.

The BCL is organized hierarchically by namespace, grouping related functionality together. For instance, System.IO contains file and directory operations, System.Net handles networking, System.Collections.Generic provides type-safe collections, and System.Text.Json handles JSON serialization. These namespaces wrap the underlying operating system capabilities and provide a consistent, object-oriented interface that works across Windows, Linux, and macOS.

The BCL also includes modern features like LINQ, which allows you to query collections with a SQL-like syntax, and System.Text.Json for parsing and generating JSON without external dependencies. The BCL is continuously updated with each .NET release, adding new types, methods, and performance improvements while maintaining backward compatibility.

Example
csharp
```
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text.Json;

// BCL example: Collections, LINQ, File I/O, JSON
var numbers = new List<int> { 1, 2, 3, 4, 5 };
var evenNumbers = numbers.Where(n => n % 2 == 0).ToList();
Console.WriteLine($"Even numbers: {string.Join(", ", evenNumbers)}");

// File I/O from System.IO
var path = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Desktop), "data.json");
File.WriteAllText(path, JsonSerializer.Serialize(evenNumbers));

// Read it back
var readContent = File.ReadAllText(path);
var parsed = JsonSerializer.Deserialize<List<int>>(readContent);
Console.WriteLine($"Parsed from file: {string.Join(", ", parsed ?? [])}");
```
This example demonstrates BCL usage: creating a typed collection, using LINQ.Where() to filter, writing to a file with System.IO.File, serializing to JSON with System.Text.Json, and reading it back—all from the BCL with no external packages.

Key points to mention
- The BCL is built-in and free; no installation or NuGet packages required for basic functionality.
- It provides cross-platform abstractions, so code written for Windows works on Linux and macOS without changes.
- Common namespaces include System (core types), System.Collections.Generic (dictionaries, lists), System.IO (files), System.Linq (querying), System.Net (networking), and System.Text.Json (serialization).
- The BCL is always available in every .NET project; you only need to add using statements to access it.
- It is designed for performance and is heavily optimized; many operations delegate to the runtime or operating system.
Common follow-up questions
- How does the BCL differ from NuGet packages? The BCL is built-in and maintained by Microsoft; NuGet packages are third-party libraries you install separately to extend functionality.
- What happens if I use BCL types in .NET Framework vs. .NET 8+? Some newer BCL types (like JsonSerializer) are only available in newer .NET versions; you must target the appropriate framework or use compatibility packages.
- Can I override or extend BCL classes? Yes, many BCL classes are designed to be inherited (e.g., collections, exceptions); sealed classes cannot be extended intentionally.
Related interview questions
Further reading
- Entities and aggregates
.NETCsharpasynclinq
08What is the .NET SDK vs the .NET runtime?
Beginner
The .NET SDK (Software Development Kit) contains everything you need to develop and build .NET applications, including compilers, the dotnet CLI, and project templates. The .NET runtime is a minimal package that contains only what is necessary to execute already-compiled .NET applications. Think of it this way: developers install the SDK, but end users only need the runtime.

How it works

When you develop a .NET application, you use the SDK, which includes the C# compiler, the dotnet command-line tool, NuGet package manager, and pre-built project templates. The SDK is a superset that enables you to write code, compile it into Intermediate Language (IL), and create assemblies.

Once your application is compiled and ready for deployment, end users do not need the compiler or development tools. They only need the .NET runtime, which provides the Just-In-Time (JIT) compiler to convert IL to machine code at runtime, the garbage collector, the type system, and the base class library necessary to execute your application.

For deployment scenarios, you have flexibility: you can deploy your app to machines with the runtime installed, or you can create self-contained deployments where the runtime is bundled with your application. When containerizing an ASP.NET Core app, you often use a lightweight runtime image as the base rather than the full SDK.

Example
csharp
```
// Program.cs - requires SDK to compile
using System;

class Program
{
    static void Main()
    {
        Console.WriteLine("Hello from .NET!");
        Console.WriteLine($"Runtime: {System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription}");
    }
}
```
To build this, you run dotnet build (SDK required). To run it, you execute dotnet run or ./bin/Release/net8.0/Program.exe (runtime required). End users only need the runtime to execute the compiled DLL.

Key points to mention
- SDK is for development: Includes compiler, CLI tools, debugger, templates, and everything needed to create applications.
- Runtime is for execution: Minimal footprint with JIT compiler, garbage collector, and runtime libraries to execute compiled code.
- Size difference: The SDK is significantly larger (500+ MB) compared to the runtime (50-150 MB), which matters for production deployments.
- Separate downloads: Both are available separately from microsoft.com; you choose based on your use case (development vs. deployment).
- Version alignment: Applications compiled with SDK version X.Y should run on runtime version X.Y or newer (generally backward compatible within a major version).
Common follow-up questions
- Can you run a .NET application without installing the SDK? Yes, if the runtime is installed or the application is self-contained with the runtime bundled.
- What is the difference between SDK versions and runtime versions? The SDK is used at compile time; the runtime version is what your deployed application targets and what end-user machines need.
- Should production servers have the SDK installed? Generally no—install only the runtime to reduce surface area and system complexity. The SDK is for development machines.
Related interview questions
.NETCsharp
09What does the dotnet CLI do?
Beginner
The dotnet CLI (Command Line Interface) is a cross-platform tool that allows developers to create, build, run, test, and publish .NET applications directly from the command line. It's the foundation for modern .NET development, eliminating the need to rely solely on Visual Studio and enabling automation in CI/CD pipelines.

How it works

The dotnet CLI is installed as part of the .NET SDK and provides a unified command structure for managing your entire project lifecycle. When you run a command like dotnet build, the CLI parses your project file (typically a .csproj), restores NuGet dependencies, compiles your code, and produces output artifacts. Each command follows a predictable pattern: dotnet [command] [arguments] [options].

The CLI works with project files to understand your application's structure, dependencies, and configuration. It supports multiple project types—console applications, class libraries, ASP.NET Core web applications, and more. The CLI also integrates with the NuGet package manager, allowing you to add, update, and remove dependencies seamlessly.

One of the most powerful aspects is its cross-platform nature. The same commands work identically on Windows, macOS, and Linux, making it ideal for DevOps teams and developers working in mixed environments. The CLI also powers many higher-level tools, including Visual Studio and Visual Studio Code, which use it behind the scenes.

Example
csharp
```
// Program.cs - Simple console application
Console.WriteLine("Hello from dotnet CLI!");

var greeting = GetGreeting("World");
Console.WriteLine(greeting);

static string GetGreeting(string name) => $"Welcome, {name}!";
```
To execute this, you'd use dotnet run in the terminal, which restores dependencies, compiles the code, and executes the program without manually creating build artifacts.

Key points to mention
- Core commands: dotnet new (creates projects), dotnet build (compiles), dotnet run (executes), dotnet test (runs unit tests), dotnet publish (creates deployment packages)
- Dependency management: Use dotnet add package and dotnet remove package to manage NuGet packages without editing .csproj files manually
- Project agnostic: Works with any .NET project type—console apps, libraries, web applications, and more—using the same fundamental commands
- CI/CD integration: Perfect for automation scripts and continuous integration pipelines since it's scriptable and cross-platform
- Restore and clean: dotnet restore downloads dependencies, while dotnet clean removes build artifacts
Common follow-up questions
- What's the difference between dotnet build and dotnet publish? (Build compiles for development; publish prepares for deployment)
- How do you run integration tests for ASP.NET Core using the CLI?
- What does dotnet restore do, and when is it necessary?
Related interview questions
Further reading
- Integration tests with WebApplicationFactory
- Test data builders
.NETCsharpTestingDevOps
10What is NuGet?
Beginner
NuGet is the package manager for .NET that enables developers to discover, download, and manage reusable libraries and dependencies in their projects. Packages are defined in your project file and automatically restored from nuget.org (the public feed) or private feeds during the build process, making dependency management centralized and version-controlled.

How it works

NuGet operates as a centralized repository system. When you add a package reference to your .csproj file, NuGet resolves that package and all its transitive dependencies from configured feeds. During build time, NuGet restores these packages to a local cache (typically in ~/.nuget/packages) and makes the assemblies available to your project.

You interact with NuGet through multiple interfaces: the dotnet CLI (e.g., dotnet add package), Visual Studio's Package Manager UI, the Package Manager Console, or by directly editing your project file. The packages.lock.json file (when enabled) ensures deterministic restores by locking exact versions across team members.

Private NuGet feeds allow organizations to host internal packages securely, enabling code sharing across teams while maintaining intellectual property protection. Authentication can be configured per feed, supporting various credential types.

Example
csharp
```
// After installing NuGet package "Newtonsoft.Json" via:
// dotnet add package Newtonsoft.Json

using Newtonsoft.Json;

var jsonString = "{\"name\": \"Alice\", \"age\": 30}";
var person = JsonConvert.DeserializeObject<dynamic>(jsonString);

Console.WriteLine($"{person.name} is {person.age} years old");
// Output: Alice is 30 years old
```
This code uses the popular Newtonsoft.Json NuGet package to deserialize JSON without writing custom parsing logic—demonstrating how NuGet packages provide reusable functionality.

Key points to mention
- Central repository: nuget.org hosts millions of open-source packages; organizations can also host private feeds
- Declarative dependency management: Package references in the .csproj file make dependencies explicit and version-controlled
- Transitive dependency resolution: NuGet automatically downloads dependencies of your dependencies, resolving version conflicts
- Version control: Lock files ensure reproducible builds and consistent versions across development teams
- Package metadata: Each package includes version information, license, dependencies, and documentation for informed selection
Common follow-up questions
- How do you handle version conflicts when two packages require different versions of the same dependency?
- What's the difference between a NuGet package and a local project reference?
- How do you create and publish your own NuGet package?
Related interview questions
- What is a .csproj file?
- What does the dotnet CLI do?
.NETCsharp
11What is a .csproj file?
Beginner
A .csproj file is the MSBuild project file for C# projects. It is an XML configuration file that defines how your project should be built, including the target framework, dependencies, output type, and build settings. Modern .NET projects use the compact SDK-style format rather than the verbose .NET Framework format.

How it works

When you build a C# project, MSBuild reads the .csproj file to understand what to compile, which NuGet packages to restore, what the target framework is, and which compilation options to apply. The file is XML-based and contains property groups, item groups, and targets that instruct MSBuild how to orchestrate the build process.

The SDK-style format (introduced with .NET Core) automatically includes sensible defaults and globs common file patterns like *.cs files in the project directory. This means you rarely need to explicitly list every source file. The file can also reference property files, define custom build steps, and configure package metadata for NuGet publishing.

The .csproj file works hand-in-hand with the .sln (solution) file when managing multiple projects. The solution file references one or more .csproj files, enabling you to build and manage them as a cohesive unit.

Example
csharp
```
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <OutputType>Exe</OutputType>
    <LangVersion>latest</LangVersion>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="13.0.3" />
  </ItemGroup>
</Project>
```
This minimal .csproj declares a console application targeting .NET 8.0 with nullable reference types enabled and a dependency on Newtonsoft.Json; MSBuild automatically discovers all .cs files in the directory and compiles them.

Key points to mention
- PropertyGroup: Contains metadata like TargetFramework, OutputType (Exe, Library), and compiler settings such as Nullable and LangVersion.
- ItemGroup: Lists package references (NuGet dependencies), project references, and other files to include in the build.
- SDK-style format: The modern, concise format used by .NET 5+; older .NET Framework projects used verbose formats that explicitly listed every file.
- Automatic file discovery: SDK projects automatically include all .cs files in the directory tree without explicit declarations.
- TargetFramework: Specifies which .NET runtime your project targets (e.g., net8.0, net48, net6.0-windows).
Common follow-up questions
- What is the difference between a .csproj file and a .sln file? A .csproj file defines a single project; a .sln file is a container that references multiple .csproj files to organize them into a solution.
- How do you add a NuGet package to a .csproj file? You can either use dotnet add package from the CLI, or manually add a <PackageReference> entry to the <ItemGroup> section and restore with dotnet restore.
- What is the .csproj.user file? It is a local, machine-specific file that stores user preferences (like debug settings or breakpoints) and is typically not checked into source control.
Related interview questions
.NETCsharp
12What is the difference between a value type and a reference type?
Beginner
Value types hold their data directly in memory and are copied entirely when assigned to another variable, meaning each copy is independent. Reference types store only a reference (pointer) to an object on the managed heap, so multiple variables can point to the same object. This fundamental distinction affects memory allocation, performance, and how changes to data are observed across your application.

How it works

When you declare a value type variable like int or struct, the runtime allocates memory on the stack to store the actual value. When you assign a value type to another variable, the entire data is copied, creating two independent copies. Changes to one copy do not affect the other.

Reference types like class, string, and arrays work differently. The variable doesn't hold the actual data; it holds a reference (memory address) to an object stored on the managed heap. When you assign a reference type to another variable, you're copying the reference, not the object itself. Both variables now point to the same object in memory. Any modification through either variable affects the shared object.

The garbage collector automatically manages heap memory for reference types, cleaning up objects that no longer have any references. Value types on the stack are automatically freed when they go out of scope, making them more efficient for small, short-lived data.

Example
csharp
```
// Value type example
int a = 5;
int b = a;
b = 10;
Console.WriteLine($"a: {a}, b: {b}"); // Output: a: 5, b: 10

// Reference type example
var list1 = new List<int> { 1, 2, 3 };
var list2 = list1;
list2.Add(4);
Console.WriteLine($"list1.Count: {list1.Count}"); // Output: list1.Count: 4

// Struct (value type) example
struct Point
{
    public int X, Y;
}

var p1 = new Point { X = 1, Y = 2 };
var p2 = p1;
p2.X = 10;
Console.WriteLine($"p1.X: {p1.X}, p2.X: {p2.X}"); // Output: p1.X: 1, p2.X: 10
```
In the value type example, changing b doesn't affect a because they're independent copies. In the reference type example, list1 and list2 reference the same list, so adding to list2 is visible through list1. The struct example demonstrates that structs are value types, so copying creates independent instances.

Key points to mention
- Memory location: Value types live on the stack; reference types live on the managed heap.
- Copying behavior: Value types are deep-copied on assignment; reference types share the same object.
- Common value types: Primitives (int, double, bool), struct, and enum.
- Common reference types: class, string, arrays, delegates, and interfaces.
- Performance implications: Value types are generally faster for small data due to stack allocation; large value types can harm performance if copied frequently.
Common follow-up questions
- What is the difference between class and struct in C#?
- What are nullable value types?
- Why should you avoid large structs, and when should you prefer a class over a struct?
Related interview questions
Further reading
- Nullable reference types
- Value objects
.NETCsharp
13What is the difference between stack and heap memory?
Beginner
The stack stores method frames and local value types (like integers and structs) and is automatically cleaned up when methods return, while the heap stores reference types (objects, strings, arrays) and is managed by the garbage collector. Stack allocation is faster but limited in size, while heap allocation is flexible but requires garbage collection overhead.

How it works

Memory in .NET is divided into two main regions: the stack and the heap. When a method is called, a new frame is created on the stack containing space for all local variables and method parameters. Value types (like int, bool, struct) are stored directly in this stack frame. When the method returns, the entire frame is popped off the stack, and all local variables are immediately destroyed—no garbage collection needed.

The heap, by contrast, is a large pool of memory where reference types live. When you use the new keyword to create an object, the object is allocated on the heap, and a reference (pointer) to that object is returned. This reference is typically stored on the stack (if it's a local variable) or in another object on the heap (if it's a field). Because objects can outlive the method that created them and can be referenced from multiple places, the heap cannot be cleaned up as simply as the stack. Instead, the garbage collector periodically scans the heap, identifies objects that are no longer referenced, and reclaims their memory.

Stack memory is also more efficient—allocation and deallocation are O(1) operations that just move a pointer. Heap allocation and garbage collection introduce overhead. However, the stack is limited in size (typically a few megabytes per thread), while the heap can grow much larger.

Example
csharp
```
public class Program
{
    public static void Main()
    {
        int age = 25;                    // Stack: value type stored directly
        string name = "Alice";           // Stack: reference to string object
                                         // Heap: "Alice" string object stored here
        Person person = new Person();    // Stack: reference to Person object
                                         // Heap: Person object stored here
        person.Name = "Bob";
    }
}

public class Person
{
    public string Name { get; set; }     // Field reference stored in Person object on heap
}
```
In this example, age (an int) is stored directly on the stack, while name and person are stack references pointing to objects on the heap. When Main returns, the stack frame is destroyed, references are lost, and the heap objects become candidates for garbage collection.

Key points to mention
- Stack is automatic and deterministic—memory is freed instantly when a method returns; predictable performance with no GC pauses.
- Heap requires garbage collection—the CLR must identify unreachable objects and reclaim memory, which can cause temporary pauses.
- Value types live on the stack (when local), while reference types live on the heap—understanding this distinction is crucial for value types vs. reference types.
- Stack is thread-local; each thread gets its own stack, preventing race conditions for local variables.
- Stack size is limited, making it unsuitable for large data structures; this is why collections are reference types stored on the heap.
Common follow-up questions
- Why are structs sometimes stored on the stack but can also end up on the heap?
- Can I force memory to be freed immediately instead of waiting for garbage collection?
- How do I know if my code is causing excessive garbage collection?
Related interview questions
Further reading
- Value objects
- Creational patterns overview
.NETCsharpPerformance
14What is boxing and unboxing?
Beginner
Boxing is the process of wrapping a value type (like int, struct) in an object reference on the heap. Unboxing is extracting that value type back out. Both operations carry performance costs—heap allocation for boxing, and validation plus copying for unboxing—so modern C# encourages generics and value types to avoid them in performance-critical code paths.

How it works

When you assign a value type to an object variable or pass it to a method expecting object, the runtime allocates memory on the heap, copies the value there, and gives you a reference to that heap object. This is boxing. The original value type remains on the stack; the boxed copy lives on the heap until garbage collected.

Unboxing reverses this: you extract the value back from the heap object and copy it onto the stack (or into a local variable). The runtime validates that the boxed type matches the target type—unboxing an int box into a long variable throws an InvalidCastException.

Because value types are stored on the stack (fast, automatic cleanup) but reference types live on the heap (requiring GC), boxing trades performance for the convenience of treating all values uniformly through the object interface. This was especially common in pre-generic .NET; today, generics like List<T> eliminate most boxing scenarios.

Example
csharp
```
// Boxing and unboxing example
int number = 42;

// Boxing: value type → object reference
object boxed = number;  // Allocates heap memory, copies value

// Unboxing: object reference → value type
int unboxed = (int)boxed;  // Validates type, copies from heap
Console.WriteLine(unboxed);  // 42

// Common mistake: implicit boxing in collections
ArrayList list = new ArrayList();
list.Add(100);  // Boxing occurs here
int value = (int)list[0];  // Unboxing occurs here

// Modern approach: use generics to avoid boxing
List<int> genericList = new List<int>();
genericList.Add(100);  // No boxing
int value2 = genericList[0];  // No unboxing
```
The first section demonstrates explicit boxing (assigning int to object) and explicit unboxing (casting back). The second half shows how old non-generic collections forced boxing on every value; generics eliminate this by storing actual int instances.

Key points to mention
- Performance cost: Boxing allocates heap memory and copies the value; unboxing validates type and copies back. Both are expensive in tight loops.
- Generics eliminate boxing: List<int> stores integers directly without boxing, unlike the old non-generic ArrayList.
- Type safety on unbox: Unboxing validates that the boxed type matches exactly—you cannot unbox an int box as long without a cast that may fail.
- Reference equality after boxing: Each boxing creates a new heap object, so two boxed copies of the same value are different objects: object a = 5; object b = 5; a == b is false.
- Nullable value types: Boxing a nullable value type like int? boxes the underlying value if it has one, or null if it doesn't.
Common follow-up questions
- Why does boxing happen implicitly in some cases? When you pass a value type to a method expecting object or an interface the value type implements, the runtime automatically boxes it for you.
- How do structs avoid boxing? Record structs and regular structs are value types, so using generics with them avoids boxing entirely compared to reference type wrappers.
- Can you unbox to a different type? No—unboxing requires an exact type match or an exception is thrown. You must unbox to the original type or use Convert class methods instead.
Related interview questions
Further reading
- Reducing allocations in hot paths
- Compiled queries for hot paths
.NETCsharpPerformance
15What is the difference between class and struct in C#?
Beginner
Classes are reference types that live on the heap and support inheritance, making them ideal for complex objects. Structs are value types that live on the stack and are copied on assignment, making them best for small, immutable data structures like coordinates or currency values.

How it works

The fundamental difference lies in how classes and structs are stored and passed in memory. Value types like structs store their data directly on the stack, while reference types like classes store a reference on the stack that points to data on the heap. When you assign a struct to another variable or pass it as a parameter, the entire value is copied. When you assign a class, only the reference is copied—both variables point to the same object.

Classes support inheritance, allowing you to create hierarchies and use polymorphism. Structs do not support inheritance (except from interfaces) and cannot be abstract. Classes can have null values; structs have default values for each field. Classes require explicit initialization; structs are automatically initialized with default values.

Performance and memory characteristics differ significantly. Structs are allocated on the stack, making them faster to create and destroy, but copying large structs repeatedly can be expensive. Classes have heap allocation overhead but avoid copying when passed around. For small, simple data, structs are often more efficient; for complex, frequently-used objects, classes are typically better.

Example
csharp
```
// Struct: value type, best for small immutable data
public struct Point
{
    public int X { get; set; }
    public int Y { get; set; }
    
    public Point(int x, int y) => (X, Y) = (x, y);
}

// Class: reference type, supports inheritance
public class Person
{
    public string Name { get; set; }
    public int Age { get; set; }
    
    public Person(string name, int age) => (Name, Age) = (name, age);
}

// Usage demonstrating value vs reference behavior
var point1 = new Point(10, 20);
var point2 = point1;
point2.X = 30;
Console.WriteLine(point1.X); // Output: 10 (struct was copied)

var person1 = new Person("Alice", 30);
var person2 = person1;
person2.Name = "Bob";
Console.WriteLine(person1.Name); // Output: Bob (both reference same object)
```
This example shows how modifying a copied struct leaves the original unchanged, while modifying through a class reference affects the original because both variables point to the same object.

Key points to mention
- Memory allocation: Structs are stack-allocated (faster creation/destruction), classes are heap-allocated (more memory overhead but better for complex objects)
- Value vs reference semantics: Structs are copied on assignment; classes pass references, so modifications affect the original
- Inheritance: Classes support inheritance and polymorphism; structs only implement interfaces
- Nullability: Class variables can be null; struct variables have default values and cannot be null (without nullable reference types)
- Use cases: Use structs for small, immutable data (Point, Size, Color); use classes for complex, mutable objects with shared state (Person, Customer, Service)
Common follow-up questions
- When would you choose a struct over a class, and when would you choose a class?
- What is a record, and how does it differ from a class or struct? (See record class vs record struct)
- What happens when you box a struct, and why is it important to know?
Related interview questions
Further reading
- Value objects
- Nullable reference types
.NETCsharp
16What is a record in C#?
Beginner
A record is a C# type that provides value-based equality, automatic ToString generation, and non-destructive mutation through the with keyword. Introduced in C# 9, records are reference types (or value types if declared as record struct) designed primarily for immutable data transfer objects, events, and domain objects where structural equality matters more than reference equality.

How it works

Records automatically generate several members for you:
- Value-based equality: Two records are equal if all their properties have the same values, not because they reference the same object in memory. The compiler generates Equals, GetHashCode, and equality operators.
- ToString override: Records automatically generate a readable ToString that displays the type name and all properties, making debugging easier.
- Copy-with-mutation: The with expression creates a shallow copy of a record with specified properties changed. This is non-destructive—the original record remains unchanged.
- Positional parameters: Records support positional syntax in declarations, creating properties and a primary constructor automatically.
Records are immutable by convention, though not enforced by the compiler unless you explicitly use init-only properties. This makes them safe for multi-threaded scenarios and reliable as dictionary keys.

Example
csharp
```
// Positional record—generates properties, constructor, and equality members
public record Person(string Name, int Age);

// Usage
var person1 = new Person("Alice", 30);
var person2 = new Person("Alice", 30);

// Value-based equality
Console.WriteLine(person1 == person2); // true

// Automatic ToString
Console.WriteLine(person1); // Person { Name = Alice, Age = 30 }

// Non-destructive mutation with 'with'
var person3 = person1 with { Age = 31 };
Console.WriteLine(person3); // Person { Name = Alice, Age = 31 }
Console.WriteLine(person1.Age); // 30 (original unchanged)
```
This example demonstrates how a record makes data-carrying types concise: a single line replaces dozens of lines of boilerplate code for equality and ToString, and the with expression elegantly handles immutable updates.

Key points to mention
- Records are reference types by default—they inherit from object, not struct. Use record struct for value semantics.
- Equality is based on property values, not reference identity, making records suitable as dictionary keys and safe for comparison.
- Records are immutable by design convention—use init-only properties to enforce compile-time immutability and prevent accidental mutation.
- Perfect for DTOs, events, and command/query objects where you need lightweight, immutable data containers without ceremony.
- The with keyword provides non-destructive mutation, enabling functional-style programming patterns in C#.
Common follow-up questions
- What is the difference between record class and record struct?
- How does record equality differ from class equality, and why should I use init-only properties?
- Can records inherit from other records or classes? (Yes—records can inherit from other records; inheritance chains work, but be cautious with equality semantics.)
Related interview questions
Further reading
- Use records for DTOs
- Validation with FluentValidation
.NETCsharpArchitecture
17What is the difference between record class and record struct?
Beginner
A record class is a reference type stored on the heap with value-based equality, while a record struct is a value type stored on the stack with the same conveniences. Both provide positional deconstruction, immutability support, and compiler-generated equality, but they differ in memory allocation and performance characteristics. The choice depends on whether you need reference semantics (class) or value semantics (struct).

How it works

Records were introduced in C# 9 to simplify immutable data types. Both record class and record struct automatically generate constructors, equality methods (Equals, GetHashCode, ==, !=), and a ToString method based on the declared properties.

A record class is a reference type that inherits from System.Object. Two instances are equal if their property values are equal, even if they occupy different memory locations. It supports inheritance and polymorphism.

A record struct is a value type that lives on the stack (unless boxed). Two instances are equal based on value comparison. Record structs are useful for small, immutable data structures where avoiding heap allocation improves performance. Unlike regular structs, record structs support the with keyword for non-destructive mutation and cleaner copying.

Example
csharp
```
// Record class (reference type)
public record Person(string Name, int Age);

// Record struct (value type)
public record struct Point(double X, double Y);

var person1 = new Person("Alice", 30);
var person2 = new Person("Alice", 30);
Console.WriteLine(person1 == person2); // True (value equality)

var point1 = new Point(1.0, 2.0);
var point2 = new Point(1.0, 2.0);
Console.WriteLine(point1 == point2); // True (value equality)

// Both support 'with' for creating modified copies
var person3 = person1 with { Age = 31 };
var point3 = point1 with { X = 2.0 };
```
This demonstrates that both record class and record struct support value-based equality and the convenient with keyword for immutable updates, regardless of their storage location.

Key points to mention
- Memory allocation: Record classes allocate on the heap (reference type); record structs allocate on the stack (value type), making structs faster for small data but requiring care with boxing.
- Equality semantics: Both use structural (value-based) equality by default, not reference equality like mutable classes.
- Immutability: Both support init-only properties and the with keyword for clean, immutable patterns.
- Inheritance: Record classes support inheritance; record structs do not (structs cannot inherit from other structs in C#).
- Performance: Record structs avoid heap allocations and garbage collection pressure, making them ideal for high-frequency data structures like coordinates or measurements.
Common follow-up questions
- Can a record struct be mutable? Yes, record structs can have settable properties, but this goes against the intent; records are designed for immutability. Mutable value types can cause subtle bugs.
- Should I always use record struct instead of record class for performance? No—record structs have trade-offs. Stack allocation is faster, but copying a struct (parameter passing, return values) copies all data. For large types or when you need reference semantics, use record class.
- How does a record struct differ from a regular struct? Record structs automatically generate equality methods and the with keyword support; regular structs require manual implementation or inherit broken default equality from ValueType.
Related interview questions
Further reading
- Single Responsibility, practically
- Data Mapper vs Active Record
.NETCsharpPerformance
18What are the access modifiers in C#?
Beginner
C# has six access modifiers—public, private, protected, internal, protected internal, and private protected—that control the visibility and accessibility of classes, methods, properties, and fields. They define which code can access a member, from anywhere in your application down to only within the declaring class or assembly. The best practice is to use the most restrictive modifier that still allows your code to function correctly.

How it works

Access modifiers restrict visibility by defining scope boundaries. Public members are accessible from anywhere, making them part of your public API. Private members (the default for class members) are accessible only within the declaring class, hiding implementation details. Protected members are accessible within the class and any derived classes, useful for inheritance hierarchies. Internal members are accessible anywhere within the same assembly, allowing internal collaboration without exposing to external consumers. Protected internal (union) allows access within the same assembly or from derived classes in other assemblies. Private protected (intersection) is the most restrictive combination, allowing access only within the same class or derived classes in the same assembly.

The key principle is encapsulation: expose only what clients need, and hide everything else. This protects your implementation from unintended misuse and makes refactoring safer.

Example
csharp
```
public class BankAccount
{
    private decimal _balance;  // Only accessible within this class
    
    protected string AccountNumber { get; set; }  // Accessible in derived classes
    
    public decimal GetBalance()  // Part of the public API
    {
        return _balance;
    }
    
    internal void LogTransaction(string details)  // Used within the assembly
    {
        Console.WriteLine($"Transaction: {details}");
    }
    
    private void ValidatePin(string pin)  // Hidden implementation detail
    {
        // Validation logic
    }
    
    protected internal decimal ApplyInterest(decimal rate)
    {
        return _balance *= (1 + rate);  // Accessible across assemblies or in derived classes
    }
    
    private protected void ResetInternalState()  // Only in this class or derived classes in same assembly
    {
        _balance = 0;
    }
}
```
This example demonstrates how different modifiers create layers of visibility: private hides the balance and validation, protected and internal control inheritance and assembly access, and public defines the safe interface for external code.

Key points to mention
- The default access modifier for class members is private; for top-level types it is internal—always be explicit to avoid surprises.
- Use public sparingly for your public API; prefer private or protected for internal implementation details to reduce coupling.
- Protected is for inheritance scenarios; use it when derived classes need to override or access behavior, such as in template method patterns.
- Internal is ideal for multi-project solutions where you want code sharing within your own assemblies but not external consumers.
- Protected internal and private protected are advanced modifiers; use them when you need precise control over inheritance and assembly boundaries.
- Access modifiers apply to classes, structs, interfaces, methods, properties, and fields, and even nested types.
Common follow-up questions
- What is the default access modifier in C#? — For class members, it is private; for top-level types (classes, interfaces, structs), it is internal.
- Why should I avoid making everything public? — Public members become part of your contract, making them hard to change later. Private members are implementation details you can refactor freely without breaking clients.
- When would I use protected internal vs. private protected? — Use protected internal (union) when derived classes or assembly-internal code need access; use private protected (intersection) only when both conditions must be true—rarely needed in practice.
Related interview questions
- What is the difference between a field and a property?
- When would you choose gRPC over REST?
Further reading
- Permission-based authorization
.NETCsharpSecurity
19What is the difference between const and readonly?
Beginner
const is a compile-time constant whose value is baked directly into every place it's referenced, while readonly is a field that can only be assigned once—either at declaration or in the constructor—and its value is determined at runtime. Use const for true constants that never change across versions; use readonly for values that should be immutable but may vary per instance or need runtime initialization.

How it works

When you declare a const field, the C# compiler replaces every reference to that constant with its literal value during compilation. This means the value is "baked in" to the calling assembly. If you later change the constant value and recompile only the library—but not the calling code—callers will still see the old value until they recompile.

readonly fields, by contrast, are resolved at runtime. The field can be assigned a value during initialization (at declaration) or inside any constructor, but nowhere else. Once assigned, it cannot be modified. Because the value is looked up at runtime rather than baked in, changing a readonly field's value and recompiling will immediately affect all callers without them needing to recompile.

const is implicitly static and must be assigned a compile-time constant expression (a literal or another constant). readonly can be instance-level or static, and can be assigned the result of a method call or any expression that runs at initialization time.

Example
csharp
```
public class Configuration
{
    // Compile-time constant: value is baked into calling code
    public const int MaxRetries = 3;
    
    // Runtime constant: value is resolved when accessed
    public readonly string AppVersion;
    public readonly DateTime StartupTime;
    
    public Configuration(string version)
    {
        AppVersion = version;  // Can only assign once
        StartupTime = DateTime.UtcNow;  // Runtime value
    }
}

// Usage
var config = new Configuration("1.0.0");
Console.WriteLine(Configuration.MaxRetries);  // 3 (compiled into IL)
Console.WriteLine(config.AppVersion);         // "1.0.0" (runtime lookup)
Console.WriteLine(config.StartupTime);        // Current UTC time
```
The MaxRetries constant is compiled into the calling code's IL, while AppVersion and StartupTime are set once during construction and cannot change afterward.

Key points to mention
- const is implicitly static, so there is only one value shared across all instances; readonly can be instance-level or static.
- const must be assigned a compile-time constant expression; readonly can be assigned at runtime (in a constructor or initializer).
- Changing a const value requires recompiling all dependent code; changing readonly only requires recompiling the assembly that defines it.
- const applies only to primitives and strings; readonly can hold any type, including reference types (though the reference itself becomes immutable, not the object it points to).
- readonly is the safer default for most scenarios because it provides versioning safety and allows runtime flexibility.
Common follow-up questions
- Can you make a readonly reference type truly immutable? The field reference is immutable, but the object it points to can still be modified. To prevent that, use an immutable collection or readonly struct.
- What happens if a library changes a const value? Callers see the old value until they recompile, which can cause version mismatch bugs. This is why readonly is preferred for public constants.
- Can you use readonly with properties? Yes, modern C# allows readonly properties and init accessors for similar immutability semantics.
Related interview questions
Further reading
- Source generators in C#
.NETCsharp
20What is a static class?
Beginner
A static class is a sealed class that cannot be instantiated and contains only static members (methods, properties, and fields). It serves as a container for utility functions and extension methods, and is loaded into memory only once by the CLR when first accessed.

How it works

When you declare a class as static, the compiler enforces several rules: no instance can be created (the constructor is private by default), all members must be static, and the class is implicitly sealed and abstract. This means you cannot inherit from a static class. Static classes are ideal for grouping related functionality that doesn't require object state—think of them as organized collections of utility functions.

The CLR loads a static class the first time any of its members are accessed, initializing static fields and running the static constructor if one exists. All subsequent calls to static members reference the same data in memory, making static classes efficient for shared utilities.

Static classes are commonly used in the .NET Framework itself—examples include Math, String, File, and Console. They're also the natural home for extension methods, which must be declared in static classes in C#.

Example
csharp
```
public static class StringHelper
{
    public static bool IsValidEmail(string email)
    {
        return email != null && email.Contains("@");
    }

    public static string Reverse(string input)
    {
        return new string(input.Reverse().ToArray());
    }
}

// Usage
class Program
{
    static void Main()
    {
        string email = "user@example.com";
        if (StringHelper.IsValidEmail(email))
        {
            Console.WriteLine("Valid email");
        }

        string reversed = StringHelper.Reverse("Hello");
        Console.WriteLine(reversed); // "olleH"
    }
}
```
This example shows a static utility class that provides string validation and manipulation methods. All members are accessed directly on the class name without creating an instance.

Key points to mention
- No instantiation: You cannot use new to create an instance; the compiler will throw an error.
- All members must be static: Instance members, instance constructors (other than the private static constructor), and instance fields are not allowed.
- Sealed and abstract: A static class cannot be inherited from, making it impossible to extend its behavior through inheritance.
- Memory efficiency: Static members are loaded once and shared across the entire application lifetime, reducing memory overhead compared to creating multiple instances.
- Thread-safe initialization: The CLR guarantees that static constructors run only once and are thread-safe, making static classes reliable for singleton-like patterns.
Common follow-up questions
- How do static classes differ from the Singleton pattern? (Static classes are simpler and thread-safe by default, while Singleton requires manual implementation and instantiation.)
- Can you use a static class as a base class? (No, static classes are implicitly sealed.)
- What is the difference between a static class and a regular class with all static members? (A static class is explicitly sealed by the compiler and cannot be instantiated, while a regular class with static members can still be instantiated, though it would be wasteful.)
Related interview questions
Further reading
- Extension methods done right
.NETCsharp
21What is a constructor?
Beginner
A constructor is a special method that runs automatically when you create an instance of a class or struct, allowing you to initialize the object's state. C# supports several constructor types: parameterless (default), parameterized, static, and primary constructors, each serving different initialization needs.

How it works

When you use the new keyword to instantiate a class or struct, the runtime automatically invokes the constructor before the object is returned to you. Constructors have the same name as the class and no return type (not even void). They initialize fields, properties, and perform any setup logic the object needs to function correctly.

Constructors are useful for enforcing invariants—ensuring that an object never exists in an invalid state. For example, you might require certain fields to be set or validated before the object is ready to use. If you don't define a constructor, C# provides a default parameterless constructor, but defining your own gives you control over initialization.

You can have multiple constructors with different parameters (constructor overloading). Constructors can also call other constructors using the this() keyword, allowing you to reuse initialization logic and reduce code duplication.

Example
csharp
```
public class Person
{
    public string Name { get; set; }
    public int Age { get; set; }

    // Parameterless constructor
    public Person()
    {
        Name = "Unknown";
        Age = 0;
    }

    // Parameterized constructor
    public Person(string name, int age)
    {
        Name = name;
        Age = age;
    }

    // Constructor calling another constructor
    public Person(string name) : this(name, 0)
    {
    }

    // Static constructor (runs once for the class)
    static Person()
    {
        Console.WriteLine("Person class initialized");
    }
}

// Usage
Person p1 = new Person();  // Uses parameterless constructor
Person p2 = new Person("Alice", 30);  // Uses parameterized constructor
Person p3 = new Person("Bob");  // Calls parameterized with default age
```
This example demonstrates a class with multiple constructors: a default one, a parameterized one, one that chains to another constructor, and a static constructor that initializes class-level data.

Key points to mention
- Constructors must have the same name as the class and no return type
- You can overload constructors with different parameter lists
- Use this() to call another constructor in the same class (constructor chaining)
- Static constructors run once before any instance is created and cannot have parameters
- Classes and structs both support constructors, though structs have special rules for parameterless constructors
Common follow-up questions
- What is the difference between a constructor and a finalizer/destructor?
- Can a constructor be private, and if so, why would you do that?
- What happens if you don't define a constructor?
Related interview questions
Further reading
- Primary constructors in C# 12
.NETCsharp
22What is a primary constructor in C# 12?
Beginner
A primary constructor is a C# 12 feature that allows you to declare constructor parameters directly in the class declaration. These parameters are automatically available as fields throughout the entire class, eliminating the need for manual field declarations and assignments. This reduces boilerplate code, particularly for dependency injection scenarios.

How it works

In C# 12, you can append parameter declarations directly to the class name using parentheses, similar to how method signatures work. The parameters become implicitly captured and accessible throughout the class scope without requiring explicit backing fields or properties. The compiler generates the constructor logic automatically.

When you declare a primary constructor parameter, it has class scope and can be used in field initializers, property initializers, and all instance methods. The parameters are read-only by default, ensuring immutability and thread safety. If you need custom constructor logic beyond parameter capture, you can still define an explicit constructor body using a colon syntax.

Primary constructors work seamlessly with inheritance, record types, and both reference and value types. They integrate naturally with nullable reference types and property initialization patterns, making them ideal for dependency injection, data carrier classes, and services that depend on external components.

Example
csharp
```
// Without primary constructor (traditional approach)
public class OrderService
{
    private readonly IOrderRepository _repository;
    private readonly ILogger<OrderService> _logger;

    public OrderService(IOrderRepository repository, ILogger<OrderService> logger)
    {
        _repository = repository;
        _logger = logger;
    }

    public async Task<Order?> GetOrderAsync(int id)
    {
        _logger.LogInformation("Fetching order {OrderId}", id);
        return await _repository.GetByIdAsync(id);
    }
}

// With primary constructor (C# 12)
public class OrderService(IOrderRepository repository, ILogger<OrderService> logger)
{
    public async Task<Order?> GetOrderAsync(int id)
    {
        logger.LogInformation("Fetching order {OrderId}", id);
        return await _repository.GetByIdAsync(id);
    }
}
```
In the primary constructor version, the repository and logger parameters are automatically available throughout the class without declaring backing fields or assignment statements.

Key points to mention
- Reduced boilerplate: Primary constructors eliminate repetitive field declarations and assignments, making code more concise, especially for dependency injection scenarios.
- Class-scoped parameters: Parameters are implicitly available throughout the entire class, including in property initializers, field initializers, and all methods.
- Read-only by default: Primary constructor parameters are read-only, promoting immutability and thread safety without additional effort.
- Inheritance support: Derived classes must explicitly call the base class primary constructor, maintaining clear dependency flow in inheritance hierarchies.
- Optional explicit constructor body: You can still add custom constructor logic using explicit constructor syntax if needed beyond parameter capture.
Common follow-up questions
- Can primary constructors have default values? Yes, you can use default parameter values in primary constructors just like regular method parameters, but this pattern is less common since most frameworks expect all dependencies to be explicitly provided.
- How do primary constructors interact with inheritance? Derived classes must explicitly invoke the base class primary constructor using the base() syntax; parameters are not inherited automatically.
- Are primary constructor parameters the same as properties? No; they are implicitly captured as class-scoped variables. If you need public access, you must explicitly declare properties in addition to the primary constructor.
Related interview questions
Further reading
- Primary constructors in C# 12
- Dependency injection is a pattern too
.NETCsharpSecuritydependency-injection
23What are properties in C#?
Beginner
Properties are members of a class that expose controlled access to data through getter and setter accessors. They provide a clean, object-oriented way to read and write values while maintaining encapsulation. Auto-properties simplify syntax by automatically generating backing fields, and the init accessor allows values to be set only during object initialization, supporting immutability patterns.

How it works

Properties bridge the gap between fields and methods. When you access a property, you're actually calling methods (get and set accessors) behind the scenes, but the syntax looks like direct field access. This allows you to add validation, logging, or other logic without changing the public interface.

A property has two main accessors: get returns a value and set assigns a value. You can control access levels independently—for example, a public getter with a private setter. Auto-properties (introduced in C# 3.0) automatically create a hidden backing field, eliminating boilerplate code. The init accessor (C# 9.0+) restricts assignment to the initialization phase, enabling immutable object patterns. Properties are part of encapsulation, a core principle of object-oriented design.

Example
csharp
```
public class Person
{
    // Auto-property with private setter
    public string Name { get; private set; }
    
    // Full property with validation
    private int _age;
    public int Age
    {
        get { return _age; }
        set { _age = value >= 0 ? value : throw new ArgumentException("Age cannot be negative"); }
    }
    
    // Init-only property (immutable after construction)
    public string Email { get; init; }
    
    public Person(string name, string email)
    {
        Name = name;
        Email = email;
    }
}

// Usage
var person = new Person("Alice", "alice@example.com") { Email = "newemail@example.com" };
// person.Email = "another@example.com"; // Error: init-only property cannot be set
person.Age = 25; // Valid
// person.Age = -5; // Error: throws ArgumentException
```
This example demonstrates three property patterns: an auto-property with a private setter for controlled initialization, a full property with validation logic in the setter, and an init-only property for immutable data after construction.

Key points to mention
- Properties provide encapsulation by allowing you to control read/write access and add logic without exposing internal implementation details.
- Auto-properties simplify syntax when no special logic is needed; the compiler generates a private backing field automatically.
- get and set can have different access levels (e.g., public get, private set) to enforce controlled mutation.
- The init accessor (C# 9+) enables immutability by allowing assignment only during object initialization, supporting modern patterns like immutable records.
- Properties are different from fields; properties are computed/controlled access points, while fields are raw data storage.
Common follow-up questions
- When would you use a property versus a field? Always prefer properties for public members because they provide encapsulation and allow future validation without breaking the API.
- Can a property be abstract or virtual? Yes, properties can be declared as abstract or virtual in base classes to force or allow derived classes to override their behavior.
- What is the performance difference between properties and fields? Modern .NET compilers optimize auto-properties to near-field performance; any difference is negligible in real applications.
Related interview questions
Further reading
- The pipeline pattern
.NETCsharp
24What is the difference between a field and a property?
Beginner
A field is a raw data member that directly stores a value, while a property is a wrapper around field access that provides controlled get and set accessors. Properties allow you to add logic, validation, and change implementation without breaking your public API, making them the preferred choice for class members in modern C#.

How it works

A field is simply a variable declared directly in a class or struct. It holds data and nothing more. When you access a field, you are directly reading from or writing to that memory location.

A property is a member that wraps field access through accessor methods called get and set. The get accessor runs when you read the property; the set accessor runs when you assign a value. This indirection allows you to:
- Add validation logic before accepting a new value
- Perform side effects (logging, notifying observers, updating related fields)
- Compute a value on-the-fly without storing it
- Change the internal implementation without changing the public interface
- Implement data binding in UI frameworks
Because properties feel syntactically like fields (you use dot notation to access them), they provide a clean abstraction while maintaining encapsulation—a core object-oriented principle.

Example
csharp
```
public class User
{
    // Raw field – direct access, no control
    private int _age;

    // Property wrapping the field with validation
    public int Age
    {
        get { return _age; }
        set
        {
            if (value < 0 || value > 150)
                throw new ArgumentException("Age must be between 0 and 150");
            _age = value;
        }
    }

    // Auto-property – no explicit backing field needed
    public string Name { get; set; }

    // Computed property – no backing field, returns a calculated value
    public bool IsAdult => Age >= 18;
}

// Usage
var user = new User { Name = "Alice" };
user.Age = 25;  // Validation runs
Console.WriteLine(user.IsAdult);  // True – computed on access
```
This example demonstrates that properties provide a single, consistent interface for accessing data while hiding validation and computation logic from the caller.

Key points to mention
- Encapsulation: Properties enforce the principle that internal state should be protected and accessed only through controlled interfaces
- API stability: You can change a field to a property without recompiling consuming code, but changing a property's name or removing it is a breaking change
- Flexibility: A property can be read-only (get only), write-only (set only), or use different access levels for each accessor (e.g., public get; private set;)
- Auto-properties: C# 3.0+ introduced auto-properties like public string Name { get; set; }, which eliminate boilerplate while still providing property benefits
- Best practice: Expose public data members as properties, not fields—fields are typically private and often back a public property
Common follow-up questions
- What is an auto-property, and when would you use one?
- How do access modifiers apply to properties?
- Can you have a read-only property, and how would you implement it?
Related interview questions
.NETCsharp
25What is method overloading?
Beginner
Method overloading is a feature that allows you to define multiple methods with the same name but different parameter lists (signatures). The compiler determines which method to call at compile time based on the arguments you pass. This is a form of compile-time (static) polymorphism.

How it works

When you overload a method, you create several versions of it that differ by their parameters. The differences can be:
- Number of parameters: Calculate(int a) vs. Calculate(int a, int b)
- Type of parameters: Display(string text) vs. Display(int number)
- Order of parameters: Combine(string first, int second) vs. Combine(int first, string second)
The return type alone cannot be used to differentiate overloaded methods—the compiler wouldn't know which version to call when it sees only the method name. At compile time, the C# compiler analyzes the argument types and counts to select the most specific matching method. If no exact match exists, it attempts implicit conversions to find a suitable candidate.

Example
csharp
```
public class Calculator
{
    // Overload 1: Two integers
    public int Add(int a, int b)
    {
        return a + b;
    }
    
    // Overload 2: Three integers
    public int Add(int a, int b, int c)
    {
        return a + b + c;
    }
    
    // Overload 3: Two doubles
    public double Add(double a, double b)
    {
        return a + b;
    }
    
    // Overload 4: Parameter array (variable length)
    public int Add(params int[] numbers)
    {
        return numbers.Sum();
    }
}

// Usage
var calc = new Calculator();
Console.WriteLine(calc.Add(5, 10));           // Calls Overload 1 → 15
Console.WriteLine(calc.Add(5, 10, 15));       // Calls Overload 2 → 30
Console.WriteLine(calc.Add(5.5, 10.5));       // Calls Overload 3 → 16.0
Console.WriteLine(calc.Add(1, 2, 3, 4, 5));   // Calls Overload 4 → 15
```
The compiler selects the correct Add method based on the argument types and count, making the API more intuitive and readable.

Key points to mention
- Overloading is resolved at compile time, not runtime—this differs from method overriding, which uses runtime polymorphism.
- The method signature (name + parameters) must be unique; return type alone does not create a valid overload.
- Overloading improves code readability and maintainability by using a single, intuitive method name for related operations.
- Use optional parameters and default values carefully alongside overloading to avoid redundant method definitions.
- Overloading works with constructors, operators, and regular methods.
Common follow-up questions
- What's the difference between overloading and overriding? — Overloading creates multiple methods with the same name but different signatures (compile-time); overriding replaces a base class method in a derived class (runtime polymorphism).
- Can you overload a method based only on return type? — No, the compiler cannot determine which overload to call when it sees only the method name and arguments, making return-type-only differences invalid.
- How does the compiler choose the best overload match? — The compiler performs overload resolution by finding the most specific match: exact type match first, then implicit conversions, then params arrays as a last resort.
Related interview questions
Further reading
- Source generators in C#
.NETCsharp
26What is method overriding?
Beginner
Method overriding is a mechanism that allows a derived class to provide a different implementation of a method that already exists in its base class. The derived class uses the override keyword to replace a virtual or abstract base method, enabling runtime polymorphism where the correct method is called based on the actual object type, not the reference type.

How it works

When you declare a method as virtual in a base class, you're signaling that derived classes are permitted to override it with their own implementation. The derived class then uses the override keyword to replace that method. At runtime, when you call the method through a base class reference pointing to a derived class object, .NET uses dynamic dispatch to invoke the overridden method in the derived class, not the base class version.

This is different from method overloading, which creates multiple methods with the same name but different signatures in the same class. Overriding specifically replaces an inherited method with a new implementation.

For virtual, abstract, and override, the relationship is clear: virtual provides a default implementation that can be overridden, abstract requires derived classes to provide an implementation, and override is how you provide that implementation in the derived class.

Example
csharp
```
public class Animal
{
    public virtual void MakeSound()
    {
        Console.WriteLine("Some generic sound");
    }
}

public class Dog : Animal
{
    public override void MakeSound()
    {
        Console.WriteLine("Woof!");
    }
}

public class Cat : Animal
{
    public override void MakeSound()
    {
        Console.WriteLine("Meow!");
    }
}

// Usage
Animal myPet = new Dog();
myPet.MakeSound(); // Output: Woof!

myPet = new Cat();
myPet.MakeSound(); // Output: Meow!
```
This example demonstrates polymorphism in action: the same method call produces different results depending on the actual object type, not the reference type.

Key points to mention
- The base method must be marked virtual or abstract to be overridable; you cannot override a non-virtual method.
- The overridden method must have the same signature (name, parameters, and return type) as the base method.
- Overriding enables runtime polymorphism through late binding—the correct method is resolved at runtime based on the actual object type.
- You can use the sealed keyword to prevent further overriding in derived classes, or mark a method as sealed override to block overriding in subclasses while still overriding the base method.
- The base keyword allows you to call the base class implementation from within the overridden method if needed.
Common follow-up questions
- What is the difference between overriding and overloading?
- Can you override a static method? (Answer: No, static methods are resolved by reference type, not runtime type.)
- What happens if you forget the virtual keyword in the base class? (Answer: The method cannot be overridden; it will be hidden if you use a similar method name in the derived class.)
Related interview questions
Further reading
- Factory method
.NETCsharp
27What is the difference between virtual, abstract and override?
Beginner
Virtual allows derived classes to optionally override a method while providing a default implementation in the base class. Abstract requires derived classes to implement a method—there is no default implementation. Override is the keyword used in derived classes to replace a virtual or abstract method with a new implementation.

How it works

Virtual methods enable polymorphic behavior with a safety net. When you mark a method as virtual, you're saying "derived classes may override this, but they don't have to." The base class provides working code, so if a derived class doesn't override it, the base implementation runs. This is useful when you have sensible default behavior that some subclasses might customize.

Abstract methods are the opposite. They define a contract that every derived class must fulfill. An abstract method has no body—it's purely a signature. The derived class is forced to provide an implementation using the override keyword. Abstract methods must live inside an abstract class, and you cannot instantiate an abstract class directly.

Override is the mechanism that fulfills the contract. When a derived class implements a virtual or abstract method, it uses the override keyword to signal that it's intentionally replacing the base class behavior. Without override, you're just creating a new method that hides the base method—which is usually a mistake.

Example
csharp
```
abstract class Animal
{
    // Virtual: optional to override, has default behavior
    public virtual void MakeSound()
    {
        Console.WriteLine("Some generic animal sound");
    }

    // Abstract: must override, no implementation
    public abstract void Move();
}

class Dog : Animal
{
    // Override virtual method
    public override void MakeSound()
    {
        Console.WriteLine("Woof!");
    }

    // Must override abstract method
    public override void Move()
    {
        Console.WriteLine("Dog runs on four legs");
    }
}

class Bird : Animal
{
    // Don't override MakeSound—uses base implementation implicitly
    // But could override if needed

    // Must override abstract Move
    public override void Move()
    {
        Console.WriteLine("Bird flies with wings");
    }
}

// Usage
Animal myDog = new Dog();
myDog.MakeSound(); // Output: Woof!
myDog.Move();      // Output: Dog runs on four legs

Animal myBird = new Bird();
myBird.MakeSound(); // Output: Some generic animal sound
myBird.Move();      // Output: Bird flies with wings
```
This example demonstrates that Dog overrides both methods, while Bird only overrides Move and inherits the default MakeSound—showing the difference between mandatory (abstract) and optional (virtual) overrides.

Key points to mention
- Virtual = optional override: Provides default behavior; derived classes can customize but don't have to.
- Abstract = mandatory override: No implementation provided; every derived class must implement it.
- Override keyword = fulfillment: Used in derived classes to replace base behavior and avoid the accidental method hiding that occurs without it.
- Abstract classes only: Abstract methods can only exist inside abstract classes; you cannot instantiate abstract classes directly.
- Polymorphism enabler: Both virtual and abstract enable runtime polymorphism—the correct override is called based on the actual object type, not the reference type. See method overriding for more details.
Common follow-up questions
- Can you use override without virtual or abstract? No—you can only override a virtual or abstract member. If you define a new method with the same signature without override, you're hiding (shadowing) the base method, which is usually unintended.
- What's the difference between abstract classes and interfaces? See abstract class vs. interface. In short: abstract classes can have state and constructors; interfaces define contracts only.
- Can an abstract class have non-abstract methods? Yes—abstract classes can mix abstract methods (that must be overridden) with virtual or concrete methods (that provide default behavior).
Related interview questions
.NETCsharp
28What is an interface?
Beginner
An interface defines a contract that specifies which members (methods, properties, events, and indexers) a type must implement. Classes and structs can implement one or more interfaces, allowing you to define a blueprint for behavior without providing implementation details. Interfaces enable loose coupling, polymorphism, and make code more testable and maintainable.

How it works

An interface is declared using the interface keyword and contains only member signatures—no implementation. When a class or struct implements an interface, it must provide concrete implementations for all members defined by that interface. This creates a contract: "if you claim to implement this interface, you must provide these capabilities."

Interfaces support multiple inheritance—a single type can implement multiple interfaces simultaneously. This is one of the key differences from abstract classes, which allow only single inheritance. Interfaces promote loose coupling because code can depend on an interface rather than a concrete implementation, making it easier to swap implementations and write unit tests with mock objects.

Starting with C# 8.0, interfaces can include default implementations for methods, allowing you to add new members to an interface without breaking existing implementations. However, the core purpose remains defining a contract.

Example
csharp
```
// Define an interface contract
public interface IPaymentProcessor
{
    decimal ProcessPayment(decimal amount);
    string GetStatus();
}

// Implement the interface in a class
public class CreditCardProcessor : IPaymentProcessor
{
    public decimal ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing credit card payment: ${amount}");
        return amount;
    }

    public string GetStatus()
    {
        return "Credit card ready";
    }
}

// Another implementation of the same interface
public class PayPalProcessor : IPaymentProcessor
{
    public decimal ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing PayPal payment: ${amount}");
        return amount * 0.99m; // 1% fee
    }

    public string GetStatus()
    {
        return "PayPal connected";
    }
}

// Use any implementation through the interface
class Program
{
    static void Main()
    {
        IPaymentProcessor processor = new CreditCardProcessor();
        processor.ProcessPayment(100);
        
        processor = new PayPalProcessor();
        processor.ProcessPayment(100);
    }
}
```
This example demonstrates how two different classes implement the same IPaymentProcessor interface, providing their own versions of payment processing. Code using the interface doesn't need to know which implementation it's working with—it only depends on the contract.

Key points to mention
- Contract definition: Interfaces define what members must exist, not how they work.
- Multiple implementation: A class can implement multiple interfaces, unlike abstract classes which support only single inheritance.
- Loose coupling: Code depending on interfaces rather than concrete classes is more flexible, testable, and maintainable.
- Polymorphism: Different implementations can be used interchangeably wherever the interface type is expected.
- Default implementations (C# 8+): Interfaces can now include method bodies, though this is optional and less common.
Common follow-up questions
- What is the difference between an interface and an abstract class?
- Can a struct implement an interface?
- What's the purpose of using interfaces in dependency injection?
Related interview questions
.NETCsharpTesting
29What is the difference between an abstract class and an interface?
Beginner
Abstract classes define a base template for derived classes with shared state and logic, allowing only single inheritance. Interfaces define contracts that classes must implement and support multiple inheritance, making them ideal for defining capabilities without enforcing implementation details. In modern C#, the distinction has blurred somewhat with default interface methods, but the intent remains: abstract classes represent "is-a" relationships, while interfaces represent "can-do" capabilities.

How it works

An abstract class serves as a blueprint for a family of related classes. It can contain abstract methods (which must be overridden), concrete methods (with implementations), fields, constructors, and access modifiers like protected or private. When a class inherits from an abstract class, it commits to implementing all abstract members and gains access to shared logic and state. However, C# allows a class to inherit from only one abstract class.

An interface, by contrast, is a contract that specifies what methods and properties a class must provide, but not necessarily how. Interfaces cannot hold state (no instance fields) and traditionally contained only method signatures. Since C# 8.0, interfaces can include default implementations and static members, giving them more flexibility. Critically, a class can implement multiple interfaces, allowing it to adopt many different contracts simultaneously.

Use abstract classes when you have a clear hierarchy with shared code, constructor logic, or state management. Use interfaces when you want to define a capability that unrelated classes should provide, or when you need multiple inheritance of contract.

Example
csharp
```
// Abstract class: represents a family of animals with shared behavior
public abstract class Animal
{
    protected string Name { get; set; } // State
    
    protected Animal(string name)
    {
        Name = name; // Constructor logic
    }
    
    // Abstract method: derived classes must implement
    public abstract void Speak();
    
    // Concrete method: shared logic
    public void Sleep()
    {
        Console.WriteLine($"{Name} is sleeping.");
    }
}

// Interface: represents the capability to fly
public interface IFlyable
{
    void Fly();
    void Land();
}

// Concrete class: inherits from one abstract class, implements multiple interfaces
public class Bird : Animal, IFlyable
{
    public Bird(string name) : base(name) { }
    
    public override void Speak()
    {
        Console.WriteLine($"{Name} chirps.");
    }
    
    public void Fly()
    {
        Console.WriteLine($"{Name} is flying.");
    }
    
    public void Land()
    {
        Console.WriteLine($"{Name} lands.");
    }
}

// Usage
var bird = new Bird("Sparrow");
bird.Speak();   // Output: Sparrow chirps.
bird.Sleep();   // Output: Sparrow is sleeping.
bird.Fly();     // Output: Sparrow is flying.
```
This example shows that Bird inherits from Animal (gaining state and shared logic) and implements IFlyable (satisfying a capability contract). It can do this because C# supports multiple interface implementation but single class inheritance.

Key points to mention
- Inheritance model: Abstract classes support single inheritance; interfaces support multiple implementation.
- State management: Abstract classes can hold instance fields and maintain state; interfaces cannot hold instance state (though they can have constants and, since C# 8, static fields).
- Constructors: Abstract classes can have constructors to initialize state; interfaces cannot.
- Access modifiers: Abstract class members can be private, protected, internal, or public; interface members are implicitly public (with private implementation in C# 8+).
- Purpose: Abstract classes model "is-a" hierarchies with shared behavior; interfaces define "can-do" capabilities independent of hierarchy.
Common follow-up questions
- Can an interface have constructors? (No, but a class implementing an interface can.)
- Can an abstract class implement an interface? (Yes, and often does to define default behavior for that interface.)
- What is the difference between a virtual method in a base class and a method in an interface? (Virtual methods provide optional overrides with a default implementation; interface methods enforce a contract, though C# 8+ defaults blur this distinction.)
Related interview questions
Further reading
- Primary constructors in C# 12
- Single Responsibility, practically
.NETCsharp
30What are the four pillars of OOP?
Beginner
The four pillars of Object-Oriented Programming are encapsulation, abstraction, inheritance, and polymorphism. These foundational concepts enable developers to write maintainable, scalable, and reusable code by organizing data and behavior into logical, self-contained units. Together, they form the backbone of how we design and structure applications in languages like C#.

How it works

Encapsulation bundles data (fields) and methods together into a class, hiding internal implementation details behind access modifiers (private, protected, public). This protects the object's state from unintended external modification and allows controlled access through properties or methods.

Abstraction exposes only the essential features of an object while concealing complex implementation details. It allows you to interact with objects at a high level without needing to understand how they work internally. Abstract classes and interfaces are key tools for achieving abstraction.

Inheritance enables a class (derived class) to inherit properties and methods from another class (base class), promoting code reuse and establishing hierarchical relationships. A child class can extend or override parent behavior, reducing duplication and improving maintainability.

Polymorphism allows objects of different types to be treated through a common interface or base class. This enables flexible, extensible code where the specific implementation is determined at runtime based on the actual object type, supporting both method overriding and method overloading.

Example
csharp
```
// Encapsulation: private fields, public property
// Abstraction: abstract base class hides implementation details
public abstract class Animal
{
    private string _name;
    
    public string Name
    {
        get => _name;
        set => _name = value;
    }
    
    // Abstraction: abstract method defines contract
    public abstract void MakeSound();
}

// Inheritance: Dog inherits from Animal
public class Dog : Animal
{
    // Polymorphism: override abstract method
    public override void MakeSound()
    {
        Console.WriteLine($"{Name} barks!");
    }
}

public class Cat : Animal
{
    public override void MakeSound()
    {
        Console.WriteLine($"{Name} meows!");
    }
}

// Usage
Animal dog = new Dog { Name = "Buddy" };
Animal cat = new Cat { Name = "Whiskers" };

dog.MakeSound(); // Output: Buddy barks!
cat.MakeSound(); // Output: Whiskers meows!
```
This example demonstrates all four pillars: encapsulation via the private _name field and public Name property, abstraction through the Animal abstract class, inheritance with Dog and Cat extending Animal, and polymorphism by calling MakeSound() on different animal types through the common Animal interface.

Key points to mention
- Encapsulation protects object integrity by controlling access to internal state, reducing bugs and unintended side effects.
- Abstraction simplifies code by hiding complexity, making systems easier to understand and maintain.
- Inheritance promotes the DRY (Don't Repeat Yourself) principle, allowing shared functionality to be defined once in a base class.
- Polymorphism enables flexible, loosely-coupled designs where new types can be added without changing existing code that uses the base interface.
- These pillars work together: encapsulation and abstraction reduce complexity, inheritance enables code reuse, and polymorphism creates extensibility.
Common follow-up questions
- What is the difference between method overloading and method overriding? (Both are forms of polymorphism; overloading occurs at compile-time, overriding at runtime.)
- How do abstract classes differ from interfaces in achieving abstraction? (See this related question for a detailed comparison.)
- Can you explain the SOLID principles in relation to OOP pillars? (SOLID builds on these pillars to create even more maintainable designs.)
Related interview questions
Further reading
- Flyweight pattern
.NETCsharp
31What is encapsulation?
Beginner
Encapsulation is the practice of bundling data (fields) and behavior (methods) together while hiding internal implementation details behind a public interface. It protects an object's state from unauthorized or invalid changes by controlling access through properties and methods, making code more maintainable and reducing unintended side effects.

How it works

Encapsulation operates on the principle of information hiding. You declare fields as private so external code cannot directly access or modify them. Instead, you expose controlled access through public properties, methods, or events. This creates a boundary between the internal state of an object and the outside world.

The key benefit is protecting invariants—the rules that must always be true for your object to work correctly. For example, a bank account balance should never be negative. By hiding the balance field and only allowing withdrawals through a validated method, you guarantee this invariant is maintained. If the balance were public, any code could set it to an invalid value.

Encapsulation also makes code easier to refactor. If the internal implementation changes—say you switch from storing a single balance to storing transactions and computing balance on-demand—external code doesn't break because it only depends on the public interface, not the private details.

Example
csharp
```
public class BankAccount
{
    private decimal _balance;
    
    public string AccountHolder { get; }
    public decimal Balance 
    { 
        get => _balance;
        private set => _balance = value;
    }
    
    public BankAccount(string accountHolder, decimal initialBalance)
    {
        AccountHolder = accountHolder;
        Balance = initialBalance;
    }
    
    public void Deposit(decimal amount)
    {
        if (amount <= 0)
            throw new ArgumentException("Deposit must be positive");
        
        Balance += amount;
    }
    
    public bool Withdraw(decimal amount)
    {
        if (amount <= 0 || amount > Balance)
            return false;
        
        Balance -= amount;
        return true;
    }
}
```
The _balance field is private and can only change through validated Deposit and Withdraw methods, ensuring the balance never becomes invalid. The Balance property has a private setter so external code cannot bypass these rules.

Key points to mention
- Encapsulation is one of the four pillars of OOP, alongside inheritance, polymorphism, and abstraction.
- Use access modifiers (private, public, protected) to control visibility and enforce boundaries.
- Properties with getters and setters provide a cleaner syntax than traditional getter/setter methods while still allowing validation logic.
- Encapsulation protects object invariants and reduces coupling between classes, making code more maintainable and testable.
- It enables you to change internal implementation without affecting code that depends on the public interface.
Common follow-up questions
- Why use properties instead of just public fields?
- How does encapsulation relate to enforcing aggregate invariants in domain-driven design?
- What is the difference between encapsulation and abstraction?
Related interview questions
Further reading
- Validation with FluentValidation
- SOLID in one carousel
.NETCsharpSecurity
32What is polymorphism?
Beginner
Polymorphism is the ability of objects to take on multiple forms and allows you to write code that can work with objects of different types through a common base type or interface. At runtime, the actual object's type determines which method implementation is executed, enabling flexible and extensible code design.

How it works

Polymorphism operates through the principle that a variable of a base class or interface type can reference objects of derived classes. When you call a method on that variable, the CLR (Common Language Runtime) uses late binding to determine which implementation to execute based on the actual runtime type of the object, not the variable's declared type.

There are two main forms of polymorphism in C#:
- Compile-time (Static) Polymorphism: Method overloading, where multiple methods share the same name but have different parameters. The compiler resolves which method to call based on the arguments provided.
- Runtime (Dynamic) Polymorphism: Method overriding, where a derived class provides a different implementation of a base class method marked as virtual. The runtime determines which implementation to execute.
Polymorphism works hand-in-hand with method overriding to create extensible and maintainable code that adheres to the Open/Closed Principle—open for extension through inheritance, closed for modification.

Example
csharp
```
using System;

abstract class Animal
{
    public virtual void Speak()
    {
        Console.WriteLine("Animal makes a sound");
    }
}

class Dog : Animal
{
    public override void Speak()
    {
        Console.WriteLine("Dog barks: Woof!");
    }
}

class Cat : Animal
{
    public override void Speak()
    {
        Console.WriteLine("Cat meows: Meow!");
    }
}

class Program
{
    static void Main()
    {
        Animal dog = new Dog();
        Animal cat = new Cat();
        
        dog.Speak();  // Outputs: Dog barks: Woof!
        cat.Speak();  // Outputs: Cat meows: Meow!
        
        // Process any animal
        ProcessAnimal(dog);
        ProcessAnimal(cat);
    }
    
    static void ProcessAnimal(Animal animal)
    {
        animal.Speak();  // Correct method called based on actual type
    }
}
```
This example shows runtime polymorphism: variables of type Animal hold Dog and Cat objects, and calling Speak() executes the correct overridden method for each actual type.

Key points to mention
- Polymorphism requires a base class or interface; derived classes override or implement methods to provide specific behavior.
- The actual runtime type of the object determines which method implementation executes, not the variable's declared type.
- Polymorphism reduces code duplication and makes code more flexible—you can add new types without changing existing code that uses the base type.
- Use virtual keyword in the base class and override in derived classes to enable runtime polymorphism.
- Interfaces are a powerful way to achieve polymorphism without inheritance; multiple types can implement the same interface differently.
Common follow-up questions
- What's the difference between virtual and abstract methods? (Abstract forces implementation in derived classes; virtual provides a default that can be overridden.)
- How does polymorphism relate to the four pillars of OOP? (It's one of the core pillars; the others are encapsulation, inheritance, and abstraction.)
- Can you use polymorphism with interfaces? (Yes, interfaces are even more flexible than base classes for achieving polymorphic behavior.)
Related interview questions
Further reading
- Compound components
.NETCsharp
33What is the sealed keyword?
Beginner
The sealed keyword prevents a class from being inherited or a method from being overridden further. It explicitly communicates that a type is not designed for extension and can unlock small JIT compilation optimizations by allowing devirtualization.

How it works

When you mark a class as sealed, the compiler prevents any derived class from inheriting it. When you mark a method (or property) as sealed, you prevent further overrides in subclasses—though the method must already be marked virtual or override to seal it.

The sealed keyword serves two purposes. First, it clarifies design intent: the author is saying "this class is complete and not meant to be extended." This makes code easier to reason about and safer to refactor. Second, it enables the JIT compiler to devirtualize method calls and apply inlining more aggressively, since there's no possibility of a derived implementation being called at runtime.

Most .NET framework classes are sealed by default (like string, int, DateTime) for both safety and performance reasons. You should consider sealing your own classes unless you explicitly design them for inheritance.

Example
csharp
```
// Sealed class—cannot be inherited
public sealed class PaymentProcessor
{
    public virtual void Process(decimal amount) { }
}

// This will not compile
// public class CreditCardProcessor : PaymentProcessor { }  // Error!

// Sealed method—prevents further override in subclasses
public class DataService
{
    public virtual void Fetch() { }
}

public class CachedDataService : DataService
{
    public sealed override void Fetch()
    {
        // This is the final implementation; no subclass can override it
    }
}

// This will not compile
// public class LoggedCachedDataService : CachedDataService
// {
//     public override void Fetch() { }  // Error!
// }
```
The first class prevents any inheritance; the sealed method in the subclass prevents further overrides down the chain, while still allowing the class itself to be inherited.

Key points to mention
- sealed class prevents inheritance entirely; sealed override prevents further overrides of a specific method in derived types.
- Sealing enables JIT optimizations by removing the possibility of polymorphic dispatch, allowing devirtualization and inlining.
- Most built-in .NET types (String, DateTime, Int32) are sealed to protect their invariants and improve performance.
- Seal by default unless you explicitly design a class for inheritance; this follows the principle of "make it hard to misuse."
- Sealed does not affect static members, constructors, or internal implementation—only inheritance and override relationships.
Common follow-up questions
- Why would you seal a method but not the class? — To allow subclasses to exist and override some members, but lock down a specific method that has no safe alternative implementation path.
- Does sealing improve performance in all cases? — Not dramatically in everyday code, but it removes a source of virtual dispatch overhead and signals to the JIT that devirtualization is safe, which matters in hot paths.
- Can you seal a static member or constructor? — No, static members and constructors are not virtual by nature, so sealing does not apply to them.
Related interview questions
Further reading
- Factory method
.NETCsharpPerformanceArchitecture
34What is a namespace?
Beginner
A namespace is a container that organizes types (classes, interfaces, structs, enums, delegates) and prevents naming conflicts by creating a logical hierarchy. In C#, namespaces allow you to group related code and avoid collisions when multiple developers or libraries define types with the same name. Modern C# (7.10+) supports file-scoped namespaces, which eliminate excessive indentation.

How it works

Namespaces create a fully qualified name for each type by prefixing it with the namespace path. For example, a class User in the namespace Company.Services is fully qualified as Company.Services.User. Two different namespaces can both contain a User class without conflict because they are distinguishable by their full names.

You access types in a namespace either by using their fully qualified name or by importing the namespace with a using directive at the top of your file. Namespaces can be nested, creating a hierarchical organization that mirrors your project structure. The .NET Framework itself uses deep namespace hierarchies—for example, System.Collections.Generic or Microsoft.AspNetCore.Mvc—to organize its vast library of types.

File-scoped namespaces, introduced in C# 11, simplify syntax by allowing you to declare a single namespace for an entire file with namespace MyNamespace; instead of wrapping all code in braces. This reduces indentation and improves readability, especially for single-namespace files.

Example
csharp
```
// File-scoped namespace (C# 11+)
namespace Company.Services;

public class UserService
{
    public void CreateUser(string name)
    {
        Console.WriteLine($"Creating user: {name}");
    }
}

// Another file
namespace Company.Data;

public class UserRepository
{
    public void SaveUser(string name)
    {
        Console.WriteLine($"Saving user: {name}");
    }
}

// Usage in main program
using Company.Services;
using Company.Data;

var service = new UserService();
var repo = new UserRepository();

service.CreateUser("Alice");
repo.SaveUser("Alice");
```
This example demonstrates two separate namespaces (Company.Services and Company.Data) each containing different types, and how using directives make them accessible without fully qualified names.

Key points to mention
- Namespaces prevent naming collisions—multiple libraries can define a Logger class as long as they are in different namespaces.
- The fully qualified name includes the complete namespace path; using directives allow you to omit the prefix for brevity.
- Namespaces are hierarchical and typically mirror your project folder structure for maintainability (e.g., MyApp.Features.Auth.Services).
- File-scoped namespaces (C# 11+) use namespace X; syntax and apply to the entire file, reducing nesting and indentation.
- Namespaces are purely a logical organization tool; they do not affect runtime performance or memory usage.
Common follow-up questions
- What is the difference between a namespace and a class? A namespace is a logical grouping container; a class is a type that can be instantiated and contains members.
- How do global using directives work? They allow you to import a namespace once in a central file so it is available to all files in your project.
- Can namespaces span multiple files? Yes; you can declare the same namespace in several files, and all types from those files are considered part of that namespace.
Related interview questions
- What are global using directives?
- What is the sealed keyword?
Further reading
- Program.cs, line by line
.NETCsharpArchitecturedependency-injection
35What are global using directives?
Beginner
Global using directives are a C# 10+ feature that imports a namespace for your entire project, eliminating the need to repeat using statements in every file. In SDK-style projects (the modern standard), implicit usings automatically add common namespaces like System, System.Linq, and System.Collections.Generic without you writing anything at all.

How it works

When you declare a global using directive with the global keyword, the compiler makes that namespace available throughout your entire project. You typically place these in a dedicated file (often called GlobalUsings.cs or Usings.cs) rather than scattering them across multiple files.

Implicit usings go a step further. When you create a new SDK-style project (which uses a modern .csproj file), the project is configured with <ImplicitUsings>enable</ImplicitUsings>. This automatically adds a set of common namespaces based on your project type. For example, a console application automatically includes System, System.IO, System.Threading, and others—you don't have to write them. You can see exactly which namespaces are implicitly included by examining the generated *.GlobalUsings.g.cs file in your obj folder.

This feature reduces boilerplate and makes code cleaner, especially in larger projects where the same namespaces appear in every file.

Example
csharp
```
// GlobalUsings.cs
global using System;
global using System.Collections.Generic;
global using System.Linq;
global using MyProject.Models;
global using MyProject.Services;

// Program.cs (no using statements needed!)
var items = new List<string> { "apple", "banana", "cherry" };
var filtered = items.Where(x => x.Length > 5).ToList();
Console.WriteLine($"Found {filtered.Count} items");
```
The GlobalUsings.cs file declares all namespaces once for the entire project, so Program.cs can use List<T>, LINQ methods, and custom project namespaces without any using statements.

Key points to mention
- C# 10+ feature: Global usings are only available in .NET 6+ projects; they don't work in older Framework projects.
- Implicit usings are default: New SDK-style projects have implicit usings enabled by default, so you automatically get System, System.Linq, and other common namespaces without writing anything.
- Centralized management: Putting all global usings in one file makes it easy to see and manage project-wide dependencies.
- Can be disabled: If you prefer explicit control, you can set <ImplicitUsings>disable</ImplicitUsings> in your .csproj.
- Scope is project-wide: Global usings apply only to the project they're declared in; they don't leak to other projects that reference it.
Common follow-up questions
- Can I disable implicit usings? Yes—add <ImplicitUsings>disable</ImplicitUsings> to your .csproj if you want full control over every namespace.
- How do I see what namespaces are implicitly included? Build your project and look at obj/Debug/net8.0/ProjectName.GlobalUsings.g.cs (the exact path depends on your target framework).
- Are global usings the same as using static? No—global using imports a namespace, while using static imports static members from a specific type.
Related interview questions
Further reading
- Project to DTOs with Select
.NETCsharp
36What is the difference between == and Equals?
Beginner
The core difference is that == is an operator that compares references by default for reference types, while Equals() is a virtual method that can be overridden to implement custom equality logic. For value types, == and Equals() both compare values, but strings and records override both operators to compare by value despite being reference types.

How it works

== is an operator defined on specific types. For most reference types like classes, it performs reference equality by default—checking if both variables point to the same object in memory. However, the behavior of == can be overloaded, and many built-in types do override it. For example, string overloads == to compare the actual text content rather than object references.

Equals() is a virtual method inherited from System.Object. By default, it performs reference equality for classes and value equality for structs. Unlike ==, Equals() can always be overridden in derived classes to implement custom comparison logic. This makes it more flexible for defining what "equality" means in your domain.

Strings override both == and Equals() to compare content. Records, introduced in C# 9, automatically override both to provide value-based equality by comparing their properties rather than their references.

Example
csharp
```
// Reference type (class)
class Person
{
    public string Name { get; set; }
    
    public override bool Equals(object obj)
    {
        return obj is Person p && p.Name == Name;
    }
    
    public override int GetHashCode() => Name.GetHashCode();
}

// Test
var person1 = new Person { Name = "Alice" };
var person2 = new Person { Name = "Alice" };
var person3 = person1;

// Different references, same content
Console.WriteLine(person1 == person2);        // False (different objects)
Console.WriteLine(person1.Equals(person2));   // True (overridden for value equality)

// Same reference
Console.WriteLine(person1 == person3);        // True (same object)
Console.WriteLine(person1.Equals(person3));   // True

// String comparison (overloaded == and Equals)
var str1 = new string(new[] { 'A', 'B' });
var str2 = new string(new[] { 'A', 'B' });
Console.WriteLine(str1 == str2);              // True (content comparison)
Console.WriteLine(str1.Equals(str2));         // True
```
This example shows how == defaults to reference equality for custom classes, while Equals() can be overridden to compare by value. Strings behave differently due to their overloaded operators.

Key points to mention
- == is an operator that can be overloaded; by default it compares references for classes and values for structs.
- Equals() is a virtual method from object that can always be overridden to define custom equality regardless of type.
- Strings and records override both == and Equals() to provide value-based comparison.
- If you override Equals(), you should also override GetHashCode() and consider overloading == for consistency.
- Equals() is safer for polymorphic comparisons because it's virtual and cannot cause unexpected behavior through operator overloading.
Common follow-up questions
- Why should you override GetHashCode() when you override Equals()?
- What's the difference between Equals() and ReferenceEquals()?
- How do classes and structs differ in their default equality behavior?
Related interview questions
Further reading
- Nullable reference types
- Value objects
.NETCsharp
37Why are strings immutable in .NET?
Beginner
Strings in .NET are immutable because once created, their value cannot be changed. Every operation that appears to modify a string actually creates a new string object. This design choice provides significant benefits including thread safety, performance optimization through interning, and safe usage as dictionary keys without worrying about value changes.

How it works

When you declare a string in .NET, it's stored in memory with a fixed character sequence. The System.String class is sealed and its internal character array cannot be modified after creation. This is enforced at the CLR level—there are no public methods that allow you to change a string's content in place.

When you perform operations like concatenation, substring extraction, or case conversion, the CLR creates an entirely new string object with the result and returns a reference to it. The original string remains unchanged in memory. This immutability guarantee means multiple references can safely point to the same string without fear that one caller might change it for another.

The .NET runtime also implements string interning—a optimization where identical string literals and many string values are stored only once in the intern pool. Since strings cannot change, the runtime can confidently reuse the same memory location for multiple references, reducing memory pressure and improving performance.

Example
csharp
```
string original = "Hello";
string modified = original.ToUpper();

Console.WriteLine(original);  // Output: Hello (unchanged)
Console.WriteLine(modified);  // Output: HELLO (new string)

// Each operation creates a new string
string s1 = "dotnet";
string s2 = s1 + " rocks";
string s3 = s1 + " rocks";

Console.WriteLine(ReferenceEquals(s2, s3));  // Output: True (interned)
Console.WriteLine(ReferenceEquals(s1, s2));  // Output: False (different strings)
```
This demonstrates that ToUpper() returns a new string while the original remains "Hello", and identical strings may share the same memory through interning.

Key points to mention
- Thread safety—multiple threads can safely access the same string reference without synchronization because no thread can modify it.
- Dictionary key safety—strings can be reliably used as dictionary keys since their hash code won't change unexpectedly during the key's lifetime.
- Performance cost—frequent string modifications through concatenation create many intermediate objects; use StringBuilder for heavy concatenation to avoid this overhead.
- Memory efficiency—string interning means duplicate strings share memory, reducing overall allocation.
- Predictable behavior—immutability eliminates entire classes of bugs where unexpected string mutations cause hard-to-trace issues.
Common follow-up questions
- What is the difference between string and StringBuilder, and when should each be used?
- How does string interning work, and can you control it programmatically?
- If strings are immutable, why can string interpolation appear to modify a string?
Related interview questions
Further reading
- Strings: StringBuilder and interpolation
- Raw SQL in EF Core, safely
.NETCsharpasync
38When should you use StringBuilder?
Beginner
Use StringBuilder when concatenating strings in loops or combining many string pieces. Since strings are immutable in .NET, each concatenation creates a new string object. StringBuilder buffers changes in memory and builds the final string once, dramatically reducing memory allocations and improving performance.

How it works

Strings in .NET are immutable, meaning once created, they cannot be changed. When you use the + operator or string concatenation, the runtime creates a brand new string object containing the combined result. This is inefficient when done repeatedly because each operation allocates memory, copies data, and discards the old string.

StringBuilder, part of the System.Text namespace, maintains an internal character buffer that can grow dynamically. Instead of creating new objects with each addition, StringBuilder appends content to this mutable buffer. Only when you call ToString() does it create the final immutable string. This approach minimizes allocations and garbage collection pressure, resulting in significant performance gains for operations involving many concatenations.

Example
csharp
```
// Bad: Creates 100 string objects
string result = "";
for (int i = 0; i < 100; i++)
{
    result += "Item " + i + ", ";
}

// Good: Uses StringBuilder efficiently
var sb = new StringBuilder();
for (int i = 0; i < 100; i++)
{
    sb.Append("Item ").Append(i).Append(", ");
}
string result = sb.ToString();
```
The StringBuilder version performs the same loop but creates only one final string object, while the concatenation version creates approximately 100 intermediate strings that must be garbage collected.

Key points to mention
- StringBuilder is most beneficial in loops where you perform many concatenations; for simple one-time operations, the performance difference is negligible.
- StringBuilder maintains a resizable internal buffer (capacity) that grows as needed; you can optimize by setting initial capacity if you know the approximate final length.
- StringBuilder provides Append(), Insert(), Remove(), and Replace() methods for flexible string manipulation before converting to a final string.
- Modern string interpolation with $"" syntax is optimized by the compiler and can be nearly as efficient as StringBuilder in many cases, but StringBuilder is still preferred for complex loops.
- StringBuilder is not thread-safe; use lock statements or other synchronization if accessed from multiple threads.
Common follow-up questions
- When should I set StringBuilder's capacity? If you know the approximate final string length beforehand, set capacity in the constructor to avoid internal buffer resizing: new StringBuilder(1000).
- Is StringBuilder necessary with string interpolation? String interpolation is compiler-optimized and adequate for most scenarios, but StringBuilder remains superior for dynamic loops where the number of concatenations is unknown or large.
- What's the performance difference? With 1000+ concatenations, StringBuilder can be orders of magnitude faster; with small operations (2-3 concatenations), the difference is imperceptible.
Related interview questions
Further reading
- Strings: StringBuilder and interpolation
.NETCsharp
39What is string interpolation?
Beginner
String interpolation is a C# feature that lets you embed expressions directly inside string literals using the $ prefix and curly braces {}. For example, $"Hello {name}" produces a cleaner, more readable alternative to older string concatenation or formatting methods. The compiler optimizes interpolated strings at compile time, making them both performant and expressive.

How it works

When you prefix a string with the $ symbol, the C# compiler treats the string as a template. Any expression inside curly braces {} is evaluated at runtime and its result is inserted into the string. Behind the scenes, the compiler generates efficient code—often calling string.Format() or using interpolated string handlers in modern .NET versions for optimal performance.

You can embed simple variables, object properties, method calls, arithmetic expressions, and even complex logic inside the braces. The compiler also supports format specifiers (like {price:C2} for currency) and alignment (like {name,10} for padding). String interpolation respects string immutability in .NET—each interpolated string creates a new string object.

Example
csharp
```
string name = "Alice";
int age = 30;
decimal salary = 75000m;
DateTime startDate = new DateTime(2023, 1, 15);

// Basic interpolation
string greeting = $"Hello, {name}!";
Console.WriteLine(greeting); // Output: Hello, Alice!

// Multiple expressions and format specifiers
string profile = $"{name} is {age} years old and earns {salary:C2} annually.";
Console.WriteLine(profile); 
// Output: Alice is 30 years old and earns $75,000.00 annually.

// Expressions inside braces
string summary = $"In {DateTime.Now.Year}, {name} will be {age + 1}.";
Console.WriteLine(summary);
// Output: In 2024, Alice will be 31.

// Alignment and padding
string aligned = $"|{name,15}| {age,3}|";
Console.WriteLine(aligned);
// Output: |           Alice|  30|
```
This example demonstrates basic interpolation, format specifiers like :C2 for currency, embedded expressions like age + 1, and alignment padding with ,10 syntax.

Key points to mention
- Readability: Interpolation is far more readable than string concatenation (+) or string.Format(), reducing cognitive load and errors.
- Compiler optimization: Modern .NET uses interpolated string handlers to avoid allocating intermediate objects, improving performance compared to older formatting methods.
- Format specifiers: You can use format specifiers like {price:F2}, {date:yyyy-MM-dd}, or {value:P} for precise formatting without additional method calls.
- Expression support: Any valid C# expression can go inside braces—method calls, ternary operators, LINQ queries, and arithmetic all work seamlessly.
- Null-coalescing and null-conditional: You can combine interpolation with null operators like {user?.Name ?? "Guest"} for safe, concise null handling.
Common follow-up questions
- How does string interpolation compare to string.Format() or StringBuilder? String interpolation is more readable and compile-time optimized; use StringBuilder when building strings in loops to avoid excessive allocations.
- Can you use interpolation in older .NET versions? String interpolation was introduced in C# 6.0 (.NET Framework 4.6 and .NET Core). Earlier versions require string.Format() or concatenation.
- What happens if you use $@ together? The $@ prefix combines interpolation ($) with verbatim strings (@, which ignore escape sequences), allowing multi-line interpolated strings with literal backslashes and newlines.
Related interview questions
Further reading
- Strings: StringBuilder and interpolation
- Modern pattern matching in C#
.NETCsharp
40What are nullable value types?
Beginner
Nullable value types allow value types like int, bool, and DateTime to hold a null value in addition to their normal range of values. The syntax int? is shorthand for Nullable<int>, and you can check whether a value is present using the HasValue property or use the null-coalescing operator ?? to provide a default when null is encountered.

How it works

By default, value types cannot be null—they always contain a value. For example, an int defaults to 0, and a bool defaults to false. However, in many real-world scenarios, you need to represent the absence of a value (not just a default). This is where nullable value types come in.

When you declare a variable as int?, you're actually creating an instance of the generic struct Nullable<T>. This struct wraps the value type and adds a boolean flag that indicates whether a value is present. Internally, Nullable<int> contains two fields: a bool HasValue property and a int Value property.

You interact with nullable value types in three main ways: checking HasValue before accessing Value, using the null-coalescing operator ?? to supply a default, or relying on implicit unwrapping when you're confident a value exists. Boxing a nullable value type with a null value results in a null reference; boxing a nullable value type with a value results in a boxed version of the underlying value (not the Nullable<T> wrapper).

Example
csharp
```
int? age = null;
string? name = null;
DateTime? birthDate = new DateTime(1990, 5, 15);

// Checking HasValue
if (age.HasValue)
{
    Console.WriteLine($"Age: {age.Value}");
}
else
{
    Console.WriteLine("Age is unknown");
}

// Using null-coalescing operator
int displayAge = age ?? 0;
Console.WriteLine($"Display age: {displayAge}");

// Using GetValueOrDefault
int safeAge = age.GetValueOrDefault(18);
Console.WriteLine($"Safe age: {safeAge}");

// Direct comparison with null
if (birthDate != null)
{
    Console.WriteLine($"Birth date: {birthDate}");
}
```
This example demonstrates declaring nullable value types, checking for null with HasValue, providing defaults with ??, and using GetValueOrDefault() to safely extract values.

Key points to mention
- int? is syntactic sugar for Nullable<T>, a generic struct that wraps a value type and a boolean flag.
- Always check HasValue or use the ?? operator before assuming a nullable value type contains a value; accessing Value when HasValue is false throws an InvalidOperationException.
- Nullable value types are still value types—they live on the stack (when local variables) and are passed by value, unlike nullable reference types.
- You can use GetValueOrDefault() to safely extract a value with a fallback, or use pattern matching in C# 7+ with if (age is int ageValue).
- Boxing a nullable value type with null produces a null reference; boxing a nullable value type with a value produces a boxed instance of the underlying type.
Common follow-up questions
- What is the difference between int? and int in terms of memory or performance? — A nullable int requires 5 bytes (4 bytes for the int plus 1 byte for the boolean flag), versus 4 bytes for a regular int. The performance cost is minimal but noticeable in performance-critical scenarios or large collections.
- Can I use nullable value types with null in LINQ or database queries? — Yes, nullable value types are essential for ORM frameworks like Entity Framework; they allow you to model optional columns in databases where a value may genuinely be missing.
- How do nullable value types differ from null reference types? — Nullable value types are opt-in per variable and use the Nullable<T> wrapper, while nullable reference types (C# 8+) are a static analysis feature that helps prevent null reference exceptions on reference types.
Related interview questions
Further reading
- Nullable reference types
- Value objects
.NETCsharp
41What are nullable reference types?
Beginner
Nullable reference types (NRTs) are a C# feature that enables the compiler to track and warn about potential null reference exceptions before runtime. By enabling this feature, you can annotate reference types with ? to indicate they may be null, while unmarked references are treated as non-nullable and should never be null. This shifts null-safety checking from runtime to compile-time.

How it works

Nullable reference types were introduced in C# 8.0 as an optional feature and became enabled by default in .NET 6+. When enabled (via the <nullable>enable</nullable> project setting or #nullable enable directive), the compiler performs static analysis to detect when you might dereference a null reference.

The system works as follows: a variable declared as string name is considered non-nullable, meaning the compiler expects it to never be null and will warn if you assign null to it or pass it where a non-nullable string is expected. In contrast, string? optionalName is nullable, signaling that the variable may contain null, and the compiler requires you to null-check before dereferencing it.

This is purely a compile-time safety mechanism. At runtime, the ? annotation has no effect—it does not prevent null from being assigned. Rather, it communicates intent to the compiler and serves as documentation for other developers. The compiler uses flow analysis to understand when a nullable variable has been checked and is safe to use.

Example
csharp
```
#nullable enable

public class UserService
{
    public void ProcessUser(string? email)
    {
        // Compiler warning: Cannot convert null literal to non-nullable string type
        // string name = email;  // ❌ Error

        // Compiler accepts this after null-check
        if (email != null)
        {
            string name = email;  // ✓ Safe
            Console.WriteLine(name.Length);
        }

        // Without null-check, compiler warns
        // Console.WriteLine(email.Length);  // ⚠️ Warning: possible null reference
    }

    public string GetUserEmail(User? user)
    {
        // Requires null-check before accessing property
        return user?.Email ?? "unknown@example.com";
    }
}

public class User
{
    public required string Id { get; init; }        // Non-nullable, must be provided
    public string? Email { get; set; }              // Nullable, may be null
}
```
This example shows how the compiler warns when assigning a nullable reference to a non-nullable variable without a null-check, and how the null-conditional operator ?. safely handles potential null values.

Key points to mention
- Compile-time feature: NRTs are a static analysis tool; they do not affect runtime behavior or IL code generation.
- Opt-in (historically): While enabled by default in newer templates, projects can enable or disable NRTs per file or project-wide via the <nullable> project setting.
- Flow-sensitive: The compiler tracks whether a nullable variable has been null-checked within a code path, allowing you to use it safely after the check without additional casts.
- Works with nullable value types: NRTs apply similar logic to reference types that nullable value types provide for structs.
- Helps prevent NullReferenceException: By catching potential null dereferences at compile-time, NRTs reduce a common class of runtime errors.
Common follow-up questions
- Can you disable nullable reference types in a .NET 6+ project, and why might you want to?
- How do nullable reference types interact with inheritance and interface implementation?
- What is the difference between the null-coalescing operator ?? and the null-conditional operator ?. when working with NRTs?
Related interview questions
Further reading
- Nullable reference types
.NETCsharp
42What do the ?. and ?? operators do?
Beginner
The ?. operator (null-conditional operator) safely accesses members on an object only when that object is not null, returning null if the object is null. The ?? operator (null-coalescing operator) returns a fallback value when the left operand is null, and ??= (null-coalescing assignment) assigns a value only when the variable is currently null. Together, these operators provide a concise, readable way to handle null scenarios without explicit null checks.

How it works

The ?. operator allows you to chain member access (properties, methods, indexers) without throwing a NullReferenceException. If the object is null, the entire expression short-circuits and returns null. This is especially useful when working with nested objects or method chains where any level might be null.

The ?? operator evaluates the right operand only if the left operand is null. This is called null coalescing and provides a clean syntax for supplying default values. It works with both reference and nullable value types.

The ??= operator (introduced in C# 8.0) combines assignment with null coalescing. It assigns the right-hand value to the left-hand variable only if that variable is currently null, useful for lazy initialization patterns.

Example
csharp
```
public class User
{
    public string? Name { get; set; }
    public Address? Address { get; set; }
}

public class Address
{
    public string? City { get; set; }
}

// Usage
User? user = GetUser(); // might be null

// ?. operator - safe navigation
string? city = user?.Address?.City; // Returns null if user or Address is null

// ?? operator - null coalescing
string displayName = user?.Name ?? "Unknown";

// ??= operator - null coalescing assignment
user ??= new User { Name = "Guest" }; // Assigns only if user is null

// Combining them
string message = user?.Address?.City ?? "No city available";
Console.WriteLine(message); // Prints city name or "No city available"
```
This example demonstrates all three operators: safely accessing nested properties with ?., providing fallback values with ??, and conditionally assigning with ??=.

Key points to mention
- The ?. operator returns null if the object is null; otherwise, it proceeds with the member access. It prevents NullReferenceException from being thrown.
- The ?? operator is right-associative, so a ?? b ?? c evaluates as a ?? (b ?? c), allowing easy chaining of fallback values.
- The ??= operator only assigns if the left side is null, making it perfect for lazy initialization and default value setup patterns.
- These operators work with nullable reference types (available with the nullable reference types feature in C# 8.0+), improving code safety by distinguishing between nullable and non-nullable references at compile time.
- You can combine ?. with indexers and methods: list?[0] or person?.GetName() are both valid.
Common follow-up questions
- What is the difference between ?? and the ternary operator? (The ternary operator requires an explicit condition, while ?? specifically checks for null.)
- Can you use ?. with methods that have side effects? (Yes, but be cautious—the method only executes if the object is not null.)
- What does user?.Method()?. Property do? (It calls Method() on user if user is not null, then accesses Property only if the returned object is not null.)
Related interview questions
- What is the difference between First and FirstOrDefault?
- What is an enum?
Further reading
- Null object pattern
.NETCsharp
43What is an enum?
Beginner
An enum (enumeration) is a named set of integral constants that allows you to define a group of related constant values with meaningful names. Instead of using magic numbers or strings throughout your code, enums provide type safety, readability, and maintainability. They are value types (structs) that inherit from System.Enum and are compiled into integer values at runtime.

How it works

When you declare an enum, you define a new type with a fixed set of named constants. Each constant has an underlying integral value—by default, an int starting at 0 and incrementing. The compiler treats each enum member as a constant and enforces that only valid enum values can be used in code.

Enums provide several benefits: they replace magic numbers with self-documenting names, enable compile-time validation (you can't accidentally pass an invalid status), and work seamlessly with switch statements. For combinable values (like permissions or flags), the [Flags] attribute lets you combine multiple enum values using bitwise operations, treating each member as a power of two.

Under the hood, enums are just syntactic sugar over integers. When you reference an enum member, the compiler substitutes its underlying integer value. This makes enums both type-safe at compile time and efficient at runtime.

Example
csharp
```
// Simple enum for order status
public enum OrderStatus
{
    Pending = 0,
    Processing = 1,
    Shipped = 2,
    Delivered = 3,
    Cancelled = 4
}

// Flags enum for file permissions
[Flags]
public enum FilePermissions
{
    None = 0,
    Read = 1,
    Write = 2,
    Execute = 4,
    Delete = 8
}

class Program
{
    static void Main()
    {
        // Simple enum usage
        OrderStatus status = OrderStatus.Processing;
        Console.WriteLine($"Order status: {status}"); // Output: Order status: Processing

        // Switch with enum
        if (status == OrderStatus.Processing)
            Console.WriteLine("Your order is being processed.");

        // Flags enum usage
        FilePermissions perms = FilePermissions.Read | FilePermissions.Write;
        Console.WriteLine($"Has read: {perms.HasFlag(FilePermissions.Read)}"); // Output: True
        Console.WriteLine($"Has execute: {perms.HasFlag(FilePermissions.Execute)}"); // Output: False
    }
}
```
This example shows a simple enum for order statuses and a [Flags] enum for file permissions that can be combined using bitwise OR and checked with HasFlag().

Key points to mention
- Enums are value types derived from System.Enum with an underlying integral type (default is int); you can also use byte, short, long, etc.
- They provide type safety—the compiler prevents invalid values and makes code self-documenting compared to magic numbers or strings.
- Use [Flags] attribute for enums representing combinable bit flags; each value should be a power of two (1, 2, 4, 8, etc.).
- Enums work efficiently in switch statements and can be converted to/from their underlying integer values with casting or Enum.Parse().
- Unlike const fields, enum members are implicitly static and cannot be changed after compilation.
Common follow-up questions
- Can you change an enum's underlying type, and why would you?
- What is the difference between a simple enum and a [Flags] enum?
- How do you parse a string into an enum value, and how do you convert an enum to a string?
Related interview questions
- What is the difference between const and readonly?
- What are generics?
.NETCsharp
44What are generics?
Beginner
Generics are a language feature that allows you to write type-safe, reusable code by using type parameters (placeholders) instead of specific types. A generic class or method works with any data type while maintaining compile-time type checking and avoiding the need for casting or boxing and unboxing.

How it works

Generics use angle brackets with a type parameter (usually T, but can be any name) to define a placeholder for a concrete type. When you create an instance or call a method, you specify what type should replace that parameter. The compiler generates type-specific code at compile time, so you get both flexibility and safety.

Instead of writing separate classes for ListOfInts, ListOfStrings, and ListOfObjects, you write one generic List<T>. The runtime and compiler handle the rest. This eliminates:
- Casting: No need to cast retrieved items back to their original type.
- Boxing overhead: Value types don't get boxed when stored in generic containers.
- Type errors: The compiler catches type mismatches at build time, not runtime.
You can constrain generics too. For example, <T where T : IComparable> ensures T implements IComparable, so you can safely call comparison methods.

Example
csharp
```
// Generic class that works with any type
public class Container<T>
{
    private T _value;

    public void Set(T value) => _value = value;
    public T Get() => _value;
}

// Generic method
public static void PrintArray<T>(T[] items)
{
    foreach (var item in items)
        Console.WriteLine(item);
}

// Usage
var intContainer = new Container<int>();
intContainer.Set(42);
Console.WriteLine(intContainer.Get()); // Output: 42

var stringContainer = new Container<string>();
stringContainer.Set("Hello");
Console.WriteLine(stringContainer.Get()); // Output: Hello

PrintArray(new[] { 1, 2, 3 });
PrintArray(new[] { "a", "b", "c" });
```
The Container<T> class works with any type—integers, strings, objects—without casting. When you create Container<int>, the compiler generates type-safe code just for integers.

Key points to mention
- Generics provide type safety at compile time, catching errors early rather than at runtime.
- They eliminate casting—you retrieve items in their original type without as or (Type).
- They improve performance by avoiding boxing of value types; an int in a List<int> stays on the stack or inline in memory.
- Generics work with constraints (e.g., <T where T : class>, <T where T : struct>, <T where T : IComparable>) to restrict what types can be used.
- List<T>, Dictionary<TKey, TValue>, and IEnumerable<T> are built-in generic types you use constantly in .NET.
Common follow-up questions
- What is the difference between generics and object? — Using object requires casting every time you retrieve a value and causes boxing for value types, losing type safety and performance. Generics avoid both.
- Can you have multiple type parameters? — Yes: Dictionary<TKey, TValue> or Tuple<T1, T2, T3> use multiple parameters separated by commas.
- What is covariance and contravariance? — Advanced topic: out T (covariance) allows IEnumerable<Derived> to be used where IEnumerable<Base> is expected; in T (contravariance) does the opposite.
Related interview questions
Further reading
- Generics and constraints that pay off
- Health checks that mean something
.NETCsharp
45What are generic constraints?
Beginner
Generic constraints are restrictions placed on type parameters in generic classes, methods, or interfaces that specify what types are allowed to be substituted. They enable you to write type-safe generic code by ensuring that only types meeting certain criteria can be used, allowing the compiler to verify that specific operations or member accesses are valid. Common constraints include where T : class, where T : struct, where T : new(), and where T : SomeInterface.

How it works

Without constraints, a generic type parameter T is treated as the most basic type possible—essentially object. This means you can only call methods that exist on object (like ToString(), GetHashCode(), etc.). Constraints tell the compiler and developers what assumptions can be safely made about T.

When you apply a constraint using the where keyword, the compiler enforces it at compile time. If someone tries to use a type that doesn't satisfy the constraint, they'll get a compilation error rather than a runtime failure. This allows you to call methods specific to the constrained type without casting or reflection.

Multiple constraints can be combined. For example, where T : class, IComparable, new() means T must be a reference type that implements IComparable and has a parameterless constructor. There are also base type constraints (like where T : Animal) and unmanaged constraints for low-level programming.

Example
csharp
```
// Generic repository with constraints
public class Repository<T> where T : class, new()
{
    private List<T> _items = new();

    public void Add(T item)
    {
        if (item != null)
            _items.Add(item);
    }

    public T CreateNew()
    {
        return new T(); // Valid because of new() constraint
    }
}

public class User
{
    public string Name { get; set; }
}

// Usage
var userRepo = new Repository<User>();
var newUser = userRepo.CreateNew(); // Works fine

// var stringRepo = new Repository<string>(); 
// Compiler error: string doesn't satisfy constraints (can't instantiate with new())
```
This example demonstrates a repository pattern where T must be a reference type with a parameterless constructor, allowing us to safely call new T() and work with objects predictably.

Key points to mention
- Compile-time safety: Constraint violations are caught at compilation, not at runtime, preventing type-related errors before deployment.
- Reference vs. value types: The class constraint restricts to reference types, while struct restricts to value types, giving you control over object allocation and behavior.
- Interface and base type constraints: You can require that T implements a specific interface (e.g., where T : IComparable) or derives from a base class, enabling you to call interface or base class methods confidently.
- Constructor constraint: new() ensures T has a parameterless constructor, allowing the generic code to instantiate new instances.
- Multiple constraints: Constraints are combined with commas and follow a specific order: base type/class/struct first, then interfaces, then new() last.
Common follow-up questions
- Can you have multiple constraints on a single type parameter? Yes, you can combine them (e.g., where T : class, IDisposable, new()), but the order matters and there are limitations—for example, you cannot have both class and struct constraints together.
- What is the difference between where T : class and where T : struct? class restricts to reference types, while struct restricts to value types, affecting memory allocation and null-ability.
- Can you use constraints with multiple type parameters? Yes, each type parameter can have its own set of constraints; for example, public class Pair<T, U> where T : class where U : struct applies different constraints to different parameters.
Related interview questions
.NETCsharp
46What is the difference between an array and a List<T>?
Beginner
Arrays have a fixed size determined at creation and are slightly faster due to direct memory allocation, while List<T> is a dynamic collection that grows automatically as you add elements. List<T> provides convenient methods like Add, Remove, and Insert, whereas arrays require manual index management. For most modern C# applications, List<T> is the preferred choice because its dynamic nature and rich API outweigh the minor performance difference.

How it works

An array is a contiguous block of memory with a predetermined length. Once created, its size cannot change—if you need more space, you must create a new array and copy all elements over manually. This fixed nature makes array access extremely fast because the runtime can calculate the memory address of any element in constant time.

List<T> is a generic wrapper around an internal array. When you create a List<T>, it allocates an internal array with initial capacity (typically 4 elements). As you add items beyond this capacity, List<T> automatically creates a larger internal array (usually doubling the capacity) and copies elements to it. This dynamic resizing incurs a small overhead, but it happens infrequently enough that most operations remain very efficient.

Both arrays and List<T> maintain elements in memory sequentially, providing fast index-based access. The key difference lies in flexibility: arrays demand that you know the exact size upfront, while List<T> adapts to your needs.

Example
csharp
```
// Array: fixed size
int[] numbers = new int[5]; // Must specify size upfront
numbers[0] = 10;
numbers[1] = 20;
// numbers[5] = 30; // IndexOutOfRangeException!

// List: dynamic size
List numbersList = new(); // No size needed
numbersList.Add(10);
numbersList.Add(20);
numbersList.Add(30); // Grows automatically
numbersList.Insert(1, 15); // Easy to insert at specific position
numbersList.Remove(20); // Easy to remove by value

Console.WriteLine($"Array length: {numbers.Length}"); // 5
Console.WriteLine($"List count: {numbersList.Count}"); // 4
```
This example shows that arrays require you to specify length upfront and crash if you exceed bounds, while List<T> grows seamlessly and provides convenient methods for common operations.

Key points to mention
- Fixed vs. Dynamic: Arrays have immutable length; List<T> grows and shrinks automatically.
- Performance: Arrays are marginally faster for pure access patterns; List<T> adds minimal overhead through internal resizing, which is amortized across many operations.
- API: List<T> offers rich methods (Add, Remove, Insert, Contains, ForEach) that require manual loops with arrays.
- Memory efficiency: Arrays use only as much memory as needed; List<T> may allocate more internal capacity than current item count to reduce resizing frequency.
- Use cases: Use arrays when size is truly fixed (e.g., a deck of 52 cards); use List<T> for collections of unknown or variable size.
Common follow-up questions
- "What happens internally when a List exceeds its capacity?" The list doubles its internal array capacity, allocates a new array, copies all elements, and discards the old array. This is an O(n) operation, but it happens rarely enough that the amortized cost per Add is still O(1).
- "When would you use an array instead of List<T>?" Use arrays for fixed-size collections, performance-critical code paths where the small overhead matters, interop scenarios, or when working with legacy code. Modern C# favors List<T> or IEnumerable<T> for flexibility.
- "How does List<T> compare to other collections like Dictionary or HashSet?" List<T> maintains insertion order and allows duplicates with fast index access; Dictionary<K, V> uses key-value pairs; HashSet<T> removes duplicates and offers fast lookups. Choose based on your access patterns.
Related interview questions
.NETCsharp
47What is a Dictionary<TKey,TValue>?
Beginner
A Dictionary<TKey, TValue> is a generic, hash-based collection that stores key-value pairs and provides O(1) average-time lookups by key. It is part of the System.Collections.Generic namespace and is the most commonly used collection for fast data retrieval when you need to associate unique keys with values. Unlike HashSet<T>, which stores only keys, a Dictionary stores both a key and its corresponding value.

How it works

A Dictionary uses a hash table internally. When you add a key-value pair, the key is passed through a hash function to compute a hash code, which determines where in an internal array the pair is stored. This hash-based approach enables constant-time (O(1)) average lookup, insertion, and deletion.

The dictionary maintains an array of "buckets." If two different keys hash to the same bucket (a hash collision), the dictionary uses chaining or linear probing to store both entries. Modern implementations typically use chaining with linked lists or similar techniques.

Keys must be unique; attempting to add a duplicate key will throw an ArgumentException. Values, however, can be duplicated. The dictionary is mutable—you can add, remove, or update entries after creation. For thread-safe scenarios, consider using ConcurrentDictionary<TKey, TValue> from System.Collections.Concurrent.

Example
csharp
```
var users = new Dictionary<int, string>
{
    { 1, "Alice" },
    { 2, "Bob" },
    { 3, "Charlie" }
};

// Lookup by key (may throw KeyNotFoundException)
string name = users[1]; // "Alice"

// Safe lookup using TryGetValue
if (users.TryGetValue(2, out string? value))
{
    Console.WriteLine($"Found: {value}");
}

// Add or update
users[4] = "Diana";
users[1] = "Alicia"; // Updates existing key

// Iterate over key-value pairs
foreach (var kvp in users)
{
    Console.WriteLine($"{kvp.Key}: {kvp.Value}");
}

// Remove
users.Remove(2);
```
This example creates a dictionary mapping user IDs to names, demonstrates safe lookups with TryGetValue, shows updates, iteration, and removal.

Key points to mention
- O(1) average lookup: Fast key-based retrieval makes dictionaries ideal for caches, lookups, and associations.
- Use TryGetValue to avoid exceptions: Indexer access (dict[key]) throws KeyNotFoundException if the key is missing; TryGetValue(key, out var value) is safer.
- Keys must be unique and override GetHashCode/Equals: Keys must implement meaningful GetHashCode() and Equals() for correct behavior with custom types.
- Mutable and not thread-safe: Modifying a dictionary while iterating throws InvalidOperationException; use ConcurrentDictionary<TKey, TValue> for multi-threaded scenarios.
Common follow-up questions
- What is the difference between Dictionary and Hashtable? Hashtable is a non-generic, legacy collection that requires boxing/unboxing. Dictionary is generic, type-safe, and faster.
- How do hash collisions affect performance? Excessive collisions degrade average lookup time. A good hash function minimizes collisions; the dictionary automatically resizes when load factor exceeds a threshold.
- Can I use a custom class as a key? Yes, but it must override GetHashCode() and Equals() correctly. Immutable types are safer for keys to prevent hash code changes after insertion.
Related interview questions
.NETCsharp
48What is the difference between IEnumerable and IList?
Beginner
IEnumerable<T> is a contract for forward-only iteration through a collection, while IList<T> extends that capability with random access via indexing, a Count property, and the ability to add, remove, or modify elements. In other words, every IList<T> is an IEnumerable<T>, but not every IEnumerable<T> is an IList<T>.

How it works

IEnumerable<T> defines a single method: GetEnumerator(), which returns an IEnumerator<T>. This enumerator lets you move forward through items one at a time using MoveNext() and Current. You cannot go backward, jump to a specific position, or modify the collection during iteration (in most cases). This minimal interface is lightweight and can represent virtually any data source: arrays, lists, database queries, files, or even infinite streams.

IList<T>, on the other hand, inherits from IEnumerable<T>> and ICollection<T>, adding:
- this[int index] — get or set an element by position
- int IndexOf(T item) — find an element's position
- void Insert(int index, T item) — insert at a specific position
- void RemoveAt(int index) — remove by position
- Count property — know how many elements exist
The trade-off is clear: IEnumerable<T> is simpler and more flexible (it can wrap lazy-evaluated streams), while IList<T> is more powerful but requires the underlying collection to support random access and modification.

Example
csharp
```
// IEnumerable - iteration only
IEnumerable<int> numbers = GetNumbers();
foreach (var n in numbers)
{
    Console.WriteLine(n);  // Works
}
// var first = numbers[0];  // ❌ Compile error: no indexer
// numbers.Add(5);  // ❌ Compile error: no Add method

// IList - full control
IList<int> list = new List<int> { 1, 2, 3 };
Console.WriteLine(list[0]);  // ✅ 1 - direct access
list.Add(4);  // ✅ Now { 1, 2, 3, 4 }
list.RemoveAt(1);  // ✅ Now { 1, 3, 4 }

foreach (var n in list)  // ✅ IList is also IEnumerable
{
    Console.WriteLine(n);
}

IEnumerable<int> GetNumbers() => Enumerable.Range(1, 3);  // Deferred execution
```
This example shows that IList gives you indexing and modification, while IEnumerable only lets you iterate; IList is always usable where IEnumerable is expected.

Key points to mention
- IEnumerable<T> is the base contract; IList<T> inherits from it and adds indexing and modification capabilities.
- Use IEnumerable<T> when you only need to read and iterate; it's cheaper and works with LINQ queries, lazy sequences, and streams.
- Use IList<T> when you need random access, counting, inserting, or removing elements; concrete types like List<T> and array implementations support it.
- IEnumerable<T> does not guarantee the collection is re-enumerable; some sources (like query results) may be consumed once.
- Methods accepting IEnumerable<T> are more flexible and reusable; methods accepting IList<T> are more specialized but more powerful.
Common follow-up questions
- What about ICollection<T>? — It sits between them, adding Count, Add, Remove, and Contains, but no indexing. IList inherits from both ICollection and IEnumerable.
- Can I use LINQ on both? — Yes, both work with LINQ because LINQ extension methods target IEnumerable<T>. However, .ToList() materializes the sequence into an IList<T>.
- What about HashSet<T>? — It implements IEnumerable<T> and ICollection<T>, but not IList<T> (no indexing, no guaranteed order).
Related interview questions
- What is a HashSet<T>?
- What is a Dictionary<TKey,TValue>?
.NETCsharplinq
49What is a HashSet<T>?
Beginner
A HashSet<T> is an unordered collection of unique elements that uses a hash table for fast lookups and insertions. It enforces uniqueness automatically and provides O(1) average-case performance for Contains, Add, and Remove operations, making it ideal for deduplication and membership testing.

How it works

HashSet<T> uses a hash table data structure internally. When you add an item, it computes a hash code for that item and stores it in a bucket based on that hash. When you check if an item exists (Contains), it computes the same hash code and checks that bucket—without scanning the entire collection. This gives you constant-time lookups.

The key characteristic is uniqueness. If you try to add a duplicate item, the Add method returns false and the item is not added again. Equality is determined by the item's GetHashCode() and Equals() methods. Two objects are considered the same if they have the same hash code and return true from Equals().

Unlike Dictionary<TKey,TValue>, a HashSet has no key-value pairs—it just stores values. It's also unordered, so you cannot rely on iteration order.

Example
csharp
```
// Deduplication and membership testing
HashSet<int> uniqueNumbers = new HashSet<int> { 1, 2, 3, 4, 5 };

// Fast Contains check
if (uniqueNumbers.Contains(3))
{
    Console.WriteLine("3 is in the set");
}

// Add only adds if not present
uniqueNumbers.Add(3);  // Returns false, not added
uniqueNumbers.Add(6);  // Returns true, added

// Remove
uniqueNumbers.Remove(5);

// Set operations
HashSet<int> other = new HashSet<int> { 3, 6, 7 };
uniqueNumbers.IntersectWith(other);  // Keep only common elements
Console.WriteLine(string.Join(", ", uniqueNumbers));  // Output: 3, 6
```
This example demonstrates adding unique numbers, checking membership in constant time, and performing set operations like intersection—all operations that would be inefficient with a List.

Key points to mention
- HashSet enforces uniqueness; duplicate adds are silently ignored (Add returns false)
- Provides O(1) average-case performance for Add, Remove, and Contains—much faster than List for membership tests
- Unordered collection; iteration order is not guaranteed and may change as the set is modified
- Supports efficient set operations: Union, Intersect, Except, SymmetricExcept, IsSubsetOf, IsSupersetOf
- Items must implement GetHashCode() and Equals() correctly for proper behavior; custom types should override both methods
Common follow-up questions
- How does HashSet handle hash collisions? — Multiple items with the same hash code are stored in the same bucket using a linked list or chain; Equals() is used to find the exact item within the bucket.
- What's the difference between HashSet and List for checking if an item exists? — HashSet.Contains() is O(1) average; List.Contains() is O(n) because it must scan every element. For large collections and frequent lookups, HashSet is far superior.
- When should I use HashSet versus Dictionary? — Use HashSet when you only need to store and check for unique values; use Dictionary when you need to store key-value pairs and look up values by key.
Related interview questions
- What is a Dictionary<TKey,TValue>?
- How do you use the Channel-based background queue pattern?
Further reading
- Unit testing with xUnit
.NETCsharpTesting
50What is LINQ?
Beginner
LINQ (Language Integrated Query) is a .NET feature that provides a unified, strongly-typed syntax for querying data from any source—collections, databases, XML, or web services. It introduces standard query operators like Where, Select, GroupBy, and OrderBy directly into the C# language, eliminating the need to learn different query syntaxes for different data sources.

How it works

LINQ bridges the gap between the imperative world of C# and the declarative world of data queries. When you write a LINQ query, the compiler translates it into method calls on objects that implement specific interfaces like IEnumerable or IQueryable.

For in-memory collections, LINQ to Objects works directly with IEnumerable<T>. For databases, LINQ providers (such as Entity Framework Core) translate your query into SQL before executing it on the server. The key benefit is that you write the same query syntax regardless of the underlying data source—the provider handles the translation.

LINQ supports two syntaxes: query syntax (resembling SQL) and method syntax (using lambda expressions and extension methods). Both are equally powerful; the choice depends on readability and preference. You can also learn more about deferred execution in LINQ, which means queries often don't execute until you enumerate the results.

Example
csharp
```
var employees = new List<Employee>
{
    new(1, "Alice", 75000),
    new(2, "Bob", 65000),
    new(3, "Charlie", 85000)
};

// Query syntax
var highEarners = from emp in employees
                  where emp.Salary > 70000
                  orderby emp.Name
                  select emp.Name;

// Method syntax (equivalent)
var highEarnersMethod = employees
    .Where(e => e.Salary > 70000)
    .OrderBy(e => e.Name)
    .Select(e => e.Name);

foreach (var name in highEarners)
    Console.WriteLine(name); // Output: Alice, Charlie

record Employee(int Id, string Name, decimal Salary);
```
This example demonstrates querying an in-memory list to find employees earning more than £70,000, ordered by name, returning only their names.

Key points to mention
- Language integration: LINQ is built into C# syntax, not a separate library, making queries feel natural and IntelliSense-friendly.
- Provider-based: Different LINQ providers handle different data sources—LINQ to Objects, LINQ to SQL, Entity Framework (Entity Framework Core), LINQ to XML—using the same query syntax.
- Strongly typed: Queries are checked at compile time, catching errors early and enabling refactoring with confidence.
- Composable: You can chain multiple operators together, building complex queries incrementally.
- Query and method syntax are interchangeable: Choose whichever reads better for your use case.
Common follow-up questions
- What is the difference between IEnumerable and IQueryable in LINQ?
- How does LINQ to SQL differ from LINQ to Objects?
- What are deferred execution and eager execution in LINQ, and when would you use ToList() or ToArray()?
Related interview questions
Further reading
- LINQ performance traps
.NETCsharplinq
51What is the difference between LINQ query syntax and method syntax?
Beginner
LINQ query syntax and method syntax are two different ways to write the same LINQ queries. Query syntax resembles SQL with keywords like from, where, and select, while method syntax chains extension methods like Where(), Select(), and OrderBy(). Both compile to identical IL code—the compiler translates query syntax into method calls behind the scenes.

How it works

Query syntax is a declarative language integrated into C# that mimics SQL. It uses contextual keywords and reads naturally from left to right, making complex queries more readable. The compiler parses this syntax and converts it into method calls at compile time.

Method syntax (also called fluent syntax) chains extension methods directly on collections. Each method returns an IEnumerable or IQueryable, allowing you to chain operations. This approach is more functional and gives you access to every overload of each method.

Both syntaxes ultimately generate the same delegates and lambda expressions. The choice between them is largely about readability and personal preference. Method syntax offers more flexibility because you can use any extension method available, while query syntax is limited to keywords the compiler recognizes. Many developers mix both approaches in the same codebase—using query syntax for simple filters and method syntax for complex operations.

Example
csharp
```
var employees = new List<Employee>
{
    new Employee { Id = 1, Name = "Alice", Department = "IT", Salary = 75000 },
    new Employee { Id = 2, Name = "Bob", Department = "HR", Salary = 55000 },
    new Employee { Id = 3, Name = "Charlie", Department = "IT", Salary = 85000 }
};

// Query syntax
var queryResult = from emp in employees
                  where emp.Department == "IT"
                  orderby emp.Salary descending
                  select new { emp.Name, emp.Salary };

// Method syntax (identical result)
var methodResult = employees
    .Where(emp => emp.Department == "IT")
    .OrderByDescending(emp => emp.Salary)
    .Select(emp => new { emp.Name, emp.Salary });

foreach (var item in queryResult)
{
    Console.WriteLine($"{item.Name}: ${item.Salary}");
}
```
Both approaches filter IT employees, sort by salary in descending order, and project only the name and salary—they compile to identical executable code.

Key points to mention
- Query syntax and method syntax produce the same compiled IL code; the difference is purely syntactic.
- Query syntax reads more like SQL and is often preferred for complex filtering and joins; method syntax provides more control and flexibility.
- LINQ deferred execution applies to both syntaxes—the query doesn't run until enumerated.
- Method syntax allows access to all overloads and gives you granular control; query syntax is limited to recognized keywords.
- Most real-world codebases mix both styles depending on what makes the code more readable in context.
Common follow-up questions
- Can you mix query and method syntax in one LINQ statement? Yes—you can start with query syntax and chain method calls, or vice versa. The compiler will handle the mix seamlessly.
- Which syntax performs better? Both compile to identical code, so there is no performance difference. The choice is purely about readability and maintainability.
- When should I use one over the other? Use query syntax for readable, multi-step filtering and joins; use method syntax for complex transformations, grouping, or when you need specific method overloads.
Related interview questions
Further reading
- LINQ performance traps
- Extension methods done right
.NETCsharpefcorelinq
52What is deferred execution in LINQ?
Beginner
Deferred execution in LINQ means that query execution is delayed until the results are actually enumerated or materialized. When you write a LINQ query, it builds an expression tree but does not run immediately. The query executes only when you call a materializing method like ToList(), Count(), ForEach(), or iterate through results with a foreach loop.

How it works

When you construct a LINQ query using LINQ methods or query syntax, you are building an IEnumerable<T> or IQueryable<T> object that represents the query logic. This is not yet executed. The query is held as a set of instructions, waiting to be evaluated. Execution occurs only when something consumes the enumerable—typically a foreach loop, a materializing method, or an aggregate operation. This design allows LINQ to be lazy and efficient, enabling features like filtering at the source and combining multiple operations before running. It also means the same query can produce different results if enumerated at different times, since the underlying data may have changed.

Example
csharp
```
var numbers = new List<int> { 1, 2, 3, 4, 5 };

// This query does NOT execute yet—it's deferred
var evenNumbers = numbers.Where(n => n % 2 == 0);

Console.WriteLine("Query defined, not executed");

// Execution happens here when we enumerate
foreach (var num in evenNumbers)
{
    Console.WriteLine(num); // Output: 2, 4
}

// Executing again produces results again
var count = evenNumbers.Count(); // Query runs a second time
Console.WriteLine($"Count: {count}"); // Output: Count: 2

// Materializing to a list—query runs a third time
var list = evenNumbers.ToList(); // Execution happens here
```
The query is defined but not executed on the third line; it runs each time we enumerate or materialize it, showing that deferred execution allows multiple evaluations of the same query expression.

Key points to mention
- Lazy evaluation: LINQ queries are lazy and execute only when consumed, reducing memory usage and improving performance.
- Materializing methods: ToList(), ToArray(), Count(), First(), and ForEach() force immediate execution.
- Multiple executions: Enumerating the same query multiple times can run the query repeatedly, potentially with different results if the data changes.
- Side effects and debugging: Deferred execution can be surprising when debugging; a breakpoint in a Where clause may not be hit if the query is never enumerated.
- Query compilation: Compiled queries in EF Core and PLINQ provide ways to optimize or eagerly execute queries when needed.
Common follow-up questions
- What is the difference between deferred and immediate execution? Deferred execution delays query evaluation until enumeration; immediate execution runs the query right away. Methods like ToList() make execution immediate.
- Why might enumerating the same LINQ query multiple times be a problem? If the query runs against a changeable data source each time, results may differ. Also, repeated enumerations waste resources; it's often better to materialize once with ToList().
- How does deferred execution affect performance in Entity Framework? It allows EF to combine filters and projections into a single database query, improving efficiency, but can also lead to unexpected N+1 queries if not managed carefully.
Related interview questions
Further reading
- LINQ performance traps
- Compiled queries for hot paths
.NETCsharplinq
53What is the difference between First and FirstOrDefault?
Beginner
First throws an InvalidOperationException if the sequence is empty or no element matches the condition, while FirstOrDefault returns the default value (typically null for reference types or the zero value for value types) when the sequence is empty or no match is found. Choose First when you expect a result and want to fail fast on missing data; choose FirstOrDefault when an empty result is a valid outcome.

How it works

Both First and FirstOrDefault are LINQ methods that retrieve a single element from a sequence. They differ fundamentally in error handling:

First() immediately throws an exception if:
- The sequence is empty
- No element satisfies an optional predicate
This design enforces fail-fast semantics—if you call First, you're asserting that a matching element must exist. If it doesn't, an exception bubbles up immediately, alerting you to an unexpected state.

FirstOrDefault() handles absence gracefully by returning:
- null for reference types
- The default value (0, false, default) for value types
- A custom default value if provided as an overload parameter
This design is useful when missing data is anticipated or acceptable. You then check the returned value before proceeding, allowing your code to continue execution.

The distinction also relates to nullable value types, since FirstOrDefault on a non-nullable value type returns its zero value, which may be ambiguous—you cannot distinguish between "no element found" and "an element with the zero value exists."

Example
csharp
```
var numbers = new List<int> { 10, 20, 30 };

// First - throws if no match
try
{
    var result = numbers.First(n => n > 50);
    Console.WriteLine(result);
}
catch (InvalidOperationException ex)
{
    Console.WriteLine($"Exception: {ex.Message}");
    // Output: Exception: Sequence contains no matching element
}

// FirstOrDefault - returns default value
var resultOrDefault = numbers.FirstOrDefault(n => n > 50);
Console.WriteLine(resultOrDefault);  // Output: 0

// FirstOrDefault with custom default
var custom = numbers.FirstOrDefault(n => n > 50, -1);
Console.WriteLine(custom);  // Output: -1

// With reference types - returns null
var words = new List<string> { "apple", "banana" };
var found = words.FirstOrDefault(w => w.StartsWith("z"));
Console.WriteLine(found ?? "Not found");  // Output: Not found
```
The code demonstrates that First throws when no element matches, while FirstOrDefault safely returns a default value—zero for integers, null for strings—allowing continued execution.

Key points to mention
- First is safer when you expect data to exist; an exception signals a genuine problem early.
- FirstOrDefault is safer when absence is valid; it lets you handle the null or zero value explicitly.
- With value types, FirstOrDefault returning 0 or false does not tell you whether no element was found or if an element with that zero value exists—consider using nullable types or checking the count first.
- Both methods accept an optional predicate for filtering: First(x => x.Property == value) or FirstOrDefault(x => x.Property == value).
- Overloads of FirstOrDefault allow specifying a custom default value to return instead of the implicit zero value.
Common follow-up questions
- How does FirstOrDefault behave with nullable value types? — If you use List<int?>, FirstOrDefault returns null by default, making it clearer that no element was found versus finding an actual zero or null value.
- What is the difference between First and Single? — First returns the first matching element; Single throws if there is more than one match or if the sequence is empty, guaranteeing exactly one result.
- When should I use First versus FirstOrDefault in production code? — Use First for required data; use FirstOrDefault for optional data, then validate the result before using it.
Related interview questions
Further reading
- Null object pattern
.NETCsharp
54What is the difference between Single and First?
Beginner
Single expects exactly one element in a sequence and throws an exception if there are zero or multiple matches, while First simply returns the first element it encounters and ignores any others. Use Single when you need to guarantee uniqueness; use First when you only care about the first match.

How it works

LINQ provides these two methods for extracting elements, but they have fundamentally different expectations and behaviors:

Single() validates that the sequence contains exactly one element matching the predicate (or exactly one element total if no predicate is provided). If the sequence is empty, it throws InvalidOperationException. If the sequence contains more than one matching element, it also throws InvalidOperationException. This makes Single ideal for scenarios where you expect and enforce a one-to-one relationship.

First() returns the first element in a sequence that matches the predicate (or the first element overall if no predicate is provided). If the sequence is empty, it throws InvalidOperationException. However, First does not care if there are additional matching elements—it stops after finding the first one and returns immediately.

The key distinction is intent: Single asserts a constraint, while First simply retrieves. This difference affects performance, safety, and how you should use each method depending on your data expectations.

Example
csharp
```
var users = new List<User>
{
    new User { Id = 1, Email = "alice@example.com" },
    new User { Id = 2, Email = "bob@example.com" },
    new User { Id = 3, Email = "charlie@example.com" }
};

// Using First - returns the first user, ignores others
var firstUser = users.First();
Console.WriteLine(firstUser.Email); // Output: alice@example.com

// Using First with predicate - returns first user with Id > 1
var firstMatching = users.First(u => u.Id > 1);
Console.WriteLine(firstMatching.Email); // Output: bob@example.com

// Using Single - expects exactly one match
try
{
    var singleUser = users.Single(u => u.Id == 2);
    Console.WriteLine(singleUser.Email); // Output: bob@example.com
}
catch (InvalidOperationException ex)
{
    Console.WriteLine("Error: " + ex.Message);
}

// This will throw because multiple users have Id > 1
try
{
    var singleMatching = users.Single(u => u.Id > 1);
}
catch (InvalidOperationException ex)
{
    Console.WriteLine("Error: Sequence contains more than one element"); // This executes
}
```
In this example, First returns the first matching user regardless of how many others exist, while Single validates that exactly one match exists and throws an exception if that constraint is violated.

Key points to mention
- Exception handling: Both throw InvalidOperationException on empty sequences, but Single also throws if multiple matches exist.
- Performance: First is generally faster because it stops after finding one element, while Single must scan the entire sequence to verify uniqueness.
- Use cases: Use Single when enforcing business rules (e.g., "get the admin user" where only one should exist); use First when simply retrieving the earliest match.
- Alternatives: Consider FirstOrDefault and SingleOrDefault to avoid exceptions on empty sequences.
- Predicate behavior: Both methods accept optional predicates to filter before matching; the filtering logic is identical, only the validation differs.
Common follow-up questions
- What is the difference between FirstOrDefault and SingleOrDefault?
- When would you choose Single over First in a real application?
- What performance impact does Single have compared to First on large datasets?
Related interview questions
- What is the difference between First and FirstOrDefault?
- What is parameter sniffing and how does it affect .NET apps?
.NETCsharp
55What is a lambda expression?
Beginner
A lambda expression is an inline, anonymous function that uses the => operator to define a concise syntax for creating delegates or expression trees. Lambdas are fundamental to modern C# and are extensively used with LINQ, event handlers, and asynchronous operations.

How it works

A lambda expression is essentially a shorthand way to write an anonymous method without the verbose delegate keyword. The syntax is: (parameters) => expression or statement body.

When you write a lambda, the compiler infers the parameter types and return type based on context. The lambda is converted into either a Func<T, TResult>, Action<T>, or an expression tree depending on how it's used.

Lambdas enable functional programming patterns in C#. They capture variables from their enclosing scope (closure), allowing the function to access and modify outer state. When a lambda captures variables, the compiler creates a hidden class to store those values, which is important to understand for memory management.

The expression form (single line, no braces) returns a value implicitly. The statement form (with braces) can contain multiple statements and requires an explicit return keyword if needed.

Example
csharp
```
// Simple lambda with LINQ
var numbers = new[] { 1, 2, 3, 4, 5 };
var squared = numbers.Where(x => x > 2).Select(x => x * x);

// Lambda with multiple parameters
Func<int, int, int> add = (a, b) => a + b;
var result = add(5, 3); // Returns 8

// Lambda with statement body
Func<int, string> getGrade = score =>
{
    if (score >= 90) return "A";
    if (score >= 80) return "B";
    return "C";
};

// Lambda capturing outer variable
int multiplier = 10;
Func<int, int> multiplyBy = x => x * multiplier;
Console.WriteLine(multiplyBy(5)); // Outputs 50
```
This code demonstrates simple filtering and transformation with lambdas, multi-parameter lambdas assigned to delegates, statement-body lambdas with complex logic, and variable capturing from the outer scope.

Key points to mention
- Lambdas are anonymous functions that provide concise syntax compared to named methods or anonymous delegates
- They are primarily used with LINQ (Where, Select, GroupBy, etc.) and make data queries more readable
- Lambdas capture variables from their enclosing scope, creating closures that can lead to unexpected behavior if you're not careful with mutable captured state
- The compiler infers parameter and return types automatically, but you can specify them explicitly if needed
- Lambdas can be converted to expression trees, which allows LINQ providers to analyze and execute them as database queries (LINQ to SQL, Entity Framework)
Common follow-up questions
- What is the difference between Func<T, TResult> and Action<T>? (Func returns a value; Action returns void)
- How do captured variables in lambdas relate to memory leaks in managed code?
- What is the difference between lambda expressions and expression trees, and when would you use each?
Related interview questions
.NETCsharpArchitecturelinq
56What is a delegate?
Beginner
A delegate is a type-safe reference type that defines the signature of a method. It allows you to pass methods as parameters to other methods, store them in variables, and invoke them later. Delegates form the foundation of the event system in .NET and enable callback patterns, functional programming styles, and decoupling of components.

How it works

A delegate acts as a contract that specifies the return type and parameters a method must have. When you declare a delegate, you're creating a new type that can hold a reference to any method matching that signature. This is similar to a function pointer in C++, but type-safe.

At runtime, when you assign a method to a delegate variable, you're creating a delegate instance that wraps that method. You can then invoke the delegate as if you were calling the method directly. Multiple methods can be combined into a single delegate using the += operator, creating a multicast delegate that invokes all registered methods in sequence.

Delegates enable several important patterns: callbacks (passing a method to be called later), event handling (notifying subscribers of state changes), and functional composition (chaining operations). The .NET Framework provides built-in generic delegates like Action and Func that cover most common scenarios, reducing the need to declare custom delegate types.

Example
csharp
```
// Define a delegate type
public delegate void NotificationDelegate(string message);

// Method matching the delegate signature
public static void SendEmail(string message) => Console.WriteLine($"Email: {message}");
public static void SendSms(string message) => Console.WriteLine($"SMS: {message}");

// Usage
NotificationDelegate notify = SendEmail;
notify("Hello!");  // Output: Email: Hello!

// Add another method (multicast)
notify += SendSms;
notify("Alert");  // Invokes both SendEmail and SendSms

// Modern approach using Action (no need to declare delegate type)
Action<string> modernNotify = SendEmail;
modernNotify("Modern way");
```
This example shows a custom delegate type, assigning a method to it, invoking it, and combining multiple methods. The modern approach uses the built-in Action<T> generic delegate, which is cleaner and more commonly used today.

Key points to mention
- Type-safety: The compiler ensures only methods with matching signatures can be assigned to a delegate
- Multicast capability: Multiple methods can be combined using += and -=, creating chains of invocations
- Foundation for events: Events in .NET are built on delegates; an event is essentially a delegate with restricted access (can only be invoked from the declaring class)
- Generic alternatives: Action<T> (no return value) and Func<T, TResult> (returns a value) cover most use cases and are preferred over custom delegate declarations
- Enables functional programming: Delegates allow passing behavior as data, supporting lambda expressions and LINQ operations
Common follow-up questions
- What is the difference between a delegate and an event? (Events restrict who can invoke the delegate)
- How do lambda expressions relate to delegates? (Lambdas are anonymous functions commonly assigned to delegates)
- What is the difference between Action and Func? (Action performs an operation with no return value; Func returns a result)
Related interview questions
.NETCsharpArchitecture
57What are Func, Action and Predicate?
Beginner
Func, Action, and Predicate are built-in generic delegate types in .NET that simplify working with methods as first-class objects. Action represents a method that returns void, Func represents a method that returns a value, and Predicate represents a method that returns a boolean. They eliminate the need to declare custom delegate types for common scenarios.

How it works

Delegates are type-safe function pointers that allow you to pass methods around as parameters or store them as variables. Before generics, you'd define a custom delegate type for each method signature. The framework team recognized three patterns were so common they built them in as generic delegates.

Action<T> represents a method that takes parameters of type T and returns nothing (void). It has 16 overloads: Action (no parameters), Action<T>, Action<T1, T2>, and so on up to 16 parameters.

Func<T, TResult> represents a method that takes parameters and returns a value of type TResult. The last type parameter is always the return type. Like Action, it supports overloads from zero to 16 input parameters.

Predicate<T> is a specialized version of Func that takes a single parameter and returns bool. It's commonly used for filtering and searching operations. Under the hood, Predicate<T> is equivalent to Func<T, bool>, but its name makes the intent clearer.

All three are reference types stored on the heap, allowing them to be passed between methods and stored in collections.

Example
csharp
```
// Action: takes parameters, returns void
Action<string> greet = name => Console.WriteLine($"Hello, {name}!");
greet("Alice"); // Output: Hello, Alice!

// Func: takes parameters, returns a value
Func<int, int, int> add = (a, b) => a + b;
int result = add(5, 3); // result = 8

// Predicate: takes one parameter, returns bool
Predicate<int> isEven = x => x % 2 == 0;
bool check = isEven(4); // check = true

// Practical usage with LINQ
List<int> numbers = [1, 2, 3, 4, 5];
var evenNumbers = numbers.Where(x => x % 2 == 0).ToList(); // [2, 4]
var squared = numbers.Select(x => x * x).ToList(); // [1, 4, 9, 16, 25]
```
This example shows how Action executes an operation with side effects, Func transforms input into output, and Predicate filters collections based on a condition.

Key points to mention
- Action returns void, Func returns a value, Predicate<T> returns bool—choose based on what your method needs to do
- They support lambda expressions and method groups, making code more concise than declaring custom delegates
- Predicate<T> is semantically equivalent to Func<T, bool> but signals intent when used for filtering or validation
- All three integrate seamlessly with LINQ methods like Where, Select, Find, and ForEach
- Type parameters are generic, so they work with any type—primitives, classes, structs, or custom types
Common follow-up questions
- What's the difference between Predicate<T> and Func<T, bool>? When would you use one over the other?
- Can you pass an async method as an Action or Func? What happens?
- How do delegates relate to the delegate keyword versus lambda expressions?
Related interview questions
Further reading
- Value objects
.NETCsharp
58What is an event in C#?
Beginner
An event in C# is a wrapper around a delegate that allows a class to notify subscribers when something happens. It enforces encapsulation by restricting external code to only subscribe (+=) or unsubscribe (-=), preventing them from reassigning or invoking the delegate directly. Events are a core pattern for implementing the observer design pattern and enabling loose coupling between components.

How it works

An event is built on top of delegates. A delegate defines the signature (parameters and return type) that event handlers must match. When you declare an event, you specify a delegate type, and only the class that owns the event can invoke it. External subscribers can only attach their handlers (methods) to the event using the += operator or detach them using the -= operator.

This differs from exposing a delegate directly. If you expose a public delegate field, external code could reassign it entirely (wiping out all subscribers) or invoke it from outside. Events prevent both of these problems by making the delegate accessible only within the class, while providing controlled subscription and unsubscription access to the outside world.

Events follow a publish-subscribe pattern: the publisher (the class that owns the event) raises the event when a condition occurs, and all subscribers receive notification by having their handler methods called automatically.

Example
csharp
```
public delegate void OrderEventHandler(string message);

public class OrderProcessor
{
    // Event declaration
    public event OrderEventHandler OrderPlaced;
    public event OrderEventHandler OrderShipped;

    public void PlaceOrder(string orderId)
    {
        Console.WriteLine($"Processing order: {orderId}");
        // Raise the event (only possible within this class)
        OnOrderPlaced($"Order {orderId} has been placed");
    }

    public void ShipOrder(string orderId)
    {
        Console.WriteLine($"Shipping order: {orderId}");
        OnOrderShipped($"Order {orderId} has been shipped");
    }

    // Protected method to raise the event
    protected virtual void OnOrderPlaced(string message)
    {
        OrderPlaced?.Invoke(message);
    }

    protected virtual void OnOrderShipped(string message)
    {
        OrderShipped?.Invoke(message);
    }
}

// Usage
var processor = new OrderProcessor();

// Subscribe to events
processor.OrderPlaced += (message) => Console.WriteLine($"[Notification] {message}");
processor.OrderPlaced += (message) => Console.WriteLine($"[Email] Sending email: {message}");
processor.OrderShipped += (message) => Console.WriteLine($"[SMS] Sending SMS: {message}");

processor.PlaceOrder("ORD-123");
processor.ShipOrder("ORD-123");

// This would cause a compile error:
// processor.OrderPlaced = null;  // Cannot reassign
// processor.OrderPlaced.Invoke("test");  // Cannot invoke from outside
```
This example demonstrates a publisher (OrderProcessor) raising events when orders are placed or shipped, and multiple subscribers receiving notifications through their subscribed handlers.

Key points to mention
- Built on delegates: Events use a delegate type to define the signature that handlers must match.
- Encapsulation: Only the class owning the event can raise it; external code can only subscribe and unsubscribe.
- Loose coupling: Publishers don't need to know the details of subscribers, promoting maintainability and extensibility.
- Thread safety: Modern C# uses the null-conditional operator (?.Invoke()) to safely invoke events even if no subscribers exist.
- Event naming convention: Event names typically describe what happened (past tense), like OrderPlaced or ButtonClicked, and handlers follow the pattern On[EventName].
Common follow-up questions
- What is the difference between an event and a delegate? (Events prevent external reassignment; delegates don't.)
- How do you unsubscribe from an event, and why is it important? (Use -= to unsubscribe and prevent memory leaks from dangling event handlers.)
- What is the EventHandler and EventHandler<T> pattern? (Standard delegate types used for events in the .NET framework, with specific signatures.)
Related interview questions
- What is a lambda expression?
- What are Func, Action and Predicate?
Further reading
- Observer pattern
.NETCsharpArchitecture
59What is an extension method?
Beginner
An extension method allows you to add new methods to existing types without modifying their source code or creating a derived class. It is a static method defined in a static class with the this keyword on its first parameter, which specifies the type being extended.

How it works

Extension methods provide a way to extend functionality of sealed types, built-in types, and third-party classes that you cannot modify directly. When you define an extension method, the compiler translates the call into a static method invocation. For example, when you call myString.IsNullOrEmpty(), the compiler converts it to StringExtensions.IsNullOrEmpty(myString). This syntactic sugar makes the code more readable and intuitive, as if the method belonged to the original type.

The this keyword in the first parameter is crucial—it tells the compiler which type this method extends. The remaining parameters are regular method parameters that can be passed when calling the extension method. Extension methods must be defined in a static class and must themselves be static.

Extension methods are discovered through the namespace in which they are defined. If you want to use an extension method, you must either have it in the same namespace or explicitly import the namespace with a using statement. This prevents accidental pollution of the global method space.

Example
csharp
```
using System;

// Extension method defined in a static class
public static class StringExtensions
{
    public static bool IsValidEmail(this string value)
    {
        return value.Contains("@") && value.Contains(".");
    }

    public static string Reverse(this string value)
    {
        char[] charArray = value.ToCharArray();
        Array.Reverse(charArray);
        return new string(charArray);
    }
}

class Program
{
    static void Main()
    {
        string email = "user@example.com";
        
        // Calling extension methods as if they belong to string
        if (email.IsValidEmail())
            Console.WriteLine("Valid email");
        
        Console.WriteLine(email.Reverse()); // Output: moc.elpmaxe@resu
    }
}
```
This example defines two extension methods for the string type: one to validate email format and one to reverse a string. The methods can be called directly on any string variable, making the code more fluent and readable.

Key points to mention
- Extension methods must be declared in a static class and must be static themselves
- The first parameter uses the this keyword to specify which type is being extended
- They work on any type: built-in types, sealed classes, third-party libraries, and your own classes
- Extension methods are resolved at compile time, not runtime, so they do not affect performance
- They are commonly used in LINQ, where methods like Where(), Select(), and GroupBy() are extensions on IEnumerable<T>
Common follow-up questions
- Can you use extension methods with interfaces or only classes? (Yes, both—you extend the interface type itself)
- What happens if an extension method has the same name as an instance method on the type? (Instance methods take precedence; the extension is ignored)
- Can extension methods access private members of the class they extend? (No, they have the same access restrictions as any external code)
Related interview questions
Further reading
- Configuring EF Core relationships
- Extension methods done right
.NETCsharp
60What is exception handling in C#?
Beginner
Exception handling in C# is a mechanism to gracefully manage runtime errors using try-catch-finally blocks. It allows you to detect errors (exceptions), handle them appropriately, and ensure cleanup code runs regardless of success or failure. Proper exception handling prevents application crashes and enables recovery strategies.

How it works

When an error occurs in a try block, the runtime creates an exception object and looks for a matching catch block. If found, the catch block executes; if not, the exception propagates up the call stack. The finally block (if present) always executes, whether an exception occurred or not, making it ideal for resource cleanup.

C# uses a hierarchical exception model where all exceptions inherit from System.Exception. You should catch specific exceptions (like FileNotFoundException or ArgumentNullException) before general ones (like Exception). This specificity allows targeted recovery—for example, retrying a failed network request differently than handling invalid input.

Modern C# offers the using statement and using declaration for automatic resource disposal, which work alongside exception handling to ensure that resources like file streams or database connections are released even when exceptions occur. The difference between Results.Problem and throwing exceptions relates to how APIs signal errors: exceptions are for exceptional, unrecoverable conditions, while Result patterns are often preferred in modern API design.

Example
csharp
```
public class FileProcessor
{
    public string ReadConfigFile(string path)
    {
        try
        {
            using var reader = new StreamReader(path);
            return reader.ReadToEnd();
        }
        catch (FileNotFoundException ex)
        {
            Console.WriteLine($"Config file not found: {ex.Message}");
            return string.Empty;
        }
        catch (UnauthorizedAccessException ex)
        {
            Console.WriteLine($"Access denied: {ex.Message}");
            return string.Empty;
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Unexpected error: {ex.Message}");
            throw;
        }
        finally
        {
            Console.WriteLine("File read attempt completed.");
        }
    }
}

// Usage
var processor = new FileProcessor();
string config = processor.ReadConfigFile("appsettings.json");
```
This example demonstrates catching specific exceptions first (file not found, access denied), then a general catch-all that rethrows to propagate unexpected errors. The finally block logs completion, and the using declaration automatically disposes the StreamReader.

Key points to mention
- Catch specific exceptions first—let unexpected exceptions bubble up rather than silently swallowing them with a bare catch (Exception).
- Finally always runs—use it (or using statements) for guaranteed cleanup of resources, connections, or file handles.
- Exceptions are for exceptional cases—don't use them for normal control flow; they're expensive and indicate something went wrong.
- Exception details matter—include the message, stack trace, and inner exception when logging or rethrowing so debugging is easier.
- Consider using Result patterns in modern APIs instead of throwing exceptions for expected error conditions, improving clarity and testability.
Common follow-up questions
- What's the difference between throw and throw ex?
- When should I use finally vs. using statements?
- How do you implement global exception handling?
Related interview questions
Further reading
- Exception handling anti-patterns
.NETCsharp
61What is the difference between throw and throw ex?
Beginner
throw; rethrows the current exception while preserving its original stack trace, making debugging easier. throw ex; rethrows the exception but resets the stack trace to the point where throw ex; is called, losing information about where the error originally occurred. Always use throw; without arguments when rethrowing exceptions in a catch block.

How it works

When an exception is thrown in .NET, the runtime captures a stack trace showing the exact sequence of method calls that led to the error. This stack trace is invaluable for debugging because it shows the complete call chain from where the exception originated to where it was caught.

When you use throw; (bare throw statement) inside a catch block, the CLR rethrows the same exception object with its original stack trace intact. The stack trace still points to the original location where the exception was first thrown, preserving the complete debugging information.

When you use throw ex; (where ex is the caught exception variable), you are explicitly throwing the exception object again, but this creates a new throw point. The runtime updates the stack trace to start from this new throw statement, effectively erasing information about all the intermediate calls between the original throw and the catch block. This makes it significantly harder to trace back to the root cause of the problem.

Modern versions of .NET and Visual Studio partially mitigate this issue by preserving an "inner" exception reference, but using throw ex; still loses critical stack trace information that was present in the original exception.

Example
csharp
```
public class StackTraceExample
{
    public static void Main()
    {
        try
        {
            MethodA();
        }
        catch (Exception ex)
        {
            Console.WriteLine("Stack trace:");
            Console.WriteLine(ex.StackTrace);
        }
    }

    public static void MethodA() => MethodB();
    public static void MethodB() => MethodC();

    public static void MethodC()
    {
        try
        {
            throw new InvalidOperationException("Original error");
        }
        catch (Exception ex)
        {
            // GOOD: Preserves original stack trace
            throw;
            
            // BAD: Resets stack trace (uncomment to see difference)
            // throw ex;
        }
    }
}
```
When using throw;, the stack trace shows MethodA → MethodB → MethodC. With throw ex;, the stack trace only shows the catch block in MethodC, hiding the earlier methods in the call chain.

Key points to mention
- Use throw; (bare throw) to preserve the original stack trace when rethrowing in a catch block
- throw ex; resets the stack trace, making it harder to debug and understand the root cause
- The stack trace is critical diagnostic information that shows the complete call sequence leading to an exception
- Only throw a new exception explicitly if you're transforming the error or wrapping it in a custom custom exception
- Most exception handling best practices recommend avoiding unnecessary rethrows altogether
Common follow-up questions
- When should you create a new exception instead of rethrowing?
- What is the difference between using throw; versus wrapping an exception in InnerException?
- How does ExceptionDispatchInfo help preserve stack traces in async code?
Related interview questions
- What is a custom exception?
- What is exception handling in C#?
.NETCsharp
62What is a custom exception?
Beginner
A custom exception is a class that inherits from the Exception class (or a more specific exception type) and represents a domain-specific error condition in your application. Unlike built-in exceptions like ArgumentNullException or InvalidOperationException, custom exceptions allow you to throw and catch application-specific scenarios—such as OrderNotFoundException or InsufficientInventoryException—making error handling more precise and your code's intent clearer.

How it works

When you create a custom exception, you define a new class that inherits from Exception or another exception type. This allows you to encapsulate domain logic and error details relevant to your business context. Custom exceptions are typically thrown when a specific business rule is violated or an expected operation fails in a way that your application needs to handle differently.

The benefit is semantic clarity: instead of throwing a generic InvalidOperationException when an order cannot be found, you throw OrderNotFoundException, signaling to callers exactly what went wrong. Calling code can then catch that specific exception and respond appropriately—perhaps logging, returning a 404 response, or retrying with different parameters.

Custom exceptions follow the same exception handling mechanisms as built-in exceptions: they propagate up the call stack until caught by a try-catch block or handled by a global error handler. They can include additional properties to provide context—like an order ID, the requested quantity, or a custom error code—helping downstream handlers make informed decisions.

Example
csharp
```
// Define a custom exception
public class OrderNotFoundException : Exception
{
    public int OrderId { get; }

    public OrderNotFoundException(int orderId)
        : base($"Order with ID {orderId} was not found.")
    {
        OrderId = orderId;
    }

    public OrderNotFoundException(int orderId, Exception innerException)
        : base($"Order with ID {orderId} was not found.", innerException)
    {
        OrderId = orderId;
    }
}

// Usage
public class OrderService
{
    public Order GetOrder(int orderId)
    {
        var order = _database.FindOrder(orderId);
        if (order == null)
            throw new OrderNotFoundException(orderId);

        return order;
    }
}

// Calling code catches the specific exception
try
{
    var order = orderService.GetOrder(999);
}
catch (OrderNotFoundException ex)
{
    Console.WriteLine($"Could not retrieve order {ex.OrderId}");
}
```
This example defines OrderNotFoundException with a custom property (OrderId) and multiple constructors to support inner exceptions, making it easy for calling code to handle missing orders specifically and access context about what failed.

Key points to mention
- Inherit from Exception or a specific base: Always derive from Exception or a more targeted base class like InvalidOperationException; follow .NET naming conventions by ending with "Exception".
- Provide constructors for flexibility: Include constructors that accept a message, an inner exception, or both, allowing callers to wrap or pass through root causes.
- Include contextual properties: Add public properties (like OrderId) that give callers specific details about what failed, reducing the need to parse error messages.
- Use for domain-specific errors: Reserve custom exceptions for business logic failures and expected edge cases, not for control flow or catching programming mistakes.
- Keep them lightweight: Custom exceptions should not contain heavy business logic; they are signals, not solutions.
Common follow-up questions
- Should I always create a custom exception, or use built-in ones? Use built-in exceptions for framework-level errors (ArgumentNullException, InvalidOperationException). Create custom exceptions only when you need specific, domain-aware handling that callers will benefit from catching distinctly.
- Can I add static methods or factory patterns to custom exceptions? Yes, though it is uncommon. You might create a static factory to standardize logging or wrap multiple error scenarios, but keep this minimal; exceptions should primarily be data carriers for error context.
- How do custom exceptions interact with middleware or global error handlers? Middleware and error-handling filters can catch custom exceptions and translate them into appropriate HTTP responses—for example, converting OrderNotFoundException to a 404 status code.
Related interview questions
.NETCsharp
63What is the using statement?
Beginner
The using statement is a C# language construct that ensures the Dispose() method is called on IDisposable objects when execution leaves the using block, even if an exception occurs. This guarantees proper cleanup of unmanaged resources like file handles, database connections, and network streams without requiring explicit try-finally blocks. The modern using var declaration form (C# 8+) automatically disposes the object at the end of its scope.

How it works

When you declare a variable with using, the compiler generates code that wraps your block in an implicit try-finally statement. After the using block exits—whether normally, via return, or due to an exception—the finally block calls Dispose() on the resource.

There are two forms of the using statement:
1. Traditional using statement: using (Type variable = new Type()) { } — disposes when the block ends
2. Using declaration (C# 8+): using Type variable = new Type(); — disposes at the end of the enclosing scope (method, class, etc.)
The compiler essentially transforms using (var resource = GetResource()) { /* code */ } into:
csharp
```
var resource = GetResource();
try
{
    /* code */
}
finally
{
    resource?.Dispose();
}
```
This pattern is critical because many .NET types manage unmanaged resources—file handles, database connections, streams—that won't be cleaned up by the garbage collector alone. Without proper disposal, you can leak resources, exhaust connection pools, or leave files locked.

Example
csharp
```
// Traditional using statement
using (var file = new StreamWriter("output.txt"))
{
    file.WriteLine("Hello, World!");
} // Dispose() called automatically here

// Modern using declaration (C# 8+)
using var connection = new SqlConnection("Server=localhost");
connection.Open();
// ... use connection
// Dispose() called at end of method scope

// Multiple resources
using var reader = new StreamReader("input.txt");
using var writer = new StreamWriter("output.txt");
{
    string line = reader.ReadLine();
    if (line != null) writer.WriteLine(line);
} // Both disposed automatically
```
In this example, the StreamWriter and StreamReader objects are automatically disposed when their using scopes end, ensuring file handles are released even if an exception occurs during file operations.

Key points to mention
- The using statement requires the object to implement IDisposable interface; it calls Dispose() automatically
- Exception safety is built-in: Dispose() is called even if an unhandled exception occurs within the block
- Using declarations (C# 8+) dispose at the end of scope rather than at the end of a block, making the code cleaner and less nested
- Multiple using declarations can be chained to manage several resources in order (disposed in reverse declaration order)
- You can use resource?.Dispose() syntax to safely dispose nullable resources
Common follow-up questions
- What happens if Dispose() throws an exception? The exception propagates; if you need to dispose multiple resources safely despite exceptions, use nested using statements or consider a finally block
- What's the difference between using statement and try-finally? Both call Dispose() in finally, but using is syntactic sugar that's cleaner and less error-prone
- Do I need using for every IDisposable object? Yes, or you risk resource leaks; most .NET framework classes that manage resources implement IDisposable and should be wrapped in using
Related interview questions
- What is IDisposable?
- What is a custom exception?
.NETCsharpasync
64What is IDisposable?
Beginner
IDisposable is a .NET interface that defines a Dispose() method for deterministically releasing unmanaged resources like file handles, database connections, and network sockets. Instead of waiting for the garbage collector to run, you explicitly call Dispose() to free these resources immediately, preventing resource leaks and improving application performance.

How it works

The IDisposable interface contains a single method: void Dispose(). When a class implements this interface, it promises to clean up unmanaged resources when Dispose() is called. Unmanaged resources are anything not managed by the CLR—think file handles from the operating system, database connection sockets, or memory allocated via P/Invoke.

The garbage collector doesn't know about these resources and won't clean them up automatically. Without Dispose(), a file might stay locked, a database connection might remain open, or system memory might leak until the application terminates. By implementing IDisposable, your class provides a way for consumers to explicitly free these resources when done.

The pattern is often combined with the using statement (or declaration in C# 8+), which automatically calls Dispose() when the variable goes out of scope, even if an exception occurs.

Example
csharp
```
public class FileProcessor : IDisposable
{
    private FileStream? _fileStream;

    public void OpenFile(string path)
    {
        _fileStream = new FileStream(path, FileMode.Open);
    }

    public void Dispose()
    {
        _fileStream?.Dispose();
        GC.SuppressFinalize(this);
    }
}

// Usage
using (var processor = new FileProcessor())
{
    processor.OpenFile("data.txt");
    // File is open here
} // Dispose() is called automatically here
```
This example shows a class managing a FileStream (an unmanaged resource). The using statement automatically calls Dispose() when the block exits, closing the file handle immediately.

Key points to mention
- Unmanaged resources only: Use IDisposable for OS handles, file streams, database connections, and P/Invoke memory—not for regular managed objects.
- Deterministic cleanup: Dispose() lets you control exactly when resources are freed, rather than waiting for garbage collection.
- Using statement integration: The using keyword automatically calls Dispose(), making the pattern safe even if exceptions occur.
- Best practice is the full pattern: The standard full Dispose pattern includes a finalizer and separate protected Dispose(bool) method for inheritance safety.
- IAsyncDisposable: For async cleanup operations, IAsyncDisposable provides DisposeAsync() instead.
Common follow-up questions
- Why not just use a finalizer? Finalizers run unpredictably after garbage collection; Dispose() runs immediately when called.
- What's the difference between Close() and Dispose()? Some classes (like FileStream) have both, but Dispose() is the standard interface and should always be preferred.
- Do I need to implement both Dispose() and a finalizer? Only if your class holds unmanaged resources directly; if it only holds IDisposable objects, you don't need a finalizer.
Related interview questions
.NETCsharpPerformance
65What is garbage collection?
Beginner
Garbage collection (GC) is the automatic memory management process that frees heap memory occupied by objects that the application no longer needs. The .NET runtime tracks object references and periodically reclaims memory from objects that are unreachable, eliminating the need for manual memory deallocation like in C++. This prevents memory leaks and makes .NET development safer and more productive.

How it works

The garbage collector operates by marking objects as reachable or unreachable. It starts with root references (local variables, static fields, CPU registers) and traverses the object graph to identify all objects still in use. Any object not found in this traversal is considered unreachable and its memory can be reclaimed.

.NET uses a generational garbage collection strategy to optimize performance. Objects are organized into three generations (0, 1, and 2). Generation 0 contains newly created objects and is collected frequently—most short-lived objects die here and are cleaned up cheaply. Generation 1 is an intermediate stage for objects that survived one collection. Generation 2 holds long-lived objects collected less frequently. This strategy works because most objects are short-lived; by focusing collection effort on Generation 0, the GC minimizes pause times.

The garbage collector also compacts the heap after collection, moving surviving objects together in memory to reduce fragmentation and improve cache locality. This process is deterministic in the sense that you can't predict exactly when a collection occurs, but you can request one explicitly if needed (though rarely recommended).

Example
csharp
```
public class MemoryExample
{
    public static void Main()
    {
        // Create objects
        var person1 = new Person { Name = "Alice" };
        var person2 = new Person { Name = "Bob" };
        
        // person1 goes out of scope and becomes unreachable
        person1 = null;
        
        // At some point, GC runs and reclaims memory for the original person1 object
        // person2 remains reachable and its memory is not freed
        
        Console.WriteLine(person2.Name); // Output: Bob
    }
}

public class Person
{
    public string Name { get; set; }
}
```
In this example, when person1 is set to null, the original Person object it referenced becomes unreachable. The garbage collector will eventually collect that object's memory, while the object referenced by person2 remains safe because it's still reachable.

Key points to mention
- Automatic memory management: Developers don't manually free memory; the runtime handles it transparently.
- Generational strategy: Objects are divided into generations so young, short-lived objects are collected more frequently than old, long-lived ones.
- Heap compaction: After collecting dead objects, the GC moves surviving objects together, reducing fragmentation and improving performance.
- Heap allocation only: GC only manages heap memory; stack memory (value types) is freed when they go out of scope.
- Non-deterministic timing: You cannot predict when GC runs, though you can request it with GC.Collect() (rarely recommended in production).
Common follow-up questions
- What causes memory leaks in managed code if garbage collection is automatic?
- How does the garbage collector handle objects with destructors or IDisposable?
- Can you force garbage collection, and when would you do it?
Related interview questions
.NETCsharpPerformance
66What are GC generations?
Beginner
GC generations are a memory management optimization in .NET where objects are categorized into three age groups—Generation 0, 1, and 2—based on how long they've survived garbage collection cycles. The garbage collector prioritizes collecting younger generations more frequently because most objects are short-lived, making the system more efficient than collecting all memory every time.

How it works

When the .NET garbage collector (GC) runs, it doesn't treat all objects equally. Instead, it uses a generational hypothesis: most objects die young, and those that survive collection are likely to live longer.

Generation 0 is where all new objects are allocated. When memory pressure triggers a collection, Gen 0 is collected frequently and aggressively. Objects that survive a Gen 0 collection are promoted to Generation 1.

Generation 1 acts as a buffer zone. It contains objects that survived at least one collection. Gen 1 is collected less frequently than Gen 0, and when it is collected, both Gen 0 and Gen 1 are examined. Objects surviving a Gen 1 collection move to Generation 2.

Generation 2 holds long-lived objects—those that have survived multiple collections. Gen 2 is collected infrequently, typically only when memory is critically needed. A full garbage collection examines all three generations.

This tiered approach means the GC spends most time on the youngest generation where most garbage is found, rather than repeatedly scanning long-lived objects that rarely need collection.

Example
csharp
```
using System;

class Program
{
    static void Main()
    {
        // These objects start in Gen 0
        var temp1 = new byte[1000];
        var temp2 = new byte[1000];
        
        Console.WriteLine($"Before GC - Gen 0 objects: {GC.GetTotalMemory(false)}");
        
        // Force a Gen 0 collection
        GC.Collect(0, GCCollectionMode.Optimized);
        
        // temp1 and temp2 are unreachable, so they're collected
        // Objects that survive move to Gen 1
        Console.WriteLine($"After Gen 0 collection: {GC.GetTotalMemory(false)}");
        
        // Create a long-lived object
        var longLived = new byte[10000];
        
        // Multiple collections eventually promote longLived to Gen 2
        for (int i = 0; i < 3; i++)
        {
            GC.Collect(i);
        }
        
        Console.WriteLine($"longLived is now in Gen {GC.GetGeneration(longLived)}");
    }
}
```
This code demonstrates object promotion: newly created objects start in Gen 0, and GC.GetGeneration() shows which generation an object currently occupies after successive collections.

Key points to mention
- Three-tier structure: Gen 0 (new), Gen 1 (intermediate), Gen 2 (old) optimize collection frequency based on object lifespan.
- The generational hypothesis: Most objects die young, so collecting Gen 0 frequently captures most garbage with minimal overhead.
- Promotion on survival: Objects that survive a collection are promoted to the next generation, reducing re-scanning of long-lived objects.
- Full collections are expensive: Gen 2 collections pause the application longer because they examine all objects, making them rare by design.
- Predictable performance: The generational model provides more predictable pause times compared to collecting the entire heap at once.
Common follow-up questions
- What triggers garbage collection? (See how does the .NET garbage collector decide when to run?)
- Can you manually control which generation gets collected?
- What is garbage collection and why do we need it?
Related interview questions
Further reading
- Refresh token rotation in .NET
.NETCsharpPerformance
67What is async and await?
Beginner
async and await are keywords that enable asynchronous programming in C#. The async keyword marks a method as asynchronous, allowing it to use the await keyword. The await keyword pauses execution of the method, frees the thread to handle other work, and resumes when the awaited task completes, keeping applications responsive and scalable without blocking threads.

How it works

When you mark a method with async, the compiler transforms it into a state machine that can pause and resume. Inside an async method, await does three things:
1. Checks if the awaited task is already complete. If yes, execution continues synchronously.
2. If not complete, the method returns a Task to the caller and the thread is freed to process other requests.
3. When the awaited operation finishes, a continuation is scheduled to resume the method from where it paused.
This is fundamentally different from blocking. Traditional synchronous code holds a thread hostage while waiting for I/O (network, disk, database). Async/await releases the thread, allowing the thread pool to serve other requests. This multiplies throughput without creating new threads.

The return type of an async method should be Task, Task<T>, or (in rare cases) void. Always prefer Task or Task<T> over async void because async void methods cannot be awaited and exceptions thrown in them crash the application domain.

Example
csharp
```
public async Task<string> FetchUserNameAsync(int userId)
{
    // Await frees the thread while the HTTP request is in flight
    var response = await httpClient.GetAsync($"https://api.example.com/users/{userId}");
    response.EnsureSuccessStatusCode();
    
    var content = await response.Content.ReadAsStringAsync();
    return content;
}

// Calling code
var userName = await FetchUserNameAsync(42);
Console.WriteLine(userName);
```
This method makes an HTTP request without blocking the thread. While waiting for the server response, the thread handles other requests. Once the response arrives, the method resumes, reads the content, and returns it.

Key points to mention
- async is a compile-time marker; it doesn't create threads. It enables use of await and transforms the method into a state machine.
- await only works inside an async method. It pauses execution and frees the thread, enabling better resource utilization.
- Always use Task or Task<T> as return types, never async void (except for event handlers), because exceptions in async void cannot be caught.
- Async doesn't make code faster; it makes applications more scalable by reducing thread starvation in high-concurrency scenarios.
- Understand the difference between Task.Run and async/await—Task.Run creates a new thread, while await releases the current one.
Common follow-up questions
- Why should I avoid async void? (Because exceptions thrown in async void methods cannot be caught by the caller and will crash the application.)
- What happens if I don't await an async method? (The method returns a Task that is never observed, potentially causing unhandled exceptions and unpredictable behavior.)
- How does async/await compile under the hood? (The compiler generates a state machine that manages pause/resume logic and continuations.)
Related interview questions
Further reading
- async/await pitfalls in .NET
.NETCsharpasync
68What is a Task?
Beginner
A Task is a .NET abstraction that represents an asynchronous operation that may or may not return a value. The Task class (representing no return value) and Task<T> generic class (representing a return value of type T) are fundamental to C# async/await programming. Tasks can be awaited, combined, cancelled, and monitored for completion.

How it works

A Task is a promise that work will be completed at some point in the future. When you call an async method, it returns a Task immediately without blocking the calling thread. The actual execution may happen on a thread pool thread, or it may be scheduled to run later. The Task itself acts as a handle to that ongoing work, allowing you to:
- Await it — pause execution until the Task completes using the await keyword
- Check its status — inspect whether it's running, completed, faulted, or cancelled via properties like IsCompleted, IsFaulted, and IsCanceled
- Get a result — with Task<T>, retrieve the value via the Result property (blocking if necessary) or await and extract it
- Combine multiple Tasks — use Task.WhenAll() or Task.WhenAny() to coordinate multiple asynchronous operations
- Cancel it — request cancellation through a CancellationToken
Under the hood, Tasks are built on top of the thread pool and compiler-generated state machines created by the async/await pattern. When you await a Task, the method pauses, and the runtime schedules a continuation to resume when the Task completes.

Example
csharp
```
// Returning Task with no value
async Task FetchDataAsync()
{
    await Task.Delay(1000);
    Console.WriteLine("Data fetched");
}

// Returning Task<T> with a value
async Task<int> GetCountAsync()
{
    await Task.Delay(500);
    return 42;
}

// Usage
async Task Main()
{
    // Await a Task with no return value
    await FetchDataAsync();
    
    // Await a Task<T> and capture the result
    int count = await GetCountAsync();
    Console.WriteLine($"Count: {count}");
    
    // Combine multiple tasks
    var task1 = FetchDataAsync();
    var task2 = GetCountAsync();
    await Task.WhenAll(task1, task2);
}
```
This example shows how FetchDataAsync() returns a non-generic Task, while GetCountAsync() returns Task<int>; both can be awaited, and Task.WhenAll() waits for both to complete.

Key points to mention
- Task represents future work — it doesn't necessarily run on a different thread; it's a scheduling and coordination mechanism
- Async methods should return Task or Task<T>, not void (see why you should avoid async void)
- Tasks are allocated on the heap and are reference types
- Use await to unwrap a Task rather than blocking with .Result or .Wait(), which can cause deadlocks
- Tasks support cancellation through CancellationToken and exception handling via try/catch around await statements
Common follow-up questions
- What's the difference between Task and Thread? — Tasks are higher-level abstractions managed by the thread pool, while threads are lower-level OS constructs. Many Tasks can run on a single thread through cooperative multitasking.
- When should you use Task.Run()? — Use Task.Run() to offload CPU-bound work to a thread pool thread, not for I/O-bound operations which already return Tasks.
- Can I await a Task multiple times? — Yes, a completed Task can be awaited multiple times and will return the same result each time.
Related interview questions
- Why should you avoid async void?
- What is the difference between stack and heap memory?
.NETCsharpasync
69Why should you avoid async void?
Beginner
Avoid async void methods because they cannot be awaited, making it impossible to know when they complete, and any unhandled exceptions will crash your entire application. Async void should only be used for event handlers; everywhere else, return Task or Task<T> to ensure proper exception handling and composability.

How it works

When you declare a method as async void, the compiler generates a state machine that doesn't return anything to the caller. Unlike async Task, which returns a Task object that represents the asynchronous operation, async void returns control immediately and the caller has no handle on the ongoing work.

This creates two critical problems. First, the caller cannot await the method or know when it finishes executing. If calling code needs to wait for completion or coordinate multiple operations, it's impossible. Second, any exception thrown inside an async void method is raised on the synchronization context that invoked it. If there's no handler, the exception propagates to the top level and crashes the entire process—often with a cryptic "An unhandled exception of type 'System.Exception' occurred in YourApp.exe" message.

Async Task, by contrast, captures exceptions into the returned Task object. The caller can await it and handle exceptions with try-catch, or let them propagate as faulted tasks. This gives you control and predictability.

Example
csharp
```
// ❌ BAD: async void – cannot await, exceptions crash the app
public async void ProcessDataBad()
{
    await Task.Delay(1000);
    throw new InvalidOperationException("Something went wrong!");
}

// ✅ GOOD: async Task – can await and handle exceptions
public async Task ProcessDataGood()
{
    await Task.Delay(1000);
    throw new InvalidOperationException("Something went wrong!");
}

// Usage
public async void OnButtonClick()
{
    // ❌ No way to await or catch exceptions
    ProcessDataBad();
    
    // ✅ Can await and handle errors
    try
    {
        await ProcessDataGood();
    }
    catch (InvalidOperationException ex)
    {
        Console.WriteLine($"Caught: {ex.Message}");
    }
}
```
The bad example throws an unhandled exception that crashes the application; the good example lets you catch and handle it gracefully in calling code.

Key points to mention
- No awaiting: Callers cannot await async void methods, breaking the async chain and making it impossible to coordinate work.
- Uncontrolled exceptions: Exceptions in async void bypass Task exception handling and can crash the process.
- Event handlers are the exception: The only acceptable use of async void is for event handlers (like button clicks) where the caller expects no return value.
- Always return Task or Task<T>: Make async methods returnable so callers can await them, compose them with other operations, and handle errors.
- Difficult to test: Unit tests cannot easily verify completion or await async void methods, making them hard to test reliably.
Common follow-up questions
- "When is async void acceptable?" – Only for event handlers (button clicks, form loaded, etc.) where the runtime expects no return value and fire-and-forget semantics are appropriate.
- "What about using Task.Run with async void?" – Still avoid it; Task.Run should pair with async Task, not async void.
- "How do I make an event handler properly async?" – Use async Task and handle any exceptions inside the handler or attach handlers to the returned task.
Related interview questions
Further reading
- Pass CancellationToken everywhere
.NETCsharpasync
70What is the difference between Task.Run and async/await?
Beginner
Task.Run explicitly queues a delegate to run on a thread pool thread, typically for CPU-bound work that needs a dedicated thread. async/await is a language feature for writing asynchronous code that returns control to the caller without blocking a thread, ideal for I/O-bound operations. The key difference: Task.Run uses a thread; async/await frees a thread while waiting.

How it works

Task.Run immediately schedules work on the ThreadPool and returns a Task representing that scheduled work. This is useful when you have synchronous CPU-intensive logic (like heavy calculations) that you want to offload from the current thread so it doesn't block the UI or request handler. The thread remains active for the duration of the operation.

async/await is syntactic sugar over state machines that allows you to write asynchronous code that looks synchronous. When an async method hits an await point (like a network call or database query), it returns control immediately without consuming a thread. The continuation resumes when the I/O operation completes. This is much more efficient for I/O-bound work because you don't need a thread waiting idle for a network response—potentially thousands of concurrent I/O operations can be pending with just a handful of threads in the pool.

In summary: use Task.Run to parallelize CPU work; use async/await to avoid blocking threads during I/O waits.

Example
csharp
```
// Task.Run – CPU-bound work
public static async Task DoCpuWork()
{
    // Offload expensive calculation to thread pool
    int result = await Task.Run(() =>
    {
        int sum = 0;
        for (int i = 0; i < 1_000_000_000; i++)
            sum += i;
        return sum;
    });
    Console.WriteLine($"Result: {result}");
}

// async/await – I/O-bound work (no Task.Run needed)
public static async Task FetchDataAsync()
{
    using var client = new HttpClient();
    // This awaits without consuming a thread while waiting
    string response = await client.GetStringAsync("https://api.example.com/data");
    Console.WriteLine($"Data: {response}");
}

// Usage
await DoCpuWork();
await FetchDataAsync();
```
In the first method, Task.Run explicitly pushes the CPU-intensive loop onto a thread pool thread so it doesn't block the caller. In the second method, GetStringAsync already returns a Task and is designed to not consume a thread while waiting for the HTTP response—no Task.Run is needed or beneficial.

Key points to mention
- Task.Run is for CPU-bound work; async/await is for I/O-bound work. Mixing them (e.g., Task.Run around I/O) wastes threads.
- async/await preserves the thread pool thread for other work; Task.Run dedicates a thread to your operation, then returns it to the pool when done.
- Overusing Task.Run on I/O operations can cause thread pool starvation and deadlocks if you block on async code.
- async/await requires the underlying operation to be truly asynchronous (return a Task); wrapping synchronous code in Task.Run is the workaround.
- Task.Run introduces scheduling overhead; use it only when you genuinely need parallel execution, not for every async call.
Common follow-up questions
- When should I use Task.Run in an ASP.NET Core handler? — Rarely. If you have a short CPU burst, just do it synchronously on the request thread. For long operations, offload to a background service. Task.Run on a web server often indicates poor architecture.
- Is it ever correct to do Task.Run around an async method? — Only to change the SynchronizationContext (rare). Generally, no—you're wasting the benefit of async by consuming an extra thread.
- Can I use Task.Run inside an async method for true parallelism? — Yes, if you have independent CPU-bound tasks and want to run them in parallel, e.g., await Task.WhenAll(Task.Run(...), Task.Run(...)).
Related interview questions
Further reading
- async/await pitfalls in .NET
.NETCsharpasync
71What is ASP.NET Core?
Beginner
ASP.NET Core is a free, open-source, cross-platform framework for building web applications and APIs on the modern .NET runtime. It replaces the older ASP.NET Framework and is designed to be fast, lightweight, modular, and cloud-native. ASP.NET Core includes built-in features like dependency injection, middleware pipeline, configuration management, and logging, making it ideal for contemporary web development.

How it works

ASP.NET Core runs on top of the .NET runtime and uses a request-response model. When a client makes an HTTP request, it is received by Kestrel, the built-in web server, and passed through a pipeline of middleware components. Each middleware can process the request, modify it, and pass it to the next middleware, or short-circuit and return a response. This pipeline eventually reaches your application logic—controllers, handlers, or endpoints—which generates a response that flows back through the middleware stack to the client.

ASP.NET Core is fundamentally modular. You start with a minimal base and add only the features you need via NuGet packages. The framework automatically handles HTTP protocol details, routing, model binding, validation, and serialization. The built-in dependency injection container makes it easy to manage dependencies and promote testability. Configuration can come from multiple sources (JSON files, environment variables, command-line arguments) and is automatically injected where needed.

Example
csharp
```
var builder = WebApplication.CreateBuilder(args);

// Add services
builder.Services.AddScoped<IGreetingService, GreetingService>();

var app = builder.Build();

// Middleware pipeline
app.UseRouting();

app.MapGet("/hello/{name}", (string name, IGreetingService service) =>
{
    var message = service.Greet(name);
    return Results.Ok(new { message });
});

app.Run();

// Simple service
interface IGreetingService
{
    string Greet(string name);
}

class GreetingService : IGreetingService
{
    public string Greet(string name) => $"Hello, {name}!";
}
```
This minimal ASP.NET Core application registers a service in the dependency injection container, sets up a middleware pipeline, defines a GET endpoint that receives a name parameter and injects the greeting service, and returns a JSON response.

Key points to mention
- Cross-platform: Runs on Windows, Linux, and macOS, unlike the older .NET Framework.
- Modular and lightweight: Start with minimal features and add only what you need; no bloat.
- High performance: Consistently ranks at the top in TechEmpower benchmarks due to efficient async/await patterns and minimal allocations.
- Built-in dependency injection: No need for external containers; DI is first-class.
- Cloud-native: Designed for containerization (Docker), microservices, and cloud platforms like Azure.
Common follow-up questions
- What is the difference between app.Use() and app.Run() in middleware?
- How does the ASP.NET Core dependency injection container work, and what are the lifetime scopes (Transient, Scoped, Singleton)?
- What is the role of Program.cs and how does the startup process work in modern ASP.NET Core?
Related interview questions
Further reading
- Dependency injection is a pattern too
.NETCsharpaspnetcore
72What is Kestrel?
Beginner
Kestrel is the cross-platform web server built into ASP.NET Core that handles HTTP and HTTPS traffic directly. It ships with every ASP.NET Core application and can run on Windows, Linux, and macOS. While it can serve traffic directly to clients, it's commonly deployed behind a reverse proxy like Nginx or IIS for production workloads.

How it works

Kestrel is a managed HTTP server written in C# that runs on top of the .NET runtime. When you create an ASP.NET Core application, Kestrel is the default hosting server. It listens on specified ports and processes incoming HTTP/HTTPS requests, passing them through the ASP.NET Core request pipeline (middleware) where your application logic handles them.

Unlike older IIS-based hosting, Kestrel doesn't require a separate server installation—it's part of your application runtime. This makes it extremely lightweight and portable. The server is optimized for performance and supports modern HTTP features including HTTP/1.1, HTTP/2, and HTTP/3.

In production, Kestrel is typically deployed behind a reverse proxy. The reverse proxy (Nginx, Apache, or IIS) receives external traffic on standard ports (80, 443), forwards it to Kestrel running on a private port, and handles concerns like SSL termination, load balancing, and compression. This separation provides security benefits and allows you to run multiple Kestrel instances behind a single proxy.

Example
csharp
```
var builder = WebApplication.CreateBuilder(args);

// Configure Kestrel options
builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.ListenLocalhost(5000);  // HTTP on port 5000
    serverOptions.ListenLocalhost(5001, listenOptions =>
    {
        listenOptions.UseHttps();  // HTTPS on port 5001
    });
    
    serverOptions.Limits.MaxRequestLineSize = 16_384;
    serverOptions.Limits.MaxRequestHeadersTotalSize = 32_768;
});

var app = builder.Build();
app.MapGet("/", () => "Hello from Kestrel!");
app.Run();
```
This example configures Kestrel to listen on both HTTP (port 5000) and HTTPS (port 5001) with custom request size limits, demonstrating how to customize the server's behavior before the application starts.

Key points to mention
- Kestrel is built into ASP.NET Core and requires no external dependencies or separate server installation
- It supports multiple platforms (Windows, Linux, macOS) and modern HTTP protocols (HTTP/1.1, HTTP/2, HTTP/3)
- Configuration happens in code via ConfigureKestrel() or through configuration files (appsettings.json)
- In production, Kestrel typically runs behind a reverse proxy for security, SSL termination, and load balancing
- You can tune performance through options like MaxRequestHeadersTotalSize, MaxConnections, and thread pool settings
Common follow-up questions
- Why would you use Kestrel behind a reverse proxy instead of directly? — Reverse proxies provide SSL termination, handle external traffic routing, protect Kestrel from direct attacks, and allow multiple application instances
- Can Kestrel handle production traffic directly? — Technically yes for smaller applications, but industry best practice is to use a reverse proxy for security and operational benefits (see how to tune Kestrel for production)
- How do you configure Kestrel for different environments? — Use environment-specific appsettings files (appsettings.Production.json) or conditional logic in ConfigureKestrel() based on IHostEnvironment
Related interview questions
Further reading
- Hosting .NET on Linux behind Nginx
.NETCsharpaspnetcore
73What is Program.cs in ASP.NET Core?
Beginner
Program.cs is the entry point of an ASP.NET Core application where you configure the application's services, middleware pipeline, and endpoints. It replaces the traditional Startup.cs file and uses the WebApplication builder pattern to set up dependency injection, logging, authentication, and request handling in a modern, minimal hosting model.

How it works

Program.cs follows a structured flow that initializes your ASP.NET Core application:

1. Create the builder: The WebApplication.CreateBuilder(args) method instantiates a WebApplicationBuilder that provides access to services, configuration, and logging infrastructure.

2. Register services: You add services to the dependency injection container using builder.Services.Add*() methods. This includes controllers, Entity Framework, authentication, CORS, and any custom services your application needs.

3. Build the application: Calling builder.Build() creates the WebApplication instance with all registered services. After this point, the service container is locked and you cannot add new services (though you can access them).

4. Configure middleware: You use app.Use*() and app.Map*() methods to add middleware components that handle requests. The order matters—each middleware processes the request and passes control to the next in the pipeline. This is where you configure routing, authentication, HTTPS redirection, and exception handling.

5. Map endpoints: You define API routes and controllers using app.MapControllers(), app.MapGet(), app.MapPost(), and similar methods, which tell ASP.NET Core how to handle specific HTTP requests.

6. Run the application: app.Run() starts the Kestrel web server and begins listening for requests.

Example
csharp
```
var builder = WebApplication.CreateBuilder(args);

// Register services
builder.Services.AddControllers();
builder.Services.AddScoped<IUserService, UserService>();
builder.Services.AddDbContext<AppDbContext>();
builder.Services.AddCors(options =>
{
    options.AddPolicy("AllowAll", policy =>
        policy.AllowAnyOrigin().AllowAnyMethod().AllowAnyHeader());
});

var app = builder.Build();

// Configure middleware pipeline
if (app.Environment.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
}
else
{
    app.UseExceptionHandler("/Error");
}

app.UseHttpsRedirection();
app.UseCors("AllowAll");
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();

// Map endpoints
app.MapControllers();
app.MapGet("/health", () => Results.Ok("Healthy"));

app.Run();
```
This example demonstrates the complete lifecycle: creating a builder, adding services like a database context and CORS policy, configuring middleware in the correct order, mapping controllers and custom endpoints, and running the application.

Key points to mention
- Minimal hosting model: Modern ASP.NET Core (6.0+) uses Program.cs without a separate Startup class, reducing boilerplate and improving readability.
- Service registration order doesn't matter: Services can be registered in any order during the builder phase, but middleware order is critical—it determines how requests flow through your application.
- Top-level statements: Program.cs uses C# top-level statements, allowing code without a Main method or Program class wrapper.
- Environment-aware configuration: Use app.Environment.IsDevelopment() and similar checks to conditionally register middleware and services based on your deployment environment.
- Middleware pipeline immutability: Once you call app.Run(), you cannot add more middleware—the pipeline is locked and execution begins.
Common follow-up questions
- What is the difference between services and middleware? (Services are dependencies injected into components; middleware handles requests in a pipeline.)
- Why does middleware order matter? (The request pipeline order determines which middleware processes requests first, affecting authentication, authorization, logging, and error handling behavior.)
- Can you add services after calling builder.Build()? (No, the service container is locked; attempting to add services after building will throw an exception.)
Related interview questions
Further reading
- The middleware pipeline: order matters
.NETCsharpaspnetcore
74What is middleware?
Beginner
Middleware are software components in ASP.NET Core that form a request processing pipeline. Each middleware component can inspect or modify HTTP requests, execute logic, pass control to the next middleware, or short-circuit the pipeline and return a response directly.

How it works

Middleware operates in a chain-of-responsibility pattern. When an HTTP request arrives, it flows through each middleware component in the order they're registered in the pipeline. Each middleware can:
- Process the request — examine or modify the incoming HTTP request
- Call the next middleware — invoke the next component in the chain using await next(context)
- Short-circuit the pipeline — return a response without calling subsequent middleware
- Process the response — modify the response after the next middleware has executed
Think of middleware as a stack of interceptors. The request travels down through each layer, and the response travels back up. This creates an "onion" pattern where outer middleware can wrap inner middleware. Understanding how the ASP.NET Core middleware pipeline works internally helps clarify this layering.

Example
csharp
```
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

// Middleware 1: Logging
app.Use(async (context, next) =>
{
    Console.WriteLine($"Request: {context.Request.Path}");
    await next(context);
    Console.WriteLine($"Response: {context.Response.StatusCode}");
});

// Middleware 2: Authentication check
app.Use(async (context, next) =>
{
    if (!context.Request.Headers.ContainsKey("Authorization"))
    {
        context.Response.StatusCode = 401;
        await context.Response.WriteAsync("Unauthorized");
        return; // Short-circuit
    }
    await next(context);
});

// Middleware 3: Handle requests
app.MapGet("/", () => "Hello, World!");

app.Run();
```
This example demonstrates three middleware: the first logs request and response, the second validates authentication (and short-circuits if missing), and the third handles the actual GET request. The Use method is the standard way to add custom middleware.

Key points to mention
- Middleware order matters — they execute in the order registered, and the request flows down while the response flows back up
- You can use next() to pass control forward or omit it to terminate the pipeline
- Common built-in middleware includes authentication, CORS, routing, and exception handling
- Middleware is perfect for cross-cutting concerns like logging, error handling, and security checks
- The Run() method terminates the pipeline, while Use() and Map() allow continuation — see the difference between Use, Run, and Map
Common follow-up questions
- What's the difference between middleware and filters?
- How do you create custom middleware as a class rather than inline?
- Can middleware access dependency-injected services?
Related interview questions
Further reading
- The middleware pipeline: order matters
.NETCsharpaspnetcore
75What is the request pipeline order?
Beginner
The request pipeline is a chain of middleware components that process HTTP requests and responses in the order they are registered in Program.cs. Each middleware can inspect, modify, or short-circuit the request before passing it to the next middleware, and can also inspect or modify the response on the way back. The order matters critically—middleware registered first runs first for requests and last for responses.

How it works

ASP.NET Core uses a middleware pipeline architecture where each middleware component is a delegate that receives the next middleware in the chain. When a request arrives, it flows through each middleware in registration order. Each middleware can:
- Process the request before calling next()
- Pass control to the next middleware
- Short-circuit the pipeline and return early (preventing subsequent middleware from running)
- Process the response after the next middleware completes
Typical pipeline order follows a logical flow: exception handling comes first (to catch errors from all downstream middleware), then HTTPS redirection, static file serving, routing, CORS, authentication, authorization, and finally the endpoint handler. This ordering ensures security policies are checked before endpoints execute and that errors are caught at the application level.

Example
csharp
```
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

// Middleware order matters
app.UseExceptionHandler("/error");           // 1. Exception handling
app.UseHttpsRedirection();                    // 2. HTTPS redirection
app.UseStaticFiles();                         // 3. Static files
app.UseRouting();                             // 4. Routing
app.UseCors("AllowAll");                      // 5. CORS
app.UseAuthentication();                      // 6. Authentication
app.UseAuthorization();                       // 7. Authorization

app.MapGet("/public", () => "Public endpoint");
app.MapGet("/protected", () => "Protected endpoint")
    .RequireAuthorization();

app.Run();
```
This pipeline ensures that static files are served without authentication, public endpoints are accessible, but protected endpoints require authorization—all because middleware runs in this exact order.

Key points to mention
- Order is critical: Middleware must be registered in the correct sequence. For example, UseAuthentication() must come before UseAuthorization(), and both must come after UseRouting().
- Request/response flow: For requests, middleware runs top-to-bottom; for responses, it unwinds bottom-to-top. A middleware can execute code before and after calling next().
- Short-circuiting: Middleware like UseStaticFiles() or early validation can short-circuit the pipeline, preventing later middleware from running.
- Exception handling first: UseExceptionHandler() should be registered early to catch errors from all downstream middleware.
- UseRouting() requirement: Most middleware that needs route information must come after UseRouting(), as that's when route matching occurs.
Common follow-up questions
- Why must UseAuthentication() come before UseAuthorization()? — Because authorization requires knowing who the user is; authentication establishes identity first.
- Can I create custom middleware and where should I place it in the pipeline? — Yes, custom middleware can be placed strategically; for example, logging middleware often goes early, while validation middleware might go after routing.
- What happens if I call UseRouting() multiple times or forget it? — Routing matches endpoints efficiently only when explicitly called; forgetting it means routes won't be matched. Calling it multiple times is redundant and can cause issues.
Related interview questions
Further reading
- The middleware pipeline: order matters
- Handling concurrency in EF Core
.NETCsharpaspnetcoreSecurity
76What is dependency injection?
Beginner
Dependency Injection (DI) is a design pattern where objects receive their dependencies from external sources rather than creating them internally. Instead of a class instantiating its own dependencies, those dependencies are provided—typically through a constructor, property, or method. ASP.NET Core has a built-in DI container that automatically resolves and injects registered services.

How it works

Dependency Injection inverts control over object creation and dependency management. Rather than a class being responsible for instantiating everything it needs, a central container manages object lifecycles and relationships.

When you register a service in the DI container, you tell it: "When someone asks for this interface, create or return that implementation." At runtime, when a class requests a dependency through its constructor, the container automatically provides it. This decouples classes from their concrete implementations, making code more testable, maintainable, and flexible.

ASP.NET Core's built-in DI container supports three service lifetimes: Transient (new instance every time), Scoped (one instance per HTTP request), and Singleton (one instance for the entire application). Understanding these lifetimes is crucial—for example, injecting a scoped service into a singleton can cause issues because the singleton will hold a stale reference.

Example
csharp
```
// Without DI: class creates its own dependency
public class OrderService
{
    private readonly EmailSender _emailSender = new();
    public void PlaceOrder(string item) => _emailSender.Send($"Order: {item}");
}

// With DI: dependency is injected
public interface IEmailSender
{
    void Send(string message);
}

public class EmailSender : IEmailSender
{
    public void Send(string message) => Console.WriteLine($"Sending: {message}");
}

public class OrderService
{
    private readonly IEmailSender _emailSender;
    
    public OrderService(IEmailSender emailSender)
    {
        _emailSender = emailSender;
    }
    
    public void PlaceOrder(string item) => _emailSender.Send($"Order: {item}");
}

// In Program.cs (ASP.NET Core 8+)
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddScoped();
builder.Services.AddScoped();
var app = builder.Build();
```
The OrderService no longer creates EmailSender directly; instead, it receives IEmailSender through its constructor, making it easy to swap implementations for testing or different environments.

Key points to mention
- Loose coupling: Classes depend on abstractions (interfaces) rather than concrete implementations, making code more flexible and testable.
- Service lifetimes matter: Transient, Scoped, and Singleton have different implications for performance and behavior.
- Constructor injection is standard: In .NET, dependencies are typically provided via constructor parameters, though property and method injection are also supported.
- ASP.NET Core has built-in support: You don't need a third-party container like Autofac for basic scenarios; the framework provides everything you need in IServiceCollection.
- Testability: DI makes unit testing simpler because you can inject mock implementations instead of real ones.
Common follow-up questions
- What are the three service lifetimes in ASP.NET Core, and when would you use each?
- What happens if you inject a scoped service into a singleton?
- How do you register and resolve services manually if you need more control over instantiation?
Related interview questions
Further reading
- Object pool
- Dependency injection is a pattern too
.NETCsharpSecuritydependency-injection
77What are the service lifetimes in ASP.NET Core?
Beginner
Service lifetimes in ASP.NET Core define how long an instance of a service persists in memory and how it is reused. There are three lifetimes: Transient (new instance every time), Scoped (one instance per HTTP request), and Singleton (one instance for the entire application lifetime). Choosing the right lifetime is critical for performance, memory usage, and correctness in your application.

How it works

ASP.NET Core's dependency injection container manages service lifetimes automatically. When you register a service, you specify how it should be instantiated and cached.

Transient services create a fresh instance every time they are requested. This is useful for stateless services or when you need a clean slate each time. The downside is potential memory overhead and slower performance if many instances are created.

Scoped services create one instance per logical scope, typically one per HTTP request in web applications. Within a single request, the same instance is injected everywhere it is needed. This is ideal for request-specific data like database contexts—see How do you manage DbContext lifetime? for more details. When the request completes, the instance is disposed.

Singleton services create one instance when first requested and reuse it for the entire application lifetime. They are created lazily or at application startup, depending on configuration. Singletons are efficient for expensive-to-create, thread-safe services like caches or configuration objects. However, they must be thread-safe and stateless (or carefully managed) to avoid concurrency issues across requests.

Example
csharp
```
public interface ILogger { void Log(string message); }
public class ConsoleLogger : ILogger { public void Log(string message) => Console.WriteLine(message); }

public class Program
{
    public static void Main(string[] args)
    {
        var builder = WebApplication.CreateBuilder(args);
        
        builder.Services.AddTransient<ILogger, ConsoleLogger>();  // New instance each time
        builder.Services.AddScoped<IUserService, UserService>();   // One per request
        builder.Services.AddSingleton<ICache, MemoryCache>();      // One for app lifetime
        
        var app = builder.Build();
        app.MapGet("/", (ILogger logger) => { logger.Log("Request received"); return "OK"; });
        app.Run();
    }
}
```
This example registers three services with different lifetimes: a transient logger (creates a new instance per injection), a scoped user service (one per HTTP request), and a singleton cache (shared across all requests).

Key points to mention
- Transient: Always creates a new instance. Use for stateless services or when you need isolated state. Be aware of AddTransient services that hold state issues.
- Scoped: One instance per request. Ideal for DbContext and other request-scoped resources. Perfect for isolating data between concurrent requests.
- Singleton: One instance forever. Must be thread-safe. Best for immutable or thread-safe shared resources like caches, loggers, or configuration.
- Disposing: Scoped and Singleton services are disposed when their scope ends or the application shuts down. Transient instances may not be disposed by the container unless explicitly tracked.
- Memory and performance: Singletons are fastest but require careful design; Scoped offers a good balance; Transient is safest but slower and memory-hungry.
Common follow-up questions
- Can you inject a Singleton service into a Scoped or Transient service? Yes, but the reverse (injecting Scoped into Singleton) is dangerous and throws an error by design to prevent capturing request-specific state in long-lived services.
- What happens if I dispose a Singleton manually? It can cause issues for subsequent requests. Singletons should only be disposed once at application shutdown.
- How does DbContext lifetime relate to Scoped services? DbContext is registered as Scoped by default because each request should have its own database connection and object tracking context.
Related interview questions
Further reading
- DI lifetimes: Singleton, Scoped, Transient
.NETCsharpaspnetcoredependency-injection
78What is appsettings.json?
Beginner
appsettings.json is a configuration file in ASP.NET Core applications that stores application settings in JSON format, such as database connection strings, logging levels, and custom options. Environment-specific files like appsettings.Development.json and appsettings.Production.json override the base configuration based on the current environment, enabling different settings for development, testing, and production without code changes.

How it works

ASP.NET Core uses a configuration provider system that reads appsettings.json during application startup. The framework loads the base appsettings.json file first, then overlays environment-specific files on top of it. This layered approach means values in appsettings.Development.json will override matching keys from appsettings.json when running in development.

The configuration is injected into the dependency container and made available throughout your application via the IConfiguration interface. You can access settings directly by key, or bind entire sections to strongly-typed options classes using the Options pattern. This approach keeps sensitive data (like production connection strings) out of source control by using different files per environment or external secret management.

The configuration system also supports multiple sources beyond JSON files, including environment variables, command-line arguments, and User Secrets for sensitive development data. These are layered in a defined configuration precedence order, allowing environment variables and secrets to override file-based settings.

Example
csharp
```
// appsettings.json
{
  "ConnectionStrings": {
    "DefaultConnection": "Server=localhost;Database=myapp;"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information"
    }
  },
  "AppSettings": {
    "ApiTimeout": 30,
    "MaxRetries": 3
  }
}

// appsettings.Development.json (overrides for development)
{
  "Logging": {
    "LogLevel": {
      "Default": "Debug"
    }
  }
}

// Program.cs - accessing configuration
var builder = WebApplication.CreateBuilder(args);

// Access via IConfiguration
var connectionString = builder.Configuration.GetConnectionString("DefaultConnection");

// Or bind to a strongly-typed class
var appSettings = new AppSettings();
builder.Configuration.GetSection("AppSettings").Bind(appSettings);

builder.Services.Configure<AppSettings>(
    builder.Configuration.GetSection("AppSettings"));

var app = builder.Build();

// Inject IConfiguration or IOptions<AppSettings> into controllers/services
app.Run();

public class AppSettings
{
    public int ApiTimeout { get; set; }
    public int MaxRetries { get; set; }
}
```
This example shows how appsettings.json stores configuration, how environment-specific files override values, and how to access settings via IConfiguration or the Options pattern in your application.

Key points to mention
- appsettings.json is the default configuration file; environment-specific files (Development, Production) overlay on top based on ASPNETCORE_ENVIRONMENT
- Use the Options pattern with IOptions<T> to bind configuration sections to strongly-typed classes for better type safety and validation
- Never commit sensitive data like production connection strings or API keys to appsettings.json; use User Secrets in development and environment variables or secret management services in production
- Configuration is read-only after application startup; changes to the file require an application restart
- The configuration system supports nested JSON objects and arrays, making it flexible for complex settings
Common follow-up questions
- How do you handle environment-specific configuration? — Use environment-specific appsettings files (appsettings.{Environment}.json) and set the ASPNETCORE_ENVIRONMENT variable via environment variables, launch settings, or Docker. The framework automatically merges these with the base file.
- What's the difference between IConfiguration and IOptions? — IConfiguration provides direct access to raw configuration values and supports dynamic reloading; IOptions<T> binds configuration to strongly-typed classes, provides validation, and is recommended for the Options pattern.
- How do you access nested configuration values? — Use colon-separated keys like Configuration["ConnectionStrings:DefaultConnection"] or the Options pattern to bind entire sections to classes with matching property names.
Related interview questions
Further reading
- The Options pattern, properly
- Managing secrets in .NET
.NETCsharp
79What are environments in ASP.NET Core?
Beginner
Environments in ASP.NET Core are a way to conditionally configure and run your application differently based on where it's deployed. The ASPNETCORE_ENVIRONMENT variable specifies which environment is active—typically Development, Staging, or Production—allowing you to load different configuration, logging levels, and middleware behavior for each.

How it works

ASP.NET Core uses the ASPNETCORE_ENVIRONMENT environment variable to determine the current runtime environment. When your application starts, the framework checks this variable and uses it to:
- Load environment-specific configuration files (e.g., appsettings.Development.json, appsettings.Production.json)
- Enable or disable middleware and features conditionally
- Apply environment-specific dependency injection registrations
- Control logging verbosity and output
- Manage which secrets or connection strings are used
The three standard environments are Development (local machine), Staging (pre-production testing), and Production (live). You can also define custom environments. The environment name is case-insensitive and accessible via IHostEnvironment.EnvironmentName throughout your application.

When you use appsettings.json, the configuration system automatically merges settings from environment-specific files, with later sources overriding earlier ones. This layering approach makes it easy to maintain environment-specific secrets and settings without duplicating common configuration.

Example
csharp
```
var builder = WebApplication.CreateBuilder(args);

// Access the current environment
var isDevelopment = builder.Environment.IsDevelopment();
var isProduction = builder.Environment.IsProduction();

// Configure services conditionally
if (isDevelopment)
{
    builder.Services.AddScoped<ILogger, ConsoleLogger>();
    builder.Logging.SetMinimumLevel(LogLevel.Debug);
}
else
{
    builder.Services.AddScoped<ILogger, FileLogger>();
    builder.Logging.SetMinimumLevel(LogLevel.Warning);
}

// Load environment-specific settings
var environment = builder.Configuration["Environment"];
Console.WriteLine($"Running in: {builder.Environment.EnvironmentName}");

var app = builder.Build();

// Use middleware conditionally
if (app.Environment.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
}
else
{
    app.UseExceptionHandler("/Error");
}

app.Run();
```
This code demonstrates how to conditionally register services and middleware based on the current environment, enabling verbose logging in Development but minimal logging in Production.

Key points to mention
- Set ASPNETCORE_ENVIRONMENT via system environment variables, launch settings (launchSettings.json), or deployment configuration
- Environment-specific configuration files follow the naming pattern appsettings.{Environment}.json and override base appsettings.json settings
- Use IHostEnvironment to inject environment information into your services and middleware for runtime decisions
- Helper methods like IsDevelopment(), IsProduction(), and IsEnvironment("custom") make environment checks readable and safe
- The default environment is Production if not explicitly set; always explicitly configure your target environment in deployment
Common follow-up questions
- How do you set the ASPNETCORE_ENVIRONMENT in different deployment scenarios (local, Docker, Azure)?
- What's the difference between configuration precedence and environment-specific overrides?
- How should you handle secrets in each environment, particularly Production? (See storing secrets safely in .NET apps)
Related interview questions
.NETCsharpaspnetcore
80What is the Options pattern?
Beginner
The Options pattern is a configuration management approach in .NET that binds configuration sections from appsettings.json (or other sources) to strongly typed classes, which are then injected via dependency injection using IOptions<T>, IOptionsSnapshot<T>, or IOptionsMonitor<T>. This makes configuration type-safe, validated, and testable instead of relying on magic strings or dynamic dictionaries.

How it works

The Options pattern follows a simple three-step process:

1. Define a configuration class: Create a Plain Old CLR Object (POCO) that mirrors your configuration structure. Property names should match the JSON keys in appsettings.json.

2. Register in Dependency Injection: In Program.cs (or Startup.cs), bind the configuration section to your POCO class using services.Configure<YourOptionsClass>(configuration.GetSection("SectionName")).

3. Inject and use: Inject IOptions<YourOptionsClass> into your services, accessing the configuration through the Value property.

This approach provides immediate benefits: the compiler validates property names, you get IntelliSense support, and you can apply data annotations for validation. Unlike string-based configuration access, this catches typos at compile time or during startup validation.

Example
csharp
```
// appsettings.json
{
  "EmailService": {
    "SmtpServer": "smtp.gmail.com",
    "Port": 587,
    "SenderEmail": "noreply@example.com"
  }
}

// Configuration class
public class EmailServiceOptions
{
    public string SmtpServer { get; set; }
    public int Port { get; set; }
    public string SenderEmail { get; set; }
}

// Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.Services.Configure<EmailServiceOptions>(
    builder.Configuration.GetSection("EmailService"));
builder.Services.AddScoped<IEmailService, EmailService>();
var app = builder.Build();

// Using the options
public class EmailService : IEmailService
{
    private readonly EmailServiceOptions _options;
    
    public EmailService(IOptions<EmailServiceOptions> options)
    {
        _options = options.Value;
    }
    
    public async Task SendEmailAsync(string to, string subject, string body)
    {
        using var client = new SmtpClient(_options.SmtpServer, _options.Port);
        await client.SendMailAsync(_options.SenderEmail, to, subject, body);
    }
}
```
This example demonstrates binding the "EmailService" configuration section to EmailServiceOptions, then injecting it into EmailService where it's used to configure an SMTP client.

Key points to mention
- Three injection types: IOptions<T> (singleton, immutable), IOptionsSnapshot<T> (scoped, reloads per request), and IOptionsMonitor<T> (singleton, reloads dynamically) serve different reload requirements.
- Validation support: Add DataAnnotations attributes (like [Required], [Range]) to your options class for automatic validation; use ValidateDataAnnotations() in Program.cs.
- Type safety: Configuration is checked at compile time and startup, preventing runtime string-key errors common with IConfiguration.GetValue("SomeKey").
- Testability: Mock IOptions<T> easily in unit tests using Options.Create(new MyOptions { ... }).
- Flexibility: Supports multiple configuration sources (JSON, environment variables, Azure Key Vault) through the standard IConfiguration abstraction.
Common follow-up questions
- What's the difference between IOptions, IOptionsSnapshot, and IOptionsMonitor? IOptions is a singleton and never reloads; IOptionsSnapshot reloads per request scope and is useful for multi-tenant scenarios; IOptionsMonitor reloads dynamically and supports change callbacks.
- How do you validate options at startup? Use .ValidateDataAnnotations(), implement IValidateOptions<T>, or call .Validate(options => !string.IsNullOrEmpty(options.SmtpServer)) during configuration.
- Can you use Options pattern with environment-specific settings? Yes—combine appsettings.json with appsettings.{Environment}.json or environment variables, and the IConfiguration layer merges them automatically before binding to your options class.
Related interview questions
Further reading
- Options and configuration patterns
- The Options pattern, properly
.NETCsharpArchitecture
81What is routing in ASP.NET Core?
Beginner
Routing in ASP.NET Core is the mechanism that maps incoming HTTP requests to the appropriate endpoint handler based on the request URL and HTTP method. It determines which controller action, Minimal API handler, or Razor Page processes each request. Routing uses template patterns like /products/{id} to extract data from URLs and pass it to your application logic.

How it works

When an HTTP request arrives, the routing system evaluates it against a collection of route patterns defined in your application. Each route template can include static segments (like /api/products) and dynamic segments (like {id}) that capture values from the URL.

ASP.NET Core supports three main routing approaches:
- Conventional Routing – Uses MapControllerRoute to define patterns that map to controller and action names
- Attribute Routing – Routes defined directly on controllers and actions using [Route] attributes
- Minimal APIs – Routes defined fluently in Program.cs using Map methods
The router matches the incoming request against each route in order until it finds a match. If a match is found, route values (like id, controller, action) are extracted and made available to the endpoint handler. If no match is found, a 404 response is returned.

Example
csharp
```
// Program.cs - Minimal API routing example
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/products", () => "Get all products");

app.MapGet("/products/{id}", (int id) => 
{
    return $"Get product with ID: {id}";
});

app.MapPost("/products", (CreateProductDto dto) => 
{
    return Results.Created($"/products/1", new { id = 1, name = dto.Name });
});

app.Run();

public record CreateProductDto(string Name);
```
This example defines three routes: one to list all products, one to get a specific product by ID (with the ID extracted from the URL), and one to create a new product. The {id} segment is automatically parsed as an integer and passed to the handler method.

Key points to mention
- Route patterns are processed in order; the first match wins, so place more specific routes before general ones
- Route parameters can be constrained using route constraints like {id:int} or {slug:regex(^[a-z]+$)} to ensure only matching requests reach the endpoint
- Controllers use a combination of conventional and attribute routing to map URLs to action methods
- Minimal APIs provide a lightweight alternative for defining routes without controllers, ideal for APIs and microservices
- The router integrates with dependency injection to resolve handler parameters and inject services
Common follow-up questions
- What's the difference between conventional routing and attribute routing?
- How do route constraints work and when should you use them?
- Can you mix Minimal API routes with controller-based routes in the same application?
Related interview questions
Further reading
- Endpoint filters in minimal APIs
- Organize minimal APIs with route groups
.NETCsharpaspnetcore
82What is a controller?
Beginner
A controller is a class that handles HTTP requests and returns responses in an ASP.NET Core application. API controllers inherit from ControllerBase and use attributes like [HttpGet], [HttpPost], and [Route] to map incoming requests to specific action methods. Controllers are the core building block of the MVC pattern and serve as the entry point for processing client requests and returning data.

How it works

When a client makes an HTTP request, the ASP.NET Core routing system matches the request URL and HTTP method to a controller action. The controller receives the request, processes business logic (often by calling services), and returns a response—typically JSON data wrapped in an IActionResult. Controllers can accept parameters from the URL, query string, request body, or headers. The framework automatically deserializes request data and serializes response data using configured formatters (usually JSON).

Controllers separate concerns by keeping HTTP handling logic distinct from business logic. A controller orchestrates the flow: it receives input, delegates work to services, and formats output. This makes code testable, maintainable, and follows the Single Responsibility Principle. For APIs, ControllerBase is preferred over Controller because Controller includes view-rendering features needed only for traditional MVC web applications.

Example
csharp
```
[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    private readonly IProductService _productService;

    public ProductsController(IProductService productService)
    {
        _productService = productService;
    }

    [HttpGet("{id}")]
    public async Task<ActionResult<ProductDto>> GetProduct(int id)
    {
        var product = await _productService.GetProductByIdAsync(id);
        if (product == null)
            return NotFound();
        
        return Ok(product);
    }

    [HttpPost]
    public async Task<ActionResult<ProductDto>> CreateProduct(CreateProductDto dto)
    {
        var product = await _productService.CreateProductAsync(dto);
        return CreatedAtAction(nameof(GetProduct), new { id = product.Id }, product);
    }
}
```
This controller handles GET and POST requests for products; GetProduct retrieves a single product by ID, and CreateProduct creates a new product and returns a 201 Created response with the location of the new resource.

Key points to mention
- Controllers inherit from ControllerBase for APIs (or Controller for traditional MVC with views)
- HTTP method attributes ([HttpGet], [HttpPost], etc.) and [Route] map requests to actions
- The [ApiController] attribute enables automatic model validation and consistent error responses
- Dependency injection is used to inject services into controller constructors, promoting testability
- Action methods return IActionResult subclasses like Ok(), NotFound(), BadRequest(), and CreatedAtAction()
Common follow-up questions
- What is the difference between Controller and ControllerBase? (Controller includes view support for server-rendered pages)
- What is routing in ASP.NET Core and how does it connect to controllers?
- How do you choose between Minimal APIs and controllers for large systems?
Related interview questions
Further reading
- Organize minimal APIs with route groups
.NETCsharpaspnetcore
83What are Minimal APIs?
Beginner
Minimal APIs are a lightweight approach to building HTTP endpoints in ASP.NET Core that use lambda expressions and fluent method calls instead of controller classes. Introduced in .NET 6 and refined through .NET 8, they enable you to define routes, handlers, and middleware with minimal boilerplate code, making them ideal for microservices, REST APIs, and rapid prototyping.

How it works

Minimal APIs eliminate the traditional controller-based architecture by allowing you to map HTTP endpoints directly on the WebApplication object using methods like MapGet, MapPost, MapPut, and MapDelete. Each method accepts a route pattern and a handler function (typically a lambda). The handler receives dependencies through parameter injection, processes the request, and returns a response. ASP.NET Core automatically handles serialization, model validation, and dependency resolution, so you write less infrastructure code and focus on business logic.

The model binding system works the same as controllers—route parameters, query strings, request bodies, and services are automatically injected into your handler parameters. You can also apply filters, middleware, and authorization declaratively using extension methods on the endpoint definition.

Example
csharp
```
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddScoped<IProductService, ProductService>();

var app = builder.Build();

app.MapGet("/products", async (IProductService service) =>
    await service.GetAllAsync())
    .WithName("GetProducts")
    .WithOpenApi();

app.MapGet("/products/{id}", async (int id, IProductService service) =>
    await service.GetByIdAsync(id))
    .WithName("GetProductById")
    .Produces<Product>(StatusCodes.Status200OK)
    .Produces(StatusCodes.Status404NotFound);

app.MapPost("/products", async (CreateProductRequest request, IProductService service) =>
{
    var product = await service.CreateAsync(request);
    return Results.Created($"/products/{product.Id}", product);
})
    .WithName("CreateProduct")
    .Accepts<CreateProductRequest>("application/json")
    .RequireAuthorization();

app.Run();
```
This example defines three endpoints: fetching all products, retrieving a single product by ID, and creating a new product with authorization. The service is injected automatically, and Results helper methods provide strongly-typed responses.

Key points to mention
- Low ceremony: No controller classes, attributes, or action methods—just route patterns and handlers, reducing scaffolding.
- Dependency injection: Services are injected directly into handler parameters, keeping code clean and testable.
- OpenAPI/Swagger: Built-in support for generating OpenAPI documentation via WithOpenApi() without extra configuration.
- Performance: Minimal APIs are fast because they skip the controller routing layer and use direct method invocation.
- Scalability trade-offs: Ideal for small to medium APIs; larger systems often benefit from controllers for organization and consistency.
Common follow-up questions
- How do you validate input in Minimal APIs? Use Validate(), fluent validators, or data annotations on your request DTOs; ASP.NET Core validates before invoking the handler.
- Can you group related endpoints? Yes, use MapGroup() to create route groups and apply middleware or authorization to multiple endpoints at once.
- How do you handle errors and exceptions? Use middleware, exception handlers, or return Results.BadRequest(), Results.InternalServerError(), and other helper methods.
Related interview questions
Further reading
- Endpoint filters in minimal APIs
- Organize minimal APIs with route groups
.NETCsharpaspnetcore
84What is model binding?
Beginner
Model binding is the automatic mechanism in ASP.NET Core that converts incoming request data (from route, query strings, headers, and body) into strongly-typed action method parameters. It eliminates the need to manually parse HTTP requests, making controller actions cleaner and more maintainable. The framework inspects the action method signature and populates those parameters from various data sources according to a configurable priority order.

How it works

When a request arrives at an action method, ASP.NET Core's model binding system follows a predictable sequence to locate and convert data:
1. Inspection: The framework examines the action method's parameters and their names.
2. Source Resolution: It searches for matching data in sources in this order: route values, query string, form data (body), headers, and cookies.
3. Type Conversion: Once found, the data is converted to the parameter's declared type using type converters or custom binding logic.
4. Validation: After binding, model validation attributes are applied to verify the data meets requirements.
You can control binding behavior using attributes like [FromRoute], [FromQuery], [FromBody], and [FromHeader] to explicitly specify where data should come from, or use [BindNever] to exclude properties entirely.

Example
csharp
```
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
}

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    // GET /api/products/5?name=Widget
    [HttpGet("{id}")]
    public IActionResult GetProduct(int id, string name)
    {
        // id is bound from route, name from query string
        return Ok(new { id, name });
    }

    // POST /api/products
    // Body: { "id": 1, "name": "Widget", "price": 29.99 }
    [HttpPost]
    public IActionResult CreateProduct([FromBody] Product product)
    {
        // Entire Product object is bound from JSON body
        return CreatedAtAction(nameof(GetProduct), new { id = product.Id }, product);
    }
}
```
In the first method, id is automatically bound from the route segment and name from the query string. In the second method, the entire JSON body is deserialized into a Product object because of the [FromBody] attribute.

Key points to mention
- Automatic and configurable: Model binding works automatically for primitive types and complex objects, but you can override behavior with binding attributes.
- Priority matters: Route parameters take precedence over query strings, which take precedence over form data—unless you explicitly specify a source.
- Works with complex types: Model binding can reconstruct nested objects and collections from flattened request data (e.g., Product.Supplier.Name from form field Product.Supplier.Name).
- Type safety: Invalid data types are caught during binding before your action executes, providing automatic client validation feedback.
- Integrates with validation: Model binding feeds directly into model validation annotations like [Required] and [Range].
Common follow-up questions
- How do I bind a property from a custom source? Implement IModelBinder or IModelBinderProvider to create custom binding logic for specific types.
- What happens if binding fails? The parameter receives its default value (null for reference types, default for value types), and ModelState.IsValid becomes false, triggering validation errors.
- Can I prevent certain properties from being bound? Yes, use the [BindNever] attribute on properties you want excluded from automatic binding, which is important for security in MVC scenarios.
Related interview questions
.NETCsharpefcore
85What is model validation?
Beginner
Model validation is the process of checking that data submitted to your application meets defined rules and constraints before processing. In .NET, you use data annotations (attributes like [Required], [StringLength], [Range]) to declare validation rules on model properties, and the framework automatically enforces them during model binding. With the [ApiController] attribute, invalid models automatically return a 400 Bad Request response with validation error details.

How it works

Model validation happens after model binding completes. The ASP.NET Core runtime examines all data annotations on your model properties and runs the corresponding validators. The ModelState.IsValid property tells you whether all validations passed. When you mark a controller with [ApiController], the framework intercepts requests with invalid models and returns a structured 400 response automatically—you don't need to manually check ModelState.IsValid in most cases. You can also implement IValidatableObject for complex, multi-property validation logic that annotations alone cannot express.

Example
csharp
```
using System.ComponentModel.DataAnnotations;

public class CreateUserRequest
{
    [Required]
    [StringLength(100, MinimumLength = 2)]
    public string Name { get; set; }

    [Required]
    [EmailAddress]
    public string Email { get; set; }

    [Range(18, 120)]
    public int Age { get; set; }

    [Phone]
    public string PhoneNumber { get; set; }
}

[ApiController]
[Route("api/[controller]")]
public class UsersController : ControllerBase
{
    [HttpPost]
    public IActionResult CreateUser(CreateUserRequest request)
    {
        // ModelState is automatically valid here; invalid requests return 400
        return Ok(new { message = "User created", user = request });
    }
}
```
When a client sends a request with missing or invalid data (e.g., an empty Name or invalid Email format), ASP.NET Core automatically rejects it with a 400 response containing validation error details; the action method never executes.

Key points to mention
- Data annotations like [Required], [StringLength], [EmailAddress], [Range], and [RegularExpression] provide declarative validation rules.
- Validation occurs during model binding, before your action method runs.
- The [ApiController] attribute enables automatic 400 responses for invalid models, eliminating boilerplate validation checks.
- IValidatableObject allows you to implement custom validation logic that involves multiple properties or complex business rules.
- Custom validation attributes let you create domain-specific validators (e.g., [ValidCreditCard]) that can be reused across models.
Common follow-up questions
- How do you implement custom validation? — Derive from ValidationAttribute and override IsValid, or implement IValidatableObject on your model for cross-property rules.
- What's the difference between server-side and client-side validation? — Server-side validation (data annotations) is mandatory for security; client-side validation (HTML5 or JavaScript) improves user experience but can be bypassed.
- How do you access validation errors in your action method? — Without [ApiController], check ModelState.IsValid and iterate ModelState.Values; with [ApiController], the framework handles this for you and includes errors in the 400 response payload.
Related interview questions
Further reading
- Validation with FluentValidation
- Anti-corruption layer
.NETCsharpaspnetcore
86What are the common HTTP status codes for APIs?
Beginner
HTTP status codes are standardized three-digit numbers that indicate the outcome of an API request. The most common codes for APIs are 200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, and 500 Internal Server Error. These codes help clients understand whether their request succeeded, and if not, what went wrong and how to handle the failure.

How it works

HTTP status codes are grouped into five categories based on their first digit. The 2xx range indicates success, 3xx indicates redirection, 4xx indicates client errors (the request was malformed or invalid), and 5xx indicates server errors (the server failed to process a valid request).

Success codes (2xx): 200 OK means the request succeeded and the server is returning data. 201 Created indicates a new resource was successfully created (typically used for POST requests). 204 No Content indicates success but there is no content to return (common for DELETE or update operations).

Client error codes (4xx): 400 Bad Request means the client sent malformed data or missing required fields. 401 Unauthorized means authentication is required or failed, often related to cookie and JWT authentication. 403 Forbidden means the authenticated user lacks permission to access the resource. 404 Not Found means the requested resource does not exist. 409 Conflict indicates a conflict, such as trying to create a resource that already exists.

Server error codes (5xx): 500 Internal Server Error is a catch-all for unexpected server failures. Other 5xx codes include 502 Bad Gateway and 503 Service Unavailable.

Example
csharp
```
[ApiController]
[Route("api/[controller]")]
public class UsersController : ControllerBase
{
    [HttpPost]
    public IActionResult CreateUser([FromBody] CreateUserDto dto)
    {
        if (dto == null || string.IsNullOrEmpty(dto.Name))
            return BadRequest("Name is required"); // 400
        
        if (UserExists(dto.Email))
            return Conflict("Email already registered"); // 409
        
        var user = new User { Name = dto.Name, Email = dto.Email };
        _context.Users.Add(user);
        _context.SaveChanges();
        
        return CreatedAtAction(nameof(GetUser), new { id = user.Id }, user); // 201
    }
    
    [HttpGet("{id}")]
    public IActionResult GetUser(int id)
    {
        var user = _context.Users.Find(id);
        if (user == null)
            return NotFound(); // 404
        
        return Ok(user); // 200
    }
    
    [HttpDelete("{id}")]
    public IActionResult DeleteUser(int id)
    {
        var user = _context.Users.Find(id);
        if (user == null)
            return NotFound(); // 404
        
        _context.Users.Remove(user);
        _context.SaveChanges();
        
        return NoContent(); // 204
    }
}
```
This example demonstrates a typical REST API controller that returns appropriate status codes for different scenarios: 201 when creating, 200 when retrieving, 204 when deleting, 400 for validation errors, 409 for conflicts, and 404 when resources don't exist.

Key points to mention
- Use correct status codes consistently—they communicate intent to API consumers and are often parsed by client libraries for retry logic.
- Always return 2xx for success and 4xx for client errors; avoid returning 200 with an error message in the response body.
- 401 and 403 are different: 401 means "you need to authenticate," while 403 means "you're authenticated but don't have permission."
- Include meaningful error details in the response body (e.g., validation messages for 400 errors) to help clients debug issues.
- Idempotent operations (GET, DELETE) should return 404 if the resource doesn't exist; POST may return 409 if the resource already exists depending on your API design.
Common follow-up questions
- What is the difference between 401 and 403? (401 = authentication failed, 403 = insufficient permissions)
- When should you use 204 No Content vs. 200 OK? (204 for operations where you don't need to return data, 200 when returning a body)
- How do you handle authorization errors in your API? (This ties into testing authorization rules in integration tests)
Related interview questions
.NETCsharpSecurity
87What is IActionResult?
Beginner
IActionResult is an interface in ASP.NET Core that represents the result of a controller action. It allows actions to return different HTTP responses—such as Ok, NotFound, BadRequest, or Redirect—without coupling the action to a specific response type. ActionResult<T> extends this pattern by combining a typed response body with standard HTTP status results.

How it works

IActionResult is a contract that says "I know how to convert myself into an HTTP response." When an action method returns an IActionResult, the ASP.NET Core framework calls the ExecuteAsync() method on that result object, which writes the appropriate HTTP status code, headers, and body to the response.

Built-in implementations include OkResult (200), BadRequestResult (400), NotFoundResult (404), and CreatedAtActionResult (201). You can also create custom results by implementing the interface yourself.

ActionResult<T> is a helper that combines typed data with status results. It has an implicit conversion to IActionResult, so you can return either a typed object (which becomes a 200 Ok response) or an IActionResult from the same action. This gives you flexibility while maintaining type safety for the happy path.

Example
csharp
```
using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/[controller]")]
public class UsersController : ControllerBase
{
    [HttpGet("{id}")]
    public ActionResult<UserDto> GetUser(int id)
    {
        if (id <= 0)
            return BadRequest("User ID must be greater than 0.");
        
        var user = new UserDto { Id = id, Name = "Alice" };
        return Ok(user);
    }
    
    [HttpPost]
    public ActionResult<UserDto> CreateUser(CreateUserRequest request)
    {
        if (string.IsNullOrWhiteSpace(request.Name))
            return BadRequest("Name is required.");
        
        var user = new UserDto { Id = 1, Name = request.Name };
        return CreatedAtAction(nameof(GetUser), new { id = user.Id }, user);
    }
}

public class UserDto { public int Id { get; set; } public string Name { get; set; } }
public class CreateUserRequest { public string Name { get; set; } }
```
This example shows how ActionResult<T> lets the GetUser action return either a BadRequest (with explanation) or an Ok result with typed user data, and how CreateUser can return a CreatedAtAction result with a 201 status and location header.

Key points to mention
- IActionResult decouples the action logic from HTTP response details; the framework handles serialization and status codes.
- ActionResult<T> provides type safety for the success case while still allowing you to return problem results (like BadRequest or NotFound).
- Helper methods like Ok(), BadRequest(), NotFound(), and CreatedAtAction() are shortcuts that create the corresponding result objects.
- You can return the typed object directly from an ActionResult<T> method, and it is implicitly wrapped in an Ok response.
- For Minimal APIs, TypedResults provides similar functionality with better discoverability and OpenAPI support.
Common follow-up questions
- What's the difference between returning IActionResult and ActionResult<T>? IActionResult is the base interface with no type information; ActionResult<T> adds a typed body and makes it easier to document with Swagger/OpenAPI.
- Can I create a custom result by implementing IActionResult? Yes, you implement ExecuteAsync(HttpContext) to write your custom logic directly to the response.
- What happens if I just return an object without wrapping it in Ok()? In controller actions, the framework may auto-wrap it as a 200 response, but explicitly using Ok() or ActionResult<T> is clearer and more testable.
Related interview questions
.NETCsharp
88What is REST?
Beginner
REST (Representational State Transfer) is an architectural style for building web APIs that uses standard HTTP methods, resources identified by URIs, and stateless communication. It leverages HTTP semantics—GET to retrieve, POST to create, PUT to replace, PATCH to update, and DELETE to remove—making APIs predictable, scalable, and easy to integrate with.

How it works

REST treats everything as a resource identified by a unique URI (e.g., /api/products/42). Clients interact with these resources by sending HTTP requests with appropriate verbs, and servers respond with representations of those resources (typically JSON) and status codes that describe the outcome.

The core principles are:
- Client-Server Architecture: Separation of concerns between the client requesting data and the server managing it.
- Statelessness: Each request contains all information needed; the server doesn't store client context between requests.
- Standard HTTP Methods: Consistent use of GET (safe, idempotent), POST (creates), PUT (replaces), PATCH (partial update), and DELETE (removes).
- Resource-Oriented: URIs represent nouns (resources), not verbs (actions). For example, use PUT /api/products/5 instead of GET /api/updateProduct?id=5.
- Status Codes: Responses include meaningful HTTP status codes like 200 (OK), 201 (Created), 400 (Bad Request), 404 (Not Found), and 500 (Server Error) to communicate results clearly. See what are the common HTTP status codes for APIs for more detail.
Example
csharp
```
// Simple REST API using minimal APIs in .NET 8
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

var products = new List<Product> 
{ 
    new(1, "Laptop", 999.99m), 
    new(2, "Mouse", 29.99m) 
};

// GET - Retrieve all products
app.MapGet("/api/products", () => Results.Ok(products));

// GET - Retrieve a single product
app.MapGet("/api/products/{id}", (int id) => 
    products.FirstOrDefault(p => p.Id == id) is Product p 
        ? Results.Ok(p) 
        : Results.NotFound());

// POST - Create a new product
app.MapPost("/api/products", (Product newProduct) => 
{
    products.Add(newProduct);
    return Results.Created($"/api/products/{newProduct.Id}", newProduct);
});

// PUT - Replace a product entirely
app.MapPut("/api/products/{id}", (int id, Product updated) =>
{
    var product = products.FirstOrDefault(p => p.Id == id);
    if (product is null) return Results.NotFound();
    product.Name = updated.Name;
    product.Price = updated.Price;
    return Results.Ok(product);
});

// DELETE - Remove a product
app.MapDelete("/api/products/{id}", (int id) =>
{
    var product = products.FirstOrDefault(p => p.Id == id);
    if (product is null) return Results.NotFound();
    products.Remove(product);
    return Results.NoContent();
});

app.Run();

record Product(int Id, string Name, decimal Price);
```
This example demonstrates all REST verbs: GET retrieves data, POST creates new products, PUT updates existing ones, and DELETE removes them—each returning appropriate status codes.

Key points to mention
- REST is not a protocol or standard; it's an architectural style that sits on top of HTTP.
- Statelessness is critical—each request must be independent; the server should not rely on session data from previous requests.
- Use nouns for URIs (e.g., /api/customers) and HTTP verbs for actions, not custom URL patterns like /api/getCustomer.
- Always return meaningful status codes; a 200 OK with an error message in the body is misleading.
- REST APIs should be idempotent where appropriate—GET, PUT, and DELETE should produce the same result if called multiple times with identical data.
Common follow-up questions
- What makes an API truly "RESTful," and is every HTTP API considered REST?
- How does REST differ from other architectural styles like GraphQL or RPC?
- What best practices should you follow when designing a REST API in .NET?
Related interview questions
Further reading
- Idempotency keys in ASP.NET Core
.NETCsharpArchitecture
89What is Swagger or OpenAPI?
Beginner
OpenAPI (formerly Swagger) is a standardized specification for describing REST APIs in a machine-readable format (JSON or YAML). Swagger UI is a tool that renders this specification as interactive documentation where developers can test endpoints directly in the browser. Clients, SDKs, and mock servers can be automatically generated from an OpenAPI document.

How it works

OpenAPI works by defining your entire API surface—endpoints, request/response schemas, authentication methods, and error codes—in a structured document. When you build an ASP.NET Core API, you can generate this document automatically using tools like Swashbuckle (which uses Swagger/OpenAPI under the hood).

The workflow is: (1) you write API controllers with XML comments or attributes, (2) Swashbuckle scans your code at startup and generates an OpenAPI JSON/YAML file, (3) Swagger UI consumes that file and renders an interactive interface, and (4) clients can call your endpoints through the UI or generate typed client code from the specification.

This approach ensures your documentation is always in sync with your actual code, eliminating the problem of outdated or manually-written API docs. It also enables contract-driven development where frontend teams can work from the OpenAPI spec even before backend implementation is complete.

Example
csharp
```
using Microsoft.AspNetCore.Mvc;

namespace MyApi.Controllers;

/// <summary>
/// Manages product operations.
/// </summary>
[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    /// <summary>
    /// Retrieves a product by ID.
    /// </summary>
    /// <param name="id">The product ID.</param>
    /// <returns>The product details.</returns>
    /// <response code="200">Product found.</response>
    /// <response code="404">Product not found.</response>
    [HttpGet("{id}")]
    [ProduceResponseType(typeof(ProductDto), StatusCodes.Status200OK)]
    [ProduceResponseType(StatusCodes.Status404NotFound)]
    public ActionResult<ProductDto> GetProduct(int id)
    {
        var product = new ProductDto { Id = id, Name = "Widget", Price = 19.99m };
        return Ok(product);
    }
}

public record ProductDto(int Id, string Name, decimal Price);
```
This controller automatically generates OpenAPI documentation. Swashbuckle reads the XML comments and ProduceResponseType attributes to describe what the endpoint does, what it accepts, and what responses it returns. Swagger UI then displays this as an interactive page where you can click "Try it out" to test the endpoint.

Key points to mention
- Industry standard: OpenAPI is language-agnostic and widely adopted, making it easier for third parties to integrate with your API.
- Self-documenting code: Documentation stays current with your implementation because it's generated directly from your code, not maintained separately.
- Code generation: Clients, mock servers, and strongly-typed proxies can be generated from the OpenAPI spec, reducing manual coding.
- Swashbuckle in .NET: ASP.NET Core has built-in integration via Swashbuckle NuGet package; it requires minimal setup (one-line registration and middleware).
- Contract-first development: Teams can define the API contract in OpenAPI first, then implement backends and frontends in parallel.
Common follow-up questions
- How do you customize Swagger/OpenAPI documentation? Use XML comments, [Summary], [Description] attributes, and Swashbuckle filters to control what's exposed and how it appears.
- Can you version APIs with OpenAPI? Yes; you can define multiple OpenAPI documents (one per version) and register them separately in Swashbuckle, allowing clients to see documentation for different API versions.
- How does this relate to designing a good REST API? OpenAPI enforces clarity and consistency in API design; it encourages you to think through schemas, error responses, and endpoint behavior upfront.
Related interview questions
- How do you design a good REST API in .NET?
- How do you build a high-throughput API?
Further reading
- Unit testing with xUnit
- Testing patterns
.NETCsharpTesting
90What is CORS?
Beginner
CORS (Cross-Origin Resource Sharing) is a browser security mechanism that allows web applications running on one origin (domain, protocol, or port) to make requests to APIs hosted on a different origin. By default, browsers block these cross-origin requests for security reasons, but CORS provides a standardized way to explicitly permit them by configuring allowed origins, HTTP methods, and headers on the server.

How it works

When a browser makes a cross-origin request, it first sends a preflight request (an OPTIONS request) to the server asking what origins, methods, and headers are allowed. The server responds with CORS headers indicating permissions. If the preflight passes, the browser allows the actual request (GET, POST, etc.) to proceed.

For simple requests (GET, HEAD, POST with standard headers), the browser may skip the preflight and send the actual request directly, then check the response headers to determine if the cross-origin access is allowed.

The key CORS response headers include:
- Access-Control-Allow-Origin – specifies which origins can access the resource
- Access-Control-Allow-Methods – specifies allowed HTTP methods (GET, POST, PUT, DELETE, etc.)
- Access-Control-Allow-Headers – specifies which request headers are allowed
- Access-Control-Allow-Credentials – indicates whether credentials (cookies, auth) can be included
Example
csharp
```
// Program.cs (.NET 8+)
var builder = WebApplication.CreateBuilder(args);

// Define a CORS policy
builder.Services.AddCors(options =>
{
    options.AddPolicy("AllowFrontend", policy =>
    {
        policy.WithOrigins("https://example.com", "https://app.example.com")
              .AllowAnyMethod()
              .AllowAnyHeader()
              .AllowCredentials();
    });
});

builder.Services.AddControllers();
var app = builder.Build();

// Apply the CORS policy globally
app.UseCors("AllowFrontend");

app.MapControllers();
app.Run();
```
This configuration allows requests from two specific origins, permits any HTTP method and header, and allows credentials to be sent with requests.

Key points to mention
- CORS is a browser-enforced security feature; it doesn't prevent server-to-server API calls or non-browser clients from accessing your API
- You can define multiple CORS policies and apply them selectively to different endpoints or controllers using the [EnableCors] attribute, similar to how filters in ASP.NET Core work
- In development, you can use AllowAnyOrigin(), but in production you should explicitly whitelist trusted origins for security
- Avoid setting AllowAnyOrigin() with AllowCredentials() – this combination is rejected by browsers as a security violation
- CORS must be configured before authentication middleware in the middleware pipeline to work correctly
Common follow-up questions
- What is the difference between a CORS preflight request and a simple request?
- How do you apply CORS to specific controllers or endpoints rather than globally?
- What security risks should you consider when configuring CORS?
Related interview questions
.NETCsharpaspnetcore
91What is Entity Framework Core?
Beginner
Entity Framework Core (EF Core) is the official Object-Relational Mapping (ORM) framework for .NET. It enables developers to work with databases using .NET objects instead of raw SQL, automatically mapping C# classes to database tables and translating LINQ queries into SQL commands. EF Core handles database operations, change tracking, migrations, and relationships declaratively.

How it works

Entity Framework Core acts as an abstraction layer between your application and the database. You define C# classes (called entities) that represent your data model. EF Core maintains a DbContext, which represents your database session and coordinates all database operations.

When you query using LINQ, EF Core translates your C# expressions into SQL at runtime. For example, a LINQ Where() clause becomes a SQL WHERE statement. EF Core then executes the SQL against your database and materializes the results back into C# objects.

Change tracking is a core feature: EF Core monitors which entities have been created, modified, or deleted during your DbContext's lifetime. When you call SaveChanges(), it generates the appropriate INSERT, UPDATE, or DELETE statements based on these changes.

Migrations provide version control for your database schema. Instead of manually running SQL scripts, you define your model in code, and EF Core generates migration files that evolve your database schema over time.

Example
csharp
```
// Define your entities
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
    public int CategoryId { get; set; }
    public Category Category { get; set; }
}

public class Category
{
    public int Id { get; set; }
    public string Name { get; set; }
    public List<Product> Products { get; set; } = new();
}

// Define your DbContext
public class AppDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }
    public DbSet<Category> Categories { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder options)
        => options.UseSqlServer("Server=.;Database=Shop;Trusted_Connection=true;");
}

// Usage
using var context = new AppDbContext();

// Query with LINQ (translates to SQL)
var expensiveProducts = context.Products
    .Where(p => p.Price > 100)
    .Include(p => p.Category)
    .ToList();

// Create and save
var newProduct = new Product { Name = "Laptop", Price = 1500, CategoryId = 1 };
context.Products.Add(newProduct);
context.SaveChanges(); // Generates INSERT statement
```
This example demonstrates querying products by price with their related category, then creating and persisting a new product—all using C# objects and LINQ instead of SQL.

Key points to mention
- LINQ to SQL translation: EF Core converts LINQ expressions into database-specific SQL queries at runtime.
- Change tracking: EF Core automatically detects and tracks modifications to entities, generating appropriate SQL statements on SaveChanges().
- Relationships: Navigation properties define one-to-many, many-to-many, and one-to-one relationships declaratively in code.
- Migrations: Database schema evolution is managed through code-based migrations rather than manual SQL scripts.
- Database agnostic: EF Core supports multiple database providers (SQL Server, PostgreSQL, SQLite, MySQL) with minimal code changes.
Common follow-up questions
- What is the difference between eager loading, lazy loading, and explicit loading in EF Core?
- Why use projections with Select in EF Core?
- What is Dapper and when would you use it instead of EF Core?
Related interview questions
Further reading
- AsNoTracking: free performance
.NETCsharpefcore
92What is a DbContext?
Beginner
DbContext is the core Entity Framework Core class that represents a session with the database. It provides an abstraction layer between your application and the database, exposing DbSet properties for each entity, tracking changes to objects in memory, and coordinating the saving of those changes back to the database through SaveChanges.

How it works

DbContext acts as a bridge between your domain objects and the database. When you create a DbContext instance, it opens a logical session that manages the lifecycle of your entities. The context maintains an internal change tracker that monitors every entity you load, create, modify, or delete. This is part of the Unit of Work pattern, where all changes are batched together and committed in a single transaction.

Each DbSet<T> property represents a collection of entities of type T in the database. When you query through a DbSet, the context tracks the returned entities. As you modify these objects, the context detects those changes through its change tracking mechanism. When you call SaveChanges(), the context generates appropriate SQL INSERT, UPDATE, or DELETE statements and executes them within a transaction, ensuring data consistency.

DbContext is typically configured with connection strings and model mappings in the OnConfiguring method or through dependency injection. Modern applications almost always use constructor-based dependency injection to register DbContext in the service container, making it easy to manage its lifetime and enable features like automatic connection pooling.

Example
csharp
```
public class ApplicationDbContext : DbContext
{
    public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
        : base(options) { }

    public DbSet<Product> Products { get; set; }
    public DbSet<Order> Orders { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Product>().HasKey(p => p.Id);
        modelBuilder.Entity<Order>().HasKey(o => o.Id);
    }
}

// Usage in a service
public class ProductService
{
    private readonly ApplicationDbContext _context;

    public ProductService(ApplicationDbContext context)
    {
        _context = context;
    }

    public async Task AddProductAsync(Product product)
    {
        _context.Products.Add(product);
        await _context.SaveChangesAsync();
    }
}
```
This example shows a custom DbContext defining two entities, configured via dependency injection, and then used in a service to add and persist a new product to the database.

Key points to mention
- DbContext maintains a session and tracks all entity changes in memory until SaveChanges is called
- DbSet<T> properties expose queryable collections for LINQ operations against specific entity types
- The context must be disposed properly (typically handled automatically with dependency injection scopes) to release database connections
- DbContext is not thread-safe; use a new instance per request in web applications or employ synchronization for other scenarios
- OnModelCreating allows fluent configuration of entity mappings, relationships, and database constraints
Common follow-up questions
- How do I configure DbContext with a connection string in dependency injection?
- What is the difference between tracking and non-tracking queries?
- How does SaveChanges differ from SaveChangesAsync, and when should I use each?
Related interview questions
.NETCsharpefcore
93What are EF Core migrations?
Beginner
EF Core migrations are a version control system for your database schema. They automatically track changes to your Entity Framework Core models and generate SQL scripts that transform your database from one schema state to another. Migrations let you evolve your database alongside your code without losing data.

How it works

When you modify a DbContext or entity class, EF Core doesn't automatically update the database. Instead, you use the migration system to capture those changes as discrete, reversible steps.

The workflow is straightforward: after changing your model, you run dotnet ef migrations add MigrationName to create a migration file. This file contains an Up() method (applies the change) and a Down() method (reverts it). EF Core analyzes the difference between your current model and the database schema snapshot, then generates the SQL. Finally, you run dotnet ef database update to apply pending migrations to the database.

Each migration is stored as a C# file in your Migrations folder alongside a snapshot file that tracks the complete schema state. This history forms an audit trail of all schema changes, making it easy to understand when and why changes occurred.

Example
csharp
```
// Original model
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
}

// After adding a property
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }  // New property
}

// Terminal: dotnet ef migrations add AddPriceToProduct
// This generates Up() with: migrationBuilder.AddColumn("Price", "Products", ...);
// And Down() with: migrationBuilder.DropColumn("Price", "Products", ...);

// Terminal: dotnet ef database update
// Applies the migration to the database
```
This example shows how a single property addition translates into a generated migration file with both forward and rollback logic.

Key points to mention
- Idempotency: Migrations track which ones have been applied via the __EFMigrationsHistory table, preventing duplicate execution.
- Snapshot files: EF Core maintains a model snapshot to compare against when generating new migrations, ensuring accuracy.
- Reversibility: The Down() method lets you roll back a migration with dotnet ef database update <PreviousMigration>.
- Data loss risk: Some operations (like dropping columns) are destructive; you should review generated migrations before applying them to production, especially for zero-downtime deployments.
- Customization: Generated migrations can be edited manually to include seed data or custom SQL logic.
Common follow-up questions
- How do you handle merge conflicts when multiple developers create migrations on different branches?
- Can you safely rename a column without losing data, and how does EF Core handle this?
- What's the difference between Update-Database and Script-Migration, and when would you use each?
Related interview questions
.NETCsharpefcore

94What is the difference between Add and Update in EF Core?

Beginner

Add marks an entity as new and schedules it for insertion into the database. Update marks an entity as modified and schedules all its properties for update in the database. The key difference is their intent: Add assumes the entity doesn't exist yet, while Update assumes it already exists and needs changes.

How it works

When you call DbContext.Add(), Entity Framework Core assigns the entity an EntityState of Added. This state tells EF Core to generate an INSERT statement when SaveChanges() is called. The entity is tracked by the context, and all property values are captured for the INSERT command.

When you call DbContext.Update(), EF Core assigns an EntityState of Modified. This tells EF Core to generate an UPDATE statement. Importantly, Update marks all properties as changed, regardless of whether you actually modified them. This means every column in the UPDATE statement will be SET, even if the value hasn't changed.

The distinction matters because Add expects a new entity (often with a default or zero primary key), while Update expects an entity that already exists in the database and needs synchronization. If you call Update on an entity that doesn't exist, the UPDATE statement will execute but affect zero rows—no error occurs, but the intended change doesn't happen.

Example

csharp

var context = new BlogContext();

// Using Add - for new entities
var newBlog = new Blog { Title = "My New Blog" };
context.Add(newBlog);
await context.SaveChangesAsync();
// Generates: INSERT INTO Blogs (Title) VALUES ('My New Blog')

// Using Update - for existing entities
var existingBlog = new Blog { Id = 1, Title = "Updated Title" };
context.Update(existingBlog);
await context.SaveChangesAsync();
// Generates: UPDATE Blogs SET Title = 'Updated Title' WHERE Id = 1

This example shows Add creating a new blog record and Update modifying an existing one identified by its Id.

Aspect	Add	Update
Entity State	Added	Modified
SQL Generated	INSERT	UPDATE
Property Tracking	Only provided values included	All properties marked as changed
Use Case	New entities not in database	Existing entities requiring modification
Primary Key	Usually generated or default	Must exist in database
If Entity Doesn't Exist	INSERT succeeds; new record created	UPDATE executes but affects 0 rows

What is the difference between Add and Update in EF Core diagram

Key points to mention

EntityState matters: Add uses EntityState.Added, Update uses EntityState.Modified. You can check entry.State to verify the current state.
All properties updated: Update marks all properties as changed, so UPDATE statements include every column. This differs from attaching an entity and modifying only specific properties.
Tracking vs. detached entities: Both methods work on tracked or detached entities. Use Add for new detached entities and Update for existing detached entities that need full synchronization.
Performance consideration: If you only need to update specific properties, consider using DbContext.Attach() followed by property-level changes instead of Update for better performance.
Relationships: Add handles relationship setup for new entities; Update assumes relationships already exist in the database.

Common follow-up questions

What's the difference between Update and Attach? How would you update only specific properties?
What happens if you call Add on an entity with an existing primary key value?
How does Update interact with EF Core migrations and schema changes?

96What is the difference between IQueryable and IEnumerable?

Beginner

IQueryable translates LINQ expressions into provider-specific queries (usually SQL) executed on the server, while IEnumerable executes in-memory using LINQ-to-Objects. This means IQueryable is deferred, filtered at the source, and more efficient for large datasets; IEnumerable loads data first, then filters in your application.

How it works

IQueryable uses an expression tree—a representation of your query as data—which a provider (like Entity Framework Core) translates into SQL or another language before execution. When you call .Where() on an IQueryable, you're not executing the filter; you're building an abstract syntax tree. Only when you materialize the result (with .ToList(), .FirstOrDefault(), or iteration) does the provider send SQL to the database.

IEnumerable uses delegates and LINQ-to-Objects, executing in-memory. Filters happen after data is loaded into your application. If you call .Where() on an IEnumerable of 1 million records, all 1 million are loaded first, then filtered in memory—potentially wasteful.

The key insight: defer execution until necessary, and push filtering as close to the data source as possible. Calling .ToList() converts IQueryable to IEnumerable, severing the connection to the database provider.

Example

csharp

using Microsoft.EntityFrameworkCore;

var context = new AppDbContext();

// IQueryable: builds SQL expression tree, filters on server
IQueryable<User> queryable = context.Users
    .Where(u => u.Age > 30)
    .Where(u => u.City == "New York");

// Nothing executed yet. Inspect queryable.ToString() to see the SQL expression.

// IEnumerable: loads all users into memory, filters in-app
IEnumerable<User> enumerable = context.Users
    .ToList()  // ← SQL executes here; all rows loaded
    .Where(u => u.Age > 30)
    .Where(u => u.City == "New York");

// This inefficient pattern loads 1M rows, then filters in RAM.

var results = queryable.ToList();  // ← SQL executes NOW with WHERE clauses; fewer rows returned

The IQueryable version sends SELECT * FROM Users WHERE Age > 30 AND City = 'New York' to the database; the IEnumerable version fetches all users, then filters in your process.

Key points to mention

Deferred execution: IQueryable delays translation until materialization; IEnumerable executes immediately upon filtering.
Data source: IQueryable targets external sources (databases); IEnumerable is in-memory only, using LINQ-to-Objects.
Performance: IQueryable is far more efficient for large datasets because filtering happens server-side; IEnumerable loads everything into RAM first.
Conversion: Calling .ToList(), .ToArray(), or .FirstOrDefault() on IQueryable executes the query and returns IEnumerable (or a concrete type). After that, no further filtering goes to the database.
Expressions: IQueryable accepts Expression<Func> predicates; IEnumerable accepts Func delegates. Expressions are code-as-data, enabling translation.

Common follow-up questions

When would you intentionally use IEnumerable over IQueryable? When you need in-memory LINQ with custom logic that the database provider cannot translate, or when working with collections already loaded in memory.
What happens if you chain IQueryable and IEnumerable together? The moment you call .ToList(), you create an IEnumerable; all subsequent LINQ operations execute in-memory, defeating server-side query optimization.
Can you use .Select() on IQueryable to project before .ToList()? Yes, and you should—select only the columns you need server-side to reduce data transfer and memory usage.

Aspect	IQueryable	IEnumerable
Execution Model	Deferred; translates to SQL/provider-specific query	Deferred; executes in-memory with delegates
Data Source	External (database, OData, etc.) via provider	In-memory collections
When Query Runs	At materialization (ToList, FirstOrDefault, iteration)	At materialization, but filtering happens in-app
Filtering Location	Server-side; only filtered rows returned	Client-side; all data loaded, then filtered in RAM
Performance (1M rows)	Excellent; WHERE clause sent to database	Poor; all 1M rows loaded into memory
Use Case	EF Core queries, LINQ-to-SQL, large datasets	In-memory lists, arrays, already-materialized data

What is the difference between IQueryable and IEnumerable diagram

107What is the difference between Debug and Release builds?

Beginner

Debug builds include debugging symbols, disable optimizations, and enable runtime checks to help you find and fix bugs during development. Release builds are optimized for performance and size, remove debugging information, and are intended for production deployment.

How it works

When you compile a .NET project, the build configuration determines how the compiler and runtime treat your code. In Debug mode, the compiler preserves full symbol information (variable names, line numbers, stack traces) and applies minimal optimizations so code execution matches your source code line-by-line. This makes debugging easier but produces slower, larger binaries.

Release mode strips debugging symbols, applies aggressive optimizations (inlining, dead code elimination, loop unrolling), and removes conditional compilation blocks marked for Debug only. The result is a faster, smaller executable suitable for end users.

Both configurations are controlled via preprocessor directives and project properties. You can conditionally compile code using #if DEBUG blocks, and the runtime behavior differs too—Debug builds may include extra validation that Release builds skip entirely.

Example

csharp

using System;
using System.Diagnostics;

class Program
{
    static void Main()
    {
        #if DEBUG
        Console.WriteLine("Debug mode: Running with full logging enabled");
        LogDetailedMetrics();
        #endif

        int result = CalculateSum(1000000);
        Console.WriteLine($"Result: {result}");

        Debug.Assert(result > 0, "Result should be positive");
    }

    static int CalculateSum(int n)
    {
        int sum = 0;
        for (int i = 0; i < n; i++)
        {
            sum += i;
        }
        return sum;
    }

    static void LogDetailedMetrics()
    {
        var sw = Stopwatch.StartNew();
        // Expensive logging operations
        sw.Stop();
        Console.WriteLine($"Metrics logged in {sw.ElapsedMilliseconds}ms");
    }
}

This example demonstrates conditional compilation: the Debug logging and assertion only execute in Debug builds; in Release, they're stripped entirely, leaving a lean executable.

Key points to mention

Symbols and debugging: Debug builds embed PDB (Program Database) files containing source-level debugging information; Release strips these for smaller, faster binaries.
Optimizations: Release enables compiler optimizations like inlining and tail-call optimization; Debug disables them to preserve step-through execution.
Preprocessor directives: Use #if DEBUG blocks to conditionally include expensive logging, assertions, or validation only during development.
Performance difference: Release builds can be 2–10× faster depending on the workload; Debug builds prioritize debuggability over speed.
Deployment: Always deploy Release builds to production; Debug builds waste resources and expose internal details.

Aspect	Debug Build	Release Build
Optimization Level	Minimal (preserves line-by-line execution)	Aggressive (inlining, dead-code elimination)
Debug Symbols	Included (full PDB file with variable names, line numbers)	Stripped (no debugging information)
Binary Size	Larger (includes metadata and symbols)	Smaller (optimized, no extra info)
Execution Speed	Slower (optimizations disabled)	Faster (fully optimized)
#if DEBUG Blocks	Included (compiled in)	Excluded (compiled out)
Use Case	Development and local testing	Production and release deployment

What is the difference between Debug and Release builds diagram

Common follow-up questions

Can I debug a Release build? Yes, if you have the matching PDB file and enable "Debug release binaries" in your debugger, but stepping through optimized code can be confusing since instructions don't map 1:1 to source lines.
How do I set the build configuration in Visual Studio? Use the Solution Configuration dropdown in the toolbar, or go to Project Properties → Build and set the "Configuration" to Debug or Release.
Should I ever run Release locally? Yes—test Release builds locally before deployment to catch performance regressions or environment-specific issues.

108What is .NET LTS vs STS?

Beginner

.NET LTS (Long Term Support) versions receive three years of support and are released every two years in even-numbered years, while .NET STS (Standard Term Support) versions receive 18 months of support and are released in odd-numbered years. LTS versions are intended for production workloads requiring stability and long-term compatibility, whereas STS versions offer new features more frequently for teams that can upgrade regularly.

How it works

Microsoft maintains two release cadences for .NET to balance innovation with stability. Every even year (2022, 2024, 2026), an LTS release ships with a guarantee of three years of mainstream support plus an additional year of extended support if needed. These versions become the backbone of enterprise applications because they receive critical security and bug fixes over an extended period without major breaking changes.

In odd years (2023, 2025), Microsoft releases STS versions that receive 18 months of support. These versions introduce new language features, performance improvements, and library enhancements, but they have a shorter support window. Teams using STS must plan to upgrade within that timeframe or risk running unsupported software.

The rationale is straightforward: organizations with large codebases, regulatory requirements, or conservative upgrade schedules need LTS for predictability. Teams working on greenfield projects or microservices that update frequently benefit from STS innovations. For example, .NET 8 (released November 2023) is LTS, while .NET 9 (released November 2024) is STS.

Comparison table

Aspect	LTS (Long Term Support)	STS (Standard Term Support)
Release cycle	Every 2 years (even years: 2022, 2024, 2026)	Every year (odd years: 2023, 2025)
Mainstream support duration	3 years	18 months
Extended support	1 additional year available	None
Target audience	Enterprise, regulated industries, stable workloads	Fast-moving teams, microservices, new projects
Feature velocity	Conservative; focused on stability	High; new features every 12 months
Examples	.NET 6, .NET 8	.NET 7, .NET 9

Example

csharp

// Checking runtime version at startup
var runtimeVersion = System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription;
Console.WriteLine($"Running on: {runtimeVersion}");

// Output example: Running on: .NET 8.0.0
// .NET 8 is LTS (supported until November 2026)

var version = Environment.Version;
bool isLtsVersion = version.Major is 6 or 8; // .NET 6 and 8 are LTS
Console.WriteLine($"Using LTS: {isLtsVersion}");

This code detects the running .NET version and identifies whether it is an LTS release; in production, you might log this during startup or enforce minimum version requirements.

Key points to mention

Support timeline matters in production: Running unsupported versions exposes you to unpatched security vulnerabilities and lack of official bug fixes.
LTS is not "slow": LTS versions still receive performance improvements and new minor features; the difference is they avoid breaking changes to the runtime and framework APIs.
Plan upgrades accordingly: Teams using STS must budget time for annual or biennial upgrades; LTS teams have more flexibility but should still plan a transition path before support ends.
Container and CI/CD matter: With containerization, upgrading base images from one LTS to the next is simpler than it was with .NET Framework, making LTS transitions more manageable.
Hybrid approach is common: Large organizations often run LTS for core services and STS for experimental or microservice projects.

Common follow-up questions

"How do I know when support ends for my current .NET version?" — Check the official dotnet.microsoft.com release calendar or use dotnet --info to see your current version and compare against the support matrix.
"Should we always use LTS?" — Not necessarily; it depends on your team's ability to update. If you have CI/CD automation and lightweight microservices, STS can work well. If you're managing legacy monoliths with compliance requirements, LTS is safer.
"Can we stay on an older LTS forever?" — Technically yes, but not recommended; security patches eventually stop, and interoperability with new libraries becomes problematic. Plan a refresh cycle before end-of-life arrives.

110What is the difference between authentication and authorization?

Beginner

Authentication verifies who the user is by validating their credentials (username, password, token, etc.), while authorization determines what that authenticated user is allowed to do based on their roles, permissions, or policies. In short: authentication answers "Who are you?" and authorization answers "What can you do?"

How it works

Authentication is the first step in any secure system. When a user logs in, the application verifies their identity against stored credentials (typically a hashed password in a database). Once authenticated, the user receives proof of identity—usually a session token or JWT. This proof is included in subsequent requests so the server knows who is making the request.

Authorization happens after authentication. Once the server confirms who the user is, it checks what that user is permitted to access or modify. This is typically done through roles (Admin, User, Guest), claims (permissions attached to a user), or policies (custom business rules). For example, a user might be authenticated but not authorized to delete other users' accounts.

In ASP.NET Core, authentication middleware runs early in the request pipeline order, extracting the user's identity from cookies, headers, or tokens. Authorization middleware runs later, using that identity to enforce access control. You can also use resource-based authorization for more granular control over specific objects or data.

Example

csharp

[ApiController]
[Route("api/[controller]")]
public class AdminController : ControllerBase
{
    [HttpDelete("{id}")]
    [Authorize(Roles = "Admin")]  // Authorization: only Admin role
    public IActionResult DeleteUser(int id)
    {
        // Authentication already verified in [Authorize]
        // This code only runs if user is authenticated AND in Admin role
        return Ok($"User {id} deleted");
    }
}

// In Program.cs:
builder.Services.AddAuthentication("Bearer")
    .AddJwtBearer("Bearer", options => options.Authority = "https://auth-server");
builder.Services.AddAuthorization();
builder.Services.AddControllers();

The [Authorize(Roles = "Admin")] attribute first confirms the user is authenticated (authentication), then verifies they belong to the Admin role (authorization). Without both checks passing, the request is rejected.

Key points to mention

Sequential process: Authentication must succeed before authorization is even evaluated.
Different concerns: Authentication is about identity verification; authorization is about access control based on identity.
Flexible authorization: You can use roles, claims, policies, or custom handlers to implement authorization logic.
Stateless is common: Modern APIs use tokens (like JWT authentication) to carry authentication info without server-side sessions.
Multiple layers: Authorization can be applied at the action level, controller level, or globally via policies.

Common follow-up questions

How do you implement custom authorization policies in ASP.NET Core?
What's the difference between role-based and claims-based authorization?
How do you handle authorization for protected API endpoints?

Aspect	Authentication	Authorization
Purpose	Verifies the user's identity	Determines user access rights
Question it answers	"Who are you?"	"What can you do?"
Timing	Happens first, before authorization	Happens after authentication succeeds
Common methods	Username/password, tokens (JWT, OAuth), certificates, MFA	Roles, claims, policies, resource-based rules
Failure result	401 Unauthorized (identity not verified)	403 Forbidden (authenticated but not allowed)
ASP.NET Core attribute	`[Authorize]` (checks if authenticated)	`[Authorize(Roles = "...")]` or policies

What is the difference between authentication and authorization diagram

113What is the difference between Use, Run and Map in middleware?

Experienced

Use adds general-purpose middleware that can pass control to the next middleware via next(). Run adds terminal middleware that short-circuits the pipeline and never calls next(). Map branches the pipeline conditionally based on a request path prefix, allowing different middleware chains for different routes.

How it works

In ASP.NET Core's middleware pipeline, each component processes the request and either passes it forward or terminates it. Use() is the standard method for adding middleware—it receives a next delegate that represents the remainder of the pipeline. The middleware must decide whether to call next to continue processing or skip it to end execution early.

Run() is a terminal middleware extension that never calls next. It always ends the pipeline and produces a final response. Multiple Run() calls can exist, but only the first one reached will execute—subsequent ones never run because the pipeline has already terminated. This makes Run() useful for catch-all handlers or default responses at the end of your middleware chain.

Map() is a branching mechanism that evaluates a path predicate and directs matching requests to a separate middleware pipeline. If the condition matches (typically a path prefix like /admin), the mapped middleware executes. If it doesn't match, the request continues to the next middleware in the main pipeline. Importantly, mapped pipelines are independent; middleware registered inside a Map() block doesn't affect requests outside that branch.

Example

csharp

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

// General middleware - can call next or not
app.Use(async (context, next) =>
{
    context.Response.Headers.Add("X-Custom-Header", "From Use");
    await next();
});

// Branch for /admin path
app.Map("/admin", admin =>
{
    admin.Use(async (context, next) =>
    {
        context.Response.Headers.Add("X-Admin", "true");
        await next();
    });

    // Terminal middleware in admin branch
    admin.Run(async context =>
    {
        await context.Response.WriteAsJsonAsync(new { message = "Admin area" });
    });
});

// Terminal middleware - pipeline ends here if reached
app.Run(async context =>
{
    await context.Response.WriteAsJsonAsync(new { message = "Main response" });
});

app.Run();

This example shows a general middleware adding a header, a branched route for /admin with its own chain, and a terminal Run() for all other requests. Requests to /admin never reach the final Run().

Key points to mention

Use() is composable and non-terminal—middleware must explicitly call next to continue the pipeline or choose to short-circuit.
Run() is a convenience extension that creates terminal middleware; it's semantically clearer than Use() when you know the pipeline ends there.
Map() creates a conditional branch that doesn't interfere with the main pipeline—non-matching requests skip the mapped block entirely.
Order matters: middleware registered earlier always executes before later middleware, and Map() conditions are evaluated in registration order.
MapWhen() is a related method that branches on a custom predicate instead of just a path prefix, offering more flexible branching logic.

Comparison table

Method	Purpose	Calls `next`?	Terminates Pipeline?	Common Use Case
`Use()`	General-purpose middleware	Optional (your choice)	No (unless you skip `next`)	Logging, authentication, request modification
`Run()`	Terminal middleware	Never	Yes (always)	Default response, catch-all handler
`Map()`	Path-based branching	Depends on mapped middleware	No (main pipeline continues if no match)	Route-specific logic (`/api`, `/admin`)

What is the difference between Use, Run and Map in middleware diagram

Common follow-up questions

What happens if I call next() in a Run() middleware? You can't—Run() is an extension that doesn't accept a next parameter. If you need conditional behavior, use Use() instead.
Can I nest Map() calls? Yes, you can map within a map to create hierarchical branching (e.g., Map("/api").Map("/v1")), though this can get complex.
How does MapWhen() differ from Map()? MapWhen() accepts a custom predicate function instead of a path prefix, allowing branching on headers, query parameters, or custom logic.

117What is the difference between IOptions, IOptionsSnapshot and IOptionsMonitor?

Experienced

IOptions, IOptionsSnapshot, and IOptionsMonitor are three ways to inject configuration into ASP.NET Core services, each with different lifetimes and behaviors. IOptions is a singleton that reads configuration once at startup; IOptionsSnapshot is scoped and recomputes per request; IOptionsMonitor is a singleton that watches for configuration changes and notifies subscribers in real time.

How it works

These interfaces provide access to strongly-typed configuration objects bound from your appsettings.json or other configuration sources. The key difference lies in their service lifetimes and when they read configuration values.

IOptions is registered as a singleton and caches the configuration object for the application's lifetime. It reads configuration once during dependency injection setup. This is the most performant but cannot reflect runtime changes.

IOptionsSnapshot is scoped to each request and reads the current configuration at the start of each scope. It allows you to see configuration changes between requests without restarting the application, but the values remain constant within a single request.

IOptionsMonitor is a singleton that actively monitors configuration changes. It holds a reference to the latest configuration value and provides an OnChange event for subscribers to react to configuration updates immediately. This is useful for settings that change frequently and require immediate application without restarting.

Example

csharp

public class AppSettings
{
    public string ApiKey { get; set; }
    public int MaxRetries { get; set; }
}

public class ConfigurationService
{
    private readonly IOptions<AppSettings> _options;
    private readonly IOptionsSnapshot<AppSettings> _snapshot;
    private readonly IOptionsMonitor<AppSettings> _monitor;

    public ConfigurationService(
        IOptions<AppSettings> options,
        IOptionsSnapshot<AppSettings> snapshot,
        IOptionsMonitor<AppSettings> monitor)
    {
        _options = options;
        _snapshot = snapshot;
        _monitor = monitor;

        // Subscribe to configuration changes
        monitor.OnChange((newSettings, name) =>
        {
            Console.WriteLine($"Configuration changed: MaxRetries = {newSettings.MaxRetries}");
        });
    }

    public void DemonstrateUsage()
    {
        // IOptions: reads once at startup, cached
        var apiKey1 = _options.Value.ApiKey;

        // IOptionsSnapshot: reads current configuration
        var retries = _snapshot.Value.MaxRetries;

        // IOptionsMonitor: always reflects latest value
        var currentKey = _monitor.CurrentValue.ApiKey;
    }
}

// Startup configuration
builder.Services.Configure<AppSettings>(
    builder.Configuration.GetSection("Settings"));

This example demonstrates injecting all three interfaces into a service. IOptions caches the value once, IOptionsSnapshot reads fresh values per request, and IOptionsMonitor actively watches for changes and triggers callbacks when configuration updates.

Comparison table

Interface	Lifetime	Reads Configuration	Reflects Changes	Best Use Case
`IOptions<T>`	Singleton	Once at startup	No (cached)	Static settings that never change
`IOptionsSnapshot<T>`	Scoped	Per request	Between requests only	Settings that change rarely, per-request consistency required
`IOptionsMonitor<T>`	Singleton	On demand (latest)	Yes (immediate)	Dynamic settings requiring real-time updates and notifications

What is the difference between IOptions, IOptionsSnapshot and IOptionsMonitor diagram

Key points to mention

Performance vs. flexibility: IOptions is fastest because it caches; IOptionsMonitor is more flexible but slightly slower due to change detection.
Request consistency: IOptionsSnapshot guarantees the same configuration value throughout a single request, avoiding inconsistencies if settings change mid-request.
OnChange events: Only IOptionsMonitor provides the OnChange callback, allowing services to react immediately to configuration updates without restarting.
Named options: All three support named configuration instances using IOptionsMonitor.Get(name) for multiple configuration sets.
File watchers: IOptionsSnapshot and IOptionsMonitor require file watchers enabled in your configuration provider to detect changes at runtime.

Common follow-up questions

How do you reload configuration without restarting the application, and what constraints apply?
Why does IOptionsSnapshot use the scoped lifetime instead of transient?
Can you use IOptionsMonitor with database-backed configuration, and what are the performance implications?

121What is the difference between a filter and middleware?

Experienced

Middleware runs globally for every HTTP request in the ASP.NET Core pipeline and has no knowledge of MVC concepts, while filters are MVC-specific components that execute within the action invocation pipeline and have full access to action context, model state, and action results. Middleware is infrastructure-level, whereas filters are application-logic-level.

How it works

Middleware operates at the lowest level of the request pipeline. It forms a chain where each middleware component can inspect the request, modify it, pass it to the next component, and then inspect the response on the way back. Middleware runs regardless of whether the request reaches an MVC controller or not—it applies to static files, API endpoints, health checks, and everything in between.

Filters, by contrast, are part of the MVC pipeline specifically. They execute only when a request reaches an MVC controller action. Filters have access to rich MVC-specific information like ActionContext, ModelStateDictionary, ActionResult, and the controller instance itself. This makes filters ideal for cross-cutting concerns that need awareness of MVC semantics, such as model validation, authorization based on user roles, or result transformation.

The request pipeline order shows middleware wrapping everything, with filters nested inside the MVC layer. If you need to intercept requests before they reach routing or handle non-MVC traffic, use middleware. If you need to intercept at the action level with MVC context, use filters.

Example

csharp

// Middleware: runs for ALL requests
public class LoggingMiddleware
{
    private readonly RequestDelegate _next;

    public LoggingMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        Console.WriteLine($"[Middleware] Request: {context.Request.Path}");
        await _next(context);
        Console.WriteLine($"[Middleware] Response: {context.Response.StatusCode}");
    }
}

// Filter: runs only for MVC action invocations
public class ValidateModelAttribute : ActionFilterAttribute
{
    public override void OnActionExecuting(ActionExecutingContext context)
    {
        if (!context.ModelState.IsValid)
        {
            Console.WriteLine($"[Filter] Model validation failed for action {context.ActionDescriptor.DisplayName}");
            context.Result = new BadRequestObjectResult(context.ModelState);
        }
    }
}

// Usage in Program.cs
app.UseMiddleware();

// Usage on controller action
[HttpPost]
[ValidateModel]
public IActionResult Create([FromBody] UserDto dto) => Ok();

The middleware logs all HTTP requests and responses globally, while the filter validates model state only when an MVC action is about to execute, with access to the actual action context.

Aspect	Middleware	Filters
Scope	Global; runs for every request	MVC-specific; runs only for controller actions
Access to Context	Only `HttpContext`	`ActionContext`, `ModelState`, route data, action descriptor
Execution Timing	Before routing, before MVC layer	During action invocation pipeline
Use Cases	Logging, authentication, CORS, compression, static files	Authorization, model validation, result transformation, exception handling
Configuration	`app.UseMiddleware<T>()` in `Program.cs`	Attribute on controller/action or global filter
Performance	Lower overhead for infrastructure concerns	Only invoked when MVC action matches

What is the difference between a filter and middleware diagram

Key points to mention

Middleware has no knowledge of MVC concepts; it sees only raw HTTP requests and responses.
Filters are MVC-aware and can access model state, action parameters, and action results—use them for business logic validation.
Middleware executes before routing; filters execute after routing and model binding are complete.
Use middleware for cross-cutting infrastructure concerns; use filters for action-level concerns.
Both can be chained, and both support async operations, but they serve different layers of the application.

Common follow-up questions

What is middleware and how does it form a pipeline?
Can a filter access the request body, and should it? What are the performance implications?
When would you use a global filter versus a middleware component for authentication?

133What is the difference between cookie and JWT authentication?

Experienced

Cookie-based authentication stores session state on the server and uses HTTP-only cookies for browser clients, requiring explicit CSRF protection and server memory. JWT (JSON Web Token) authentication is stateless, encoding claims directly in a signed token that the client includes in request headers, making it ideal for APIs and distributed systems. The choice depends on your architecture: cookies for traditional server-rendered apps, JWT for APIs and mobile clients.

How it works

Cookie-based authentication follows a traditional session model. When a user logs in, the server validates credentials, creates a session record in memory or a data store (Redis, SQL Server), and sends a session ID back as an HTTP-only cookie. The browser automatically includes this cookie on every request to the same domain. The server looks up the session, verifies it's valid and not expired, and processes the request. On logout, the session is destroyed. Because cookies are automatically sent, CSRF attacks are possible—an attacker can trick your browser into making unwanted requests—so you must implement CSRF protection tokens.

JWT authentication is stateless. When a user logs in, the server creates a signed token containing user claims (ID, roles, permissions) and an expiration time, then returns it to the client. The client stores the token (localStorage, sessionStorage, or a secure cookie) and includes it in the Authorization: Bearer <token> header on every request. The server validates the signature and expiration without looking up any session. Because the token is explicitly passed by the client and not automatically included, CSRF is not a concern; XSS (Cross-Site Scripting) is the primary threat if the token is stored in JavaScript-accessible storage.

Example

csharp

// Cookie-based authentication (ASP.NET Core)
app.MapPost("/login-cookie", async (LoginRequest req, IAuthService auth, 
    HttpContext ctx) =>
{
    var user = await auth.ValidateCredentialsAsync(req.Email, req.Password);
    if (user == null) return Results.Unauthorized();
    
    await ctx.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme,
        new ClaimsPrincipal(new ClaimsIdentity(new[]
        {
            new Claim(ClaimTypes.NameIdentifier, user.Id),
            new Claim(ClaimTypes.Email, user.Email)
        }, "cookie")));
    
    return Results.Ok();
});

// JWT authentication (ASP.NET Core)
app.MapPost("/login-jwt", async (LoginRequest req, IAuthService auth, 
    ITokenService tokenService) =>
{
    var user = await auth.ValidateCredentialsAsync(req.Email, req.Password);
    if (user == null) return Results.Unauthorized();
    
    var token = tokenService.GenerateToken(new[]
    {
        new Claim(ClaimTypes.NameIdentifier, user.Id),
        new Claim(ClaimTypes.Email, user.Email)
    });
    
    return Results.Ok(new { token });
});

The cookie example uses SignInAsync to create a secure, HTTP-only cookie that the browser manages automatically. The JWT example generates a signed token the client must store and include explicitly on subsequent requests.

Comparison table

Aspect	Cookie-based	JWT
State	Stateful (server stores sessions)	Stateless (token is self-contained)
Storage	HTTP-only cookie (automatic on browser)	Client (localStorage, sessionStorage, or cookie)
Transmission	Automatic with every same-domain request	Manual in Authorization header
CSRF risk	High; requires CSRF token protection	Low; client explicitly sends token
Best for	Browser-based apps (MVC, Blazor Server)	APIs, SPAs, mobile apps, microservices
Scalability	Requires shared session store (Redis, DB)	No server-side session storage needed

What is the difference between cookie and JWT authentication diagram

Key points to mention

Cookies are automatic and transparent to the client but tie authentication to the browser and same-origin policy; JWTs require explicit client management but work across domains and with mobile apps.
Cookie sessions must be validated against server state every request; JWT tokens are validated cryptographically and do not require a database lookup, improving performance at scale.
Cookies mitigate XSS (HTTP-only flag) but require CSRF protection; JWTs mitigate CSRF but are vulnerable to XSS if stored in JavaScript. Use secure HTTP-only cookies for JWTs when possible.
JWT authentication in ASP.NET Core is configured with AddJwtBearer middleware; cookie authentication uses AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme).
Token expiration and refresh strategies are critical for JWT; with cookies, session expiration is server-controlled.

Common follow-up questions

How do you handle token refresh with JWT? Issue a short-lived access token and a longer-lived refresh token; when the access token expires, the client uses the refresh token to get a new access token without re-entering credentials.
Can you use both cookies and JWT together? Yes; store the JWT in an HTTP-only cookie so the browser sends it automatically, gaining JWT's stateless benefits with cookie's automatic transmission and XSS protection.
Why is revocation harder with JWT than cookies? JWTs are valid until expiration; to revoke early, you must maintain a blacklist or use a token version in your user record, defeating some stateless benefits.

137What is the difference between IMemoryCache and IDistributedCache?

Experienced

IMemoryCache stores objects in-process memory within a single application instance and offers the fastest access, but data is not shared across multiple server instances. IDistributedCache stores serialized data in an external store (Redis, SQL Server, or other backends) and is accessible across all instances in a distributed system, but with higher latency and serialization overhead.

How it works

IMemoryCache is an in-process cache that lives in your application's memory. When you store an object, it remains in RAM for the lifetime of that application instance. Retrieval is extremely fast because there's no network round-trip or deserialization. However, if your application restarts or if you're running multiple instances behind a load balancer, each instance has its own separate cache. This means cached data on Server A is invisible to Server B.

IDistributedCache abstracts over a remote cache store. The most common implementation uses Redis, but it can also use SQL Server, NCache, or custom implementations. When you store data, it's serialized (usually to JSON or binary) and sent over the network to the external store. All application instances connect to the same backend, so they share the same cached data. This makes it ideal for scaling horizontally, but introduces network latency and serialization costs.

Aspect	IMemoryCache	IDistributedCache
Storage Location	In-process memory (RAM)	External remote store (Redis, SQL, etc.)
Performance	Fastest; no network or serialization	Slower; includes network I/O and deserialization
Data Sharing	Not shared; each instance has its own cache	Shared across all application instances
Scalability	Poor for multi-instance deployments	Excellent for distributed/scaled systems
Memory Usage	Consumes application process memory	Offloaded to external service
Persistence	Lost on application restart	Can survive application restarts (depends on backend)

What is the difference between IMemoryCache and IDistributedCache diagram

Example

csharp

// IMemoryCache - single instance only
public class UserService
{
    private readonly IMemoryCache _memoryCache;

    public UserService(IMemoryCache memoryCache)
    {
        _memoryCache = memoryCache;
    }

    public async Task<User> GetUserAsync(int userId)
    {
        string key = $"user_{userId}";
        
        if (_memoryCache.TryGetValue(key, out User cachedUser))
            return cachedUser;

        var user = await FetchUserFromDb(userId);
        _memoryCache.Set(key, user, TimeSpan.FromHours(1));
        return user;
    }
}

// IDistributedCache - shared across instances
public class DistributedUserService
{
    private readonly IDistributedCache _distributedCache;

    public DistributedUserService(IDistributedCache distributedCache)
    {
        _distributedCache = distributedCache;
    }

    public async Task<User> GetUserAsync(int userId)
    {
        string key = $"user_{userId}";
        var json = await _distributedCache.GetStringAsync(key);
        
        if (json != null)
            return JsonSerializer.Deserialize<User>(json);

        var user = await FetchUserFromDb(userId);
        await _distributedCache.SetStringAsync(key, 
            JsonSerializer.Serialize(user), 
            new DistributedCacheEntryOptions 
            { 
                AbsoluteExpirationRelativeToNow = TimeSpan.FromHours(1) 
            });
        return user;
    }
}

The first example caches in-process and is only visible to that server instance. The second serializes to a distributed cache backend that all instances can access.

Key points to mention

Use IMemoryCache for single-server applications or for very fast, instance-local caching of non-critical data (like calculated UI state).
Use IDistributedCache in multi-instance deployments or when cache data must survive application restarts.
IDistributedCache requires external infrastructure (Redis, SQL Server) and adds network latency; don't over-engineer single-instance apps.
IMemoryCache can cause cache consistency issues in load-balanced scenarios if different instances have stale or different cached values.
You can layer both: use IDistributedCache for the authoritative store and IMemoryCache as a local L1 cache in front of it.

Common follow-up questions

How would you implement cache invalidation across multiple instances? (Answer: use a distributed cache event or pub/sub pattern with Redis; IMemoryCache has no cross-instance invalidation mechanism.)
When would you combine both IMemoryCache and IDistributedCache? (Answer: two-tier caching—IDistributedCache as the authoritative shared store, IMemoryCache as a local L1 cache for ultra-fast access to frequently requested items.)
What happens to IMemoryCache during a deployment or restart? (Answer: it's completely lost; use IDistributedCache if you need cache to survive application lifecycle events.)

145What is the difference between ConfigureAwait(false) and default awaiting?

Experienced

ConfigureAwait(false) tells the await expression to not capture and resume on the original synchronization context. The default behavior (no ConfigureAwait or ConfigureAwait(true)) captures the current context and resumes the continuation on that same context after the awaited task completes. In ASP.NET Core, this distinction matters less because there is no synchronization context by default, but it remains crucial in libraries, UI applications (WinForms, WPF), and anywhere a SynchronizationContext is active.

How it works

When you await a task, the runtime checks if a SynchronizationContext exists. If one does, the continuation (code after the await) is queued back to that context. This ensures thread affinity and is essential for UI frameworks that require all UI updates to happen on the UI thread.

ConfigureAwait(false) bypasses this mechanism. It tells the runtime: "I don't need to resume on the original context; use any available thread." This eliminates the overhead of context switching and prevents potential deadlocks caused by context capture.

In ASP.NET Core, the default SynchronizationContext is null, so ConfigureAwait(false) has minimal performance impact. However, in library code that may be consumed by Windows Forms or WPF applications, or in console apps where a custom context might be set, ConfigureAwait(false) is a best practice to avoid unnecessarily blocking the UI thread.

Example

csharp

// Library method – should use ConfigureAwait(false)
public async Task<string> FetchDataAsync()
{
    using var client = new HttpClient();
    var response = await client.GetAsync("https://api.example.com/data")
        .ConfigureAwait(false);
    
    var content = await response.Content.ReadAsStringAsync()
        .ConfigureAwait(false);
    
    return content;
}

// UI application – may omit ConfigureAwait(false) if UI updates needed
public async void OnButtonClick()
{
    var data = await FetchDataAsync(); // default: captures UI context
    MessageBox.Show(data); // safe to update UI
}

// ASP.NET Core – ConfigureAwait(false) is optional but recommended
public async Task<IActionResult> GetDataAsync()
{
    var data = await FetchDataAsync().ConfigureAwait(false);
    return Ok(data);
}

This example shows a reusable library method that uses ConfigureAwait(false) throughout, making it safe for any caller. The UI application omits it to maintain thread affinity for UI updates, and ASP.NET Core includes it as a best practice even though the context is typically null.

Aspect	Default await (no ConfigureAwait)	ConfigureAwait(false)
Context Capture	Captures current SynchronizationContext if present	Does not capture context
Continuation Location	Resumes on the same context thread	Resumes on any available thread from thread pool
Performance Overhead	Context switch cost (if context exists)	Minimal; avoids marshalling
UI Safety	Safe for UI updates (maintains thread affinity)	Not safe for direct UI updates unless marshalled back
Best Used In	UI applications (WinForms, WPF), code that updates UI	Libraries, service layers, ASP.NET Core, background tasks
Deadlock Risk	Higher if context is saturated and caller blocks	Lower; no context dependency

What is the difference between ConfigureAwait(false) and default awaiting diagram

Key points to mention

ConfigureAwait(false) is a best practice in library code and utility methods to avoid forcing callers into a specific thread context.
ASP.NET Core has no SynchronizationContext by default, so ConfigureAwait(false) has minimal performance benefit but is still recommended for consistency and portability.
Forgetting ConfigureAwait(false) in libraries can cause deadlocks if a synchronous caller blocks waiting for an async operation on a limited-capacity context (classic example: blocking on async in console apps with a custom context).
UI frameworks (WinForms, WPF) rely on the default behavior to ensure UI updates occur on the UI thread; omitting ConfigureAwait(false) is correct for UI code.
In modern .NET, consider using CancellationToken alongside ConfigureAwait for robust async patterns.

Common follow-up questions

Can ConfigureAwait(false) cause a deadlock? No; it actually prevents deadlocks by avoiding context starvation. However, the opposite (default await in saturated contexts) can cause deadlocks.
Should ASP.NET Core code always use ConfigureAwait(false)? While not strictly necessary (null context), it is still recommended as a defensive practice and for consistency when code may be reused in libraries.
How do I handle UI updates after ConfigureAwait(false)? Use Dispatcher.Invoke() or Control.Invoke() to marshal the update back to the UI thread if needed.

152What is the difference between lock and Monitor?

Experienced

lock is syntactic sugar over Monitor.Enter and Monitor.Exit wrapped in a try/finally block, providing a simpler, safer way to acquire mutual exclusion on an object. Monitor gives you more control over timing and behavior, including the ability to wait, pulse, and release with explicit method calls. Starting with .NET 9, the new System.Threading.Lock type offers a dedicated, faster locking primitive that avoids boxing and provides better performance than both.

How it works

When you write a lock statement, the compiler transforms it into calls to Monitor.Enter (acquiring the lock) and Monitor.Exit (releasing it) inside a try/finally block. This ensures the lock is always released, even if an exception occurs.

Monitor is a static class that provides low-level synchronization primitives. It can lock any reference type object and supports additional operations like Wait() (release the lock and wait for a signal), Pulse() (wake one waiting thread), and PulseAll() (wake all waiting threads). This makes Monitor suitable for producer-consumer patterns and more complex signaling scenarios.

System.Threading.Lock (.NET 9+) is a value type struct that wraps a dedicated internal lock mechanism. It avoids the overhead of boxing an object reference and provides faster acquisition and release. It supports EnterScope() which returns a disposable struct for use with the using statement, combining safety with performance.

Example

csharp

// Traditional lock (syntax sugar over Monitor)
object lockObj = new object();
lock (lockObj)
{
    // Critical section
    Console.WriteLine("Protected by lock");
}

// Equivalent to:
Monitor.Enter(lockObj);
try
{
    Console.WriteLine("Protected by Monitor");
}
finally
{
    Monitor.Exit(lockObj);
}

// .NET 9+ Lock type (faster, value-type)
System.Threading.Lock myLock = new();
using (myLock.EnterScope())
{
    Console.WriteLine("Protected by System.Threading.Lock");
}

The lock statement is the most common choice for straightforward mutual exclusion; Monitor gives you fine-grained control when you need Wait/Pulse signaling; the new Lock type is optimal for performance-critical code in .NET 9+.

Key points to mention

lock is compiler sugar that translates to Monitor.Enter/Exit in a try/finally, guaranteeing safe release
Monitor provides advanced operations (Wait, Pulse, PulseAll) for thread coordination, essential for producer-consumer and condition-based scenarios
System.Threading.Lock (.NET 9+) is a value-type alternative that avoids boxing overhead and delivers better performance than locking objects
All three are reentrant on the same thread; a thread can acquire the same lock multiple times if the lock tracks ownership
Choosing between them depends on your needs: simplicity (lock), signaling (Monitor), or raw performance (System.Threading.Lock)

Feature	lock	Monitor	System.Threading.Lock
Syntax	lock (obj) { }	Monitor.Enter/Exit	using (lock.EnterScope()) { }
Type	Reference type required	Reference type required	Value type (struct)
Wait/Pulse support	No (not directly)	Yes (Wait, Pulse, PulseAll)	No
Boxing overhead	Yes, if not using object	Yes, if not using object	None (value type)
Performance	Good	Good	Best (dedicated, .NET 9+)
Availability	.NET Framework 1.0+	.NET Framework 1.0+	.NET 9.0+

What is the difference between lock and Monitor diagram

Common follow-up questions

What happens if you try to lock on a null reference, or lock the same object from two different threads? (Null raises an exception; same object blocks until the first thread exits; see How do you investigate a deadlock or hang?)
Why would you use Interlocked over lock? (Interlocked operations are atomic without acquiring a full lock, better for simple value updates.)
Can lock be used with async/await? (No; lock blocks threads and cannot await inside it; use SemaphoreSlim or other async-safe primitives instead.)

173What is the difference between Clean Architecture and N-tier?

Experienced

Clean Architecture and N-tier are both layered approaches, but they differ fundamentally in dependency direction. In N-tier, layers depend downward on data access and infrastructure; in Clean Architecture, all dependencies point inward toward the domain core, keeping frameworks and databases at the outer edges as interchangeable details.

How it works

N-tier (typically Presentation → Business Logic → Data Access → Database) is a horizontal layering pattern where upper layers depend on lower layers. The business logic layer imports data access classes, which import database-specific libraries. This creates tight coupling to infrastructure and makes it difficult to swap implementations or test without a real database.

Clean Architecture inverts this dependency flow using the Dependency Inversion Principle. The domain layer (Entities and Use Cases) remains at the core and depends on nothing. Application services depend only on domain abstractions. Infrastructure adapters (repositories, API clients, database drivers) live at the outer circle and depend on interfaces defined by the core, not the other way around. This creates a testable, framework-agnostic business logic layer.

The key architectural advantage is testability and flexibility. In Clean Architecture, you test domain logic without mocking database calls because the domain knows nothing about persistence. You can replace SQL Server with PostgreSQL, REST with gRPC, or add new features without modifying core business rules.

Aspect	N-tier	Clean Architecture
Dependency Direction	Top-down (UI → Business → Data)	Inward-pointing (all toward domain core)
Database Coupling	Business logic depends on data access layer	Domain core independent; DB at edges
Testability	Requires mocks/stubs for infrastructure	Domain logic tests need no infrastructure
Framework Lock-in	Business logic imports ORM, EF DbContext	Core depends only on abstractions
Typical Layers	4–5 horizontal layers (strict order)	4 circles (Entities, Use Cases, Interface Adapters, Frameworks)
Complexity	Simpler for CRUD applications	Higher upfront cost; pays off in scale

What is the difference between Clean Architecture and N-tier diagram

Example

csharp

// Clean Architecture: Domain core (no dependencies)
public class Order
{
    public int Id { get; set; }
    public decimal Total { get; set; }
    
    public void ApplyDiscount(decimal percentage)
    {
        Total *= (1 - percentage / 100);
    }
}

// Use Case (Application layer)
public interface IOrderRepository
{
    Task SaveAsync(Order order);
}

public class PlaceOrderUseCase
{
    private readonly IOrderRepository _repo;
    
    public PlaceOrderUseCase(IOrderRepository repo) => _repo = repo;
    
    public async Task ExecuteAsync(Order order)
    {
        order.ApplyDiscount(10);
        await _repo.SaveAsync(order);
    }
}

// Infrastructure (outer layer) - EF repository implementation
public class EfOrderRepository : IOrderRepository
{
    private readonly DbContext _db;
    public EfOrderRepository(DbContext db) => _db = db;
    
    public async Task SaveAsync(Order order)
    {
        _db.Orders.Add(order);
        await _db.SaveChangesAsync();
    }
}

// Test: no database needed
[Test]
public async Task PlaceOrder_AppliesDiscount()
{
    var mockRepo = new Mock<IOrderRepository>();
    var useCase = new PlaceOrderUseCase(mockRepo.Object);
    var order = new Order { Total = 100 };
    
    await useCase.ExecuteAsync(order);
    
    Assert.That(order.Total, Is.EqualTo(90));
}

This example shows the domain Order class containing pure business logic with zero infrastructure knowledge, while the repository interface is defined by the use case and implemented by infrastructure—the dependency points inward.

Key points to mention

Dependency Inversion: Clean Architecture uses interfaces to flip dependency direction; business logic defines what it needs, infrastructure provides it.
Testability: Domain logic is trivial to unit test; you never need a test database in Clean Architecture.
Maintainability: Business rules stay isolated from framework changes (EF version bump, database migration, API protocol switch).
Framework Independence: Clean Architecture treats frameworks (ASP.NET, EF, logging) as plugins; N-tier embeds them in business logic.
Complexity Trade-off: N-tier is faster for small CRUD apps; Clean Architecture shines at domain-driven, enterprise-scale systems (see Domain-Driven Design in .NET terms).

Common follow-up questions

Isn't Clean Architecture overengineering for a simple CRUD API? — Yes, for simple projects N-tier may be faster. But consider: does your business logic ever change? If yes, Clean Architecture scales better.
How does Clean Architecture handle cross-cutting concerns like logging or transactions? — Use decorators, middleware, or aspect-oriented patterns at the adapter layer to keep the domain clean.
How does this relate to vertical slice architecture? — Vertical slice architecture organizes by feature rather than layer; it's an alternative to layering that can coexist with Clean Architecture principles.

177How do you validate requests with FluentValidation?

Experienced

FluentValidation allows you to define validation rules declaratively using a fluent API in separate validator classes, then execute them via dependency injection and either a MediatR pipeline behavior or an ASP.NET Core filter. This keeps validation logic out of your domain models and handlers, making it testable, reusable, and maintainable.

How it works

FluentValidation works by separating validation concerns from your business logic. You create a validator class that inherits from AbstractValidator<T> where T is the request or entity type you're validating. Inside the validator's constructor, you define rules using a fluent API: RuleFor(x => x.Property) chains methods like NotEmpty(), MaximumLength(), Matches(), and Custom() to express constraints.

When integrated with MediatR, you register validators and add a validation behavior to the pipeline. This behavior runs before your handler executes, collecting all validation errors into a ValidationException. You then map that exception to a standardized ProblemDetails response in your exception handler or middleware. This approach also works with ASP.NET Core model binding filters or custom middleware for non-MediatR scenarios.

Example

csharp

// Request/Command
public class CreateUserCommand
{
    public string Email { get; set; }
    public string Name { get; set; }
    public int Age { get; set; }
}

// Validator
public class CreateUserCommandValidator : AbstractValidator<CreateUserCommand>
{
    public CreateUserCommandValidator()
    {
        RuleFor(x => x.Email)
            .NotEmpty().WithMessage("Email is required")
            .EmailAddress().WithMessage("Email format is invalid");

        RuleFor(x => x.Name)
            .NotEmpty().WithMessage("Name is required")
            .MaximumLength(100).WithMessage("Name must not exceed 100 characters");

        RuleFor(x => x.Age)
            .InclusiveBetween(18, 120).WithMessage("Age must be between 18 and 120");
    }
}

// Register in Program.cs
builder.Services.AddValidatorsFromAssembly(typeof(Program).Assembly);
builder.Services.AddMediatR(config =>
{
    config.RegisterServicesFromAssembly(typeof(Program).Assembly);
    config.AddOpenBehavior(typeof(ValidationBehavior<,>));
});

// MediatR Pipeline Behavior
public class ValidationBehavior<TRequest, TResponse> 
    : IPipelineBehavior<TRequest, TResponse>
    where TRequest : notnull
{
    private readonly IEnumerable<IValidator<TRequest>> _validators;

    public ValidationBehavior(IEnumerable<IValidator<TRequest>> validators)
    {
        _validators = validators;
    }

    public async Task<TResponse> Handle(TRequest request, 
        RequestHandlerDelegate<TResponse> next, CancellationToken ct)
    {
        var context = new ValidationContext<TRequest>(request);
        var failures = (await Task.WhenAll(
            _validators.Select(v => v.ValidateAsync(context, ct))))
            .SelectMany(r => r.Errors)
            .Where(f => f != null)
            .ToList();

        if (failures.Count != 0)
        {
            throw new ValidationException(failures);
        }

        return await next();
    }
}

// Exception handler
app.UseExceptionHandler(exceptionHandlerApp =>
{
    exceptionHandlerApp.Run(async context =>
    {
        var exception = context.Features.Get<IExceptionHandlerFeature>()?.Error;
        
        if (exception is ValidationException vex)
        {
            context.Response.StatusCode = StatusCodes.Status400BadRequest;
            await context.Response.WriteAsJsonAsync(new ProblemDetails
            {
                Type = "https://example.com/problems/validation-error",
                Title = "One or more validation errors occurred.",
                Status = 400,
                Extensions = new Dictionary<string, object?>
                {
                    { "errors", vex.Errors
                        .GroupBy(e => e.PropertyName)
                        .ToDictionary(g => g.Key, g => g.Select(e => e.ErrorMessage).ToArray()) }
                }
            });
        }
    });
});

This example defines a validator for a user creation command, registers it with MediatR, injects it into a pipeline behavior that runs before the handler, and returns validation errors as a structured ProblemDetails response.

Key points to mention

Separation of concerns: Validators live in separate classes, keeping domain models and handlers clean and focused.
Reusability: A single validator can be used across MediatR handlers, API controllers, and background jobs by injecting it directly.
Composability: Validators can inherit from and compose other validators, and you can use Include() to reuse rule sets.
Async validation: Rules support MustAsync() and Custom() with async callbacks for database or external API checks.
Localization: Error messages are easily localized via resource files or message factories.

Common follow-up questions

How do you handle cross-property validation or conditional rules? Use RuleFor(x => x.Property).Must((model, value) => ...) or When() conditions to validate based on other property values.
Can you validate nested objects or collections? Yes, use RuleForEach(x => x.Items).SetValidator(new ItemValidator()) or RuleFor(x => x.Address).SetValidator(new AddressValidator()).
What's the difference between validation and enforcing aggregate invariants? Validation ensures input correctness (format, range); invariants ensure domain consistency (business rules, state transitions) and typically live in your aggregate or domain service.

191What is the difference between a mock, stub and fake?

Experienced

A stub returns predetermined canned data without verification, a mock verifies that specific methods were called with expected arguments, and a fake is a simplified but functional implementation that behaves like the real thing. These are all test doubles used in unit testing, but they serve different purposes: stubs isolate code by providing fixed responses, mocks ensure your code interacts correctly with its dependencies, and fakes replace expensive or complex components with lightweight working alternatives.

How it works

In unit testing, you often need to isolate the code under test from its external dependencies. Test doubles are stand-in objects that replace those dependencies. A stub is the simplest—it just returns hardcoded or predetermined values when called. It makes no assertions about how it was used; it simply responds. A mock goes further by recording method calls and allowing you to verify that the code under test interacted with it in a specific way—calling the right method with the right arguments in the right order. It fails the test if expectations are not met. A fake is a different animal altogether: it's a working implementation that behaves like the real dependency but in a simplified way. An in-memory database or a fake email service that writes to a list instead of actually sending emails are classic examples. Fakes are useful when you need more realistic behavior than a stub provides, but you can't use the real implementation in tests.

The choice between them depends on your testing goal. Use a stub when you need to control input. Use a mock when you need to verify interactions. Use a fake when you need realistic behavior at low cost.

Example

csharp

// Interface to test against
public interface IUserRepository
{
    Task<User> GetUserByIdAsync(int id);
    Task SaveUserAsync(User user);
}

// STUB: returns canned data, no verification
public class UserRepositoryStub : IUserRepository
{
    public Task<User> GetUserByIdAsync(int id) 
        => Task.FromResult(new User { Id = id, Name = "John Doe" });
    
    public Task SaveUserAsync(User user) => Task.CompletedTask;
}

// FAKE: working lightweight implementation
public class InMemoryUserRepository : IUserRepository
{
    private readonly List<User> _users = new();
    
    public Task<User> GetUserByIdAsync(int id) 
        => Task.FromResult(_users.FirstOrDefault(u => u.Id == id));
    
    public Task SaveUserAsync(User user)
    {
        _users.RemoveAll(u => u.Id == user.Id);
        _users.Add(user);
        return Task.CompletedTask;
    }
}

// MOCK: verifies interactions using Moq
[Fact]
public async Task UpdateUserProfile_ShouldCallSaveUser()
{
    var mockRepo = new Mock<IUserRepository>();
    mockRepo.Setup(r => r.GetUserByIdAsync(1))
        .ReturnsAsync(new User { Id = 1, Name = "John" });
    
    var service = new UserService(mockRepo.Object);
    await service.UpdateUserNameAsync(1, "Jane");
    
    // Verify SaveUserAsync was called exactly once with a user named "Jane"
    mockRepo.Verify(r => r.SaveUserAsync(It.Is<User>(u => u.Name == "Jane")), 
        Times.Once);
}

public class User { public int Id { get; set; } public string Name { get; set; } }
public class UserService 
{ 
    private readonly IUserRepository _repo;
    public UserService(IUserRepository repo) => _repo = repo;
    
    public async Task UpdateUserNameAsync(int id, string newName)
    {
        var user = await _repo.GetUserByIdAsync(id);
        user.Name = newName;
        await _repo.SaveUserAsync(user);
    }
}

This example shows a stub returning fixed data, a fake maintaining an actual in-memory list, and a mock using Moq to verify that SaveUserAsync was called with the correct user object.

Aspect	Stub	Fake	Mock
Purpose	Provide canned responses to isolate code under test	Replace real component with simplified working version	Verify interactions and method calls
Behavior	Returns hardcoded or predetermined values	Implements the interface realistically but simply (e.g., in-memory)	Records calls and can assert on them
Verification	None; stub doesn't track calls	Minimal; you might check final state but not call history	Full; verifies method calls, arguments, call count, order
Complexity	Very simple; just returns values	More complex; has logic and state	Complex; requires assertion framework like Moq
When to use	When you only need to control what a dependency returns	When you need realistic behavior but can't use the real implementation	When you need to ensure your code calls dependencies correctly
Example	A repository that always returns the same user	An in-memory database or in-memory cache	Verifying a service called repository.Save() exactly once

What is the difference between a mock, stub and fake diagram

Key points to mention

All three are test doubles: They replace real dependencies during testing to isolate the code under test and control its environment.
Stubs are passive: They respond but don't verify. Use them when you only care about what a dependency returns.
Mocks are active verifiers: They record and assert on interactions. Use them when behavior (how code interacts) matters as much as state.
Fakes are functional: They're real implementations that work correctly but in a simplified way. In-memory repositories and test email services are common examples.
Moq and NSubstitute are common frameworks: They make creating mocks easy in .NET by allowing setup, verification, and argument matching through fluent APIs.

Common follow-up questions

Should I always use mocks? No. Over-mocking leads to brittle tests that verify implementation details rather than behavior. Use stubs for simple isolation and fakes for realistic behavior. Reserve mocks for critical interactions you genuinely need to verify.
What's the difference between a mock and a spy? A spy is like a mock but wraps the real object, recording calls while still executing the real behavior. Mocks are pure test doubles; spies are partial test doubles.
How do fakes relate to integration tests? Fakes are ideal for unit tests because they're fast and deterministic. For integration tests, you might use real implementations or a containerized database. Fakes bridge the gap—more realistic than stubs, faster than real integration.

206What is the difference between framework-dependent and self-contained deployment?

Experienced

Framework-dependent deployment (FDD) publishes only your application code, assuming the .NET runtime is already installed on the target machine. Self-contained deployment (SCD) bundles the entire .NET runtime with your application, allowing it to run on systems without .NET pre-installed. The choice affects package size, deployment complexity, and portability.

How it works

In a framework-dependent deployment, the publish output contains only your compiled assemblies, configuration files, and dependencies. When the application runs, it requires the .NET runtime (matching or compatible version) to be present on the system. The operating system's PATH or global installation locations are searched for the runtime. This model is lighter and faster to publish, but creates a runtime dependency.

In a self-contained deployment, the publish output includes your code and the complete .NET runtime tailored for the target platform (Windows x64, Linux ARM64, macOS, etc.). The application launches with its bundled runtime, requiring no external .NET installation. This guarantees consistency across environments but increases package size significantly—often 60–100+ MB depending on trimming and platform.

Both deployment models are supported in modern .NET (6.0+). The choice is controlled in your project file via the <SelfContained> property and specified during dotnet publish.

Example

csharp

// .csproj configuration

// Framework-dependent (default for many scenarios)
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <SelfContained>false</SelfContained>
  </PropertyGroup>
</Project>

// Self-contained (includes runtime for Linux x64)
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <SelfContained>true</SelfContained>
    <RuntimeIdentifier>linux-x64</RuntimeIdentifier>
  </PropertyGroup>
</Project>

The first configuration publishes a smaller package that requires .NET 8 on the target machine; the second embeds the entire .NET runtime for Linux x64, enabling standalone execution.

Comparison

Aspect	Framework-Dependent (FDD)	Self-Contained (SCD)
Package Size	Small (5–50 MB typically)	Large (60–200+ MB with runtime)
Runtime Requirement	Must be pre-installed	Bundled; no pre-installation needed
Platform Specificity	Single build for compatible runtimes	Requires separate build per target OS/architecture
Deployment Speed	Fast (smaller transfer)	Slower (larger package to transfer)
Runtime Updates	Updated centrally on the machine	Each app must be republished to update runtime
Use Case	Internal servers, containers with .NET base images	Customer machines, isolated environments, offline deployment

What is the difference between framework-dependent and self-contained deployment diagram

Key points to mention

Framework-dependent is the default for many projects and assumes the target environment has .NET installed; ideal for controlled corporate environments and containerized deployments.
Self-contained guarantees portability but requires specifying a RuntimeIdentifier (e.g., win-x64, linux-arm64) and creates larger distributions.
Trimming and Ready-to-Run (R2R) compilation can reduce self-contained package size, though they introduce complexity and potential runtime behavior changes.
Security updates differ: framework-dependent apps benefit from centralized runtime patches; self-contained apps require redeployment for security fixes.
Containers typically use framework-dependent deployment layered on official .NET base images, keeping images lean and leveraging the host image's runtime.

Common follow-up questions

How does trimming reduce self-contained package size, and what are the risks?
When would you choose framework-dependent over self-contained, and why?
How do runtime identifiers (RIDs) affect multi-platform self-contained deployment?

208What is the difference between Task.WhenAll and Parallel.ForEach?

Experienced

Task.WhenAll awaits multiple async operations concurrently and returns when all complete, while Parallel.ForEach runs synchronous, CPU-bound work across multiple threads in a loop. Task.WhenAll is for I/O-bound async scenarios; Parallel.ForEach is for CPU-bound work. For async loops, use Parallel.ForEachAsync (.NET 6+) to get the best of both worlds with bounded concurrency.

How it works

Task.WhenAll accepts a collection of tasks and returns a single task that completes when all input tasks finish. It doesn't spawn new threads—it coordinates already-running async operations. If one task faults, the returned task faults with an AggregateException. It's ideal for I/O-bound work (HTTP requests, database calls) where threads are not blocked.

Parallel.ForEach is a thread-based parallelism construct that divides work across a thread pool. It blocks the calling thread until all iterations complete. The Parallel class uses work-stealing queues to balance load. It's designed for CPU-bound operations where you want true parallel execution on multiple cores.

Parallel.ForEachAsync (introduced in .NET 6) bridges the gap: it runs async work in a loop with bounded concurrency, respecting a MaxDegreeOfParallelism limit. This prevents thread starvation and resource exhaustion when awaiting thousands of I/O operations.

Example

csharp

// Task.WhenAll - for async I/O-bound operations
async Task FetchMultipleUrls(string[] urls)
{
    var httpClient = new HttpClient();
    var tasks = urls.Select(url => httpClient.GetAsync(url));
    var results = await Task.WhenAll(tasks);
    Console.WriteLine($"Fetched {results.Length} responses");
}

// Parallel.ForEach - for CPU-bound synchronous work
void ProcessLargeDataset(int[] data)
{
    Parallel.ForEach(data, item =>
    {
        var result = ExpensiveCalculation(item);
        Console.WriteLine(result);
    });
}

// Parallel.ForEachAsync - for async I/O in a loop with bounded concurrency
async Task FetchWithBoundedConcurrency(string[] urls)
{
    var httpClient = new HttpClient();
    await Parallel.ForEachAsync(urls, 
        new ParallelOptions { MaxDegreeOfParallelism = 5 },
        async (url, ct) =>
        {
            var response = await httpClient.GetAsync(url, ct);
            Console.WriteLine($"Fetched {url}: {response.StatusCode}");
        });
}

The first example fires many HTTP requests concurrently without blocking threads. The second uses all cores for intensive CPU calculations. The third limits concurrent HTTP requests to 5, preventing resource exhaustion.

Comparison table

Aspect	Task.WhenAll	Parallel.ForEach	Parallel.ForEachAsync
Use case	Awaiting multiple async operations	CPU-bound synchronous loops	Async loops with bounded concurrency
Threading	No new threads; coordinates existing tasks	Creates/reuses thread pool threads	Uses async/await; limited degree of parallelism
Blocks caller	No (async method awaits)	Yes (blocks until all iterations done)	No (async method awaits)
Concurrency limit	No built-in limit (starts all tasks immediately)	MaxDegreeOfParallelism controls thread count	MaxDegreeOfParallelism controls concurrent operations
Exception handling	AggregateException on any task fault	OperationCanceledException or AggregateException	AggregateException if any operation fails
Introduced	.NET 4.0	.NET 4.0	.NET 6.0

What is the difference between Task.WhenAll and Parallel.ForEach diagram

Key points to mention

Task.WhenAll is not blocking; it's an async coordination mechanism. The calling thread is released to handle other work while tasks run.
Parallel.ForEach is thread-based parallelism for compute-intensive work; using it for I/O-bound operations wastes threads and reduces scalability.
Parallel.ForEachAsync respects CancellationToken and allows graceful shutdown. Use it when you have 100+ async operations and need backpressure.
Task.WhenAll starts all tasks eagerly, which can overwhelm servers; consider semaphore-based throttling or Parallel.ForEachAsync for large batches.
Parallel.ForEach uses Environment.ProcessorCount by default; Parallel.ForEachAsync defaults to MaxDegreeOfParallelism = -1 (unlimited, but with async fairness).

Common follow-up questions

How do you handle exceptions from Task.WhenAll? – Wrap in try-catch; WhenAll throws AggregateException (or its inner exceptions in .NET 5+ with proper awaiting). Use Task.WhenAll(...).ConfigureAwait(false) in libraries to avoid deadlocks.
What is MaxDegreeOfParallelism = -1? – It means unlimited parallelism, but the scheduler respects async fairness; tasks don't actually run more concurrently than the thread pool allows. Set it to Environment.ProcessorCount for CPU-bound work or a smaller number (e.g., 5–10) for I/O-bound async to avoid thread starvation.
Should I use Task.Run with Task.WhenAll? – Only if you have synchronous CPU work that you want to parallelize; otherwise, you're wasting threads. Read more on Task.Run vs async/await patterns.

214What is the difference between AddScoped DbContext and a factory in Blazor Server?

Experienced

In Blazor Server, AddScoped DbContext lives for the entire circuit lifetime, which can cause stale data, memory leaks, and connection pooling issues. Use IDbContextFactory instead to create short-lived contexts per operation, ensuring fresh data and proper resource cleanup.

How it works

Blazor Server maintains a persistent WebSocket connection called a "circuit" for each connected user. When you register DbContext with AddScoped, the scope is tied to the circuit's lifetime—typically 30 minutes or longer. This means a single DbContext instance serves all database operations for that entire session.

The problem: DbContext maintains identity maps, change trackers, and connection state. A long-lived context accumulates stale entity instances, holds database connections longer than necessary, and can cause DbUpdateConcurrencyException when another user modifies the same data. Additionally, connection pooling becomes inefficient because connections aren't released promptly.

IDbContextFactory solves this by creating a new DbContext instance on-demand for each operation. Each context is immediately disposed after use, releasing connections back to the pool and clearing all tracked state. This mirrors desktop application patterns where contexts are typically short-lived.

Example

csharp

// Setup - AddScoped (problematic for Blazor Server)
services.AddDbContext<AppDbContext>(options => 
    options.UseSqlServer(connectionString));

// Setup - IDbContextFactory (recommended for Blazor Server)
services.AddDbContextFactory<AppDbContext>(options => 
    options.UseSqlServer(connectionString));

// Component usage with factory
@inject IDbContextFactory<AppDbContext> ContextFactory

@code {
    private List<Product> products = new();

    protected override async Task OnInitializedAsync()
    {
        // Create context, use it, dispose it immediately
        using var context = await ContextFactory.CreateDbContextAsync();
        products = await context.Products.ToListAsync();
    }

    private async Task UpdateProduct(int id, string name)
    {
        // Fresh context for each operation
        using var context = await ContextFactory.CreateDbContextAsync();
        var product = await context.Products.FindAsync(id);
        if (product != null)
        {
            product.Name = name;
            await context.SaveChangesAsync();
        }
    }
}

This example shows how the factory creates a fresh context for page initialization and again for the update operation, with automatic disposal ensuring connections return to the pool.

Key points to mention

Circuit lifetime vs. request lifetime: Blazor Server circuits persist across multiple user interactions, unlike HTTP request cycles. AddScoped binds to circuit scope, not request scope.
Connection pooling impact: Long-lived contexts hold connections unnecessarily. Factories ensure connections are returned promptly, improving throughput for other users.
Stale data risk: A retained DbContext caches entities in memory. If another user modifies data, your context won't see those changes without explicit refresh or AsNoTracking.
Async-friendly: CreateDbContextAsync() is available in EF Core 5+, allowing proper async initialization before use.
Consider DbContext pooling: Factories work well with pooling to reuse context instances efficiently without maintaining long-lived scopes.

Comparison: AddScoped vs. IDbContextFactory in Blazor Server

Aspect	AddScoped DbContext	IDbContextFactory
Lifetime	Circuit lifetime (30+ minutes)	Single operation (milliseconds)
Connection pooling	Holds connections; reduces pool availability	Releases connections immediately; better throughput
Stale data	High risk; cached entities not refreshed	Low risk; fresh context per operation
Memory usage	Grows over time; retains all tracked entities	Minimal; disposed after use
Dependency injection	Inject DbContext directly	Inject IDbContextFactory<DbContext>
Concurrency conflicts	More common due to stale state	Reduced; each operation starts fresh

What is the difference between AddScoped DbContext and a factory in Blazor Server diagram

Common follow-up questions

Can I use AddScoped in Blazor Server at all? – Yes, for stateless services or caching layers, but not for DbContext. The circuit scope is too long.
How does DbContext lifetime management differ in Blazor WebAssembly? – WebAssembly runs client-side and doesn't connect directly to databases, so it uses APIs instead. This question is Blazor Server-specific.
What about DbContext pooling? Can I use that with a factory? – Yes, AddDbContextFactory works with pooling via UseDbContextPool(), combining the benefits of short-lived contexts with instance reuse.

216What is the difference between AddTransient services that hold state and stateless services?

Experienced

Transient services that hold state create a new instance every time they are resolved, so each consumer gets its own isolated state—no sharing occurs. Stateless transient services do the same but avoid maintaining mutable fields, making them safe and predictable. The key difference is whether the service maintains instance-level data; stateless is preferred because it eliminates accidental state leaks and makes services thread-safe by design.

How it works

Transient services are instantiated fresh on every dependency injection resolution. If a transient service holds state (mutable fields or properties), each caller receives a new instance with its own copy of that state—no sharing between callers. However, this isolation does not protect you from other problems:

If the transient holds a reference to a disposable resource (like a database connection or HttpClient) resolved from the root service provider, that resource may not be disposed properly because transient instances are not tracked by the container.
State held in transient services can still cause confusion and bugs if the service is expected to be stateless by convention.
Stateless transient services are inherently thread-safe and easier to reason about, making them the recommended pattern in most scenarios.

For proper state management in ASP.NET Core, use scoped services that hold state (one per HTTP request) or explicit state objects. Reserve transient for lightweight, stateless utilities.

Example

csharp

// Stateful transient (problematic pattern)
public class StatefulLogger
{
    private List<string> _logs = new();
    public void Log(string message) => _logs.Add(message);
    public int LogCount => _logs.Count;
}

// Stateless transient (preferred)
public class StatelessLogger
{
    public void Log(string message) => Console.WriteLine(message);
}

// Usage
var services = new ServiceCollection();
services.AddTransient<StatefulLogger>();
services.AddTransient<StatelessLogger>();
var provider = services.BuildServiceProvider();

var logger1 = provider.GetRequiredService<StatefulLogger>();
var logger2 = provider.GetRequiredService<StatefulLogger>();
logger1.Log("First");
logger2.Log("Second");
Console.WriteLine(logger1.LogCount); // Outputs 1 (isolated state)
Console.WriteLine(logger2.LogCount); // Outputs 1 (isolated state)

var stateless1 = provider.GetRequiredService<StatelessLogger>();
var stateless2 = provider.GetRequiredService<StatelessLogger>();
// Both write to console; no state held anywhere

Each transient call gets a new instance, so the stateful logger's counts are never shared between logger1 and logger2. The stateless logger avoids the confusion entirely.

Key points to mention

Isolation by design: Transient state is never shared between consumers because each gets a new instance, but this does not make stateful transients a good practice.
Disposal risk: Transient instances holding disposable resources (connections, clients) may leak if not explicitly disposed by the caller.
Stateless is safer: Stateless transient services are thread-safe, predictable, and free from accidental state pollution—always prefer this pattern.
State belongs in scoped services: If you need request-scoped state, use AddScoped instead; the container tracks and disposes scoped instances properly.
Clarity over cleverness: A stateless transient service clearly communicates its intent and makes your dependency graph easier to understand and maintain.

Comparison table

Aspect	Stateful Transient	Stateless Transient	Scoped (with state)
Instance per resolution	New instance every time	New instance every time	One per scope (e.g., HTTP request)
State isolation	Each caller has own state; no sharing	No state to share	Shared within scope; isolated across scopes
Thread safety	Safe only if state not accessed concurrently	Always thread-safe	Safe within single-threaded request context
Disposal handling	Not tracked; caller must dispose	No resources to dispose	Automatically disposed by container
Best use case	Rare; avoid if possible	Utilities, helpers, loggers	Request-specific data, entity tracking
Recommended	❌ No	✅ Yes	✅ Yes (when state needed)

What is the difference between AddTransient services that hold state and stateless services diagram

Common follow-up questions

What happens if I inject a scoped service into a singleton? — See this question for a detailed explanation of the captive dependency problem.
How do I ensure a transient service is disposed properly? — Have the immediate consumer own and dispose it, or consider using a scoped lifetime if the resource needs container-managed cleanup.
Can I use a transient service to hold per-request state in ASP.NET Core? — No; use a scoped service instead, which is properly tracked and disposed by the container at the end of each HTTP request.

218How do you handle partial failures when calling several services?

Experienced

Handle partial failures by running service calls concurrently with timeouts, gracefully degrading non-critical responses, and returning composite results that distinguish between essential and optional data. This prevents a single slow or failing dependency from blocking the entire request, improves user experience, and maintains system resilience through strategic fallbacks and comprehensive logging with correlation IDs for debugging distributed issues.

How it works

When an application depends on multiple external services, any one can fail, timeout, or respond slowly. Rather than failing the entire request, you classify dependencies as critical or non-critical. Critical services must succeed; non-critical services can degrade. You execute calls concurrently to reduce latency, enforce timeouts to prevent indefinite blocking, and catch exceptions at the individual service level. For failed non-critical services, you return default or cached data. For critical services, you retry with exponential backoff or fail fast. All failures are logged with a correlation ID so you can trace the entire request flow across services. The response to the client includes both successful data and status indicators for degraded sections, allowing the UI to adapt.

This approach, sometimes called the bulkhead pattern combined with graceful degradation, prevents cascading failures and maintains partial availability. You might also use circuit breakers to stop hammering a failing service and caching to serve stale data when services are down.

Example

csharp

public class CompositeDataService
{
    private readonly HttpClient _httpClient;
    private readonly ILogger<CompositeDataService> _logger;
    private readonly string _correlationId;

    public CompositeDataService(HttpClient httpClient, ILogger<CompositeDataService> logger)
    {
        _httpClient = httpClient;
        _logger = logger;
        _correlationId = Guid.NewGuid().ToString();
    }

    public async Task<CompositeResponse> GetAggregatedDataAsync()
    {
        var response = new CompositeResponse { CorrelationId = _correlationId };
        var cts = new CancellationTokenSource(TimeSpan.FromSeconds(5));

        // Critical service – must succeed
        try
        {
            response.UserProfile = await FetchWithRetryAsync(
                "https://users-api/profile", 
                maxRetries: 3, 
                cts.Token);
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Critical service failed. CorrelationId: {Id}", _correlationId);
            return response; // Early return for critical failure
        }

        // Non-critical services – run concurrently, tolerate failures
        var recommendationsTask = FetchWithTimeoutAsync(
            "https://recommendations-api/items", 
            defaultValue: new List<string>(), 
            cts.Token);
        
        var analyticsTask = FetchWithTimeoutAsync(
            "https://analytics-api/stats", 
            defaultValue: new Analytics(), 
            cts.Token);

        try
        {
            await Task.WhenAll(recommendationsTask, analyticsTask);
            response.Recommendations = recommendationsTask.Result;
            response.Analytics = analyticsTask.Result;
        }
        catch (OperationCanceledException ex)
        {
            _logger.LogWarning(ex, "Non-critical services timed out. CorrelationId: {Id}", _correlationId);
            response.Recommendations ??= new List<string>();
            response.Analytics ??= new Analytics();
        }

        return response;
    }

    private async Task<T> FetchWithRetryAsync<T>(string url, int maxRetries, CancellationToken ct)
    {
        for (int i = 0; i < maxRetries; i++)
        {
            try
            {
                var result = await _httpClient.GetAsync(url, ct);
                result.EnsureSuccessStatusCode();
                return JsonSerializer.Deserialize<T>(await result.Content.ReadAsStringAsync(ct))!;
            }
            catch (Exception ex) when (i < maxRetries - 1)
            {
                _logger.LogWarning(ex, "Retry {Attempt} for {Url}. CorrelationId: {Id}", i + 1, url, _correlationId);
                await Task.Delay(TimeSpan.FromMilliseconds(Math.Pow(2, i) * 100), ct);
            }
        }
        throw new InvalidOperationException($"Failed after {maxRetries} retries: {url}");
    }

    private async Task<T> FetchWithTimeoutAsync<T>(string url, T defaultValue, CancellationToken ct)
    {
        try
        {
            var result = await _httpClient.GetAsync(url, ct);
            result.EnsureSuccessStatusCode();
            return JsonSerializer.Deserialize<T>(await result.Content.ReadAsStringAsync(ct))!;
        }
        catch (Exception ex)
        {
            _logger.LogWarning(ex, "Non-critical service failed, returning default. Url: {Url}, CorrelationId: {Id}", url, _correlationId);
            return defaultValue;
        }
    }
}

public class CompositeResponse
{
    public string CorrelationId { get; set; }
    public UserProfile UserProfile { get; set; }
    public List<string> Recommendations { get; set; }
    public Analytics Analytics { get; set; }
}

This example separates critical (UserProfile) and non-critical (Recommendations, Analytics) calls, retries critical ones, tolerates timeouts on optional ones, and logs all failures with a correlation ID for tracing across the distributed system.

Key points to mention

Classify dependencies: Distinguish between critical services (fail the request if they fail) and non-critical ones (degrade gracefully).
Concurrency and timeouts: Run independent calls in parallel with aggressive timeouts to avoid blocking the main thread indefinitely.
Correlation IDs: Attach a unique ID to every request so you can trace partial failures across multiple services in logs.
Retry strategies: Use exponential backoff for critical services; avoid retrying non-critical ones if they time out.
Caching and defaults: Return cached data or sensible defaults for non-critical failures rather than empty responses, improving perceived reliability.

Common follow-up questions

How do you implement a circuit breaker to prevent calling a failing service? – Use Polly or similar libraries to track failure rates and stop requests after a threshold is exceeded, allowing the service time to recover.
How does distributed tracing help with partial failures? – Distributed tracing captures request flows across all services, making it easy to see which dependency failed and when, correlating logs and metrics.
What's the difference between timeout and cancellation? – A timeout is a duration-based limit; cancellation is a signal you send via CancellationToken to stop work immediately, which is more graceful and allows cleanup.

219What is the difference between Results.Problem and throwing exceptions?

Experienced

Results.Problem returns a ProblemDetails response directly, making expected failures explicit and performant, while exceptions should be reserved for unexpected errors handled globally via middleware. Using Results.Problem is the modern, idiomatic approach in ASP.NET Core for handling validation and business logic failures as part of normal control flow, whereas throwing exceptions incurs stack unwinding overhead and obscures intent.

How it works

Results.Problem (introduced in .NET 6+) is a typed endpoint result that directly constructs and returns a standardized ProblemDetails response. It's part of the Result pattern family and represents expected, handled failures. When you return Results.Problem from an endpoint, ASP.NET Core immediately serializes it to JSON and sends it with the appropriate HTTP status code—no exceptions are thrown.

Exceptions, by contrast, are thrown when an unexpected error occurs. An exception unwinds the call stack, performs stack trace generation, and must be caught by global exception handling middleware (like UseExceptionHandler) to produce a response. This process is orders of magnitude slower than returning a result directly.

The key distinction is intent: Results.Problem signals "this is an expected outcome I'm handling"; exceptions signal "something went wrong that I didn't anticipate." Mixing them confuses maintainers and creates performance issues.

Example

csharp

// ❌ Anti-pattern: using exceptions for expected failures
app.MapPost("/orders/{id}", (int id, OrderService service) =>
{
    if (id <= 0)
        throw new ArgumentException("Invalid order ID"); // Stack unwinding overhead
    
    var order = service.GetOrder(id);
    if (order == null)
        throw new KeyNotFoundException("Order not found"); // More overhead
    
    return Results.Ok(order);
});

// ✅ Best practice: using Results.Problem for expected failures
app.MapPost("/orders/{id}", (int id, OrderService service) =>
{
    if (id <= 0)
        return Results.Problem(
            detail: "Order ID must be greater than zero",
            statusCode: StatusCodes.Status400BadRequest,
            title: "Invalid Input"
        );
    
    var order = service.GetOrder(id);
    if (order == null)
        return Results.Problem(
            detail: $"Order {id} not found",
            statusCode: StatusCodes.Status404NotFound,
            title: "Not Found"
        );
    
    return Results.Ok(order);
});

// Global exception handler for truly unexpected errors
app.UseExceptionHandler(errorApp =>
{
    errorApp.Run(async context =>
    {
        var exceptionHandlerPathFeature =
            context.Features.Get();
        
        context.Response.StatusCode = StatusCodes.Status500InternalServerError;
        await context.Response.WriteAsJsonAsync(new ProblemDetails
        {
            Title = "Internal Server Error",
            Detail = "An unexpected error occurred",
            Status = StatusCodes.Status500InternalServerError
        });
    });
});

The first endpoint throws exceptions for predictable validation failures, which is inefficient and obscures the happy path. The second returns Results.Problem for validation and business logic failures, then relies on global exception handling only for truly unexpected errors like null reference exceptions or database connection failures.

Key points to mention

Performance: Results.Problem avoids stack unwinding overhead; exceptions are 10–100× slower because they capture the entire call stack.
Intent clarity: Results.Problem makes it explicit that a failure is expected and handled; exceptions suggest something went wrong unexpectedly.
Standard compliance: Results.Problem produces standardized ProblemDetails (RFC 7807) responses consistently across your API.
Separation of concerns: Expected failures (validation, not found, conflict) return Results.Problem; unexpected failures (bugs, null refs, database crashes) throw exceptions caught by middleware.
Testability: Code that returns Results.Problem is easier to test—you check the result directly rather than catching exceptions.

Comparison table

Aspect	Results.Problem	Throwing Exceptions
Use case	Expected failures (validation, not found, conflict)	Unexpected errors (bugs, null refs, system failures)
Performance	Fast—no stack unwinding	Slow—captures full call stack
Intent	Clear: "I handled this"	Unclear: "Something went wrong"
Response format	Consistent ProblemDetails (RFC 7807)	Depends on global error handler
Handling	Returned directly from endpoint	Caught by global middleware
Testability	Easy—assert result type and status	Requires exception setup/assertions

What is the difference between Results.Problem and throwing exceptions diagram

Common follow-up questions

Should I ever throw exceptions in endpoints? No—throw only in service/domain logic for unexpected failures. Let middleware handle them globally to return a 500 ProblemDetails response.
What's the relationship between Results.Problem and validation filters? Validation filters often return Results.Problem before your endpoint runs; use them together to keep endpoints clean and consistent.
Can I customize ProblemDetails responses? Yes—use ProblemDetailsOptions in services.AddProblemDetails() to configure default titles, status codes, and custom mappers for exception types.

222What is the difference between workstation and server GC?

Expert

Workstation GC and Server GC are two distinct garbage collection modes in .NET. Workstation GC uses a single heap and is optimized for low-latency client applications, performing collections on the same thread that triggered allocation. Server GC creates one heap and dedicated GC thread per logical processor core, maximizing throughput for server workloads at the cost of higher memory consumption and latency variability.

How it works

In Workstation GC, there is one managed heap shared across all threads. When a collection is triggered, the application thread performing the allocation blocks until the GC completes, then resumes. This simplicity makes pause times predictable and memory overhead minimal—ideal for desktop and client apps where responsiveness matters more than raw throughput.

In Server GC, .NET allocates one heap per logical processor and assigns one GC thread per heap. Each thread allocates from its own heap without lock contention. When a collection is needed, dedicated GC threads work in parallel on their respective heaps, allowing application threads to continue running (mostly unblocked). This parallelism significantly increases throughput but introduces:

Higher memory footprint (more heaps = more metadata and reserved space)
Longer maximum GC pause times (coordinating across cores takes time)
Increased CPU usage during collections

You select the mode via the project file or runtime configuration. By default, .NET Framework uses Workstation GC, while .NET Core uses Server GC on multi-core systems. You can override with <ServerGarbageCollection>true</ServerGarbageCollection> in your .csproj.

Example

csharp

// Check which GC mode is active at runtime
using System;
using System.Runtime;

class Program
{
    static void Main()
    {
        bool isServerGC = GCSettings.IsServerGC;
        Console.WriteLine($"Server GC enabled: {isServerGC}");
        Console.WriteLine($"GC Latency Mode: {GCSettings.LatencyMode}");
        Console.WriteLine($"Processor count: {Environment.ProcessorCount}");
        
        // Trigger a collection and observe behavior
        GC.Collect();
        GC.WaitForPendingFinalizers();
    }
}
// Output on a 4-core machine with Server GC:
// Server GC enabled: True
// GC Latency Mode: Interactive
// Processor count: 4

This demonstrates how to detect which GC mode is active and check system configuration—essential for diagnosing performance issues in production.

Comparison Table

Aspect	Workstation GC	Server GC
Heap Count	One shared heap	One heap per logical core
GC Threads	Concurrent with application thread	Dedicated parallel threads (one per core)
Latency	Lower, more predictable pauses	Higher peak pause times, variable
Throughput	Lower (single-threaded collections)	Higher (parallel collections across cores)
Memory Usage	Minimal overhead	Higher (multiple heaps & metadata)
Best For	Client apps, UI, single/few cores	Server workloads, high-throughput services

What is the difference between workstation and server GC diagram

Key points to mention

Trade-off: Workstation prioritizes latency; Server prioritizes throughput. Choose based on your workload's sensitivity to pauses.
Default behavior: .NET Core automatically selects Server GC on multi-core machines unless explicitly disabled—you should verify this in production.
Allocation affinity: Server GC reduces lock contention by having threads allocate from their own heap, improving concurrent performance.
Memory overhead: Server GC typically consumes 20–40% more memory than Workstation GC due to per-core heap duplication and alignment.
Monitoring: Use GC metrics like Gen 2 collection frequency and pause time to validate your choice in production.

Common follow-up questions

"Can you mix Workstation and Server GC?" No—it is a process-wide setting. However, you can use object pooling and region-based allocation to reduce GC pressure regardless of mode.
"How does Server GC interact with CPU affinity?" Each GC thread is typically affinitized to a specific core for better cache locality, which is why it scales well on NUMA systems.
"What happens on a single-core machine with Server GC enabled?" Server GC will still create the infrastructure but will behave similarly to Workstation GC since there is only one core.

244What is the difference between Span<T> and Memory<T>?

Expert

Memory<T> is a heap-allocated, reference-counted wrapper around contiguous memory that can be used across async/await boundaries and method returns, whereas Span<T> is a stack-only value type that provides zero-allocation access to contiguous memory but cannot cross await points or be stored in fields. In practice, Memory<T> produces a Span<T> via .Span property when you need the performance benefits within a synchronous context.

How it works

Span<T> is a ref struct—a stack-only type that holds a pointer and length. Because it lives only on the stack and cannot be boxed or stored in heap objects, it enables the JIT to make aggressive inlining and bounds-check elimination optimizations. This makes Span incredibly fast for synchronous scenarios like parsing or array slicing.

Memory<T> is a regular struct that wraps an MemoryManager<T> (or ArrayPool-backed array) on the heap. Because it's heap-allocated, it can be stored in fields, passed across async boundaries, and used in collections. When you need the speed of Span within a synchronous block, you call memory.Span to get a Span view of that memory.

Think of it this way: Memory<T> is the owner of memory (with a defined lifetime), and Span<T> is a temporary view into that memory. You can create many Spans from one Memory, but only within the scope where the Memory is alive.

Example

csharp

// Memory<T> can be stored and used across async boundaries
async Task ProcessDataAsync(Memory<byte> buffer)
{
    // Within a synchronous context, convert to Span for performance
    Span<byte> span = buffer.Span;
    
    // Use span for fast, zero-allocation operations
    for (int i = 0; i < span.Length; i++)
    {
        span[i] = (byte)(span[i] * 2);
    }
    
    // Can await without Span (Memory is safe across await)
    await Task.Delay(100);
    
    // After await, can get a new Span view if needed
    span = buffer.Span;
}

// Span<T> cannot be stored in fields or used across await
// This does NOT compile:
// class BadDesign { Span<byte> field; }
// async Task BadAsync(Span<byte> span) { await Task.Delay(100); }

This example shows how ProcessDataAsync accepts a Memory<byte> (safe to pass to async), extracts a Span<byte> for efficient in-place operations, then awaits without the Span, and re-obtains a Span afterward if needed.

Aspect	Span<T>	Memory<T>
Storage	Stack only (ref struct)	Heap-allocated, reference counted
Can cross async/await	No—compiler error	Yes—safe across awaits
Can store in fields	No—ref struct restriction	Yes—regular struct
Performance	Highest—aggressive JIT optimizations	Good—one extra indirection to Span
Typical use	Synchronous parsing, slicing, tight loops	API boundaries, async methods, collections
Access pattern	Direct pointer + length	Call `.Span` to get Span view

What is the difference between Span<T> and Memory<T> diagram

Key points to mention

ref struct restriction: Span cannot be boxed, stored in object fields, or captured by closures. This is by design to enable JIT optimizations.
Memory is the bridge: Use Memory<T> at API boundaries and async methods; convert to Span internally for performance.
Zero allocation: Span itself is zero-cost (just a pointer + length on the stack), but Memory may allocate or use pooled arrays underneath.
Lifetime safety: Memory has a well-defined lifetime; Span is a temporary view that must not outlive the underlying buffer.
ArrayPool integration: Memory<T> works seamlessly with MemoryPool<T> and ArrayPool for efficient buffer reuse.

Common follow-up questions

Can you pass Span<T> to an async method? Why or why not?
How do you safely use Memory<T> with ArrayPool<T> to avoid buffer lifetime issues?
When would you choose Memory<T> over a simple array return type in an API?

269Compare database-per-tenant and shared-schema multi-tenancy.

Expert

Database-per-tenant allocates a separate database instance to each tenant, providing complete isolation, independent scaling, and simplified compliance auditing. Shared-schema multi-tenancy stores all tenants in a single database with a TenantId column filtering data at the query level, reducing infrastructure costs and operational overhead. The choice depends on tenant count, data isolation requirements, and budget constraints.

How it works

Database-per-tenant architecture provisions a dedicated database for each customer. The application resolves the correct connection string based on tenant context (subdomain, header, claims) and connects to that tenant's database. Schema migrations, backups, and scaling decisions can be made per-tenant independently. This model excels when you need strict data isolation, regulatory compliance (HIPAA, GDPR per-tenant audit trails), or expect highly variable workloads across tenants.

Shared-schema multi-tenancy uses a single database where all tables include a TenantId column or discriminator. A middleware or query filter intercepts all queries to automatically append WHERE TenantId = currentTenantId, preventing cross-tenant data leakage. This approach concentrates infrastructure but requires disciplined tenant filtering logic—a missing filter in any query can expose sensitive data to the wrong tenant.

Example

csharp

// Shared-schema: Query filtering via EF Core
public class TenantContext : DbContext
{
    private readonly string _tenantId;
    
    public TenantContext(string tenantId) => _tenantId = tenantId;
    
    public DbSet<Invoice> Invoices { get; set; }
    
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        // Automatically filter all Invoice queries by TenantId
        modelBuilder.Entity<Invoice>()
            .HasQueryFilter(i => i.TenantId == _tenantId);
    }
}

// Database-per-tenant: Connection resolution
public class TenantConnectionProvider
{
    private readonly IHttpContextAccessor _httpContextAccessor;
    private readonly Dictionary<string, string> _tenantConnections;
    
    public string GetConnectionString()
    {
        var tenantId = _httpContextAccessor.HttpContext?.User
            .FindFirst("tenant_id")?.Value;
        return _tenantConnections.TryGetValue(tenantId, out var conn) 
            ? conn 
            : throw new InvalidOperationException("Tenant not found");
    }
}

The first example uses EF Core's HasQueryFilter to enforce tenant isolation at the query level; the second resolves the correct database connection based on tenant claims in the JWT token.

Key points to mention

Isolation & compliance: Database-per-tenant guarantees physical separation, easing regulatory audits and customer concerns; shared-schema relies on application logic that must be bulletproof.
Cost & operations: Database-per-tenant requires more infrastructure, backup solutions, and migration management; shared-schema scales economically but concentrates "noisy-neighbor" risk (one tenant's heavy query impacts all others).
Migration complexity: EF Core migrations on database-per-tenant require orchestrating schema changes across many databases; shared-schema applies one migration to all tenants at once.
Query safety: Shared-schema demands tenant-filtering middleware or query filters on every DbSet; a single oversight (raw SQL, forgot HasQueryFilter) leaks data between tenants.
Tenant onboarding: Database-per-tenant requires provisioning a new database; shared-schema only needs inserting a row, enabling faster, cheaper tenant signup.

Comparison table

Criterion	Database-per-Tenant	Shared-Schema Multi-Tenancy
Data Isolation	Complete physical separation; no cross-tenant risk	Logical (query filters); vulnerable to implementation bugs
Infrastructure Cost	High; scales linearly with tenant count	Low; single database serves many tenants
Migration Management	Complex; must coordinate updates across multiple databases	Simple; one migration applies to all data
Tenant Onboarding	Slow; requires database provisioning and seeding	Fast; insert row and configure in seconds
Noisy-Neighbor Impact	Minimal; tenants have dedicated resources	High; one tenant's heavy queries affect all others
Compliance & Auditing	Per-tenant backups and audit logs; easier to prove isolation	Requires careful design; harder to demonstrate separation to auditors

Compare database-per-tenant and shared-schema multi-tenancy. diagram

Common follow-up questions

"How do you prevent query-filter bypasses in shared-schema?" — Use middleware to inject tenant context, enforce HasQueryFilter on all entities, audit raw SQL queries, and consider read-only contexts that reject unsupported operations.
"What hybrid approach exists?" — Many enterprises use database-per-region or per-tier: free/trial tenants share a database; enterprise customers get dedicated databases for compliance and performance guarantees.
"How do you handle reporting across all tenants?" — Database-per-tenant requires aggregating data from many sources; shared-schema can run a single query but must handle performance and cross-tenant security scans carefully.

274How do you design a reliable event-driven system with .NET?

Expert

A reliable event-driven system in .NET requires the outbox pattern for transactional event publishing, idempotent message consumers with inbox tables to prevent duplicate processing, exponential backoff retries, dead-letter queues for failed messages, schema versioning for backward compatibility, and distributed tracing to correlate events across services. This combination ensures exactly-once processing semantics, resilience to failures, and observability.

How it works

The outbox pattern solves the dual-write problem: instead of publishing an event to a message broker and updating your database in separate transactions, you write both the domain event and the event record to your database in a single transaction. A background worker then polls the outbox table and publishes events to the broker, ensuring no events are lost if the application crashes.

On the consumer side, an inbox table tracks processed message IDs. Before handling a message, you check if it already exists in the inbox—if it does, you skip processing (idempotency). After successful processing, you insert the message ID into the inbox within the same transaction as your business logic, guaranteeing exactly-once semantics even if a consumer crashes mid-processing.

Exponential backoff retries (e.g., 1s, 2s, 4s, 8s) prevent overwhelming downstream systems during transient failures. Messages that exhaust retries move to dead-letter queues for manual investigation. Schema versioning (versioning event payloads or using discriminated unions) allows services to evolve independently. Distributed tracing with correlation IDs ties all related events together across services, simplifying debugging.

Example

csharp

// Outbox pattern with Entity Framework Core
public class OrderCreatedEvent
{
    public Guid OrderId { get; set; }
    public decimal Amount { get; set; }
    public int Version { get; set; } = 1;
}

public class OutboxEvent
{
    public Guid Id { get; set; }
    public string EventType { get; set; }
    public string Payload { get; set; }
    public DateTime CreatedAt { get; set; }
    public bool Published { get; set; }
}

public class OrderService
{
    private readonly ApplicationDbContext _db;
    private readonly ILogger _logger;

    public async Task CreateOrderAsync(Order order)
    {
        using var transaction = _db.Database.BeginTransaction();
        
        // Update domain state
        _db.Orders.Add(order);

        // Write event to outbox (same transaction)
        var outboxEvent = new OutboxEvent
        {
            Id = Guid.NewGuid(),
            EventType = nameof(OrderCreatedEvent),
            Payload = JsonSerializer.Serialize(new OrderCreatedEvent 
            { 
                OrderId = order.Id, 
                Amount = order.Amount 
            }),
            CreatedAt = DateTime.UtcNow,
            Published = false
        };
        _db.OutboxEvents.Add(outboxEvent);
        
        await _db.SaveChangesAsync();
        await transaction.CommitAsync();
    }
}

// Outbox publisher (background worker)
public class OutboxPublisher : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            var unpublished = await _db.OutboxEvents
                .Where(e => !e.Published)
                .ToListAsync(stoppingToken);

            foreach (var evt in unpublished)
            {
                try
                {
                    await _messageBroker.PublishAsync(evt.EventType, evt.Payload);
                    evt.Published = true;
                    await _db.SaveChangesAsync(stoppingToken);
                }
                catch (Exception ex)
                {
                    _logger.LogError(ex, "Failed to publish event {EventId}", evt.Id);
                }
            }

            await Task.Delay(TimeSpan.FromSeconds(5), stoppingToken);
        }
    }
}

// Idempotent consumer with inbox
public class OrderProcessedEventHandler
{
    public async Task HandleAsync(OrderCreatedEvent evt)
    {
        if (await _db.InboxEvents.AnyAsync(e => e.MessageId == evt.OrderId))
            return; // Already processed

        using var transaction = _db.Database.BeginTransaction();
        
        // Process event
        var notification = new Notification { OrderId = evt.OrderId };
        _db.Notifications.Add(notification);

        // Record in inbox (atomically)
        _db.InboxEvents.Add(new InboxEvent { MessageId = evt.OrderId, ProcessedAt = DateTime.UtcNow });
        
        await _db.SaveChangesAsync();
        await transaction.CommitAsync();
    }
}

This code demonstrates the outbox pattern writing events and orders atomically, a background publisher moving events to the broker, and an idempotent handler using an inbox table to prevent duplicate processing.

Key points to mention

Outbox + Inbox: Guarantees exactly-once delivery and processing semantics, eliminating data loss and duplicate handling
Transactional consistency: Use database transactions to couple domain changes with event writes, preventing partial failures
Idempotent operations: Design consumers so replaying the same message produces the same result (same inbox record, no side effects)
Retry strategy with backoff and DLQ: Use exponential backoff for transient failures; move messages to dead-letter queues after max retries for manual intervention
Schema versioning and tracing: Version events in payloads; include correlation IDs in message headers to track causality across services

Common follow-up questions

How do you handle event schema evolution without breaking consumers? (Discriminated unions, versioned fields, or adapter patterns)
What's the difference between the outbox pattern and consuming directly from a queue, and when would you use each?
How do you implement distributed tracing and correlation IDs across async event chains? (OpenTelemetry, activity IDs in headers)

280How do you raise and dispatch domain events?

Expert

Direct answer: Domain events are raised by aggregates and stored in a collection, then dispatched after a successful transaction commit—typically via a SaveChanges interceptor, unit of work, or outbox pattern. The dispatcher (often MediatR or a custom event bus) publishes them to handlers, decoupling the domain model from infrastructure concerns.

How it works

Domain events represent something that has happened in your business domain and are central to Domain-Driven Design. Aggregates collect these events internally without immediately publishing them. When SaveChanges commits, an interceptor or unit of work extracts and dispatches them.

The pattern ensures two critical properties: atomicity (events are published only if the transaction succeeds) and isolation (handlers run outside the domain model, preventing cascading side effects). Most implementations use an outbox table—events are persisted alongside domain data, then a background job picks them up and publishes them reliably, even if the message broker is temporarily unavailable.

Example

csharp

// Domain event
public abstract class DomainEvent
{
    public DateTime OccurredAt { get; } = DateTime.UtcNow;
    public Guid AggregateId { get; protected set; }
}

public class OrderCreatedEvent : DomainEvent
{
    public OrderCreatedEvent(Guid orderId, string customerName, decimal total)
    {
        AggregateId = orderId;
        CustomerName = customerName;
        Total = total;
    }
    public string CustomerName { get; }
    public decimal Total { get; }
}

// Aggregate
public class Order
{
    private List<DomainEvent> _domainEvents = new();
    public Guid Id { get; private set; }
    public string CustomerName { get; private set; }
    public decimal Total { get; private set; }

    public static Order Create(Guid id, string customerName, decimal total)
    {
        var order = new Order
        {
            Id = id,
            CustomerName = customerName,
            Total = total
        };
        order._domainEvents.Add(new OrderCreatedEvent(id, customerName, total));
        return order;
    }

    public IReadOnlyList<DomainEvent> GetDomainEvents() => _domainEvents.AsReadOnly();
    public void ClearDomainEvents() => _domainEvents.Clear();
}

// SaveChanges interceptor (EF Core)
public class DomainEventDispatcherInterceptor : SaveChangesInterceptor
{
    private readonly IMediator _mediator;

    public DomainEventDispatcherInterceptor(IMediator mediator) => _mediator = mediator;

    public override async ValueTask<InterceptionResult<int>> SavingChangesAsync(
        DbContextEventData eventData, InterceptionResult<int> result, CancellationToken cancellationToken)
    {
        var aggregates = eventData.Context?.ChangeTracker
            .Entries()
            .Select(e => e.Entity)
            .OfType<Order>()
            .ToList() ?? new();

        var events = aggregates
            .SelectMany(a => a.GetDomainEvents())
            .ToList();

        return await base.SavingChangesAsync(eventData, result, cancellationToken);
    }

    public override async ValueTask<int> SavedChangesAsync(
        SaveChangesCompletedEventData eventData, int result, CancellationToken cancellationToken)
    {
        var aggregates = eventData.Context?.ChangeTracker
            .Entries()
            .Select(e => e.Entity)
            .OfType<Order>()
            .ToList() ?? new();

        var events = aggregates
            .SelectMany(a => a.GetDomainEvents())
            .ToList();

        aggregates.ForEach(a => a.ClearDomainEvents());

        foreach (var @event in events)
        {
            await _mediator.Publish(@event, cancellationToken);
        }

        return await base.SavedChangesAsync(eventData, result, cancellationToken);
    }
}

// Dependency injection
services.AddScoped<DomainEventDispatcherInterceptor>();
services.AddDbContext<OrderContext>((sp, options) =>
    options.AddInterceptors(sp.GetRequiredService<DomainEventDispatcherInterceptor>()));

This example shows an aggregate raising an event during creation, an interceptor collecting events after commit, and MediatR dispatching them to handlers—ensuring atomicity and clean separation of concerns.

Key points to mention

Transactional safety: Events are published only after the transaction commits, preventing orphaned handlers if the save fails.
Outbox pattern: For guaranteed delivery, persist events to an outbox table in the same transaction, then a background process publishes them—this survives application crashes.
Event ordering and idempotency: Handlers must be idempotent and process events in a predictable order, especially in distributed systems.
Decoupling: Aggregates don't reference handlers directly; MediatR or an event bus abstracts the dispatch, allowing handlers to be added or removed without changing the domain model.
Clear state after dispatch: Always clear the events collection after publishing to prevent re-dispatching on subsequent SaveChanges calls.

Common follow-up questions

How do you guarantee event delivery if the application crashes after commit but before dispatch? Use an outbox table in the same database transaction; a background job polls and publishes events reliably.
Should domain events be persisted separately, or is the aggregate history enough? Domain events should be persisted (often in an outbox or event store) for reliable delivery and audit trails, separate from the current aggregate state.
How do you handle eventual consistency when a handler fails? Implement retry logic in handlers, use a dead-letter queue, and ensure handlers are idempotent so replaying doesn't corrupt state.

307How do you prevent thundering herds after deployments or cache flushes?

Expert

Prevent thundering herds by combining cache warming before deployment, adding randomized jitter to expiration times, implementing request coalescing to batch backend calls, and rate-limiting concurrent requests during cold starts. These techniques ensure that when caches expire or services restart, traffic doesn't overwhelm backends with synchronized spike requests.

How it works

A thundering herd occurs when many cached items expire simultaneously or when a service restarts, causing all waiting requests to hit the backend at once. This creates a spike that can overwhelm databases, APIs, or external services, causing cascading failures.

Cache warming pre-populates critical data before deployment, so users never experience a cold cache. Jitter randomizes expiration times so expirations spread across a time window rather than clustering. Request coalescing (also called request deduplication) ensures multiple identical concurrent requests only hit the backend once, with results shared among waiters. Concurrency limiting uses semaphores or circuit breakers to throttle how many requests can reach the backend simultaneously during recovery.

Together, these create resilience: requests are served from warm caches, expirations are staggered, redundant work is eliminated, and surviving requests are paced to sustainable rates.

Example

csharp

public class ThunderingHerdPrevention
{
    private readonly IMemoryCache _cache;
    private readonly HttpClient _httpClient;
    private readonly SemaphoreSlim _backendLimiter;
    private readonly ConcurrentDictionary<string, TaskCompletionSource<string>> _inFlightRequests;
    private readonly Random _jitterRandom;

    public ThunderingHerdPrevention(IMemoryCache cache, HttpClient httpClient)
    {
        _cache = cache;
        _httpClient = httpClient;
        _backendLimiter = new SemaphoreSlim(10); // Max 10 concurrent backend calls
        _inFlightRequests = new();
        _jitterRandom = new Random();
    }

    public async Task<string> GetDataWithCoalescingAsync(string key)
    {
        // Check cache first
        if (_cache.TryGetValue(key, out string cachedValue))
            return cachedValue;

        // Request coalescing: multiple calls share one backend fetch
        if (_inFlightRequests.TryGetValue(key, out var existing))
            return await existing.Task;

        var tcs = new TaskCompletionSource<string>();
        if (!_inFlightRequests.TryAdd(key, tcs))
            return await _inFlightRequests[key].Task; // Race: another thread added it

        try
        {
            // Rate-limit backend access
            await _backendLimiter.WaitAsync();
            try
            {
                var result = await _httpClient.GetStringAsync($"/api/data/{key}");

                // Add jitter to expiration: base 5min ± 30sec
                int jitterMs = _jitterRandom.Next(-30000, 30001);
                var expiration = TimeSpan.FromMinutes(5).Add(TimeSpan.FromMilliseconds(jitterMs));

                _cache.Set(key, result, expiration);
                tcs.SetResult(result);
                return result;
            }
            finally
            {
                _backendLimiter.Release();
            }
        }
        catch (Exception ex)
        {
            tcs.SetException(ex);
            throw;
        }
        finally
        {
            _inFlightRequests.TryRemove(key, out _);
        }
    }

    public async Task WarmCacheAsync(IEnumerable<string> keys)
    {
        // Pre-populate cache before deployment
        foreach (var key in keys)
        {
            try
            {
                var data = await _httpClient.GetStringAsync($"/api/data/{key}");
                _cache.Set(key, data, TimeSpan.FromMinutes(5));
            }
            catch { /* Log and continue */ }
        }
    }
}

This example uses request coalescing so concurrent calls for the same key share one backend fetch, a semaphore to rate-limit backend concurrency, jitter to spread cache expirations, and a cache warming method to pre-load data at deployment time.

Key points to mention

Request coalescing deduplicates in-flight requests: multiple threads waiting for the same cache miss send only one backend call, dramatically reducing load spikes.
Jitter in expiration is crucial—use randomized time windows (e.g., base TTL ± random offset) so millions of items don't expire simultaneously.
Cache warming at deployment eliminates the cold-start problem entirely by pre-loading critical data before traffic arrives.
Concurrency limiting with semaphores or circuit breakers prevents backends from being overwhelmed even if jitter and coalescing fail.
Monitor cache hit rates and backend request spikes; tools like Application Insights help detect thundering herds early.

Common follow-up questions

What happens if a request times out while coalescing is waiting? How do you handle retry logic to avoid cascading failures?
How do you warm caches for millions of keys without causing a separate thundering herd during the warming phase?
How does this relate to cache stampedes, and when is one strategy preferred over another?

318What makes a senior .NET engineer different from a mid-level one?

Expert

A senior .NET engineer owns outcomes end-to-end—from design through production operations—rather than just writing code that passes review. They design for operability and change, mentor others actively, communicate trade-offs clearly, and critically, know when not to add complexity. The shift is from executing tasks to multiplying team effectiveness and architectural thinking.

How it works

The distinction is not about coding speed or knowing more APIs. A mid-level engineer excels at converting requirements into working code within their assigned scope. A senior engineer thinks about the entire lifecycle: How will this be monitored in production? How will the next engineer understand and modify this? What assumptions might break in two years? Will this scale operationally, or will it create on-call pain?

Seniors operate across multiple dimensions simultaneously. They mentor junior developers by reviewing code with teaching intent, not just approval authority. They influence architectural decisions by articulating trade-offs: "We could use Event Sourcing here, but it adds complexity to queries; let's use a simpler event log pattern instead." They communicate upward and laterally about risk, dependencies, and realistic timelines. They recognize that saying "no" to a feature—or "not yet"—is often the right call.

This requires deep systems thinking, emotional intelligence, and long-term perspective. Seniors have seen what happens when quick wins become maintenance nightmares. They've experienced the cost of poor observability, tight coupling, and over-engineered solutions. They apply this wisdom proactively.

Example

Consider a new caching requirement. A mid-level engineer implements it functionally:

csharp

// Mid-level: works, but ignores operability
public class ProductService
{
    private static Dictionary<int, Product> _cache = new();

    public Product GetProduct(int id)
    {
        if (!_cache.ContainsKey(id))
            _cache[id] = _db.Products.Find(id);
        return _cache[id];
    }
}

A senior redesigns for observability, invalidation, and team maintenance:

csharp

// Senior: owns operability and change
public class ProductService(IDistributedCache cache, IProductRepository repo, ILogger<ProductService> logger)
{
    private const string CacheKeyPrefix = "product:";
    private const int CacheDurationSeconds = 300;

    public async Task<Product> GetProductAsync(int id)
    {
        var cacheKey = $"{CacheKeyPrefix}{id}";
        var cached = await cache.GetStringAsync(cacheKey);
        
        if (cached != null)
        {
            logger.LogDebug("Cache hit for product {ProductId}", id);
            return JsonSerializer.Deserialize<Product>(cached)!;
        }

        var product = await repo.GetAsync(id);
        await cache.SetStringAsync(
            cacheKey,
            JsonSerializer.Serialize(product),
            new DistributedCacheEntryOptions { AbsoluteExpirationRelativeToNow = TimeSpan.FromSeconds(CacheDurationSeconds) }
        );
        
        logger.LogInformation("Product {ProductId} cached", id);
        return product;
    }

    public async Task InvalidateProductAsync(int id)
    {
        await cache.RemoveAsync($"{CacheKeyPrefix}{id}");
        logger.LogInformation("Cache invalidated for product {ProductId}", id);
    }
}

The senior version enables monitoring (logs), provides invalidation hooks, uses IDistributedCache (testable, scalable), documents assumptions via constants, and integrates with the team's observability stack. This reduces production surprises and on-call burden.

Key points to mention

Outcome ownership: Seniors are accountable for solutions working in production, not just passing code review. They engage with support, monitoring, and incidents.
Design for operability: Structured logging, instrumentation, graceful degradation, and clear failure modes are built in, not retrofitted.
Mentoring and multiplication: They scale impact by elevating others' capabilities through intentional teaching, code review guidance, and knowledge sharing.
Trade-off articulation: Seniors explain why they chose simplicity over features, sync over async, or a familiar pattern over a novel one—and stakeholders trust their reasoning.
Complexity discipline: The hardest skill is knowing when to reject a pattern, framework, or approach because it adds more risk than value. This requires confidence and perspective.

Comparison: Mid-level vs. Senior mindset

Dimension	Mid-Level Engineer	Senior Engineer
Scope	Assigned feature or module	End-to-end system behavior, team velocity, and production impact
Code review	Does this compile and pass tests?	Will this be maintainable in 18 months? How will we debug it? Is the person who wrote this learning?
Technology choice	Use the tool recommended or most popular	Evaluate fit for the problem, team skill, and operational cost; sometimes choose boring over exciting
Risk assessment	Identify obvious bugs	Identify failure modes, scaling limits, observability gaps, and cascading dependencies
Communication	Status updates and technical explanations	Articulate trade-offs to stakeholders, manage expectations, escalate risks early
Complexity response	Implement if asked; explore advanced patterns	Push back on complexity unless the problem demands it; advocate for simplicity

What makes a senior .NET engineer different from a mid-level one diagram

Common follow-up questions

How do you balance shipping speed with code quality and maintainability? (Seniors often slow down deliberately to avoid compound technical debt.)
How do you lead architectural decisions on a .NET team? (This tests whether you think systemically and involve others.)
Tell me about a time you said "no" to a feature request or technology proposal. What was your reasoning? (Demonstrates conviction and judgment under pressure.)

300+ .NET Interview Questions and Answers

How the questions are organized

Topics covered

How to use this guide

Go deeper on the blog

01What is .NET?

How it works

Example

Key points to mention

Common follow-up questions

Related interview questions

02What is the difference between .NET Framework, .NET Core and modern .NET?

How it works

Example

Key points to mention

Comparison table

Common follow-up questions

Related interview questions

Further reading

03What is the CLR?

How it works

Example

Key points to mention

Common follow-up questions

Related interview questions

Further reading

04What is IL (Intermediate Language)?

How it works

Example

Key points to mention

Common follow-up questions

Related interview questions

05What is JIT compilation?

How it works

Example

Key points to mention

Common follow-up questions

Related interview questions

Further reading

06What is an assembly in .NET?

How it works

Example

Key points to mention

Common follow-up questions

Related interview questions

07What is the Base Class Library (BCL)?

How it works

Example

Key points to mention

Common follow-up questions

Related interview questions

Further reading

08What is the .NET SDK vs the .NET runtime?

How it works

Example

Key points to mention

Common follow-up questions

Related interview questions

09What does the dotnet CLI do?

How it works

Example

Key points to mention

Common follow-up questions

Related interview questions

Further reading

10What is NuGet?

How it works

Example

Key points to mention

Common follow-up questions

Related interview questions

11What is a .csproj file?

How it works

Example

Key points to mention

Common follow-up questions

Related interview questions

12What is the difference between a value type and a reference type?

How it works

Example