.NET Interview Questions With Model Answers

Published · by JOBB GROUP FZE

Most .NET interviews follow the same pattern. The first questions check that you understand the runtime: how code is compiled and executed, how memory is managed and how data queries actually run. Later questions, especially for experienced candidates, move to ASP.NET Core: dependency injection, the middleware pipeline and what happens under load. Interviewers are rarely impressed by recited definitions. They want to hear that you know what goes wrong in production and why.

Each question below has three parts: an illustrative model answer, a note on what the answer shows the interviewer, and the follow-up you should expect. Technical facts are taken from Microsoft’s own documentation, linked in each section. The model answers are examples to adapt, not scripts to memorise.

First, know which .NET they mean

“We use .NET” can mean the modern cross-platform .NET (5 and later) or the older Windows-only .NET Framework. Ask early, because it changes which questions make sense. For modern .NET, Microsoft publishes a new major release every November. Even-numbered releases are Long Term Support (LTS) releases with three years of free support and patches; odd-numbered releases are Standard Term Support (STS) releases with two years (Microsoft).

As of November 2026, Microsoft’s support table lists .NET 10 (released 11 November 2025) as the active LTS release, supported until 14 November 2028. .NET 8 and .NET 9 are both in maintenance and reach end of support on 10 November 2026 (Microsoft). If you are asked which version you would pick for a new service, the defensible answer is the current LTS release, unless the team has a reason to take an STS release and upgrade sooner.

.NET interview questions for freshers

If the interview also tests the C# language itself, expect value and reference types, boxing, the using statement and async/await basics. The questions here stay on the platform: what the runtime does with your code, how it manages memory, and the mistakes that only show up when an application runs under real load.

1. What happens between compiling your code and running it?

Model answer (illustrative): “The C# compiler doesn’t produce machine code. It produces intermediate language plus metadata describing the types and members, packaged in an assembly. At run time the just-in-time compiler turns that intermediate language into native code, method by method, the first time each method is called, and keeps the result in memory for later calls. The runtime also provides services such as garbage collection and type-safety checks.”

What it shows: you know where the runtime fits. Microsoft’s description of the managed execution process says compilers translate source code into common intermediate language (CIL) and metadata, that CIL is converted to native code as needed during execution, and that managed code receives services such as garbage collection (Microsoft Learn).

Likely follow-up: “Why might the first request to a new deployment be slow?” Part of the answer is JIT work on first calls, alongside caches warming up and connections opening.

2. How does garbage collection work in .NET, and what is the large object heap?

Model answer (illustrative): “New objects are allocated on the managed heap. When the runtime needs memory back, the garbage collector finds objects the application can no longer reach and reclaims them. It is generational: generation 0 holds new objects, generation 1 is a buffer, and generation 2 holds long-lived objects. Most objects die young, so collecting generation 0 often is cheap. Objects of 85,000 bytes or more go on the large object heap, which is collected with generation 2.”

What it shows: you know the design reason for generations. Microsoft’s documentation says that in a well-tuned app most objects die in generation 0, that generation 1 acts as a buffer, and that a generation 2 collection is also called a full GC. It also confirms the 85,000-byte threshold and that large objects belong to generation 2 (Microsoft Learn).

Likely follow-up: “Why might large arrays cause problems?” Because the GC normally sweeps the large object heap rather than compacting it, since compaction is expensive, which can leave fragmentation (Microsoft Learn). Repeatedly allocating large temporary buffers is a common cause of memory pressure.

3. Should you create a new HttpClient for every request?

Model answer (illustrative): “No. Each HttpClient has its own connection pool, so creating and disposing one per request keeps opening new connections, and under load the server can run out of ports. In modern .NET I’d use one long-lived client with PooledConnectionLifetime set, so connections are recycled and DNS changes are picked up, or use IHttpClientFactory, typically with typed clients.”

What it shows: you know the classic production failure behind a reasonable-looking using block. Microsoft’s HttpClient guidelines describe the port-exhaustion problem, warn that a long-lived client keeps using old DNS results unless connections are recycled, and recommend either a static or singleton client with PooledConnectionLifetime or IHttpClientFactory (Microsoft Learn).

Likely follow-up: “Then why does HttpClient implement IDisposable at all?” Because disposing releases its connections; the point is to dispose it at the end of its useful life, not after each call.

4. What is the difference between IEnumerable and IQueryable when using Entity Framework Core?

Model answer (illustrative): “With IQueryable, the query is built as an expression tree and the provider translates it into SQL, so filters run in the database. Once I switch to IEnumerable, for example by calling AsEnumerable() or ToList(), the remaining operators run in memory. If I call ToList() before Where, I load the whole table and filter it in the application.”

// Filter runs in the database
var open = await db.Orders.Where(o => o.Status == "Open").ToListAsync();

// Whole table loaded, then filtered in memory
var openSlow = db.Orders.ToList().Where(o => o.Status == "Open").ToList();

What it shows: you can spot the performance bug before it reaches production. It also rests on deferred execution, which Microsoft defines as delaying evaluation of an expression until its realised value is actually required (Microsoft Learn): nothing is sent to the database until the query is enumerated.

Likely follow-up: “What is the risk of enumerating the same query twice?” The query, and the database call behind it, runs twice.

.NET interview questions for experienced developers

5. Explain the three service lifetimes, and a bug you have seen with them

Model answer (illustrative): “Transient services are created every time they’re requested. Scoped services are created once per request in a web app. Singletons are created once and shared. The classic bug is a singleton taking a scoped service, such as a DbContext, in its constructor. The scoped service then lives as long as the singleton and carries state between requests. If a singleton genuinely needs scoped work, I inject IServiceScopeFactory and create a scope for each unit of work.”

public sealed class ReportScheduler(IServiceScopeFactory scopes)
{
    public async Task RunAsync()
    {
        using var scope = scopes.CreateScope();
        var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
        // work with db, then the scope disposes it
    }
}

What it shows: production experience. Microsoft’s guidance warns that resolving a scoped service directly from a singleton makes it behave like a singleton and can lead to incorrect state, and says an explicit scope created with IServiceScopeFactory is the acceptable alternative (Microsoft Learn). The same page notes that singletons must be thread safe (Microsoft Learn).

Likely follow-up: “Why didn’t you notice it in development?” You might have: by default, in the Development environment, resolving a service from another service with a longer lifetime throws an exception (Microsoft Learn). Problems appear when that validation is off or the dependency is resolved in a way it doesn’t catch.

6. Why does middleware order matter? Give an example

Model answer (illustrative): “Middleware runs in the order it’s registered on the way in and in reverse on the way out. Each component can do work, call the next one or short-circuit. So authentication has to come before authorization, or authorization has no user to check. Exception handling goes first so it can catch errors from everything after it.”

app.UseExceptionHandler("/error");
app.UseHttpsRedirection();
app.UseRouting();
app.UseCors();
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();

What it shows: you’ve debugged a pipeline. Microsoft’s documentation says the order in Program.cs defines the order components are invoked on requests and the reverse order for the response, and calls the order critical for security, performance and functionality. It states that UseCors, UseAuthentication and UseAuthorization must appear in that order (Microsoft Learn).

Likely follow-up: “What is terminal middleware?” Middleware that does not call the next delegate, which short-circuits the pipeline (Microsoft Learn). Static files are a common example: once a file is served, there is no need to run the rest.

7. Should you use ConfigureAwait(false) everywhere?

Model answer (illustrative): “In reusable library code, yes, it’s a sensible default because the library doesn’t know what context its caller has. In ASP.NET Core application code it makes no difference, because there is no SynchronizationContext by default. In a desktop UI handler I want the continuation back on the UI thread, so I leave it off.”

What it shows: you know when advice applies. Microsoft’s CA2007 page notes that by default a continuation runs on the context that created the task, which can deadlock a UI thread, and says passing false is a good option for app-independent libraries, that ASP.NET Core by default has no SynchronizationContext or TaskScheduler so ConfigureAwait doesn’t change behaviour there, and that suppressing the rule is generally appropriate for application code (Microsoft Learn).

8. A service’s memory keeps growing for days. How do you investigate?

Model answer (illustrative): “First I’d confirm it’s managed memory by watching GC heap size and generation counts in the runtime counters. If generation 2 and the large object heap keep growing, something is holding references. I’d take two memory dumps a few hours apart and compare which types grew. Usual suspects are static or singleton caches with no size limit, event handlers that are never unsubscribed, and large buffers allocated per request.”

What it shows: a method rather than guesses. It ties back to facts you can cite: Microsoft notes that singleton memory isn’t released until the app shuts down, so memory use deserves attention (Microsoft Learn), and that large objects are only collected during generation 2 collections (Microsoft Learn).

Likely follow-up: “Would you call GC.Collect()?” Almost never in production code; it hides the leak rather than fixing it.

9. How do you keep a .NET estate supported?

Model answer (illustrative): “I track the support dates for every runtime we deploy. Services still on .NET 8 or 9 reach end of support on 10 November 2026, so they need a plan to move to .NET 10. I’d rather move LTS to LTS on a regular schedule, with good test coverage, than do one painful jump across several versions.”

What it shows: ownership beyond your own code. The dates come from Microsoft’s support policy page (Microsoft).

How to prepare in the week before

  1. Rebuild one small API from scratch with a controller or minimal API, one scoped service and one singleton. Break the lifetimes deliberately and read the exception.
  2. Reorder your middleware and watch what changes. Being able to say “I tried it” carries more weight than a definition.
  3. Write two versions of the same EF Core query, one filtered in the database and one in memory, and compare the SQL each one logs.
  4. Prepare two production stories: a bug you diagnosed and a performance problem you fixed, with the numbers you measured.

Make sure your CV backs up what you say in the room: name the .NET versions, frameworks and data tools you actually used. The software engineer resume builder has prompts for describing technical projects, and the resume questions hub answers common formatting questions.

FAQ

What .NET topics come up most in interviews?

For every level: how the runtime executes code, garbage collection, HttpClient use and Entity Framework Core query behaviour, plus C# language basics. Experienced roles add ASP.NET Core dependency injection, middleware, async context behaviour and production debugging.

Are .NET Framework questions still asked?

Yes, where an employer maintains older Windows applications. Ask which platform the team uses. If it is .NET Framework, expect questions about migrating to modern .NET as well.

How much C# syntax do I need to memorise?

Less than you think. Interviewers care more about predicting what code does and explaining trade-offs. Know the features you claim on your CV well enough to explain them.

Which .NET version should I practise on?

As of November 2026, .NET 10 is the current LTS release, so it is the safest choice for practice projects.

Sources

Ready to build your resume?

Start with a sample or a blank page. No sign-up needed. Free to edit; US$1.00 only if you download a PDF.

Build My ATS ResumeExplore Resume Templates