Senior .NET Backend Developer — .NET interview questions

What is the difference between the workstation and server GC, and when do you tune it?

Workstation GC runs collections on the thread that triggered them, tuned for low pause times on a UI-adjacent workload; Server GC runs one heap and thread per core, favors throughput, and is the default for ASP.NET Core apps in most hosting scenarios. Concurrent (background) GC lets gen 2 collections run alongside the app at some cost to throughput. Reach for dotnet-counters and dotnet-trace to see collection rates and pause times before touching any setting — tuning blind trades one problem for a worse one.

What does Native AOT trade off against the standard JIT-compiled deployment model?

Native AOT compiles ahead of time to a self-contained native executable — no JIT warm-up, near-instant startup, a smaller footprint, which matters for containers that scale to zero or functions where cold start is the metric that matters. The cost is that runtime reflection, dynamic code generation, and some third-party libraries built around JIT semantics either break or need explicit trimming annotations, and the build is platform-specific. It is worth it for a latency-sensitive service with a known, AOT-compatible dependency graph, not as a default.

How do you approach containerizing and deploying an ASP.NET Core service to production?

A multi-stage Dockerfile builds in the SDK image, publishes, and copies only the output into the runtime-only ASP.NET image, cutting image size and keeping the SDK out of the attack surface. Configuration comes from environment variables and a secrets manager — Azure Key Vault, AWS Secrets Manager — never baked into the image. In production, graceful shutdown via IHostApplicationLifetime, health check endpoints for the orchestrator, and structured logging shipped somewhere queryable matter more than the Dockerfile itself, because docker logs on a dead container is not a debugging strategy.

A junior on your team ships a service that passes every test but times out under production load. How do you lead the investigation?

Start from what differs between production and tests — usually concurrency and data volume, which a default single-threaded xUnit run hides completely. Pull dotnet-trace or APM data instead of guessing, because "it feels like the database" is how hours get wasted; thread-pool starvation from blocking on async code (.Result or .Wait() inside a request) looks identical to a slow query until you actually look. Past the fix, the more valuable move is turning it into something the team can check for automatically — an analyzer rule or a review checklist item — so the same class of bug does not ship twice.

How do you evaluate whether to migrate a legacy .NET Framework application to modern .NET?

Start from what is actually blocking you — Windows-only hosting, an end-of-life library, or a real performance ceiling — because migration for its own sake burns months without moving the product forward. .NET Framework and modern .NET diverge most around Web Forms, WCF, and certain reflection-heavy libraries, none of which have a clean 1:1 replacement, so the real cost lives in inventorying those rather than in the bulk of straightforward ASP.NET MVC/Web API code. The incremental path — running old and new side by side behind a reverse proxy, migrating route by route — ships value continuously instead of freezing the team on a multi-quarter rewrite with nothing to show until the end.