Common Interview Questions

Structs and classes are both used to define custom types in C#, but they differ fundamentally in how they are stored, copied, and managed.

Core distinction: value type vs reference type

Example — copy semantics:

// Struct — independent copy
var p1 = new Point(1, 2);
var p2 = p1;
p2 = p2 with { X = 99 }; // record struct: non-destructive mutation
Console.WriteLine(p1.X); // 1 — unchanged

// Class — shared reference
var c1 = new Container { Value = 1 };
var c2 = c1;
c2.Value = 99;
Console.WriteLine(c1.Value); // 99 — same object

Modern struct variants:

• readonly struct (C# 7.2+): all members are readonly; prevents accidental mutation and defensive copies when passed as in parameter.
• ref struct (C# 7.2+): stack-only; cannot be boxed or stored on heap. Span and ReadOnlySpan are ref structs.
• readonly record struct (C# 10+): combines immutability + value equality + concise syntax: csharp readonly record struct Point(double X, double Y);

Boxing gotcha: assigning a struct to object or an interface variable boxes it — allocates a heap object. This is a hidden performance cost. Generics (List) avoid boxing entirely.

Microsoft guideline for using structs:

• Size ≤ 16 bytes
• Immutable (or treated as such)
• Not frequently boxed
• Not passed by value in performance-critical loops

Interviewers probe: when would you use a struct over a class? Small, immutable value objects (coordinates, colors, monetary amounts, key-value pairs). DateTime, Guid, decimal, KeyValuePair are all structs in the BCL.

using in C# serves two distinct purposes. Interviewers test both — confusing them is a red flag.

1. using directive — namespace import

using System;
using System.Collections.Generic;
using static System.Math;           // import static members
using Json = System.Text.Json;      // alias to resolve conflicts

Global usings (C# 10+) apply project-wide:

// GlobalUsings.cs
global using System;
global using Microsoft.Extensions.Logging;

Modern .NET SDK projects enable enable by default, auto-generating global usings for System, System.Linq, System.Threading.Tasks, etc.

2. using statement / declaration — resource management

Ensures IDisposable.Dispose() is called when a resource goes out of scope — even if an exception occurs.

// Block form (pre-C# 8)
using (var conn = new SqlConnection(connectionString))
{
    conn.Open();
    // ...
} // Dispose() called here

// Declaration form (C# 8+) — preferred, less nesting
using var conn = new SqlConnection(connectionString);
conn.Open();
// Dispose() called at end of enclosing scope (method, block, etc.)

await using for async disposal (C# 8+):

await using var reader = new StreamReader("file.txt");

For types implementing IAsyncDisposable — allows async teardown without blocking.

How using works: the compiler transforms it into a try/finally block. Dispose() is always called in the finally, so cleanup happens even if the guarded code throws.

Common IDisposable types: SqlConnection, FileStream, StreamReader, StreamWriter, HttpResponseMessage, DbContext (EF Core), HttpClient (but prefer IHttpClientFactory).

Interviewers probe: what if Dispose() throws? The exception from Dispose() propagates and may mask the original exception. If you need to handle both, use explicit try/finally. Also: why not rely on the finalizer for cleanup? Finalizers are non-deterministic — a DB connection held until GC runs wastes server resources.

Both const and readonly represent values that shouldn't change, but they differ in when the value is determined and what types they support.

const — compile-time constant:

public class Config
{
    public const int MaxRetries = 3;
    public const string DefaultName = "Unknown";
    public const double Pi = 3.14159;
}
// Used as: Config.MaxRetries

• Value must be a compile-time literal (primitive types and string)
• Value is baked into the calling assembly at compile time
• Implicitly static — no instance qualifier
• Cannot be changed at runtime

readonly — runtime constant:

public class Config
{
    public readonly int MaxConnections;
    public static readonly ImmutableList AllowedOrigins =
        ImmutableList.Create("https://example.com");

    public Config(int maxConnections)
    {
        MaxConnections = maxConnections; // set in constructor
    }
}

• Value can be any type
• Assigned at declaration or in constructor only
• Can be instance-level or static
• Value evaluated at runtime

Critical const gotcha — assembly versioning:

If Library A defines public const int MaxSize = 100; and Library B uses it, Library B bakes 100 into its compiled code. If you change MaxSize to 200 in Library A and redeploy only Library A, Library B still uses 100 — you must recompile Library B too.

readonly does not have this problem because the value is read at runtime from Library A.

static readonly for complex objects:

// WRONG — const can't hold complex objects
// public const List Tags = new(); // compile error

// CORRECT
public static readonly List Tags = new() { "alpha", "beta" };

Summary — which to use:

• const: true mathematical/physical constants, magic strings in switch cases, values that genuinely never change and are primitive.
• static readonly: complex objects, values that might change between library versions, anything requiring runtime initialization.

Interviewers probe: why might changing a const in a library break dependent assemblies that weren't recompiled? Because the value is baked in at compile time — the calling assembly never reads the field at runtime.

out and ref both pass arguments by reference (the method receives a pointer to the caller's variable), but they have different initialization requirements and semantic intent.

ref — read and write an existing value:

void Double(ref int value) => value *= 2;

int x = 5;
Double(ref x);
Console.WriteLine(x); // 10

• Caller must initialize the variable before passing
• Method can read the value, then optionally modify it
• Useful when the method needs both to receive input and modify it in place

out — write-only output:

bool TryParse(string input, out int result)
{
    // result MUST be assigned before returning
    return int.TryParse(input, out result);
}

// Caller — no need to initialize first; inline declaration (C# 7+)
if (int.TryParse("42", out int value))
    Console.WriteLine(value); // 42

// Discard with _ when you only care about success
if (int.TryParse("42", out _))
    Console.WriteLine("Valid number");

• Caller does not need to initialize the variable
• Method must assign the value before returning
• Clearly signals "this is output, not input"

in — read-only reference (C# 7.2+):

void Process(in LargeStruct data)
{
    // data.Field = 5; // compile error — cannot modify
    Console.WriteLine(data.Field);
}

Passes by reference but prevents modification — avoids copying large structs without the risk of accidental mutation. Use with readonly struct for maximum efficiency.

C# 13 relaxed restrictions: ref and unsafe can now be used inside iterators (yield return) and async methods in contexts where safety can be verified.

Modern alternatives to out:

Prefer tuples for multi-value returns over out:

(bool Success, int Value) TryParse(string input) =>
    int.TryParse(input, out var n) ? (true, n) : (false, 0);

var (ok, val) = TryParse("42");

Interviewers probe: when would you still use out over returning a tuple? out is idiomatic for TryX patterns (matches BCL conventions like int.TryParse, Dictionary.TryGetValue) and is often clearer for boolean-plus-value returns. Tuples are better for new APIs returning multiple distinct values.

A destructor (also called a finalizer) in C# is a method that the Garbage Collector calls before reclaiming an object's memory. It provides a last-resort opportunity to release unmanaged resources.

Syntax:

public class NativeResource
{
    private IntPtr _handle;

    public NativeResource() => _handle = NativeLib.Allocate();

    ~NativeResource() // finalizer
    {
        NativeLib.Free(_handle);
    }
}

Why finalizers are problematic:

1. Non-deterministic — you don't know when (or if, during a quick process exit) the finalizer runs.
2. GC overhead — objects with finalizers are promoted to the next GC generation, meaning they survive at least one extra collection before being reclaimed.
3. Ordering not guaranteed — two finalizers may run in any order.
4. Exceptions in finalizers crash the process (in .NET, an unhandled exception in a finalizer terminates the application by default).
5. Finalizer thread is shared — slow finalizers delay all other finalizations.

The correct pattern — IDisposable:

For deterministic cleanup, implement IDisposable and use using:

public class NativeResource : IDisposable
{
    private IntPtr _handle;
    private bool _disposed;

    public NativeResource() => _handle = NativeLib.Allocate();

    public void Dispose()
    {
        if (!_disposed)
        {
            NativeLib.Free(_handle);
            _disposed = true;
            GC.SuppressFinalize(this); // remove from finalizer queue
        }
    }

    ~NativeResource() // safety net for callers who forget Dispose()
    {
        if (!_disposed) NativeLib.Free(_handle);
    }
}

GC.SuppressFinalize(this) in Dispose() removes the object from the finalizer queue — if the user correctly called Dispose(), the finalizer never runs, avoiding the GC penalty.

IAsyncDisposable — for async cleanup scenarios (await using var resource = new AsyncResource()).

Interviewers probe: when is a finalizer actually justified? Only when wrapping a raw unmanaged handle that must be freed even if Dispose() is never called — and even then, prefer inheriting from SafeHandle (which already implements the finalize/dispose pattern correctly).

Both are used to coordinate multiple concurrent Task objects, but they have different completion semantics.

Task.WhenAll(tasks) — completes when all tasks complete:

var task1 = FetchUserAsync(1);
var task2 = FetchOrdersAsync(1);
var task3 = FetchPreferencesAsync(1);

var (user, orders, prefs) = await (task1, task2, task3); // ValueTuple await (.NET 7+)
// or:
await Task.WhenAll(task1, task2, task3);

• All tasks run concurrently
• If any task throws, WhenAll collects all exceptions in an AggregateException; awaiting it rethrows the first
• Returns Task when all tasks return the same type

Task.WhenAny(tasks) — completes when the first task completes:

var timeout = Task.Delay(TimeSpan.FromSeconds(5));
var work = DoSlowWorkAsync();

var completed = await Task.WhenAny(work, timeout);
if (completed == timeout)
    throw new TimeoutException();

• Returns the first completed Task (not the result)
• Other tasks continue running unless you cancel them
• Classic use: implementing timeouts, racing multiple sources for the fastest response

.NET 9 — Task.WhenEach(): process tasks as they complete (without knowing which finishes first):

await foreach (var completedTask in Task.WhenEach(task1, task2, task3))
{
    var result = await completedTask;
    Console.WriteLine($"Got: {result}");
}

Interviewers probe: what happens to the losing tasks in WhenAny? They keep running unless explicitly cancelled with a CancellationToken. Always pass a token and cancel on completion to avoid resource leaks.