.NET Interview Questions for 5 Years Experience with Answers

A class is a reference type allocated on the heap; a struct is a value type typically allocated on the stack (or inline in its containing type). The key differences are:

Choose struct when: the type is small (≤16 bytes), logically represents a single value, is immutable, and doesn't need to be boxed frequently. Examples: Point, DateTime, Guid.

When the compiler processes an async method, it transforms it into a state machine — a struct implementing IAsyncStateMachine. Each await point becomes a state transition.

public async Task<string> FetchDataAsync(string url)
{
    var client = new HttpClient();
    // Compiler inserts a suspension point here
    var result = await client.GetStringAsync(url);
    return result.ToUpper();
}

When await is hit: if the awaitable is already complete, execution continues synchronously. If not, a continuation (callback) is registered on the Task, and the method returns the incomplete Task to the caller. When the awaited work finishes, the continuation resumes the state machine at the next state.

Critical distinction: An IQueryable builds an expression tree. Only when you materialise it (e.g., .ToList()) does the SQL get generated and sent to the database. Calling LINQ methods on an already-materialised IEnumerable (after ToList()) performs the filtering in memory — always be deliberate about where you materialise.

Span<T> is a stack-only, ref struct that provides a safe, zero-copy window into a contiguous block of memory (array, stack-allocated buffer, or unmanaged memory). Memory<T> is the heap-compatible counterpart that can be stored in fields and used with async.

// Parse a CSV line without allocating substrings
void ParseLine(ReadOnlySpan<char> line)
{
    int comma = line.IndexOf(',');
    ReadOnlySpan<char> first = line[..comma];
    ReadOnlySpan<char> second = line[(comma + 1)..];
    // No heap allocation for substrings
}

Real-world use: High-throughput JSON/CSV parsing, network buffer slicing in ASP.NET Core Kestrel, and any hot path where reducing GC pressure is critical.

== (operator): For reference types, checks reference equality by default (unless overloaded, e.g., string). For value types, checks value equality.

Equals() (virtual method): Can be overridden to provide semantic/value equality. string.Equals() compares content, not reference.

ReferenceEquals(): Always compares object identity (pointer equality). Cannot be overridden. Even two interned strings with the same content may return true from ReferenceEquals due to string interning.

In ASP.NET Core, the middleware pipeline is a chain of request delegates. Each middleware component receives an HttpContext, can execute code before and after the next component, and decides whether to call next().

app.Use(async (context, next) =>
{
    // Before next middleware
    await next.Invoke();
    // After next middleware (response phase)
});

app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();

vs. HTTP Modules (classic ASP.NET): Modules were event-based and tightly coupled to System.Web. They fired on specific pipeline events (BeginRequest, AuthenticateRequest, etc.) in a fixed order. Middleware is simpler, more composable, and completely decoupled from IIS. Order is explicit and determined by the order you register in Program.cs.

Captive dependency problem: Injecting a Scoped or Transient service into a Singleton causes the shorter-lived service to be "captured" and reused for the entire app lifetime — causing stale data, threading issues, or leaked DbContext connections.

Minimal APIs (introduced in .NET 6) define endpoints directly in Program.cs without controllers or action methods:

app.MapGet("/products/{id}", async (int id, IProductService svc) =>
    await svc.GetByIdAsync(id) is { } product
        ? Results.Ok(product)
        : Results.NotFound());

When to use Minimal APIs: Microservices, small focused APIs, or when you want maximum control with minimum overhead. Use controllers for larger projects with complex cross-cutting concerns.

The N+1 problem occurs when you load a collection and then lazily fetch related data for each item — resulting in 1 query for the list + N queries for the related entities.

// ❌ N+1: 1 query for orders + N queries for customers
var orders = context.Orders.ToList();
foreach (var o in orders)
    Console.WriteLine(o.Customer.Name); // lazy load per order

// ✅ Eager loading — single JOIN query
var orders = context.Orders
    .Include(o => o.Customer)
    .ToList();

Solutions:

• Eager loading with Include() / ThenInclude() — join in a single query.

• Explicit loading with context.Entry(entity).Collection().LoadAsync() — when conditional loading is needed.

• Projection — use Select() to fetch only the columns you need, avoiding full entity hydration.

By default, EF Core tracks entities returned from queries using a change tracker. This allows it to detect modifications and generate appropriate UPDATE/DELETE SQL when you call SaveChanges().

AsNoTracking() skips the change tracker entirely. The entities are still materialised but EF Core doesn't monitor them. This is faster and uses less memory — ideal for read-only scenarios (report endpoints, read APIs).

// Read-only — no tracking overhead
var products = await context.Products
    .AsNoTracking()
    .Where(p => p.IsActive)
    .ToListAsync();

Use tracking when you need to update entities after loading. Use AsNoTracking() when you only read data — it can be 20–30% faster for large result sets.

Managing migrations in a team requires discipline around:

1. Never auto-apply in Production. Use Database.Migrate() only in Development or CI pipelines. In Production, generate SQL scripts and apply them via your deployment process.

# Generate idempotent SQL script
dotnet ef migrations script --idempotent -o migration.sql

2. Merge conflicts. When two developers add migrations simultaneously, one must remove their migration, pull the other's, and re-apply on top. Never edit a migration that's been applied to Production.

3. Squash old migrations. For large projects, periodically squash old migrations into a baseline snapshot to reduce startup time and history noise.

4. Separate migration projects for large solutions to keep data access concerns isolated.

The Repository pattern abstracts data access behind an interface, decoupling business logic from the ORM. The Unit of Work groups multiple repository operations into a single transaction.

public interface IProductRepository
{
    Task<Product?> GetByIdAsync(int id);
    Task AddAsync(Product product);
}

public interface IUnitOfWork
{
    IProductRepository Products { get; }
    Task<int> SaveChangesAsync();
}

When NOT to use it: EF Core's DbContext already IS a Unit of Work, and DbSet<T> is already a Repository. Adding a generic wrapper on top (e.g., Repository<T> that just delegates to DbSet) adds boilerplate with zero benefit. Use it only when you need to abstract across multiple data sources or need testability without mocking EF Core internals.

CQRS (Command Query Responsibility Segregation) separates read (query) and write (command) models. Commands change state; queries return data. This allows independent scaling and optimisation of each side.

A popular .NET implementation uses MediatR:

// Command
public record CreateOrderCommand(int CustomerId, List<OrderItem> Items)
    : IRequest<Guid>;

// Handler
public class CreateOrderHandler : IRequestHandler<CreateOrderCommand, Guid>
{
    public async Task<Guid> Handle(
        CreateOrderCommand cmd, CancellationToken ct)
    {
        var order = new Order(cmd.CustomerId, cmd.Items);
        await _repo.AddAsync(order, ct);
        return order.Id;
    }
}

The Decorator pattern wraps a service to add behaviour (caching, logging, validation) without modifying the original class — following the Open/Closed Principle.

// Original service
public class ProductService : IProductService { ... }

// Decorator adds caching
public class CachedProductService : IProductService
{
    private readonly IProductService _inner;
    private readonly IMemoryCache _cache;

    public async Task<Product?> GetByIdAsync(int id) =>
        await _cache.GetOrCreateAsync($"product-{id}",
            _ => _inner.GetByIdAsync(id));
}

// Registration (manual decorator wiring)
services.AddScoped<ProductService>();
services.AddScoped<IProductService>(sp =>
    new CachedProductService(sp.GetRequiredService<ProductService>(),
                              sp.GetRequiredService<IMemoryCache>()));

Libraries like Scrutor provide .Decorate<IProductService, CachedProductService>() for cleaner registration.

The .NET GC uses a generational model based on the assumption that most objects die young:

Objects that survive a collection are promoted to the next generation. Gen2 collections are the most expensive (stop-the-world in some modes). In server GC mode, each processor core has its own heap to enable parallel collection.

Implement IDisposable when your class holds unmanaged resources (file handles, DB connections, native memory) or references to other IDisposable objects. The full dispose pattern for classes that may be subclassed:

public class ResourceWrapper : IDisposable
{
    private bool _disposed;

    protected virtual void Dispose(bool disposing)
    {
        if (_disposed) return;
        if (disposing)
        {
            // Free managed resources
            _stream?.Dispose();
        }
        // Free unmanaged resources here
        _disposed = true;
    }

    public void Dispose() { Dispose(true); GC.SuppressFinalize(this); }
}

Use using for locally-scoped disposables (streams, connections). Let DI manage lifetime for services registered as Scoped/Singleton — the DI container calls Dispose() when the scope ends.

Choose synchronous when: the caller needs an immediate result (user-facing query, auth validation). Choose async when: order placed → email sent → inventory updated — these can happen independently and should be resilient to partial failure.

Polly is a .NET resilience library that provides policies for: Retry, Circuit Breaker, Timeout, Bulkhead Isolation, and Fallback.

// .NET 8 — Resilience pipeline via Microsoft.Extensions.Resilience
services.AddHttpClient<IOrderClient, OrderClient>()
    .AddResilienceHandler("orders", builder =>
    {
        builder.AddRetry(new HttpRetryStrategyOptions
        {
            MaxRetryAttempts = 3,
            BackoffType = DelayBackoffType.Exponential
        });
        builder.AddCircuitBreaker(new HttpCircuitBreakerStrategyOptions
        {
            SamplingDuration = TimeSpan.FromSeconds(10),
            FailureRatio = 0.5,
            MinimumThroughput = 10
        });
        builder.AddTimeout(TimeSpan.FromSeconds(5));
    });

Circuit Breaker states: Closed (normal) → Open (failing; fast-fail requests) → Half-Open (test recovery) → Closed.

A JWT (JSON Web Token) consists of three base64-encoded parts: Header (algorithm), Payload (claims), and Signature. The server signs it with a secret (HS256) or private key (RS256). Clients send it in the Authorization: Bearer <token> header.

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuerSigningKey = true,
            IssuerSigningKey = new SymmetricSecurityKey(key),
            ValidateIssuer = true,
            ValidateAudience = true,
            ClockSkew = TimeSpan.Zero // Remove 5-min leeway
        };
    });

Common pitfalls:

• Storing JWTs in localStorage (XSS vulnerable) — prefer HttpOnly cookies.

• Not validating alg — an attacker could send "alg": "none".

• Long-lived access tokens — use short expiry (15 min) with refresh tokens.

• Not checking token revocation — JWTs are stateless; use a deny-list or short expiry.

Authentication answers "Who are you?" — verifying identity (JWT, cookies, API keys). Authorization answers "What are you allowed to do?" — verifying permissions.

// Policy-based authorization
builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("AdminOnly", policy =>
        policy.RequireRole("Admin"));

    options.AddPolicy("MinAge18", policy =>
        policy.Requirements.Add(new MinimumAgeRequirement(18)));
});

// On controller/endpoint
[Authorize(Policy = "AdminOnly")]
public IActionResult AdminDashboard() => Ok();

ASP.NET Core supports role-based, claim-based, and policy-based authorisation. Always prefer policy-based as it is more expressive and testable.

Recommended structure: Follow the Testing Trophy — heavy integration tests in the middle, a solid layer of unit tests, minimal E2E tests. Separate test projects per type: MyApp.UnitTests, MyApp.IntegrationTests.

Stub: Returns canned responses; used to isolate the system under test. No assertion on calls.

Mock: A stub that also asserts it was called correctly. Created with Moq or NSubstitute.

Fake: A working lightweight implementation (e.g., in-memory database) used instead of the real one.

// Moq example — mock + verify
var mockRepo = new Mock<IProductRepository>();
mockRepo.Setup(r => r.GetByIdAsync(1))
        .ReturnsAsync(new Product { Id = 1, Name = "Widget" });

var service = new ProductService(mockRepo.Object);
var result = await service.GetProductAsync(1);

mockRepo.Verify(r => r.GetByIdAsync(1), Times.Once);
Assert.Equal("Widget", result.Name);

Microsoft unified the fragmented ecosystem under a single "just .NET" brand starting with .NET 5 in 2020. It combines the performance and cross-platform benefits of .NET Core with modern C# features. LTS releases (6, 8) are supported for 3 years.

BackgroundService is an abstract base class implementing IHostedService for running long-running background tasks within an ASP.NET Core application — like consuming a message queue, running scheduled jobs, or processing a channel.

public class OrderProcessorService : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        await foreach (var order in _channel.ReadAllAsync(stoppingToken))
        {
            await ProcessOrderAsync(order);
        }
    }
}

// Register in Program.cs
builder.Services.AddHostedService<OrderProcessorService>();

The hosted service starts with the app and is gracefully stopped when the app shuts down via the CancellationToken. Use Channel<T> for producer-consumer patterns within a single process.

Task.WhenAll: Awaits all tasks to complete. If any task faults, the exception is aggregated. Use for fan-out parallel async work where all results are needed.

Task.WhenAny: Returns as soon as the first task completes. Use for timeout patterns or "first result wins" scenarios (e.g., querying multiple cache layers).

// WhenAll — fetch user + orders + products in parallel
var (user, orders) = await (Task.WhenAll(GetUserAsync(id), GetOrdersAsync(id)))
    .ContinueWith(t => (t.Result[0], t.Result[1]));

// Parallel.ForEachAsync — bounded concurrency over a large collection
await Parallel.ForEachAsync(productIds,
    new ParallelOptions { MaxDegreeOfParallelism = 4 },
    async (id, ct) => await ProcessProductAsync(id, ct));

Parallel.ForEachAsync (introduced in .NET 6) is ideal when you have a large collection and want bounded concurrency — better than spawning unlimited tasks with Task.WhenAll on a huge list.