354 .NET Developer Interview Questions & Answers

A property is the normal way to expose object data in C#. It gives you a clean way to read and change a value through get and set, while keeping control inside the class. C# can also create the hidden backing field for you in an auto property.

In simple terms, a property is the normal way to expose a value from a C# object. It lets other code read the value with get and change it with set, while the class keeps control over what happens inside. C# can also create the hidden storage for you in an auto property. This is better than making a public field because you can add validation, keep the public shape stable, and change the internal storage later without breaking callers.

1. Should this value ever be read only from outside?
2. Do you want any validation when the value changes?
3. Should changing the value trigger any extra work?

A property looks like a field to the caller, but it behaves like a small pair of methods. The get accessor runs when someone reads the value. The set accessor runs when someone writes the value. If you use an auto property, C# creates the hidden backing field for you. If you need custom behavior, you can write a full property and store the value in your own backing field.

This matters because public fields expose data directly and give you no place to check rules or protect the object. Properties let you add validation, compute values, raise events, or keep the same public API while changing the internal storage later. That makes them a better choice for most public state in production code.

Use fields for private internal data when you do not need that control. Use properties for public state, simple computed values, or values that may need rules later. One edge case is that a property can still do work, so keep get and set fast and predictable. Another point is that a property access is still designed like a method call, so the real benefit is design and safety, not raw speed. In practice, the cost is usually tiny and the flexibility is worth it.

A common mistake is to think a property is just a public field with a different name. It is not. Another mistake is to put slow or complex work inside get or set, which can make simple reads and writes harder to reason about. A third mistake is exposing public fields when a property would give better control and future flexibility. People also forget that an auto property still has backing storage, just hidden by the compiler.

Start with the rule that public state should usually be a property, not a field. Then say that the get and set accessors let you control reads and writes while keeping the option to add validation or other logic later.

Access modifiers control who can see a class or member in C#. Private keeps it inside the class, protected opens it to derived types, internal opens it to the same assembly, and public opens it to everyone. The practical goal is to protect state and keep the public surface small.

Access modifiers decide who can use a class or part of a class. Some code should stay hidden inside one class. Some should be shared with child classes. Some should be shared inside one project, and some should be open to any code that can reach it. This question is about those visibility levels and the boundary each one creates. The main point is to protect state, keep the public surface small, and make future changes safer. That also helps avoid accidental use from the wrong place.

1. Do you want the answer for class members or for types?
2. Should I focus on one project or multiple projects?

In C#, access modifiers define who can reach a type or member.

Private means only code inside the same class can use it. This is the tightest boundary and is the best choice for internal state. Protected means the same class and derived classes can use it. That is useful in base classes when child types need to extend behavior.

Internal means any code in the same assembly can use it. An assembly is usually one compiled project such as a DLL or EXE. This is useful for code that should be shared inside one project but not exposed as part of the public API. Public means any code that can reference the assembly can use it.

Protected internal means access is allowed from derived types or from code in the same assembly. Private protected is narrower. It allows access only from derived types in the same assembly.

The practical rule is simple. Start with the smallest visibility that still works. That keeps the API smaller, reduces coupling, and makes later changes safer. In production code, private is common for fields, internal is common for helper types, protected is used when inheritance is truly needed, and public is reserved for the contract you want other code to depend on.

A common mistake is thinking internal means visible only in the same namespace. It actually means visible in the same assembly. Another mistake is using public by default when private or internal would be safer. Some people also mix up protected internal and private protected. Protected internal allows access from a derived type or from the same assembly. Private protected requires both derived type access and same assembly access.

Say the smallest boundary first, then name each modifier with its scope. If you mention class, derived type, assembly, and public API, your answer will sound clear and practical.

Encapsulation means I keep an object state private and expose only safe methods or properties to use it. In C#, that usually means private fields, public read only access when needed, and validation inside the type so invalid state cannot slip in.

Encapsulation means an object keeps its own data inside and lets other code use it through a small public surface. For example, a bank account can keep the balance private and let other code call Deposit and Withdraw. The type checks the input and protects the rules for that data. This matters because outside code cannot change the balance in unsafe ways. In C#, this is usually done with private fields, public methods, and properties that control access.

1. Should I show this with a class and private fields?
2. Do you want me to include validation in the example?

In C#, encapsulation means the type owns its data and controls how that data changes. You do not let outside code reach in and change fields directly. Instead, you keep fields private and expose a public contract, such as methods or properties, that only allow valid changes. This is why validation belongs inside the type. The object can reject bad input right away and keep its own rules in one place.

A simple example is a BankAccount class. The balance stays private. Other code can call Deposit or Withdraw, but those methods check the amount before changing the balance. That keeps the object in a valid state and makes the class easier to maintain. If the rules change later, you update one place.

In production, encapsulation helps with maintainability, testing, and safety. It is not the same as security, and it does not make code thread safe by itself. It also does not mean every value must be hidden. Read only properties are fine when outside code only needs to observe state. The key idea is control: the type should decide how its state changes, not random callers.

A common mistake is thinking encapsulation only means private fields. It also means the type controls its valid changes. Another mistake is exposing a settable property and then calling it encapsulated even though any caller can put the object into a bad state. Some people also move validation outside the class, which spreads the rules around and makes bugs easier to create. Encapsulation is not the same as inheritance, and it is not a security feature.

Say that encapsulation hides state, exposes behavior, and keeps validation close to the data. A small BankAccount example makes the idea easy to understand.

It refers to the current instance. I use it to access that object, chain constructors with this(...), and make it clear when a field belongs to the object instead of a parameter.

this is the current object inside a class. It lets code use the values and methods that belong to that object. If a constructor parameter has the same name as a field, this.field means the field on the object, not the parameter. In a constructor, this(...) can call another constructor in the same class. Interviewers ask this to check that I understand the current object, name conflicts, and constructor chaining.

1. Do you want me to explain constructor chaining too?
2. Do you want an example with a field and a parameter that share a name?

this refers to the current instance of the class. It is used inside instance methods, property accessors, and constructors. It does not create a new object. It only points to the object that is already being worked on.

The most common use is to remove confusion when names match. If a parameter has the same name as a field, C# lets the local name win. Writing this.field makes it clear that you want the field from the object. That is very common in constructors and setters.

It also supports constructor chaining. Inside one constructor, this(...) can call another constructor in the same class. That keeps shared setup in one place and reduces duplicate code. It is useful when several overloads should end with the same initialization path.

There are important limits. You cannot use this in a static member because static code has no current object. It also does not copy the object or change object identity. It only gives a direct reference to the same instance. In production code, use it when it improves clarity or when names collide. Do not add it everywhere if it makes the code noisy.

Thinking this can be used in a static method. Thinking this creates a new object. Forgetting that it is only needed when names conflict. Using it so often that the code becomes harder to read.

Start with current object, then mention constructor chaining, then explain how it separates fields from parameters.

The base keyword lets a derived class call its direct parent on purpose. I use it to pass values to a parent constructor or to call the parent version of an overridden member when I still need the inherited behavior.

When one class is built from another, the base keyword lets the new class reach the parent class on purpose. It can hand values to the parent when an object starts. It can also run the parent version of a member when the new class still wants that shared work. This matters because the parent may already set up common data, check values, or do shared work that should not be lost. So base helps a child class reuse the parent's behavior instead of copying it.

1. Do you want me to focus on constructors or overridden members?
2. Should I also cover when I would skip the parent behavior?

In C#, base is used inside a derived class to reach the direct parent. In a constructor, base(...) passes arguments to the parent constructor. That parent constructor runs before the derived constructor body, so shared state is ready first. In an instance method, base.SomeMethod() calls the parent implementation directly. It does not continue to other overrides. That is useful when the child class wants to extend behavior instead of fully replacing it.

I would use base when the shared logic belongs in the parent and every child should reuse it. A common case is an override that adds logging, extra checks, or extra work after the parent logic runs. I would not use it for unrelated behavior, and I would not use it in static code. The main limit is that base always targets the direct parent, so the child depends on the parent design. In production, that is fine when the shared behavior is stable and clearly part of the class design.

A common mistake is thinking base can reach any class in the inheritance chain. It only targets the direct parent. Another mistake is thinking base.SomeMethod() is the same as a normal virtual call. It is not. It chooses the parent implementation directly. In constructors, another mistake is expecting the derived body to run first. The parent constructor runs before the derived constructor body.

Say that base is for deliberate reuse of inherited behavior. Then give one example for a constructor and one example for an overridden member.

An abstract class is for shared code and shared state. An interface is for a contract that different types can follow. In C#, I use an abstract class when related types need common behavior, and I use an interface when I want flexibility and many implementations.

This question asks which kind of shared type to use in C# when several classes need a common shape. One option gives you a base with shared parts already written. The other option gives you a promise that each class must follow. The choice matters when you decide how much code should be reused, how much freedom each class should keep, and how easy the design will be to change later. In interviews, the main point is to show when each choice fits and why.

1. Do you want shared code in the base type?
2. Will this type need one parent or many capabilities?

An abstract class is a partly finished base class. It can have fields, constructors, implemented methods, and abstract members that derived classes must finish. It is good when several related types share code and data. An interface is a contract. It tells a type what members it must provide. It is good when you only need a common promise and want more design freedom.

A key C# rule is that a class can inherit from only one base class, but it can implement many interfaces. That is why interfaces are often used for services, adapters, and test doubles. Abstract classes are often used for base workers, shared helper logic, and template style designs where common behavior belongs in one place.

Modern C# also allows some interface implementation, but interfaces still do not hold instance state or constructors. So they are still best thought of as contracts first. The main tradeoff is simple. Abstract classes give more shared behavior, but less flexibility. Interfaces give more flexibility, but less shared code.

In production, I choose an abstract class when shared code reduces duplication and the types are closely related. I choose an interface when I want loose coupling, easier testing, or many different implementations. The runtime cost is usually not the deciding factor. The design fit is the real decision.

A common mistake is thinking an interface is only a list of methods. In modern C#, it can also have default members, but it still cannot hold instance state or constructors. Another mistake is using an abstract class when unrelated types only need the same contract. Another is forgetting that a class can inherit only one base class, so an abstract class can reduce design flexibility.

Start with the rule of thumb. Say abstract class for shared code and state, interface for a contract. Then mention that a class can implement many interfaces but inherit only one base class.

I use an interface when I only need a contract and want many different types to support it. I use an abstract class when I need shared code, shared state, or a common base for closely related types. In C#, a class can implement many interfaces but only inherit from one base class, so that choice matters a lot.

This question asks how to choose between two ways to describe what a class must do. An interface is best when you only need a promise about behavior, and many different classes may share that promise. An abstract class is best when you also want to share code, data, or a common starting point. In C#, a class can use many interfaces but only one base class, so this choice affects how flexible your design stays when you later add new behaviors or new kinds of classes.

1. Do these types need shared code or just a contract?
2. Will one type need to support more than one role?
3. Do you expect new implementations from unrelated classes?

I would say an interface is the right choice when I want a clean contract. It tells me what methods or properties a type must provide, but it does not force a shared inheritance chain. That is useful when many unrelated classes need the same behavior. It is also useful when a type may need to already inherit from another class, because C# allows only one base class.

I would choose an abstract class when I need shared implementation. That can mean common helper methods, protected state, or a default flow that several related types can reuse. It works well when the types really are part of one family.

Versioning matters too. If I add a new member to an interface, existing implementers may need to change unless the interface already uses default members. That creates more versioning pressure than an abstract class in many designs. With an abstract class, I can often add a non abstract member without forcing every derived class to change. So in practice, I use interfaces for contracts and flexibility, and abstract classes for shared behavior and controlled inheritance.

A common mistake is choosing an abstract class just to share one small helper method. An interface is often better there. Another mistake is choosing an interface when the design really needs shared state or default logic. People also forget that a class can implement many interfaces but only inherit one base class. Another issue is versioning. Adding a new member to an interface can force changes in every implementer unless the design already planned for that.

Lead with the rule of thumb. Say interface for contract and flexibility, abstract class for shared code and one inheritance path. Then give one simple example of each.

Method overloading means one method name can have several versions, and C# chooses the best one at compile time based on the arguments you pass. The parameter list is what makes each version distinct.

This question asks what it means when one action name is used in more than one way. In C#, those versions are separate only when their parameter list is different. The compiler picks the best match from the arguments in the call. The return type alone does not create a new version, and parameter names do not matter. This matters because it lets an API stay simple to use while still supporting several useful input shapes. It also helps avoid confusion when two calls could match.

1. Do you want a simple C# example or a real project example?
2. Should I explain ambiguous calls and optional parameters?

In C#, method overloading means one method name can have several versions. Those versions are different only when their parameter list is different. That can mean a different number of parameters, different parameter types, a different order of parameter types, or different ref, in, or out usage. The method name stays the same, but the compiler treats each valid parameter list as a separate overload.

Overload resolution happens at compile time. The compiler looks at the call, finds methods with the same name, and chooses the best match for the arguments you passed. An exact type match wins first. If there is no exact match, C# may use an implicit conversion. If more than one overload fits equally well, the call is ambiguous and the code does not compile.

The return type does not make a new overload. Parameter names do not make a new overload either. That is why Print(int) and Print(string) are different, but two methods that only differ by return type are not allowed. This is useful when one operation has a few natural forms, such as reading by id, reading by id and options, or writing with different input shapes. In production, keep overloads closely related so the API stays clear and predictable.

Many candidates think the return type creates a new overload, but it does not. Some also think method names alone are enough, but the parameter list is what matters. Another common mistake is forgetting that ref, in, and out are part of the signature. Optional parameters can also make a call ambiguous when another overload fits the same call.

Say that overloads are chosen at compile time and that the parameter list is what makes them different.

Overloading is when several methods in the same class share a name but take different inputs, and C# picks one at compile time. Overriding is when a derived class replaces a virtual base method, and C# picks the version at run time from the real object.

This question asks about two ways a program can use the same name for an action. One way gives one class several versions for different inputs. The other way lets a child class change what a parent class already does. The first choice is made before the program runs. The second choice is made while the program runs, based on the real object. This matters because it changes how code is designed and which result you get. It also helps you know when the compiler decides and when the object decides.

1. Do you want one name for several input shapes?
2. Should a child type change parent behavior?

Overloading means you keep the same method name in the same class, but each method has a different parameter list. C# picks the best match at compile time, before the program starts. Overriding means a derived class gives a new body for a base class method that is marked virtual, abstract, or already override. In that case, C# uses virtual dispatch, so the call is chosen at run time from the real object, not just the reference type.

Use overloading when the action is the same but the input shape changes. For example, one method can accept a string, another can accept a stream, and another can accept a file path. Use overriding when a child type must change behavior while still following the same contract from the base type.

A key limitation is that return type alone does not create an overload. The parameter list must differ. Also, a method in a child class is not an override unless the base method allows it. If the base method is not virtual, abstract, or override, the child can only hide it with new, which is a different behavior.

In production, overloading is a convenience for API design. Overriding is the main tool for polymorphism. Overloading has no virtual dispatch cost. Overriding has a small dispatch cost, but it is usually the right choice when you need flexible object behavior. There is no special memory cost from either feature itself.

Thinking return type alone creates an overload. It does not. Thinking a child method with the same name is an override even when the parameter list is different. That hides the base method instead of overriding it. Forgetting that override requires a base method marked virtual, abstract, or override. Also forgetting that overloaded methods are chosen by the compiler, not by the object at run time.

Say overload for same name, different inputs, and override for same contract, new behavior in a child class. Then mention compile time for overload and run time for override.

A C# array has a fixed length, while a List<T> can grow and shrink. Arrays are best when you know the size up front. List<T> is better when items may be added or removed later because it handles resizing for you.

The question is about two ways to hold many items in C#. One has a size that stays the same after it is created. The other can grow or shrink as needed. The interviewer wants to see whether I know when fixed size storage is better, when flexible storage is better, and how indexing, resizing, and memory use change the choice. They also want to see if I can pick the right type for a real program.

1. Will the number of items be known ahead of time?
2. Do you expect items to be added or removed often?

In C#, an array has a fixed length after it is created. You can read and update items by index, and the first item is at index 0. If you need a different size, you must create a new array and copy the values into it. That makes arrays a strong choice when the size is known and stable.

List<T> is a class that gives you a growable sequence of items. You can add and remove items without making a new collection each time. Internally, it uses an array. When it runs out of room, it allocates a bigger array and copies the items over. Indexing is still fast, but growth has a resize cost.

Arrays are a good fit when you want simple storage, a stable size, and compact memory use. They also give predictable layout in memory, which can help when you care about low overhead. List<T> is a better fit when the count is not known in advance, such as user input, query results, or items collected over time. The main tradeoff is flexibility versus resize cost. If the size never changes, an array is usually simpler. If the size changes, List<T> is usually the better default.

A common mistake is to say that a List<T> is just an array. It is not. Another mistake is to think arrays can grow automatically. They cannot. People also forget that List<T> has a Count value for items and a separate internal capacity for storage. Another mistake is assuming resizing has no cost. When List<T> grows, it may allocate a new array and copy items.

Start with the size rule first. Say that arrays are fixed and List<T> is growable. Then mention that arrays are best for stable data and List<T> is best when the size may change.