What .NET interview questions should I expect?

Interviewers start where the framework starts: the runtime. Expect to explain what the Common Language Runtime does (loading assemblies, just-in-time compiling intermediate language, managing memory), then to go one level down on garbage collection. The follow-up chain is predictable: why the collector is generational, what makes an object survive to a later generation, what the large object heap is for, and why IDisposable and using exist at all if memory is managed. Answer the last one with unmanaged resources such as file handles and connections, which the collector does not know how to release promptly.

• Value types and reference types. Where each lives, what copying means for each, and what boxing costs.
• async and await. Explain that an awaited task frees the calling thread rather than blocking it, why async void is reserved for event handlers, and what deadlock people mean when they warn about .Result.
• LINQ. Deferred execution is the trap: an IEnumerable query runs when enumerated, not when written, and a query against a database provider translates to SQL only for expressions the provider understands.
• Generics, interfaces, and records. Constraints, why interfaces over base classes for testability, and what a record's value equality buys you.

Answer each with the mechanism and one consequence. Saying that a generation-zero collection is cheap because most objects die young is the level interviewers want; naming the generations without the reason is not.

You are confident writing controllers and worried the questions will be about the plumbing you rarely touch. That worry is well placed, because this is where the framework questions live, so here is the plumbing in the order it is usually asked, with the follow-up each one carries.

• The request pipeline. Middleware runs in the order it is registered, each component choosing whether to call the next. Follow-up: where does authentication sit relative to authorization, and what happens if you register them backwards?
• Dependency injection lifetimes. Singleton lives for the application, scoped lives for one request, transient is created every time it is resolved. The classic trap is injecting a scoped service, such as a database context, into a singleton; be ready to say why that is a bug.
• Configuration and options. Layered sources, environment overrides, and the options pattern for typed settings.
• EF Core. Change tracking and when to turn it off for read-only queries, the N+1 problem and how eager loading or projection avoids it, migrations, and the honest point at which a hand-written query beats LINQ.
• Testing. How interfaces and the DI container make a service testable, and what an in-memory provider does and does not prove about a real database.

The strongest candidates connect these: a scoped context resolved inside a singleton background service is not a trivia question, it is the memory and correctness bug interviewers have actually shipped, and they want to hear that you would create a scope explicitly.

Senior loops present a symptom and watch your method. A representative one: a backend engineer interviewing for a senior role at a logistics company is told that an ASP.NET Core API's memory climbs for days until the container restarts. The strong answer does not guess. It asks what changed, checks for objects captured by static caches or long-lived event subscriptions, looks for scoped services held by singletons, inspects large object heap growth, and reaches for a memory snapshot before proposing a fix. The interviewer is grading the order of the investigation.

Other scenarios that recur: an endpoint that is slow only under load, where the answer moves from synchronous database calls to async, connection pool exhaustion, and caching; a race condition in a shared collection and what the concurrent collections and locking options cost; a request that must call three downstream services and how you handle timeouts, retries, and partial failure; and a migration that must add a column without downtime. In each case, state the constraint, choose a mechanism, and say the trade-off aloud.

These are far easier when you have rehearsed them out loud with follow-ups, which is what the mock interview mode is built for; the other language and role banks are collected under interview questions by role and topic.

In conversational rounds, yes, within stated limits. SubcueAI's native macOS and Windows desktop app captures system audio and your microphone and shows short answer suggestions in a local overlay, so when the interviewer asks why a scoped context inside a singleton is a bug, the mechanism is on your screen while you explain it in your own words. The browser extension covers browser-tab calls on Chrome and Edge by capturing the meeting tab's audio only. No bot joins the call and nothing is injected into the meeting page; setup is on the tutorial page.

The limits: a proctored assessment, a recorded screen, a company-managed laptop, or a live coding exercise where you type C# under observation are out of scope, and the assistant is weakest exactly where the interview asks you to write code. It is strongest on the runtime, framework, and trade-off questions above. Feed it your resume first so suggestions reflect the systems you actually built; the resume builder is where that profile lives.