C#/.NET Fundamentals Interview Questions

C# is a programming language; .NET is the runtime/platform (including the base class library and the Common Language Runtime) that C# code compiles down to and executes on -- .NET also supports other languages (F#, VB.NET) that all compile to the same intermediate language and run on the same runtime.

C# is compiled to an intermediate language (IL), not directly to native machine code -- the CLR then Just-In-Time (JIT) compiles that IL to native code at runtime, similar in spirit to Java's JVM/bytecode model, giving both portability across platforms and near-native runtime performance.

String interpolation embeds expressions directly inside a string literal (`$"Hello, {name}!"`), evaluated at runtime -- more readable than manually concatenating strings with `+`, and avoids the positional-argument confusion of older `string.Format`-style indexed slots.

string name = "Asha";
Console.WriteLine($"Hello, {name}!");

A value type (like `int`, `struct`) stores its actual data directly and is copied by value when assigned or passed; a reference type (like a `class` instance) stores a reference to data on the heap, so assignment copies the reference, not the underlying object -- two variables can then refer to the SAME underlying object.

Yes -- the CLR includes a garbage collector that automatically reclaims memory for objects no longer reachable, similar to Java's model -- developers generally don't manually free memory, unlike C/C++'s explicit `malloc`/`free` or `new`/`delete`.

By default, `==` on reference types compares REFERENCE identity (are these the same object in memory) unless the type overrides the `==` operator; `.Equals()` is meant for value equality and is commonly overridden by custom types to compare actual content -- built-in types like `string` override both to compare content by default.

A `switch` statement executes code per matched case (with `case`/`break` syntax); a `switch` expression (`var result = value switch { 1 => "one", _ => "other" };`) directly evaluates to a value using more concise pattern-matching arrow syntax -- the expression form is more common in modern, idiomatic C# for simple value-mapping logic.

`var` lets the compiler infer a local variable's type from its initializer -- the variable's type is still fixed and checked at COMPILE time, exactly as if you'd written the type explicitly; `var` is purely a syntax convenience, not a move toward dynamic typing.

Boxing converts a value type (like `int`) into a reference-type object (wrapping it on the heap); unboxing converts it back -- each boxing operation allocates new heap memory and adds garbage-collection pressure, so code that boxes value types frequently (e.g. storing many `int`s in a non-generic `ArrayList`) can incur real, avoidable overhead.

It combines strong tooling (Visual Studio, a rich standard library), solid performance via the CLR's JIT compilation, and a large ecosystem -- ASP.NET provides a mature web framework for backend services, while Unity adopted C# as its primary scripting language, giving the language reach across genuinely different domains.

A property (`public string Name { get; set; }`) exposes a controlled accessor/mutator pair while looking like simple field access from the caller's perspective -- unlike a plain public field, a property can later add validation logic in its getter/setter without breaking the calling code's syntax.

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

The compiler automatically generates a hidden, private backing field and the standard get/set logic for you -- convenient shorthand for the common case where a property doesn't need any custom validation logic beyond simple storage.

A class can hold state and provide full implementations; an interface (traditionally) declares a contract of members a class must implement, with no state of its own -- a C# class can implement MULTIPLE interfaces but can only inherit from ONE base class (C# has single class inheritance).

`virtual` marks a method as overridable by a derived class; the derived class then uses `override` to provide its own implementation -- calling the method through a base-class-typed reference still dispatches to the derived class's overridden version at runtime, C#'s mechanism for polymorphism.

`public`, `private`, `protected`, `internal`, and `protected internal` -- `internal` restricts access to code within the SAME assembly (compiled project/DLL), useful for exposing something to other classes in the same project while hiding it from external consumers of that assembly.

An abstract class can provide both abstract (unimplemented) and concrete (implemented) members plus real instance state, and can only be single-inherited; an interface (traditionally) declares only a contract with no state, and a class can implement many -- choose an abstract class when sharing real implementation/state across related types, an interface when only defining a capability contract.

A constructor initializes a newly-created object's state -- `: this(...)` lets one constructor overload delegate to another in the same class, avoiding duplicated initialization logic across multiple constructor overloads.

public User(string name) : this(name, 0) {}
public User(string name, int age) { Name = name; Age = age; }

A record provides built-in value-based equality, a readable `ToString()`, and concise immutable-by-default property syntax -- solves the boilerplate of manually implementing `Equals`/`GetHashCode`/`ToString` for a simple data-holding type where structural (not reference) equality is the natural expectation.

Properties let you add validation or computed logic later without changing the class's public interface (callers keep using the same `obj.Name` syntax) -- a plain public field offers no such extension point, so starting with a property (even a trivial auto-property) keeps that flexibility available from the start.

Overloading defines multiple methods with the SAME name but different parameter signatures within the same class, resolved at compile time; overriding replaces a base class's `virtual` method implementation in a derived class, resolved at runtime based on the object's actual type -- two genuinely different mechanisms, both sometimes casually called 'polymorphism.'

With nullable reference types enabled, the compiler tracks and warns when a reference-type variable that ISN'T explicitly marked nullable (`string?` vs. plain `string`) might be assigned or passed `null` -- surfaces a real class of `NullReferenceException` risk as a compile-time warning instead of a runtime crash.

string? maybeName = GetName();  // explicitly nullable
string name = GetName();        // compiler warns if this could be null

`obj?.Property` accesses the property only if `obj` is not `null`, otherwise short-circuits to `null` instead of throwing -- replaces verbose manual null-checking chains (`if (obj != null) { ... }`) with a single, concise expression.

string? city = user?.Address?.City;

`a ?? b` evaluates to `a` if it's not `null`, otherwise `b` -- a concise default-value expression; `a ??= b` assigns `b` to `a` only if `a` is currently `null`, a combined null-check-and-assign shorthand.

A set of query operators built into C# for filtering, transforming, and aggregating data (collections, and with the right provider, databases/XML) using a consistent, declarative syntax -- e.g. `users.Where(u => u.IsActive).Select(u => u.Name)` reads similarly to a database query but works directly over in-memory C# collections too.

var activeNames = users.Where(u => u.IsActive).Select(u => u.Name).ToList();

Lazily (deferred execution) -- the query is only actually evaluated when you enumerate its results (via a `foreach`, or calling `.ToList()`/`.ToArray()`), not at the point the LINQ expression is written -- this means the underlying data source could change between defining and actually enumerating the query, affecting the eventual result.

Common mistake: Assuming a LINQ query executes immediately when written, rather than being lazily evaluated only once actually enumerated.

`IEnumerable<T>` only guarantees the ability to iterate over a sequence, potentially lazily/deferred and possibly only once; `List<T>` is a concrete, fully-realized, indexable, mutable collection -- calling `.ToList()` on an `IEnumerable<T>` forces immediate, full evaluation into a real in-memory list.

`List<T>` is an ordered, resizable, index-accessible collection allowing duplicates; `Dictionary<TKey, TValue>` maps unique keys to values with fast lookup by key; `HashSet<T>` holds unique elements with fast membership testing but no meaningful positional order.

`.First()` throws an exception if no matching element exists; `.FirstOrDefault()` returns the type's default value (`null` for reference types, `0` for `int`, etc.) instead of throwing -- choosing between them depends on whether 'no match' is an expected, normal case or a genuine error condition for that specific query.

Re-executing a lazily-evaluated LINQ query multiple times (e.g. calling `.Count()` and then `.ToList()` separately on the same un-materialized query) re-runs the ENTIRE query pipeline each time -- materializing the result once (`.ToList()`) and reusing that concrete list avoids redundant recomputation.

A dense chain of `.Where().Select().GroupBy().OrderBy()` packs significant logic into one expression, which can become genuinely hard to read/debug once it grows complex -- LINQ is a readability WIN for straightforward filter/transform operations, but not an automatic win once the logic becomes intricate enough that a clearer imperative loop (or breaking the chain into named intermediate variables) would communicate intent better.

It lets you write asynchronous code (like an I/O-bound network call) that reads like sequential synchronous code -- an `async` method typically returns `Task` (no result value) or `Task<T>` (an eventual result of type `T`), representing the operation's eventual completion.

public async Task<string> FetchDataAsync() {
  var response = await httpClient.GetStringAsync(url);
  return response;
}

No -- `await` releases the current thread back to do other work while the asynchronous operation is in progress, and execution resumes on (typically) a thread-pool thread once the awaited task completes -- this is precisely why `async`/`await` is valuable for scalable I/O-bound work, unlike a blocking synchronous wait.

The async operation starts but the calling code continues immediately without waiting for it to complete or observing any exception it might throw -- an unhandled exception from a fire-and-forget async call can be silently lost, or surface much later and out of context, making the bug hard to trace back to its source.

Common mistake: Calling an async method without awaiting it, letting any exception it throws go unobserved or surface later, disconnected from its actual cause.

`await Task.WhenAll(task1, task2, task3);` -- starts all the tasks and waits for every one to complete, running them concurrently rather than sequentially awaiting each one in turn (which would needlessly serialize otherwise-independent work).

`try` contains code that might throw; `catch` handles a specific (or general) exception type if one occurs; `finally` runs regardless of whether an exception occurred or was caught -- commonly used for guaranteed cleanup (closing a resource) that must happen either way.

`using (var resource = ...) { ... }` guarantees `resource.Dispose()` is called automatically once the block exits, even if an exception is thrown -- works for any type implementing `IDisposable`, C#'s equivalent to a deterministic cleanup pattern for unmanaged resources like file handles or database connections.

using (var file = new StreamReader(path)) {
  return file.ReadToEnd();
}

It silently discards information about a real failure, making the program appear to succeed when something actually went wrong -- the underlying problem surfaces later, in a confusing, disconnected way (or never surfaces at all), making the root cause far harder to diagnose than if the exception had been logged or handled meaningfully.

Common mistake: Catching a broad Exception type with an empty catch block, silently swallowing a real failure instead of logging or handling it.

By default (unchecked), an integer arithmetic overflow silently wraps around; wrapping the expression in a `checked` block causes it to throw an `OverflowException` instead -- useful when silent wraparound would be a serious, hard-to-detect bug in a specific calculation.

A class deriving from `Exception` (e.g. `class InsufficientFundsException : Exception`) represents a specific, meaningful failure mode -- lets calling code catch and handle that SPECIFIC error type distinctly (`catch (InsufficientFundsException ex)`) rather than parsing a generic exception's message string to figure out what actually went wrong.

Throwing and catching exceptions has real runtime overhead compared to a normal conditional check, and using them for routine, expected outcomes (like a missing dictionary key, which `TryGetValue` handles cleanly without an exception) makes the code's control flow harder to follow -- exceptions communicate 'something unexpected happened,' not 'here's one of several normal outcomes.'

It scaffolds a new console application project, generating a `.csproj` project file (describing the project's target framework and dependencies) and a starter `Program.cs` source file -- the standard starting point for a new .NET console project.

It's the project's manifest -- defining the target .NET framework version, package (NuGet) dependencies, and build-related settings -- roughly analogous in role to `package.json` in a Node.js project or `go.mod` in a Go project.

`dotnet build` compiles the project into output binaries without executing it; `dotnet run` builds (if needed) AND immediately executes the resulting application -- `run` is typically used during active development, `build` alone when you just need the compiled output without running it.

It discovers and runs a project's automated tests -- commonly used with frameworks like xUnit, NUnit, or MSTest, all of which integrate with the standard `dotnet test` command regardless of which specific testing framework a project has chosen.

.NET's package manager -- it manages downloading, installing, and tracking versions of external library dependencies referenced in a project's `.csproj` file, similar in role to npm for Node.js or pip for Python.

`dotnet publish` produces a self-contained, deployment-ready set of output files (optionally including the .NET runtime itself for a self-contained deployment) intended to actually be deployed to a server -- `dotnet build`'s output is meant more for local development iteration, not necessarily deployment-ready.

The SDK includes everything needed to BUILD and develop .NET applications (compiler, CLI tools, project templates); the runtime alone is only what's needed to RUN an already-built .NET application -- a production server typically only needs the runtime installed, not the full SDK.

A solution file groups multiple related `.csproj` projects together (e.g. a web API project plus its separate test project) so they can be opened, built, and managed together as one unit in an IDE or via the CLI -- a solution can reference several independently-buildable projects.

Pinning exact versions ensures every environment installs the identical dependency code, avoiding a scenario where an unrelated upstream package update silently changes behavior between different developers' machines or between local development and CI/production.

It lets C#/.NET applications be developed and deployed on the same platforms as most other modern backend stacks (Linux containers, cloud environments) rather than being tied to Windows-only hosting -- a significant shift that broadened where and how .NET applications can realistically be deployed.