354 .NET Developer Interview Questions & Answers

Explicit typing is the clearest choice. var lets the compiler infer the type at compile time, so the value is still strongly typed. dynamic skips compile time member checks and waits until runtime, so it is more flexible but less safe.

At a simple level, this question asks how C# chooses the type of a value. With explicit typing, I write the type myself. With var, the compiler figures out the type from the right side at compile time, but the type is still fixed. With dynamic, the compiler does not check the member access until runtime. So var is still strongly typed, while dynamic delays checks until the app runs. The choice matters for readability, safety, and errors you want to catch early.

1. Are we using this in a normal app or a library?
2. Do we need runtime flexibility from COM, JSON, or scripting?

In C#, explicit typing means I write the type, like int count = 10. var means the compiler infers the type from the initializer, so var count = 10 is still an int. The type is known at compile time and cannot change later. dynamic is different. It skips compile time member checking and asks the runtime to resolve members and operations. For example, dynamic value = "abc"; value.Length works, but value.NoSuchMember throws only when the code runs.

So var is for reducing noise when the type is obvious, especially with LINQ or anonymous types. Explicit typing is best when the type improves clarity, public APIs, or maintenance. dynamic is for rare cases where the real type is not known until runtime, such as COM interop, some reflection heavy code, or code that talks to flexible objects.

In production, I prefer explicit typing first, var second, and dynamic only when there is a real runtime need. var has no runtime penalty because it is just compile time inference. dynamic adds runtime binding cost and removes compile time safety, so mistakes show up later. The main rule is simple: var keeps strong typing, dynamic does not.

A common mistake is thinking var means weak typing or dynamic. It does not. The compiler still knows the exact inferred type. Another mistake is using dynamic for normal code just to write less syntax. That hides errors until runtime and makes maintenance harder.

Say var is compile time inference, dynamic is runtime binding, and explicit typing is best when the type helps readers understand the code quickly.

Nullable value types let a C# value type such as int, decimal, or DateTime represent either a normal value or no value. I write int? as shorthand for Nullable<int>. I normally test for null, use pattern matching, check HasValue, or use operators such as ?? before I depend on the contained value. This is useful when zero, false, or a default date could be a valid value and therefore should not mean missing.

Sometimes an application needs to show that a number, date, or true or false value is missing. Using zero, false, or an ordinary date value to mean missing can be wrong because each may also be real data. C# lets these kinds of values represent either a real value or nothing. For example, an optional age can contain 35 or contain no age. This keeps missing information separate from normal values and makes the meaning of stored or received data clearer.

1. Do you want me to explain how nullable values are represented internally?
2. Should I also cover operator behavior and boxing?

A nullable value type is represented by System.Nullable<T>. The type argument T must be a value type that is not itself nullable. C# provides shorter syntax, so int? means Nullable<int> and DateTime? means Nullable<DateTime>.

Nullable<T> has two important properties. HasValue reports whether a value is present. Value returns the contained value when one is present. Reading Value when HasValue is false throws InvalidOperationException. GetValueOrDefault returns the contained value when present. Otherwise, it returns the default value of T. In normal code, a null test, pattern matching, ??, or GetValueOrDefault can make the intended behavior clearer than reading Value directly.

Nullable value types matter because a default value is not the same as missing data. Zero can be a valid integer. False can be a valid Boolean result. A DateTime can also contain its default value. Using int?, bool?, or DateTime? lets the program represent absence without reserving one ordinary value as a special marker.

Many operators that work on value types have lifted forms for nullable operands. For arithmetic such as nullable integer addition, if an operand is null, the result is null. Nullable comparisons follow their defined C# rules, so null must not be treated as if it were an ordinary number.

Nullable<T> is still a value type. Assigning it to another variable copies its state. It does not require a separate managed heap object merely because it is nullable. Its storage includes the underlying value and state that records whether a value is present, with exact size and padding depending on the type and runtime layout.

Boxing has special behavior. If a nullable value has a value, boxing produces a boxed instance of the underlying T value. If it has no value, boxing produces a null reference.

In production, nullable value types are useful for optional database values, dates, measurements, identifiers, and other business data where absence is different from an ordinary default value.

A common mistake is using the default value of a value type to mean missing. Zero, false, and a default DateTime can all be legitimate values. Another mistake is reading Value without first knowing that a value exists, which can throw InvalidOperationException. Developers may also assume Nullable<T> is a reference type because it can represent no value, but Nullable<T> is a value type. Another mistake is assuming boxing preserves Nullable<T> as the boxed runtime type. A nullable value with data boxes as its underlying value type, while a nullable value without data boxes to null.

Start by saying that T? lets a value type represent either a real value or no value. Then explain that it is shorthand for Nullable<T>. Use a simple example such as int? age, explain safe access, and finish with the practical reason: an ordinary default value may be valid data and should not automatically mean missing.

Static members belong to the type and are shared. Instance members belong to each object and can hold separate state. I use static for shared helper logic or shared data, and instance members when each object needs its own values.

This question asks whether a value belongs to the whole type or to one created object. A shared value is the same for every object. A private value belongs to only one object, so it can be different each time. That choice matters because shared data behaves the same for everyone, while per object data can change from one object to another. In C#, that affects design, state, and how you avoid bugs in code that runs many times.

1. Should this value be shared by every object?
2. Should each object keep its own copy?

Static members belong to the type itself. You can use them without creating an object. Instance members belong to one specific object, so you must create that object first. In C#, a static method or static property can only use other static members directly, because it does not have a current object to work with.

This difference matters in design. Use static for logic that does not depend on one object, such as a helper method, a shared lookup, or a factory method. Use instance members when the data changes from object to object, such as a user name, an account balance, or request data. Static mutable state can be risky in production because every thread and every request sees the same data. That can create hidden bugs and make tests harder to trust. Instance state is easier to reason about when each object should stay independent.

A simple rule is this. If the value belongs to the type, make it static. If the value belongs to one object, make it an instance member.

A common mistake is to use static for data that should be different for each object. Another mistake is to assume a static method can read instance members directly. It cannot, because there is no current object. People also forget that static mutable fields are shared, so one change can affect every caller. That can make tests flaky and production bugs hard to trace.

Say that static means one shared copy for the type, while instance means one copy per object. Then give one real example of each and mention the shared state risk.

Use const when the value is known at compile time and is truly fixed. Use readonly when the value should not be reassigned after initialization but must be chosen at runtime. A const field is implicitly static, so one constant belongs to the type. An instance readonly field belongs to each object and can receive a different value in that object's constructor.

Use const when a value is completely fixed before the program runs and can be written as a C# constant. Use readonly when the value must stay fixed after setup but can be decided while the program is running. For example, a fixed retry count that is part of the program definition can be const. A name supplied when an object is created can be readonly. This matters because const gives one type level value known during compilation, while an instance readonly field lets every object keep its own value after construction.

1. Should I explain both instance readonly fields and static readonly fields?
2. Would you like me to cover the versioning difference caused by const values being copied into compiled calling code?

In C#, const means the value must be a compile time constant. A const field must be assigned where it is declared. It is implicitly static, so it belongs to the type rather than to each object. Code that uses a const value normally has that value placed into the compiled calling code. This matters when a public constant is changed in a library because existing callers may need to be recompiled before they use the new value.

readonly is different because its value can be established at runtime. An instance readonly field can be assigned where it is declared or inside an instance constructor of the same class. Different objects can therefore receive different values. After construction, normal code cannot assign another value to that field.

A static readonly field also belongs to the type, but its value can be created at runtime. It can be assigned where it is declared or inside the static constructor of the same class.

const supports only types and values that C# allows as constants. readonly fields can use normal field types, including reference types and values created at runtime. readonly restricts assignment to the field itself. If a readonly field stores a reference to a mutable object, the object can still change internally because the field continues to hold the same reference.

In production code, const is best for values that are genuinely permanent parts of the program definition. readonly is safer when initialization depends on runtime information or when a shared library value may change between releases. Neither choice creates a meaningful asymptotic performance or memory complexity difference for this question.

A common mistake is saying that const and readonly are equivalent because both prevent normal later assignment. const requires a compile time constant value, while readonly can be initialized at runtime. Another mistake is assuming every readonly field is shared by all objects. Only static readonly is shared by the type. An instance readonly field belongs to each object. Candidates also sometimes think readonly makes a referenced object immutable. It does not. It prevents replacing the field value after allowed initialization, but a mutable referenced object can still change internally. Another mistake is forgetting that changing a public const value may require callers to be recompiled before they observe the new value.

Start with the initialization timing. Say that const is fixed at compile time, while readonly can be set at runtime during allowed initialization. Then explain that const is implicitly static, while an instance readonly field can differ for each object. Finish by mentioning static readonly and the public const versioning concern if the interviewer wants more depth.

A static class is a helper class you use by name, without creating an object first. It is best for code that always does the same kind of work, like formatting text, converting values, or checking rules. Because it does not hold per object data, it keeps the design simple and lowers the risk of accidental state bugs. In C#, you call its members through the class name, not through an instance.

A static class is a helper class that you use by name, without creating an object first. It is a good fit when the code does one small job and does not need to remember anything between calls. For example, it can format text, convert values, or hold shared helper methods. It keeps the code simple because there is no per object data to manage. In C#, that also means less chance of accidental state bugs when many parts of the app call it.

1. Is this code meant to stay stateless?
2. Do you need extension methods or shared helper methods here?

A static class is for behavior that belongs to the type itself, not to one object. In C#, you cannot create an instance of it. Every member must also be static. That makes the intent very clear. The code is just a shared helper, not something that stores its own separate data.

This is useful for pure helper work such as parsing, formatting, math, or small utility methods. It is also the required home for extension methods. Because there is no object to build, you avoid a small allocation for each use of the class itself.

Use a static class when the logic is stateless and shared by everyone. Do not use it for services that need dependency injection, per request data, or behavior that changes from one object to another. If the code needs state, a normal class is usually the better choice. Static mutable state can also make testing harder and can create thread safety problems.

A common mistake is using a static class for shared mutable state. That can make code harder to test and can create thread safety problems. Another mistake is expecting to inject a static class with dependency injection or to inherit from it. Some people also use static classes for code that really needs one object per request or per user, which is the wrong fit.

Start with the simplest rule: no object, no instance state, type level helper. Then give one good example and one reason not to use it for stateful code.

A static constructor runs once for a type before the type is used for the first time, and it is used to set up shared static data.

This question asks about the special code that runs once for a type before anything uses it. It is not for a single object. It is for values that the whole type shares. In C#, you do not call it yourself. The runtime runs it automatically before the first use of the type. This matters when a class needs shared setup, like default values, a cache, or a helper that must be ready before any object is created or any static member is read.

1. Do you want shared values only, or also shared resources?
2. Should I talk about runtime timing or language rules?

A static constructor runs one time for a type. It is used to set up shared static state. For example, a logger class can load a default prefix or build a shared lookup table. C# runs it automatically. You never call it directly. The runtime runs it before the first instance is created or before any static member is used. After that, it never runs again.

This behavior exists so shared setup is safe and predictable. The type gets a chance to initialize itself before code uses it. A static constructor cannot take parameters, so it cannot depend on per call data. It is also not a normal public method, so it is only for internal type initialization.

Use it for small, clear setup that belongs to the type itself. Do not use it for heavy work or slow I O unless you really want the first use of the type to wait. If the setup throws, the type can fail to load, so the error can block later use. That is why many teams keep static constructors short and simple.

Thinking it runs on every object, calling it by hand, putting slow work inside it, or using it for data that should change per call.

Say that it is automatic, runs once, and is best for shared setup that belongs to the type.

A class is the blueprint in C#. An object is one real thing created from that blueprint. The object holds its own state, so each object can store different values even when it comes from the same class.

A class is like a plan. It tells us what data a thing should keep and what actions it can do. An object is one real thing made from that plan. Each object keeps its own values, so two objects from the same plan can still be different. In C#, a bank account class can make many account objects, and each one can hold a different balance.

1. Do you want a simple example from our codebase?
2. Do you use classes only for data, or also for behavior?

In C#, a class defines a type. It is the shape for a group of related data and methods. An object is one instance created from that class with new. That object lives in memory and has its own state, meaning the current values in its fields and properties. If you create two objects from the same class, each one can store different values. The class definition is shared, but the state belongs to each object.

This matters because C# code often passes around references to objects, not copies of the whole object. When you assign one object variable to another, you copy the reference, so both variables point to the same object. That is why a change through one reference can be seen through the other. In production, this is useful for models like customers, orders, and services where each item needs its own data.

Use a class when you need behavior and state together, or when different objects must keep separate values. Do not confuse the class definition with the live object. A common mistake is to think the class stores the data. In reality, the live data belongs to each object instance.

A common mistake is to say the class is the object. Another mistake is to think every object shares the same state. Another is to forget that assigning one class variable to another usually copies the reference, not the whole object. People also mix up class and record. A class is best when the object can change and has behavior.

Say this in one line first: class is the blueprint, object is the instance, and state lives in the object. Then add a small C# example if asked.

I use a class when the object has identity, may be shared, needs class inheritance, or is large and mutable. I use a struct for a small value that behaves as one complete value and is usually immutable. A class is a reference type, so assignment copies the reference and both variables can refer to the same object. A struct is a value type, so assignment copies the value. A struct also always has a default zero initialized value. Large or mutable structs can cause unnecessary copying or confusing behavior.

A class and a struct both let you group related data and behavior in C#. The practical difference is what happens when values are assigned or passed around. With a class, two variables can refer to the same object, so a change through one reference can be seen through the other. With a struct, assignment copies the value, so each variable has its own struct value. This choice matters when deciding whether something should behave like a shared object with identity or like a small independent value such as a coordinate or measurement.

1. Should this type have its own identity and be shared by different parts of the program?
2. Is this type expected to be a small immutable value?

A class is a reference type. A variable of a class type holds a reference to an object. Assigning that variable to another variable copies the reference. Both variables can therefore refer to the same object. If the object is mutable, a change made through one reference can be observed through the other reference.

A struct is a value type. Assigning one struct variable to another has value semantics, so the receiving variable gets its own struct value. The same rule applies to ordinary argument passing because C# passes arguments by value by default. For a class argument, the reference is copied. For a struct argument, the struct value is copied.

A struct copy is not automatically a deep copy. If a struct contains a reference type field, the reference is copied, so both struct values can still refer to the same referenced object.

Default initialization is another important difference. The default value of a class reference is null. The default value of a struct has all its fields set to their default values. A struct can declare a public parameterless constructor in modern C#, but default expressions and zero initialized storage still produce the default value without requiring that constructor to run.

A small immutable struct is a good choice when the type represents one value without separate identity. Coordinates and measurements are common examples. A readonly struct can help enforce that design. A class is usually better when the object has identity, is shared, is large, changes over time, or needs to inherit from another class. Structs cannot inherit from classes or other structs, although they can implement interfaces.

Large structs can make copying more expensive. Boxing a struct to object or to an interface when boxing is required can also create a managed object. Structs are not simply stack values. Their storage depends on context, such as whether they are local values, fields inside objects, or elements of arrays.

A common mistake is saying that structs always live on the stack and classes always live on the managed heap. Struct storage depends on context, and a struct can be stored as a field inside a managed object or as an element of an array. Another mistake is assuming that copying a struct performs a deep copy. Reference type fields inside the struct still refer to the same referenced objects after the struct is copied. Developers also sometimes create large mutable structs, which can cause unnecessary copying and surprising mutation behavior. Another mistake is assuming that a declared parameterless struct constructor always runs during default initialization. Default expressions and zero initialized storage still produce the default struct value.

Start with value semantics versus reference semantics. Explain that struct assignment copies the value while class assignment copies the reference. Then explain default initialization and shallow copying. Finish with the practical rule that a small immutable value without identity is a strong struct candidate, while a shared, large, mutable, or identity based object is usually better represented by a class.

A constructor is a special method that runs when I create a new object. It sets the object up with valid starting values, and C# chooses the constructor by matching the arguments I pass.

This question asks about the special setup that runs when you make a new item in C#. It gives the item its first values, checks that needed input is valid, and makes sure the item starts in a safe state. That matters because later code should not use something that is only partly ready. The question also asks how C# picks the right one when more than one is available, and what must already be true before the item can be used.

1. Do you want the answer for classes only, or for structs too?
2. Should I focus on overloads or object setup?

In C#, a constructor is a special method with the same name as the class. It has no return type. It runs when you create an object with new. Its job is to put the object into a valid starting state. That often means setting required fields, checking input, and wiring any needed dependencies.

C# selects a constructor by looking at the arguments you pass. If several constructors exist, the compiler picks the best match by parameter list. If there is no match, the code does not compile. A constructor can also call another constructor in the same class or the base class, so shared setup can live in one place.

The instance is usable only after the constructor and any base constructor finish. That matters because code should not see a half done object. In production, constructors are best for required setup that must always happen. They are not a good place for slow work, network calls, or logic that often fails. Keeping them small makes objects easier to create, test, and trust.

A common mistake is thinking a constructor can return a value or be called like a normal method. Another is assuming C# picks one by name only. It picks by parameter list. People also forget that the object should not expose invalid state after construction. Another mistake is putting heavy work in a constructor, which makes object creation slow and hard to test.

Say that a constructor prepares the object, C# selects it by arguments, and the object is ready only after construction finishes.

In C#, the common constructor types are default, parameterized, copy style, and static. A default constructor runs with no inputs. A parameterized constructor takes values and sets required state. A copy style constructor makes a new object from another object. A static constructor runs once for the type before first use and is used for type level setup.

This question asks about the different ways a C# class can be set up when you make a new object from it. Some versions take no input, some take values, some make a fresh copy from another object, and one runs only once for the type itself. The interviewer wants to know whether you understand how C# starts objects, how data gets placed in them, and which form fits each situation. It also helps you see why each choice matters in practice.

1. Should I include records and structs too?
2. Do you want a small code example?

Constructors are special methods that prepare an object. A default constructor has no parameters. If you do not write any constructor for a class, C# can create a parameterless one for you. But if you write your own constructor, the compiler does not add that default one. A parameterized constructor takes values and is the best choice when the object needs required data at creation time.

A copy style constructor takes another object and copies its values into the new one. C# does not give every class a built in copy constructor. You write it yourself when you need that behavior. This matters because you must choose between shallow copy and deep copy. If the object holds mutable references, simple copying can make two objects share the same inner data.

A static constructor is different. It belongs to the type, not to one object. It has no parameters and no access modifier, and it runs once before the type is used. It is useful for static fields and one time setup. In production, keep constructors light. Do not do expensive work there unless the object cannot exist without it. If initialization can fail or take time, consider a factory method instead.

A common mistake is thinking C# always adds a parameterless constructor. Another mistake is assuming a copy style constructor is built in for every class. People also forget that a static constructor runs only once and cannot take parameters. A bigger mistake is doing heavy work inside constructors, which can make object creation slow and harder to test.

Start with the four common forms, then say when each one runs. Keep the answer simple and mention one rule that matters in real code, such as the compiler not adding a default constructor after you define your own.