.NET Developer Interview Questions (2026) and How to Answer
By FindAJobAI team Updated How we wrote this page
.NET developer interviews usually mix C# language questions, a live coding exercise, and design questions about ASP.NET Core APIs, Entity Framework Core and dependency injection. Many teams running on Azure also probe deployment and messaging experience, and some add a take-home or pair-programming session.
Interviewers want solid fundamentals, code that handles errors and concurrency sensibly, and a developer who can explain tradeoffs, not just recite syntax.
Below: 30 questions with what each one really asks and an answer outline, full sample answers to the 10 most asked, red flags to avoid and a 7-day plan.
Answering with STAR
Tell each story in four steps: the situation in a sentence, your task, the actions you took (most of the answer) and the result, with a number if you have one. Aim for about two minutes; the outlines show what to include, the details must be yours.
Behavioural questions (1–10)
How you've handled real situations. Answer each with one true story, in STAR order.
1.Tell me about a time you fixed a difficult bug in production.
What they're really asking: Can you diagnose under pressure without guessing or making things worse?
Answer outline (STAR)
- SituationAn intermittent error affecting customers in a live ASP.NET application.
- TaskFind the root cause and stop the bleeding quickly.
- ActionAdd logging, reproduce it locally, isolate the failing dependency, ship a targeted fix.
- ResultThe fix held, and the monitoring you added to catch it earlier next time.
Full sample answer (fictional example)
We had an intermittent 500 error affecting about one in two hundred checkout requests. I added structured logging around the payment call and reproduced it locally by simulating a slow network. It turned out a timeout was disposing the DbContext while a background task still referenced it. I rewrote that path to use a scoped service correctly and added a retry with backoff around the external call. The error rate dropped to zero over the following week. I also added an alert on that specific exception type so we'd catch any recurrence within minutes instead of waiting for a customer complaint.
2.Tell me about a time you had to learn a new part of the .NET ecosystem quickly.
What they're really asking: How fast can you become productive in unfamiliar territory?
Answer outline (STAR)
- SituationA project move from .NET Framework to .NET Core, or a new library like MediatR.
- TaskDeliver working code without slowing the team down.
- ActionRead the docs, build a small spike, ask a teammate to review your first PR closely.
- ResultWhat you shipped, and what you taught the team afterward.
Full sample answer (fictional example)
Our team moved a legacy .NET Framework service to .NET 8 under a tight deadline. I hadn't used the new minimal API style before, so I spent a weekend rebuilding a small internal tool with it to get comfortable. On the actual migration, I handled the authentication middleware rewrite, since that had changed the most between versions. I documented the gotchas I hit, like the different configuration binding behavior, in a shared doc. We shipped on schedule, and two other developers used my notes to migrate their own services the following month.
3.Describe a disagreement with another developer over code design.
What they're really asking: Can you argue your case and still accept being wrong gracefully?
Answer outline (STAR)
- SituationA pull request where you and a colleague wanted different architectures.
- TaskReach a decision without stalling the release.
- ActionLay out both tradeoffs in writing, suggest a quick spike to compare, defer to the team lead if needed.
- ResultThe approach chosen, and how the codebase held up later.
Full sample answer (fictional example)
A colleague wanted to introduce a generic repository layer over our EF Core context, and I thought it added complexity without real benefit since we only used one database. I wrote up both approaches with concrete examples from our codebase and shared it before the meeting instead of arguing live. We agreed to time-box a half-day spike comparing both on an actual feature. The direct EF Core approach turned out simpler to test and maintain, so we went with that. He appreciated that I'd brought evidence instead of just opinion, and we used that format for later disagreements too.
4.Tell me about refactoring a piece of legacy code.
What they're really asking: Do you improve code safely, with tests, instead of rewriting on instinct?
Answer outline (STAR)
- SituationA tangled class with no tests that everyone was afraid to touch.
- TaskMake it safer to change without breaking behavior.
- ActionWrite characterization tests first, extract small pieces, refactor in small reviewable steps.
- ResultTest coverage after, and the next feature that became easier to add.
Full sample answer (fictional example)
I inherited an order processing class with over a thousand lines and no tests, which everyone avoided touching. I wrote characterization tests first, capturing its actual current behavior, including a couple of bugs we decided to keep for compatibility. Then I extracted the discount calculation and tax logic into separate, tested classes, one small pull request at a time. It took about three weeks alongside regular work. By the end we had eighty percent test coverage on that module, and the next feature request, a new discount type, took two days instead of the week it would have taken before.
5.Tell me about delivering a feature against a tight deadline.
What they're really asking: Can you move fast without leaving a mess for the next person?
Answer outline (STAR)
- SituationA client-requested feature due before a trade show demo.
- TaskShip something real without betraying code quality entirely.
- ActionCut scope with the product owner, reuse existing patterns, flag the shortcuts taken.
- ResultWhat shipped on time, and the follow-up ticket you filed for the shortcuts.
6.Tell me about a time you improved the performance of a slow endpoint.
What they're really asking: Can you diagnose and fix real performance problems, not just add caching blindly?
Answer outline (STAR)
- SituationA customer-facing endpoint taking several seconds to respond.
- TaskBring it down to an acceptable response time.
- ActionProfile the request, found an N+1 query, added eager loading and a covering index.
- ResultResponse time dropped sharply, and the pattern was documented for the team.
7.Tell me about mentoring a junior developer.
What they're really asking: Do you grow other people's skills, not just your own code?
Answer outline (STAR)
- SituationA new graduate hire struggling with async code and EF Core.
- TaskGet them contributing confidently within their first few months.
- ActionPaired on real tickets weekly, explained the why behind patterns, reviewed their PRs in detail.
- ResultThey started shipping features independently, and later mentored someone else.
8.Tell me about a time you had to push back on a product requirement.
What they're really asking: Can you raise technical concerns constructively instead of just complying?
Answer outline (STAR)
- SituationA requested feature that would have required storing data insecurely.
- TaskGet a safer approach agreed without derailing the timeline.
- ActionExplained the risk in plain terms, proposed an alternative design, got sign-off from security.
- ResultThe safer version shipped on the original date, with no shortcuts.
9.Describe a time you worked across multiple services or teams on one feature.
What they're really asking: Can you coordinate work that crosses ownership boundaries?
Answer outline (STAR)
- SituationA feature needing changes in your API and a teammate's downstream service.
- TaskShip a consistent change on both sides at the same time.
- ActionAgreed on a contract early, built against a mock, coordinated a joint release.
- ResultLaunched without a mismatch, and the contract became a template for later work.
10.Tell me about a time you had to recover from a failed deployment.
What they're really asking: Can you stay calm and methodical when something breaks in production?
Answer outline (STAR)
- SituationA deployment that passed CI but broke a key workflow in production.
- TaskRestore service quickly and understand what slipped through.
- ActionRolled back immediately, confirmed recovery, then reproduced the bug in a test environment.
- ResultService restored within minutes, and a missing integration test added to the pipeline.
Technical and role-skill questions (11–22)
Can you do the work itself? Think out loud and name the trade-offs.
11.What's the difference between a value type and a reference type in C#?
What they're really asking: Core language knowledge that affects performance and bugs with mutation.
Answer outline
- Value types like struct and int are copied on assignment and live on the stack when local.
- Reference types like class are copied by reference, and multiple variables can point to the same object.
- Boxing moves a value type onto the heap, which costs a small performance penalty.
Full sample answer (fictional example)
Value types, like int, bool and structs, are copied when assigned or passed to a method, and local ones live on the stack, which makes them fast for small data. Reference types, like classes, are copied by reference, so two variables can point to the same object in memory, and changes through one are visible through the other. A practical trap is boxing: putting a value type into an object or interface moves it onto the heap, which costs a small performance penalty. I keep this in mind when designing high-throughput code, where avoiding unnecessary boxing and allocations matters.
12.Explain async and await, and what happens if you forget to await a task.
What they're really asking: Async is central to ASP.NET Core performance, and a common source of bugs.
Answer outline
- async marks a method that can run asynchronously; await suspends it until the task completes without blocking the thread.
- Forgetting to await means the method continues before the task finishes, which can cause silent failures or lost exceptions.
Full sample answer (fictional example)
Async and await let a method start a long-running operation, like a database call, and free up the thread while it waits instead of blocking it. The await keyword suspends the method until the task completes, then resumes it, often on a different thread pool thread. If you forget to await a task, the method continues immediately without waiting for the result, which can mean exceptions are swallowed silently and the task keeps running in the background unobserved. I've seen this cause confusing bugs where a save operation appeared to succeed but hadn't actually completed yet.
13.What is dependency injection, and how does ASP.NET Core's built-in container work?
What they're really asking: DI is central to how ASP.NET Core apps are structured and tested.
Answer outline
- Services are registered in Program.cs with a lifetime: transient, scoped or singleton.
- The framework resolves constructor parameters automatically when building controllers or other registered services.
- Picking the wrong lifetime, like injecting a scoped service into a singleton, causes subtle bugs.
14.How does Entity Framework Core track changes, and when would you use AsNoTracking?
What they're really asking: EF Core performance and correctness come up in almost every .NET interview.
Answer outline
- The change tracker keeps a snapshot of entity state so SaveChanges knows what to update.
- AsNoTracking skips that bookkeeping for read-only queries, which is faster and uses less memory.
- For large read-heavy endpoints, AsNoTracking is usually the right default.
Full sample answer (fictional example)
In my experience, EF Core's change tracker keeps a snapshot of each tracked entity's original values, so when I call SaveChanges it can work out exactly which properties changed and generate the right update statement. That tracking costs memory and CPU, which matters on queries returning large result sets. I use AsNoTracking for read-only endpoints like a list view or a report, where I'll never call SaveChanges on the results. On one reporting endpoint, switching to AsNoTracking and projecting into a DTO cut query time noticeably under load, so I now make it my default for read paths.
15.What's the difference between IEnumerable, IQueryable and List in a LINQ query?
What they're really asking: Tests whether you understand when a query actually executes against the database.
Answer outline
- IQueryable builds an expression tree that translates to SQL and executes when enumerated.
- IEnumerable operates in memory, so filtering after ToList runs on the application server, not the database.
- List is a concrete, materialized collection already loaded into memory.
16.How would you secure a Web API endpoint in ASP.NET Core?
What they're really asking: Security basics every .NET developer is expected to know.
Answer outline
- Use authentication, typically JWT bearer tokens or an identity provider like Azure AD.
- Apply the Authorize attribute and define policies or roles for finer-grained access.
- Validate input, enforce HTTPS, and never trust claims without checking their issuer and expiry.
17.How do you handle configuration and secrets across environments in .NET?
What they're really asking: Shows whether you understand deployment hygiene, not just code.
Answer outline
- Use appsettings.json layered with environment-specific overrides and environment variables.
- Keep secrets out of source control, using a secret manager locally and a vault or Azure Key Vault in production.
- Bind configuration to strongly typed options classes instead of reading raw strings everywhere.
18.What's the difference between .NET Framework, .NET Core and modern .NET?
What they're really asking: Tests whether you understand the platform's history and what runs where.
Answer outline
- .NET Framework is Windows-only and no longer under active feature development.
- .NET Core, now unified as modern .NET, is cross-platform, open source and actively developed.
- Most new projects target the current .NET LTS release for performance and platform support.
19.Explain the repository pattern and whether you'd use it with EF Core.
What they're really asking: Checks architectural judgment rather than just reciting a pattern.
Answer outline
- A repository abstracts data access behind an interface, hiding the ORM from business logic.
- With EF Core, DbContext already behaves like a unit of work, so a thin repository can be redundant.
20.How would you implement caching in an ASP.NET Core application?
What they're really asking: Caching comes up in most performance-related interview rounds.
Answer outline
- In-memory caching suits a single instance; distributed caching like Redis suits multiple instances.
- Cache keys need a clear invalidation strategy tied to the data's actual change frequency.
- Cache aside is the common pattern: check cache, miss, read from the source, populate cache.
21.What's the difference between a Task and a Task<T> in C#, and how do you handle exceptions from them?
What they're really asking: Checks solid understanding of the Task-based asynchronous pattern.
Answer outline
- Task represents an operation with no return value; Task<T> returns a value of type T on completion.
- Exceptions are captured on the task and rethrown when awaited, or available via the Exception property.
22.How do you approach unit testing a class that depends on EF Core's DbContext?
What they're really asking: Testing data-dependent code is a common pain point in .NET projects.
Answer outline
- Mock the DbContext and DbSet with a library, or use an in-memory provider for simple cases.
- Prefer testing against a real lightweight database like SQLite in-memory for query correctness.
- Keep business logic separate from the DbContext so most tests don't need a database at all.
Take-home or live exercise: tips
.NET interviews often include a live coding round in C#, a small take-home API, or a pairing session extending an existing codebase.
- Think aloud about edge cases and naming before writing code, not just after.
- Write a quick unit test for tricky logic even under time pressure, to show the habit.
- In a take-home, keep the solution scoped to what was asked rather than over-engineering it.
- Ask clarifying questions about expected scale and error handling before assuming requirements.
Situational questions (23–30)
Scenarios that test judgement: say what you'd do first, and why.
23.A nightly job starts failing intermittently in production. What do you do?
What they're really asking: Can you triage a flaky failure methodically instead of guessing?
Answer outline
- Check logs and recent deployments first for a correlated change.
- Reproduce with the same data and timing if possible, and add structured logging if you can't.
- Fix the root cause, then add alerting so it's caught sooner next time.
Full sample answer (fictional example)
I'd start with the logs around the failure time and check whether a recent deployment or configuration change correlates with when it started. If the cause isn't obvious, I'd try to reproduce it using the same data and timing conditions in a test environment, since intermittent failures are often about timing, load or external dependencies. If I can't reproduce it reliably, I'd add structured logging around the suspected area and let it run again rather than guessing blindly. Once I find the root cause, I'd fix it and add alerting so any recurrence is caught immediately rather than discovered the next morning.
24.You're asked to add a feature to a service with no automated tests. What do you do?
What they're really asking: Will you add safety as you go, or ship blind into risky code?
Answer outline
- Add a few tests around the specific area you're changing before touching it.
- Make the smallest change that satisfies the requirement.
- Flag the lack of coverage to the team as a longer-term risk.
25.Two team members have strongly different opinions on using a new library. How do you resolve it?
What they're really asking: Can you facilitate a technical decision without it becoming personal?
Answer outline
- Ask each to state the specific tradeoffs: maintenance cost, team familiarity, performance.
- Time-box a small spike to compare them on a real piece of the codebase.
- Document the decision and the reasoning so it isn't relitigated every sprint.
26.You discover a security vulnerability in a library the application depends on. What do you do?
What they're really asking: Do you treat security issues with urgency and communicate them properly?
Answer outline
- Check the severity and whether it's exploitable in your actual usage.
- Patch or upgrade promptly, and test for breaking changes before deploying.
- Report it through the right internal channel if it affects customer data.
27.A production database migration needs to run with zero downtime. How do you plan it?
What they're really asking: Can you handle schema changes safely on a live system?
Answer outline
- Make the change backward compatible, such as adding a nullable column rather than renaming one.
- Deploy code that works with both schemas, run the migration, then deploy code that requires the new schema.
- Test the migration against a copy of production data first, and have a rollback plan ready.
Full sample answer (fictional example)
I'd design the change to be backward compatible first, for example adding a new nullable column instead of renaming or dropping one outright. Then I'd deploy application code that can work with both the old and new schema, run the migration separately, and only afterward deploy code that depends on the new structure. I always test the exact migration script against a recent copy of production data beforehand, since real data often reveals edge cases a clean test database doesn't. I'd also have a rollback script ready and run the migration during a lower-traffic window as an extra safeguard.
28.A third-party API your service depends on starts timing out. What do you do?
What they're really asking: Resilience thinking: do you isolate failures instead of letting them cascade?
Answer outline
- Add timeouts, retries with backoff, and a circuit breaker so failures don't cascade.
- Return a sensible fallback or cached response where the business allows it.
- Alert the team and track the provider's status until it's resolved.
Full sample answer (fictional example)
First I'd add or check that we already have timeouts configured, since an unbounded wait on a failing dependency can tie up threads and take down our own service too. I'd add retries with exponential backoff for transient failures, and a circuit breaker so repeated failures stop hammering a service that's already struggling. Where the business allows it, I'd return a cached or fallback response rather than a hard error to the user. I'd also set up an alert tied to that dependency's error rate and keep the team updated until the provider's status page confirms it's resolved.
29.You're asked to estimate a feature you've never built before. How do you respond?
What they're really asking: Can you give a useful estimate under real uncertainty?
Answer outline
- Break it into smaller known pieces and estimate each one separately.
- State your assumptions and the confidence level clearly, with a range rather than a single number.
30.Your team's test suite takes over 40 minutes to run and is slowing releases. What do you do?
What they're really asking: Pragmatic judgment about test suite health and speed.
Answer outline
- Profile the suite to find the slowest tests and why they're slow.
- Split unit tests from slower integration tests, and run the fast ones first in CI.
- Parallelize what can run concurrently, and flag flaky tests for a fix or removal.
Red flags to avoid in your answers
Each one is quick to fix before the day.
Writing code that compiles but ignoring error handling entirely.
Narrate how you'd handle failure cases, even if you don't code every branch under time pressure.
Using async and await as decoration without understanding what they do.
Be ready to explain what happens to the thread while a task is awaited.
Dismissing testing as something to add later.
Describe the specific tests you'd write for the code you just wrote.
Blaming the framework or tooling for every bug encountered.
Walk through your own debugging steps before pointing at external causes.
How to prepare for a .NET developer interview in 7 days
An hour or two a day is enough; the order matters more than the length.
Day 1: C# fundamentals pass
Review generics, LINQ, nullable reference types and the difference between value and reference types with quick examples.
Day 2: Async deep dive
Write a few small async methods, deliberately break one by forgetting to await, and explain why it fails.
Day 3: Build a mini API
Scaffold a small ASP.NET Core Web API with EF Core, one entity, and basic CRUD endpoints.
Day 4: DI and testing
Practice registering services with different lifetimes, and write unit tests mocking a dependency.
Day 5: Azure or deployment refresh
Review how the target company likely deploys .NET apps, whether App Service, containers or IIS.
Day 6: Live coding drills
Solve two or three timed coding problems in C#, narrating your reasoning the whole time.
Day 7: Final check and rest
Skim your notes on dependency injection lifetimes and async pitfalls, then stop prepping early.
Questions to ask the interviewer
Pick two or three; the answers tell you whether you want the job.
- What does the current .NET version and Azure or AWS setup look like?
- How is the team structured around this codebase, and who owns code review?
- What does the CI/CD pipeline look like for this service?
- How much of the day is new feature work versus maintenance and bug fixes?
- What's the biggest technical debt the team wants to pay down this year?
Preparation tips
- Review C# fundamentals: generics, LINQ, async/await and the differences between value and reference types.
- Practice writing a small ASP.NET Core Web API from scratch, including a basic EF Core setup.
- Be ready to explain dependency injection lifetimes and a time you got one wrong.
- Know the company's deployment target, whether Azure App Service, containers or on-premise IIS.
Prepare the general questions too: tell me about yourself, why do you want to work here? and why are you leaving? Afterwards, send a thank-you email; when the offer comes, negotiate the salary.
How we wrote this page
The FindAJobAI team wrote the questions, outlines and sample answers for .NET developer interviews. The people, employers and numbers in the samples are invented: copy the structure, and use details from your own work.
Once we track enough live .NET developer job ads, this page also shows the skills they ask for most, counted the same way as our in-demand skills report.
Last reviewed on November 1, 2026.