RehearseAI
.NET Core interviews have a reputation for being definition quizzes, and some are. But the ones that decide offers almost always turn on the same thing: whether you can explain why the framework does something, not just what it is called.
"Dependency injection is built in" is a fact anybody can memorize. "Here is what happened when we registered a DbContext as a singleton" is an answer that ends the doubt.
Below are the questions that come up most, what each is really testing, and where candidates usually slip.
The questions almost every interview includes
"What is the difference between .NET Framework, .NET Core and .NET 5 and later?"
The short version: .NET Framework is Windows-only and in maintenance; .NET Core was the cross-platform rewrite; from .NET 5 onwards the two lines merged into one product simply called .NET. If you are asked this in 2026 it is a warm-up — answer briefly and move on rather than delivering a history lecture.
"Explain the service lifetimes."
Transient, scoped, singleton. Everyone can recite it. The follow-up is where it matters: what breaks if you get it wrong?
"Registering a DbContext as a singleton is the classic one. It is not thread-safe, so under load you get concurrency exceptions and stale tracked entities. Scoped is the right lifetime because it gives you one context per request."
Being able to name the failure, not just the rule, is the difference.
"What is middleware, and does order matter?"
Middleware is the request pipeline — each component can act, pass along, or short-circuit. Order matters enormously, and the interviewer usually wants to hear one concrete example: authentication before authorisation, exception handling near the top so it wraps everything below it, static files early so they do not travel the whole pipeline.
"How does configuration work, and where do secrets go?"
Layered providers — appsettings.json, environment-specific overrides, environment variables, user secrets in development, a vault in production. Say plainly that secrets do not live in appsettings.json committed to the repo. Interviewers notice when a candidate volunteers that unprompted.
"What is IActionResult and why not just return the object?"
Returning the object is fine when the answer is always the same shape. IActionResult exists so one action can return 200, 404 or 400 depending on what happened. ActionResult<T> gives you both — the typed body and the status flexibility.
"async/await — what is actually happening?"
The one where confident people come unstuck. The core point is that await frees the thread while waiting on I/O rather than blocking it, which is why a server handles far more concurrent requests. Then the practical bit: do not call .Result or .Wait() on an async method in a request path, because that is how you deadlock.
The questions that separate people
"How would you find out why this endpoint is slow?"
Narrate a process rather than guessing. Is it the database, the serialisation, an external call, or cold start? Check the query plan and whether an ORM call is running N+1. Look at whether async is actually async all the way down. Add timing around the suspicious section rather than rewriting on a hunch.
"How do you test this?"
Mention both unit tests around the logic and integration tests through the pipeline with WebApplicationFactory. Saying you test controllers by calling them as plain classes and never exercising routing or model binding is a common gap.
"Tell me about something you got wrong in a .NET codebase."
A behavioral question in technical clothing. Have one ready. It is the answer interviewers remember.
What to do the night before
Pick five of the questions above and answer each out loud in under ninety seconds. Not in your head — out loud, where you can hear the sentence run out of road.
Technical answers are unusually prone to this. You understand service lifetimes perfectly and still spend two minutes circling before you say anything specific, because you have never had to compress it into speech before.
If you want the follow-up questions as well, RehearseAI asks them out loud for the exact role and stage, then tells you where you rambled. Every account gets one free 5-minute interview a month, no credit card required.
Quick answers
Do .NET interviews still ask about .NET Framework? Sometimes, if the company has legacy systems. Know the difference; do not dwell on it.
How much LINQ do they expect? Enough to read it fluently and know deferred execution exists. Memorizing every operator is not the bar.
Will I have to write code live? Often, but usually small and practical rather than algorithmic. Ask the recruiter — they will tell you the format.
Should I mention EF Core if I have only used Dapper? Say which you have used and why. Pretending experience you do not have collapses in one follow-up question.
Sources
The technical ground here is Microsoft's own documentation; these are the pages I checked it against:
- Introduction to .NET — Microsoft Learn
- Dependency injection in ASP.NET Core — Microsoft Learn
- ASP.NET Core middleware — Microsoft Learn
- Overview of Entity Framework Core — Microsoft Learn
If the interview opens with "tell me about a time…", use the STAR method. More on why I built this.
