# The .NET Interview Checklist for 2026 > Source: > Published: 2026-09-22 12:55:01+00:00 The market is harder than it was two years ago. More applicants per opening, longer loops, and interviewers who have already sat through a dozen rehearsed answers this month. You don’t get much room to warm up. So I wrote out everything a backend .NET interview can reasonably reach into, and grouped it. Nine areas, roughly 120 topics. It isn’t a syllabus. It’s a checklist: go through it and mark the ones you can explain out loud, unprompted, to someone who will push back on the answer. Whatever you can’t, that’s your study list. One of these areas is new enough that a lot of good engineers still leave it blank, so I’ve put it in the middle rather than tacked on at the end. You can be excellent at ASP.NET Core and EF Core in 2026 and still stall in the second half of a conversation because you have no position on retrieval, on permissions, or on what happens when the model is confidently wrong. Backend depth gets you through the first hour. What you say about AI tends to decide the rest. [The .NET Backend Interview Handbook: 300+ Questions and Answers (Interview Prep)](https://www.amazon.com/dp/B0HDL3YYG2) Work in one pass, fast. Tick what you could explain to a sceptical senior engineer without notes. Don’t tick anything you’ve only read about. Then sort what’s left by how likely it is to come up in the role you’re applying for, and start there. This is where the interview usually starts, and a thin answer here colours everything that follows. Nearly every “our API fell over under load” story traces back to something on this list. What they’re really checking is whether you ever look at the SQL your ORM produced. Bring one query you made faster, with the numbers you took it from and to. The interesting questions here are about everything other than the endpoints. The area where a vague answer is most obvious to the person on the other side. Design questions are graded on the trade-off you name, not the diagram you draw. How the thing reaches production, and how you find out it still works. On cloud: pick whichever one is in the job ad and have a single architecture you can draw from memory — gateway, compute, secrets, database, telemetry. The service names differ between providers. The boxes don’t. This is the section worth the most preparation right now, because the answers are least rehearsed across the whole candidate pool. Two things to get straight before you walk in. First, have a real answer about your own workflow: what you hand to a model, what you read line by line before it ships, and what you would never paste into one. Vague enthusiasm reads badly, and so does blanket refusal. Second, position AI as a capability you design around rather than a replacement for the fundamentals. The engineer who can talk about permission-aware retrieval, about what an audit trail needs to capture, and about which data never leaves the tenant is having a different conversation from the one who has used an AI coding assistant and stops there. Worth knowing: some live coding rounds now ban AI assistance outright. Be able to write it cold. Half the interview, and usually the half people prepare least. That last item is where most answers stop early. The result is the easy part. What you’d do differently is what makes the story sound like it happened to you. [Top 30 Interview Questions Every .Net Developer Should Know](https://blog.devgenius.io/top-20-net-interview-questions-every-developer-should-know-3f1d52b7edb9) Have four or five ready, and make them specific to the team rather than the company: what the current stack looks like, how much of the estate is legacy, the biggest technical problem they’re working through right now, what six months of success looks like in the role, and how much design ownership it carries. That’s the list. Print it, tick it, and be honest about the blanks — they’re the only part that matters. [The .NET Interview Checklist for 2026](https://blog.devgenius.io/the-net-interview-checklist-for-2026-b346bfab2e35) was originally published in [Dev Genius](https://blog.devgenius.io) on Medium, where people are continuing the conversation by highlighting and responding to this story.