Interview Questions

class: reference type, reference equality by default. struct: value type, copied on assignment, field-by-field equality via ValueType.Equals (which can fall back to slow reflection, so override it). record (a record class): reference type with compiler-generated value equality, ToString, deconstruction and non-destructive mutation with with; positional properties are init-only. record struct: a value type with the same generated members, whose positional properties are mutable unless you write readonly record struct. Use records for DTOs, messages and value objects; classes for entities with identity and behaviour; structs for small, immutable values.

What they are really testing: Whether they know records are about equality semantics, and the mutability difference in record struct.

When the type is small (a rule of thumb is 16 bytes or less), logically a single value (Point, Money, DateOnly), immutable, and created in large numbers where avoiding heap allocations matters. Make it readonly struct so the compiler enforces immutability and avoids defensive copies. Avoid structs that are large (every assignment copies them), mutable (a modified copy is a classic bug), or frequently boxed (stored as object or a non-generic interface).

What they are really testing: Real criteria, and the mutable-struct copy bug.

If two objects are Equals, they must return the same GetHashCode. The reverse need not hold. Dictionary and HashSet use the hash to pick a bucket and Equals to confirm, so overriding only Equals makes equal keys land in different buckets and lookups fail. Hash only on fields that never change while the object is a key, and build it with HashCode.Combine(X, Y). Implement IEquatable<T> to avoid boxing for structs. Records generate all of this correctly.

What they are really testing: The dictionary failure mode, and the danger of mutating a key after inserting it.

Type patterns remove cast-and-check pairs: if (shape is Circle c). Switch expressions with property, relational and logical patterns replace long if/else chains:

decimal Fee(Order o) => o switch
{
    { Total: >= 1000 } => 0m,
    { Country: "IN", Express: true } => 99m,
    { Express: true } => 149m,
    _ => 49m,
};

What they are really testing: Modern-C# fluency; they want to see the exhaustiveness warning used as a safety net.

Nothing at run time. With <Nullable>enable</Nullable> the compiler tracks whether each reference may be null and warns on dereferences (CS8602), assignments of maybe-null values to non-nullable variables (CS8600/CS8601) and uninitialised non-nullable properties (CS8618). Values can still be null through reflection, deserialisation, default, older libraries, or the ! (null-forgiving) operator, which silences a warning without checking anything. Good practice: treat the warnings as errors, validate at the boundaries (API input, deserialisation), and use ! only where you can prove the value is set.

What they are really testing: That they understand it is static analysis, and do not sprinkle ! to make warnings disappear.

A constraint tells the compiler what a type argument can do, so the generic code can use it: where T : class (reference type), struct (non-nullable value type), notnull, new() (has a parameterless constructor), SomeBase or ISomeInterface (can call its members), unmanaged, and where T : INumber<T> for generic maths (static abstract interface members). Without a constraint you can only use object members. Example: T Max<T>(T a, T b) where T : IComparable<T> => a.CompareTo(b) >= 0 ? a : b;

What they are really testing: Understanding constraints as the contract that makes a generic method body compile.

Covariance (out T) lets a more specific type argument be used where a less specific one is expected: an IEnumerable<string> can be passed as IEnumerable<object>, because the interface only hands T out. Contravariance (in T) goes the other way: an Action<object> can be used as an Action<string>, because it only takes T in. Variance applies only to interfaces and delegates, and only with reference types. List<string> is not a List<object>: it accepts T in and out, so allowing it would let you add an int to a list of strings.

What they are really testing: Whether they can explain the List case, which shows they understand why the rule exists.

It stores entries in an array and keeps an array of buckets. To find a key it calls GetHashCode(), maps the hash to a bucket, then walks that bucket's chain comparing with Equals. When the entry count exceeds the capacity it resizes to a larger prime size and rehashes everything, so Add is amortised O(1). Lookups degrade towards O(n) with a poor hash that sends many keys to one bucket. Enumeration order is not part of the contract, and modifying the dictionary while enumerating it throws InvalidOperationException. It is not thread-safe for concurrent writes; use ConcurrentDictionary.

What they are really testing: The mechanism behind the O(1), and the practical consequences (order, mutation during enumeration, threads).

Operators like Where and Select build a pipeline; nothing runs until something enumerates it. Two classic bugs follow. Multiple enumeration: an IEnumerable used twice (a Count(), then a foreach) runs the whole pipeline twice, including any database query or expensive projection. Captured state: the query sees the source and captured variables as they are at enumeration time, not when the query was written. Call ToList() or ToArray() once when you need a snapshot. Operators such as OrderBy and GroupBy must read the whole source before yielding anything.

What they are really testing: Whether they have been bitten by multiple enumeration, the most common LINQ performance bug.

IEnumerable<T> runs LINQ in memory, with your lambdas compiled as delegates. IQueryable<T> captures the query as an expression tree that a provider such as Entity Framework Core translates into SQL. The danger is switching too early: db.Orders.AsEnumerable().Where(o => o.Total > 100) downloads the entire table and filters in memory. Keep a query IQueryable until the filtering, paging and projection are done, then materialise. The flip side: only expressions the provider can translate work, so an arbitrary C# method inside Where throws at run time.

What they are really testing: Knowing where the query executes, and the AsEnumerable/ToList-too-early performance bug.

It turns a method into an iterator: the compiler generates a state machine that implements IEnumerable<T>, runs your code up to each yield return, hands out that value, and pauses until the caller asks for the next one. It gives lazy, streaming sequences (read a huge file line by line, generate an infinite sequence) with O(1) memory. Gotchas: argument validation inside an iterator does not run until the first MoveNext, so do it in a non-iterator wrapper method; and a try/finally inside only runs when the caller finishes or disposes the enumerator (which foreach does).

What they are really testing: Understanding laziness, and the delayed-validation gotcha.

An async method is compiled into a state machine. At an await on an incomplete task, the method returns to its caller and registers the rest of itself as a continuation; when the task completes, the continuation runs (on the captured SynchronizationContext if there is one, otherwise on the thread pool). No thread is created or blocked while waiting for I/O: that is the point. async does not make CPU-bound work run in the background; for that, use Task.Run (in apps, not in library code).

What they are really testing: The single most important async question. "It runs on another thread" is the wrong answer.

An async void method cannot be awaited, so the caller cannot know when it finishes, and an exception thrown in it cannot be caught by the caller: it is raised on the synchronization context and, with none present, crashes the process. Tests cannot await it either. The only legitimate use is event handlers, whose signature requires void; wrap their body in try/catch. Everywhere else return Task. Watch for lambdas: passing an async lambda to a parameter of type Action silently creates an async void.

What they are really testing: The crash behaviour and the hidden async-void lambda.

In an environment with a single-threaded SynchronizationContext (WinForms, WPF, classic ASP.NET), calling .Result blocks that thread; the awaited method's continuation needs to resume on the same thread, which is blocked; neither can proceed. ASP.NET Core has no synchronization context so it does not deadlock, but blocking still wastes thread-pool threads and causes starvation under load. The fix is "async all the way": await instead of blocking. ConfigureAwait(false) tells an await not to resume on the captured context; library code uses it so it works safely whatever the caller's context. Application code in ASP.NET Core does not need it.

What they are really testing: The mechanism of the deadlock, and knowing it differs between ASP.NET and ASP.NET Core.

Return Task by default. ValueTask<T> is a struct that avoids allocating a Task when the result is often available synchronously (a cache hit, a buffered read), which matters only on hot paths. It has rules: await it exactly once, do not await it concurrently, and do not call .Result before it has completed. If you need to do any of those, call .AsTask(). A completed Task can also be cached and reused, which is often enough.

What they are really testing: Knowing ValueTask is an optimisation with restrictions, not a better Task.

Cancellation is cooperative: pass a CancellationToken down every async call (ASP.NET Core provides HttpContext.RequestAborted), check it with token.ThrowIfCancellationRequested() in loops, and create timeouts with new CancellationTokenSource(TimeSpan.FromSeconds(5)). Cancelled work throws OperationCanceledException, which should be treated as normal, not logged as an error. await Task.WhenAll(tasks) waits for every task; if several fail, the await rethrows only the first exception. To see all of them, keep the WhenAll task and read its Exception.InnerExceptions.

What they are really testing: Cooperative cancellation plumbing and the "only the first exception" detail.

A foreach that awaits each call runs them one at a time: simple, gentle on the API, and 500 times the latency of one call. Task.WhenAll(items.Select(CallAsync)) starts all 500 at once: fastest on paper, but it can exhaust connections, trip the API's rate limit and hold every response in memory. Parallel.ForEachAsync(items, new ParallelOptions { MaxDegreeOfParallelism = 10 }, ...) (or a SemaphoreSlim around WhenAll) gives bounded concurrency, which is usually the right answer. For CPU-bound work the tools are different: Parallel.For/ForEach or PLINQ, not async.

What they are really testing: Whether they reach for bounded concurrency instead of unleashing 500 requests, and separate I/O-bound from CPU-bound work.

It is the async version of IEnumerable<T>: an async method that uses yield return and returns IAsyncEnumerable<T> produces items one at a time, awaiting between them, and the caller consumes it with await foreach. Use it to stream results that arrive over time, such as pages from a paginated API, rows from a database reader or messages from a queue, without buffering the whole set in a List first. EF Core exposes queries this way with AsAsyncEnumerable(), and ASP.NET Core can stream it as a JSON array. Pass cancellation with [EnumeratorCancellation] on the token parameter, or .WithCancellation(token) at the call site.

What they are really testing: Knowing the streaming alternative to returning Task>, and how cancellation flows into it.

IDisposable.Dispose() releases resources deterministically, called by using. A class that merely holds other disposables implements Dispose to dispose them; it needs no finalizer. A finalizer (~MyType()) is only for a class that directly owns an unmanaged handle, as a safety net if Dispose is never called; it delays collection and runs on the finalizer thread. In modern code, wrap the handle in a SafeHandle instead and you almost never write a finalizer. Types with async cleanup implement IAsyncDisposable.

What they are really testing: Knowing finalizers are rare and SafeHandle exists; over-engineering the full pattern everywhere is a yellow flag.

Throw for exceptional conditions the caller cannot reasonably expect: a broken invariant, a missing config file, a network failure. For outcomes that are expected in normal flow (a user types "abc" into an age field, a cache miss) use the Try pattern (bool TryParse(string s, out int value)) or return a result object. Exceptions are slow when thrown (stack capture) and turn control flow into invisible jumps. Use exception filters (catch (HttpRequestException ex) when (ex.StatusCode == HttpStatusCode.NotFound)) to catch only the case you handle, and create custom exception types only when callers need to catch them specifically.

What they are really testing: Judgement: exceptions for the exceptional, and fluency with filters.

A delegate is a type-safe reference to a method (or several: delegates are multicast). Func<T, TResult> and Action<T> are the built-in generic delegates, so you rarely declare your own; lambdas convert to them. An event is a delegate field wrapped so that outside code can only += and -= handlers; only the declaring class can invoke it or replace the whole list. A public delegate field would let any caller wipe out every subscriber with = or raise the event itself. Raise events safely with Changed?.Invoke(this, args).

What they are really testing: The encapsulation that the event keyword adds, which is exactly what juniors miss.

A lambda captures variables, not values: the compiler hoists captured locals into a hidden class shared by the method and the lambda, so later changes are visible to it (and the variable lives as long as the lambda does, a possible leak). Since C# 5, a foreach variable is fresh on every iteration, but a for loop counter is one variable:

var actions = new List<Action>();
for (int i = 0; i < 3; i++) actions.Add(() => Console.Write(i));
foreach (var a in actions) a();   // prints 333

What they are really testing: Understanding closures as shared variables; the for-loop output is the follow-up question.

Subscribing (publisher.Changed += subscriber.OnChanged) stores a reference to the subscriber inside the publisher's delegate list. If the publisher lives longer (a singleton service, a static event, a main window), the subscriber can never be garbage-collected, even after everything else has forgotten it. Fixes: unsubscribe with -= (typically in Dispose), keep publisher and subscriber lifetimes aligned, or use a weak-event pattern. A memory profiler showing "retained by an EventHandler" is the tell-tale sign.

What they are really testing: Real-world debugging experience with long-lived publishers.

It is a generational, compacting, tracing collector. New objects go into generation 0; objects that survive a collection are promoted to gen 1, then gen 2. Most objects die young, so frequent cheap gen 0 collections reclaim most garbage, and expensive full (gen 2) collections are rare. Objects of 85,000 bytes or more go to the Large Object Heap, collected with gen 2 and not compacted by default, so allocating large temporary arrays repeatedly hurts; use ArrayPool<T>.Shared. Server GC (the ASP.NET Core default) uses a heap per core for throughput; background GC does most gen 2 work concurrently with your code. GC.Collect() in application code is almost always wrong.

What they are really testing: A working model (generations, LOH), and that they would measure before tuning.

Span<T> is a view over a contiguous region of memory (an array, a slice of a string, stackalloc memory or native memory) without copying it. "2024-06-01".AsSpan(0, 4) gives the year with no new string, and int.Parse accepts spans. It is a ref struct, so it can only live on the stack: it cannot be a field of a class, be boxed, or be held across an await. Memory<T> is the heap-storable counterpart for async code; call .Span on it when you need to work with the data. Together they let parsers and serializers such as System.Text.Json run with almost no allocations.

What they are really testing: Allocation-free slicing and the ref struct restrictions; mid-level candidates should know why it cannot cross an await.