How to Approach ASP.NET Core Interviews
ASP.NET Core interviews typically probe three layers: fundamentals (the request pipeline, dependency injection lifetimes, configuration), practical experience (how you structure a real project, handle errors, write tests), and system-level thinking (how a service scales, handles concurrency, or integrates with a database under load). Strong candidates explain not just what a feature does but why it exists — for example, why Scoped is the default lifetime for a DbContext rather than Singleton.
Cricket analogy: Interviewers probing fundamentals, experience, and system thinking is like a national selector evaluating a player's technique in the nets, their scoring record in domestic cricket, and how they'd handle captaincy pressure in a World Cup final — three very different lenses on the same candidate.
Core Concepts Interviewers Probe
Expect deep questions on the middleware pipeline (order matters — UseAuthentication must precede UseAuthorization), the three DI lifetimes (Transient, Scoped, Singleton) and the bugs that arise from injecting a Scoped service into a Singleton (captive dependency), and the difference between IHostedService background tasks and simple fire-and-forget async calls. Interviewers often ask you to trace what happens end-to-end when a request hits app.Run(), from Kestrel through middleware to the controller and back.
Cricket analogy: Middleware ordering mattering like UseAuthentication before UseAuthorization is like a stadium's entry sequence — security must check your ticket (authentication) before the usher decides which stand you're allowed into (authorization); reversing the order makes no sense operationally.
// Captive dependency bug: Singleton holds onto a Scoped DbContext forever
public class CacheWarmer : IHostedService
{
private readonly AppDbContext _db; // WRONG: injected as Scoped into a Singleton-lifetime service
public CacheWarmer(AppDbContext db) => _db = db;
public Task StartAsync(CancellationToken ct) =>
_db.Products.LoadAsync(ct); // uses a stale/disposed context on later calls
}
// Fix: inject IServiceScopeFactory and create a scope per operation
public class CacheWarmerFixed : IHostedService
{
private readonly IServiceScopeFactory _scopeFactory;
public CacheWarmerFixed(IServiceScopeFactory scopeFactory) =>
_scopeFactory = scopeFactory;
public async Task StartAsync(CancellationToken ct)
{
using var scope = _scopeFactory.CreateScope();
var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
await db.Products.LoadAsync(ct);
}
}Common Pitfalls Candidates Should Be Ready to Discuss
A frequent trick question involves async void versus async Task — async void swallows exceptions and can't be awaited, so it should only ever be used for event handlers, never controller actions or service methods. Another common area is EF Core's change tracking and the N+1 query problem, where a naive foreach loop calling a lazy-loaded navigation property issues one query per iteration; interviewers want you to identify the fix (Include, projection, or AsNoTracking for read-only queries).
Cricket analogy: async void swallowing exceptions like an unhandled error is like a fielder dropping a catch with no umpire or camera watching — the mistake happens but there's no mechanism to record it, review it, or hold anyone accountable, unlike a properly reviewed DRS decision.
async void methods cannot be awaited and any exception thrown inside one will crash the process (or vanish silently in some hosts) instead of propagating to a caller's try/catch — this is one of the most commonly cited real production incidents in ASP.NET Core interviews, so be ready to explain the fix: always use async Task.
System Design Style Questions
Senior-level interviews often shift to system design: how would you version an API without breaking existing clients (URL versioning vs. header versioning), how would you make an endpoint idempotent for retries (idempotency keys stored with a short TTL), or how would you scale a stateful SignalR hub across multiple instances (a backplane like Azure SignalR Service or Redis). These questions test whether you can extend ASP.NET Core fundamentals into distributed-systems reasoning.
Cricket analogy: Scaling a stateful SignalR hub with a backplane like Redis is like the BCCI syncing live scores across multiple regional broadcast centers so that whichever center a viewer connects to, they see the exact same real-time score — a shared source of truth across distributed nodes.
When asked a system-design question, narrate trade-offs out loud — e.g., 'URL versioning is simpler for clients to discover but pollutes the route table, while header versioning keeps URLs clean but is easy for API consumers to forget.' Interviewers care more about your reasoning than landing on one 'correct' answer.
- Interviews probe fundamentals, real project experience, and system-level reasoning
- Middleware order matters: authentication before authorization
- Watch for captive dependency bugs when Singletons hold Scoped services
- Never use async void outside of event handlers
- Fix EF Core's N+1 problem with Include, projection, or AsNoTracking
- Be ready to discuss API versioning and idempotency strategies
- Scaling SignalR requires a backplane like Redis or Azure SignalR Service
Practice what you learned
1. Which middleware must be registered before UseAuthorization in the ASP.NET Core pipeline?
2. What causes a 'captive dependency' bug?
3. Why is async void dangerous in application code?
4. What's a common fix for EF Core's N+1 query problem?
5. What's a typical solution for scaling a SignalR hub across multiple server instances?
Was this page helpful?
You May Also Like
Unit Testing Controllers and Services
Learn how to isolate ASP.NET Core controllers and services with xUnit and Moq to verify business logic without running the full HTTP pipeline.
Integration Testing with WebApplicationFactory
Use Microsoft.AspNetCore.Mvc.Testing's WebApplicationFactory to spin up an in-memory ASP.NET Core app and test real HTTP requests through the full middleware pipeline.
Logging and Observability with Serilog
Configure structured logging with Serilog and pair it with metrics and distributed tracing to build real observability into an ASP.NET Core API.
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