What Interviewers Actually Probe For
.NET interviews typically test three layers: fundamentals of the Common Language Runtime (CLR) such as garbage collection generations and boxing/unboxing costs; framework idioms like async/await and LINQ deferred execution; and architectural patterns like dependency injection and the options pattern used throughout ASP.NET Core. A strong candidate can explain not just what a keyword does but why it exists — for example, explaining that boxing a value type like an int into an object allocates on the heap and incurs a GC cost, which matters when writing a hot loop that processes millions of items.
Cricket analogy: A good interview answer on boxing is like a commentator explaining not just that a batsman played a reverse sweep, but why it was the right shot against that specific field placement and bowler — the reasoning matters as much as the fact.
Async/Await and Common Pitfalls
async/await in C# compiles into a state machine that frees the calling thread while an I/O-bound operation (a database query, an HTTP call) is in flight, rather than blocking it. A classic interview trap is explaining why calling .Result or .Wait() on a Task from a synchronous context can deadlock in certain environments (classic ASP.NET with a SynchronizationContext) — the blocked thread is waiting for the continuation, but the continuation needs to resume on that same captured context, which never frees up. The fix is to use await all the way up the call stack ('async all the way') or call ConfigureAwait(false) on library code that doesn't need to resume on the original context.
Cricket analogy: Blocking with .Result is like a captain refusing to make any other decision while personally waiting at the boundary rope for a specific fielder's throw, freezing the whole team's strategy instead of letting other players continue their roles.
Dependency Injection and Service Lifetimes
ASP.NET Core ships with a built-in dependency injection container configured in Program.cs via builder.Services.AddScoped<IMyService, MyService>(), and interviewers frequently probe the three lifetimes: Transient creates a new instance every time it's requested, Scoped creates one instance per HTTP request, and Singleton creates one instance for the entire application lifetime. A common pitfall is injecting a Scoped or Transient service into a Singleton — this 'captive dependency' problem locks a short-lived object inside a long-lived one, so it keeps referencing stale data (like a disposed DbContext) for the whole application's life instead of being refreshed per request.
Cricket analogy: A Singleton service is like a single stadium groundskeeper who serves the entire tournament, while Scoped is like a fresh substitute fielder brought on for each individual match, and Transient is like a new ball issued for every single over.
var builder = WebApplication.CreateBuilder(args);
// Transient: new instance every time it's requested
builder.Services.AddTransient<IGuidGenerator, GuidGenerator>();
// Scoped: one instance per HTTP request
builder.Services.AddScoped<IOrderRepository, OrderRepository>();
// Singleton: one instance for the app's lifetime
builder.Services.AddSingleton<ICacheService, MemoryCacheService>();
var app = builder.Build();
app.MapGet("/orders/{id}", async (int id, IOrderRepository repo) =>
await repo.GetByIdAsync(id));
app.Run();A frequently asked follow-up: 'What happens if you inject a Scoped service into a Singleton?' The correct answer is that .NET's DI container throws an InvalidOperationException at runtime by default when validation is enabled (ValidateScopes = true), specifically to catch this captive dependency bug early rather than letting it silently corrupt data.
Don't answer 'what is async/await' with just 'it makes code run in parallel' — that's incorrect and will lose you points. async/await enables non-blocking, asynchronous I/O on a single logical flow; true parallelism (multiple CPU cores running simultaneously) is a separate concept handled by Parallel.ForEach or Task.WhenAll running independent tasks concurrently.
- Strong candidates explain the 'why' behind a language feature, not just its syntax.
- Boxing a value type allocates on the managed heap and adds GC pressure in hot paths.
- async/await frees the calling thread during I/O without blocking; it is not the same as parallelism.
- Blocking on .Result or .Wait() can deadlock in contexts with a captured SynchronizationContext.
- ASP.NET Core's built-in DI container supports Transient, Scoped, and Singleton lifetimes.
- Injecting a Scoped service into a Singleton creates a captive dependency bug.
- DI validation (ValidateScopes = true) can catch captive dependency mistakes at startup.
Practice what you learned
1. What does boxing a value type like an int into an object involve?
2. Why can calling .Result on a Task deadlock in classic ASP.NET but often not in ASP.NET Core?
3. Which DI lifetime creates exactly one instance for the entire duration of an HTTP request?
4. What problem occurs when a Scoped service is injected into a Singleton?
5. What is the key distinction between async/await and true parallelism in .NET?
Was this page helpful?
You May Also Like
.NET Core Quick Reference
A condensed reference covering essential dotnet CLI commands, LINQ/collection quick facts, and configuration patterns for everyday .NET Core development.
Unit Testing in .NET
How to write fast, isolated unit tests for .NET applications using xUnit and Moq, and the practices that keep a test suite trustworthy.
.NET Versioning and LTS Releases
How .NET's release cadence, LTS vs STS support tiers, and target framework monikers work, and how to plan upgrades around them.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics