354 .NET Developer Interview Questions & Answers

The .NET SDK is for building .NET applications, while the .NET runtime is for running compatible applications that are already built. The SDK includes development tools such as the dotnet CLI, compiler, build tools, templates, libraries, and a runtime. A developer machine or build server normally needs the SDK. A framework dependent application needs its compatible runtime on the target machine. A self contained application includes its required runtime, so that runtime does not need to be installed separately on the target machine.

The practical difference is simple. One package gives a developer the tools needed to create and prepare an application. The other provides what an already prepared application needs so it can run. A programmer normally installs the larger package because the programmer must create, check, and prepare the application. A computer that only runs the finished application may need only the smaller package. Some applications can also carry everything they need with them, so the destination computer does not need a separate installation.

1. Are you asking about framework dependent deployment or self contained deployment?
2. Should I also explain what belongs on developer machines and build servers?

The .NET SDK is the development package. It contains the tools needed to create, restore, compile, build, test, and publish .NET projects. Important parts include the dotnet CLI, the C# compiler, build tools based on MSBuild, project templates, reference libraries, and a .NET runtime. Because the SDK includes a runtime, a machine with the SDK can also run applications that are compatible with that included runtime.

The .NET runtime has a narrower job. It provides the execution components needed by a compatible application that is already built. It does not provide the complete development tool set that comes with the SDK. Installing only a runtime is therefore not the normal choice when a machine must compile source code or build a project.

A developer machine normally needs the SDK because developers create, compile, test, and publish projects. A build server also normally needs the SDK because it restores dependencies, compiles code, runs build steps, and produces published output.

Deployment changes what the target machine needs. A framework dependent application uses a compatible runtime or shared framework installed on the target machine. This usually keeps the published application smaller because the runtime is not copied into every application deployment.

A self contained application includes the required .NET runtime with its published files. The target machine does not need that runtime installed separately for that application. The tradeoff is a larger deployment because the application carries its runtime files.

In production, I would first ask whether the machine builds the application or only runs it. Then I would check whether the published application expects an installed runtime or includes its own runtime.

A common mistake is saying that the SDK and runtime are unrelated packages. The SDK includes a runtime in addition to development tools. Another mistake is saying that every production machine needs the SDK. A machine that only runs a framework dependent application normally needs the compatible runtime or shared framework required by that application, not the full SDK. Candidates also sometimes say that every .NET application requires a separately installed runtime. A self contained application includes its required runtime. Another mistake is assuming that installing only the runtime gives a machine the complete compiler and build tool set needed to build normal .NET projects.

Start with one clear sentence: the SDK is for building applications and the runtime is for running compatible built applications. Then explain developer machines, build servers, framework dependent deployments, and self contained deployments. Mention that the SDK includes a runtime so the relationship between the two is clear.

.NET Framework is Microsoft’s older platform for running managed apps on Windows. The CLR loads the assembly, JIT compiles the code, and the base class libraries provide common APIs. It matters because the runtime manages memory, types, and execution for you.

.NET Framework is Microsoft’s older system for building and running programs on Windows. It gives each program shared tools, helps it start, and watches over memory while it runs. The program does not do all of that work by itself. Instead, the system loads it, lets it use common code, and turns that code into something the computer can run. That is why many older business apps used it. It made development simpler, and it kept apps more consistent for teams.

1. Is this about a legacy Windows app?
2. Do you want a comparison with modern .NET too?

.NET Framework has three main parts that work together. First, your code is compiled into an assembly. That assembly contains intermediate language and metadata. Second, the CLR, which is the runtime, loads that assembly and manages execution. It JIT compiles methods into machine code when they are needed. It also runs garbage collection, handles exceptions, and checks type safety. Third, the base class libraries provide the reusable APIs that most apps need, such as collections, files, networking, strings, and XML.

Managed execution means the runtime takes care of important work instead of leaving everything to the app. That gives better safety and easier development. It also adds some cost, such as JIT time and garbage collection work, so there is a small performance tradeoff. In production, .NET Framework is still useful for older Windows only systems, especially when they depend on legacy libraries or frameworks. For new cross platform work, modern .NET is usually the better choice. So the key idea is simple: the compiler creates the assembly, the CLR runs it, and the base class libraries give it the tools it needs.

Mixing up .NET Framework with modern .NET. Thinking the CLR and the libraries are the same thing. Assuming code runs directly as machine code. Forgetting that it is Windows only and not the best choice for new cross platform work.

Start with the simple model: code is compiled into an assembly, the CLR runs it, and the base class libraries provide common services. Then mention why managed execution matters for memory, safety, and maintenance.

The CLR is the runtime engine for .NET. It loads compiled C# code, runs it, manages memory, and handles things like garbage collection and exception handling. C# is the language I write, and the CLR is the part that actually executes the code.

The CLR is the part of .NET that runs your program after it is built. It loads the program, starts it, keeps track of memory, and helps clean up things you no longer use. It also helps handle errors when something goes wrong. In simple terms, C# is the language you write, and the CLR is the engine that makes the app run. That is why the CLR matters when you think about how a .NET app behaves in real use.

1. Do you want the answer from a language view or a runtime view?
2. Should I also explain garbage collection and JIT?

The CLR, or Common Language Runtime, is the engine that runs managed .NET code. C# is only the language. When you compile C# code, you do not get native machine code right away in the usual sense. You get an assembly that the CLR loads and runs.

The CLR is responsible for several core jobs. It loads assemblies, verifies that the code is valid, and manages execution. It also provides memory management through garbage collection, which frees objects that are no longer used. This matters because it reduces manual memory work and helps prevent many memory bugs.

The CLR also handles runtime services such as exception handling, type safety, thread support, and just in time compilation. JIT compilation means code is turned into machine code while the app runs. That lets the runtime optimize based on actual execution.

A good way to explain the difference is this. C# is the language and syntax. The CLR is the runtime environment that makes the code run. In production, this matters because performance, memory use, and startup behavior all depend on the CLR, not just the C# source code. If you know that split, you understand how .NET apps really execute.

A common mistake is saying that C# itself runs the app. C# is the language, not the runtime. Another mistake is thinking the CLR only does garbage collection. It does much more, including loading code, execution, verification, and exception support. People also sometimes mix up compile time and runtime work.

Say the difference in one sentence first. Then name two or three CLR jobs, such as loading code, running it, and managing memory. Keep the focus on runtime behavior, not on C# syntax.

IL is the middle code that C# compiles to before .NET turns it into native machine code. It is not the final CPU code, but the form the CLR loads and then finishes at run time.

When C# code is built, it does not go straight to the final code that the computer runs. It first becomes a shared middle form that .NET can load and understand. That middle form is IL, which stands for Intermediate Language. It sits between your source code and the native machine code for the current CPU. This matters because the same assembly can move to another system, and the CLR can still finish the last step there at run time.

1. Do you want the build step or the run time step?
2. Should I also explain JIT compilation?

IL is the code that the C# compiler writes into an assembly after it compiles your source. The CLR does not execute C# directly. At run time, the CLR reads the IL and the JIT compiler turns that IL into native machine code for the current processor. That is why IL is the bridge between source code and machine code.

IL is useful because it keeps the .NET model portable and lets the runtime apply CPU specific work later. It also stores metadata, so the runtime knows about types, methods, and other details in the assembly. You normally do not write IL by hand in everyday C# work. You use it as the hidden output of compilation.

There are a few practical points to remember. IL is not the same as native code. It is still higher level than machine code, so it needs JIT compilation in the normal .NET model. In some publish modes, .NET can do more work ahead of time, but the basic idea is still that IL is the managed intermediate form between source code and execution. If you explain that flow clearly, you show that you understand both the language and the runtime.

A common mistake is to think .NET runs C# directly. Another mistake is to think IL is already native machine code. IL is the managed middle form, while machine code is CPU specific. People also forget that the JIT is the part that finishes the last step for the current platform.

Say that C# compiles to IL first, then the CLR JIT compiles IL to native machine code at run time. Keep the bridge idea clear and simple.

Managed code runs under the .NET runtime, while unmanaged code runs outside it as native code. In C#, the practical difference is that managed code gets garbage collection and runtime safety, while unmanaged code needs more manual care for memory and lifetime.

This question asks you to compare two kinds of C# programs. One kind runs with help from the .NET system, which watches memory and cleans it up for you. The other kind runs on its own as native code and must handle memory and safety more directly. In interviews, the main idea is knowing what C# normally gives you, what changes when you call native libraries, and why that matters for reliability and debugging. It also helps explain why some bugs are caught earlier and why some crashes are harder to control.

1. Do you want a C# example that calls a native library?
2. Should I explain unsafe code as well?
3. Do you want the production impact of interop?

In practice, C# code is managed code because it runs under the .NET runtime. The runtime loads the code, checks it, runs it, and cleans up memory with garbage collection. That gives you safety and less manual work.

Unmanaged code is code that runs outside the .NET runtime, usually as native code from C, C++, or an operating system library. It does not get garbage collection from .NET, so memory, handles, and object lifetime must be managed by that code or by the caller.

A simple example is a C# app that calls a native DLL through P/Invoke. The C# part stays managed, but the call crosses into unmanaged code for that work. That boundary matters because values may need marshalling, some objects may be pinned, and bugs in the native side can crash the whole process.

In production, managed code is the normal choice for business logic because it is safer and easier to maintain. Unmanaged code matters when you need an existing native library, device access, or very low level control. One important point is that unsafe code in C# does not make the program unmanaged. It only allows pointer style work inside managed code.

A common mistake is thinking unmanaged code means faster code in every case. Another mistake is thinking unsafe code in C# turns the whole program into unmanaged code. A third mistake is forgetting that native calls can add overhead and can fail in ways the runtime cannot fully protect you from.

Start with the practical rule: normal C# is managed, native code is unmanaged, and the main difference is who handles memory and safety.

A namespace in C# is a naming scope used to organize types such as classes, interfaces, structs, and enums and to reduce naming collisions. Two types can have the same simple name when they are in different namespaces. I can identify the intended type with its fully qualified name or an appropriate using directive. A namespace is not an assembly. A namespace organizes names, while an assembly is a compiled unit that the CLR can load.

A namespace gives related types a shared name so that a large program stays organized and different types can use the same simple name without conflicting. For example, Sales.Customer and Support.Customer can both exist because their full names are different. When code needs one of them, it can state which Customer it means. This is useful in large applications that use many libraries or have many development teams. A namespace organizes names in code. It does not create a separate program, file, memory area, or deployment unit.

1. Would you like me to explain how namespaces differ from assemblies?
2. Should I show how C# resolves two types with the same simple name?

In C#, a namespace is part of the full name used to identify a type. For example, Sales.Customer and Support.Customer are different type names even though both types have the simple name Customer. This helps prevent naming collisions.

A namespace declaration places types inside that naming scope. C# also supports file scoped namespace syntax, which applies a namespace to declarations in that source file.

A using directive can let source code refer to a type by a shorter name. It does not load a namespace into memory or copy its contents. If two available namespaces contain a Customer type and the compiler cannot determine which one is intended, the reference is ambiguous. The code can resolve this by using a fully qualified type name such as Sales.Customer or by using an alias.

A namespace is different from an assembly. A namespace organizes type names. An assembly is a compiled deployment and loading unit containing metadata and code. One namespace can contain types from multiple assemblies, and one assembly can contain types from multiple namespaces.

Namespace names also do not have to match folder or project names. Matching them is a useful convention, not a C# requirement. Namespaces have no meaningful per access performance or memory cost. They should not be treated as security, deployment, or runtime isolation boundaries.

A common mistake is saying that a namespace is a compiled file or physical container. It is a naming scope. Another mistake is assuming that one namespace belongs to exactly one assembly. A namespace can contain types from multiple assemblies, and an assembly can contain types from multiple namespaces. Developers also sometimes think a using directive loads a namespace into memory. It does not. It affects how names are resolved in source code. Another mistake is assuming namespace names must match folders or project names. That is a convention, not a C# requirement.

Start by saying that a namespace organizes type names and reduces naming collisions. Give a simple example such as Sales.Customer and Support.Customer. Then make the important distinction that namespaces organize names while assemblies are compiled units loaded by the CLR. Mention that using directives can shorten type references but do not load namespaces at runtime.

An assembly is a compiled unit of managed .NET code that the runtime can identify and load. It usually contains Intermediate Language code, type metadata, an assembly manifest, and optional resources. The manifest gives the assembly its identity and records information such as referenced assemblies. In normal managed applications, assemblies are commonly stored in DLL files. This matters for references, loading, deployment, and versioning, although modern publishing options can change how those assemblies appear in the final deployed files.

An assembly is a package produced when managed .NET code is built. Think of it as a container that holds program instructions and information describing those instructions. It gives .NET a clear identity for compiled code and tells the runtime what types and other compiled parts are available. Assemblies also help projects refer to compiled libraries. In a normal deployment, they are commonly present as DLL files. Modern publishing can package or transform the application differently, so one assembly does not always mean one visible deployed file.

1. Would you like me to focus on assembly contents, loading behavior, or deployment and versioning?
2. Should I also explain how assembly versions differ from NuGet package versions and file versions?

In managed .NET, an assembly is a compiled unit that the runtime can identify and load. It is commonly stored in a Portable Executable file with a DLL extension. Some older or specialized managed assemblies can use an EXE extension, while modern SDK applications often use a managed DLL together with a separate native application host.

A managed assembly contains Common Intermediate Language instructions for compiled methods, metadata describing types and members, and an assembly manifest. The manifest describes the assembly itself. It includes its identity and information such as its name, version, culture when applicable, and references to other assemblies. An assembly can also contain embedded resources.

A C# class library project commonly produces one assembly. Another project can reference that assembly and use accessible types from it. At runtime, .NET resolves and loads required managed assemblies. AssemblyLoadContext provides loading boundaries and custom loading behavior for cases such as plugin systems.

Assemblies affect deployment because build and publish tooling determines which application assemblies and dependency assemblies are needed in the output. They affect versioning because an assembly has an assembly version, but that value is separate from a NuGet package version and a file version.

A key limitation is that modern deployment can change the physical representation. Single file publishing can bundle assemblies, trimming can remove unused code, and Native AOT can compile managed code ahead of time into native code. Therefore, an assembly is an important managed code and runtime concept, but it should not always be described as one physical file that must appear unchanged in production.

A common mistake is saying that an assembly is simply a DLL file. DLL is a common physical form, but the assembly is the managed compiled unit described by its metadata and manifest. Another mistake is treating an assembly version as the same thing as a NuGet package version or file version. Candidates also sometimes confuse an assembly with a namespace. A namespace organizes type names, while an assembly is a compiled unit with its own identity. Another mistake is assuming that every assembly must appear as one separate file in production. Single file publishing, trimming, and Native AOT can change the final deployment layout. It is also incorrect to assume that changing an assembly version alone controls package restore or automatically downloads a different dependency.

Start by saying that an assembly is a compiled managed code unit that .NET can identify and load. Then name its main contents: Intermediate Language code, metadata, the manifest, and optional resources. Connect the manifest to assembly identity and references. Finish by explaining that assembly versioning is different from NuGet package versioning and that modern publishing can change the physical deployment layout.

Value types keep the actual data, so assignments and method calls copy the value. Reference types keep a reference to an object, so assignments and method calls copy the reference, not the whole object. In practice, that means two value variables are separate copies, while two reference variables can point to the same object.

In C#, these two kinds of data behave differently when you copy them or pass them into a method. One kind carries its own data, so each copy is separate. The other kind points to one shared object, so different variables can still refer to the same thing. That matters because a change in one place may stay local for one kind, but can be seen from another variable for the other kind. This choice affects bugs, memory use, and how easy the code is to reason about.

1. Do you want me to compare structs and classes too?
2. Should I include how ref changes method calls?

In C#, value types and reference types differ mainly in what gets copied.

A value type stores the value itself. Common examples are int, bool, double, enum, and struct. When you assign one value variable to another, C# copies the data. When you pass it to a method, the method gets a copy too unless you use ref, in, or out.

A reference type stores a reference to an object. Common examples are class, string, array, delegate, and interface instances. When you assign one reference variable to another, C# copies the reference. Both variables can point to the same object. If the object is mutable, a change through one variable is visible through the other.

This is why people often say value types give value semantics and reference types give shared object semantics. But the old stack versus heap shortcut is not the full rule. A value type can still be inside a heap object, and a reference variable can live on the stack as a local. The important rule is copy behavior and object sharing.

In production, I choose a value type for small, simple data that should behave like a copy. I choose a reference type when I want shared state, inheritance, or I want to avoid copying a larger object. I also watch out for large structs because copying them can cost more than people expect.

A common mistake is thinking value types always mean stack and reference types always mean heap. Another mistake is assuming assignment copies the whole object for classes. People also forget that strings are reference types but are immutable, so changing a string usually creates a new value. Another common bug is expecting a method to change the caller variable when the parameter was passed by value.

Say the copy rule first. Then give one example for a value type and one for a reference type. Finish by explaining what happens in a method call, because that is where the difference becomes clear.

Boxing is when C# converts a value type into an object. Unboxing is when I cast that object back to the original value type. Boxing creates a heap object and copies the value, so I try to avoid it in hot code when I can.

This question is asking how C# turns a simple value, like an int, into a general object, and how it turns it back again. The important part is that the value is copied when it is boxed, so the runtime creates extra work and uses extra memory. When it is unboxed, the value must be cast back to the exact original type. I would explain that this matters in real programs because repeated boxing can slow code down and create garbage.

1. Do you want the answer focused on object boxing or interface boxing?
2. Should I explain the performance impact in real code?

Boxing happens when a value type is converted to object or to an interface type. The CLR creates a new object and copies the value into it. Unboxing is the reverse. You cast the object back to the original value type, and the runtime checks the stored type first. If it does not match, you get InvalidCastException.

The important part is cost. Boxing makes an allocation and a copy. Unboxing copies the value back out. That is usually fine for small, rare cases, but it can matter in loops, logging paths, or code that handles many values. It also changes behavior because you are working with a copy, not the original value.

In practice, I avoid boxing with generics, for example List<int> instead of List<object>. That keeps values unboxed and reduces garbage. I only box when I need to use an API that requires object or an interface and the cost is acceptable.

O(1) per boxing or unboxing, but boxing creates a heap allocation and a copy.

A common mistake is thinking boxing is free. Another is forgetting that boxing makes a copy, so later changes to the original value do not change the boxed object. A third mistake is trying to unbox to the wrong type, which throws InvalidCastException. People also box too much in loops when a generic type would avoid the cost.

Say the simple rule first. Boxing converts a value type to object or an interface and allocates. Unboxing casts it back and must match the original type. Then mention the performance cost and a generic alternative.