Engineering

.NET Developer mock interview questions

20 questions a .NET Developer panel actually asks, with what each one tests and what a strong answer contains, then practice any of them live. C# and ASP.NET Core technical round for .NET developer interviews.

  • Adaptive follow-ups, not a fixed question list
  • Rubric scorecard with evidence from your answers
  • Voice or text, with delivery coaching on voice sessions
HSHana Sato · Hiring Manager · Turn 1
HS

What actually happens when the runtime hits an await? Walk me through it, and then tell me why calling .Result on a task can deadlock.

[Your answer. Hana adapts follow-ups to what you say]

Scored on a rubric tailored to .NET Developer interviews

No account needed

Answer one real .NET Developer question now

A question a .NET Developer panel actually asks, answered out loud, scored on what you said and how you said it. Under two minutes, and nothing to sign up for.

What actually happens when the runtime hits an await? Walk me through it, and then tell me why calling .Result on a task can deadlock.

We never store the audio. Your answer is deleted within 24 hours unless you save the result.

20 .net developer mock interview questions

The questions a .NET Developer panel actually asks, with what each one is testing and what a strong answer contains. Click any question to run it in a live session: your AI interviewer will cover it and score how you answer.

  1. 1.

    What actually happens when the runtime hits an await? Walk me through it, and then tell me why calling .Result on a task can deadlock.

    Why they ask it: The defining .NET question. Nearly everyone can write async code; far fewer can explain that no thread is held during the await, which is the whole point of it.

    A strong answer: The compiler rewriting the method into a state machine, the method returning to its caller at the first incomplete await while no thread sits blocked, and the continuation resuming when the awaited operation completes. For the deadlock: a captured synchronisation context (classic ASP.NET or a UI thread) wants to resume the continuation on the one thread that .Result is currently blocking. Bonus credit for ConfigureAwait(false) in library code, async all the way up as the real fix, and async void being safe only for event handlers.

  2. 2.

    In Entity Framework Core, what is the difference between IEnumerable and IQueryable in a repository method, and why does it matter to the database?

    Why they ask it: This is where junior and senior .NET answers diverge hardest. It tests whether you know where the query is executing.

    A strong answer: IQueryable keeps composing an expression tree that the provider translates to SQL, so filtering stays on the server, while returning IEnumerable materialises the results and any further filtering happens in memory over rows you already paid to fetch. Strong answers add that a method returning IQueryable leaks the lifetime of the DbContext to the caller, mention client-side evaluation surprises, and reach for AsNoTracking on read paths.

  3. 3.

    A list endpoint is slow and the logs show hundreds of small queries per request. What is happening and how do you fix it?

    Why they ask it: The N plus one problem with an ORM in front of it. Practical, and it separates people who have profiled a real application from people who have only read about EF.

    A strong answer: Recognise lazy loading or a loop issuing per-row queries, confirm by logging generated SQL rather than assuming, then fix with Include or a projection to a DTO in a single query, split queries where a cartesian explosion is the alternative, AsNoTracking for read-only work, and paging so the endpoint has a bounded result set at all.

  4. 4.

    Explain the service lifetimes in the built-in dependency injection container, and give me a bug that a wrong lifetime causes.

    Why they ask it: Lifetime mistakes are among the most common production faults in ASP.NET Core, and they surface as intermittent corruption rather than as clean errors.

    A strong answer: Transient per resolution, scoped per request, singleton for the application lifetime, plus the captive dependency problem: injecting a scoped DbContext into a singleton pins one context for the life of the process, and DbContext is not thread-safe, so you get concurrency exceptions and stale tracked entities under load. Mentioning IServiceScopeFactory as the correct escape hatch inside a singleton or a hosted service is a strong signal.

  5. 5.

    Design the API for an order service in ASP.NET Core. Talk me through your routes, validation, error responses and how you would version it.

    Why they ask it: A design question that stays inside the framework so the interviewer can judge idiomatic .NET rather than abstract REST theology.

    A strong answer: Resource-shaped routes with correct status codes, model binding plus validation returning a problem details payload rather than a bare 400 string, cancellation tokens threaded to the data layer, idempotency for creates that a client may retry, a versioning strategy chosen deliberately (URL segment or header) with a story for deprecating the old one, and separate request and response models rather than exposing entities.

  6. 6.

    When does a struct make more sense than a class, and what is boxing costing you when it happens by accident?

    Why they ask it: The value versus reference distinction is fundamental to the CLR, and accidental boxing is a real allocation problem in hot paths.

    A strong answer: Structs for small, short-lived, immutable value-like data where copying is cheaper than allocating, classes otherwise; boxing when a value type is assigned to object or a non-generic interface, allocating on the heap and adding garbage collection pressure in a loop. Awareness of readonly struct, and of generics avoiding boxing where the old non-generic collections did not, marks real depth.

  7. 7.

    Your service is running out of sockets under load and the errors point at outbound HTTP calls. What went wrong?

    Why they ask it: A specific, well-known .NET failure. It tells the interviewer whether you have run something in production or only on a laptop.

    A strong answer: A new HttpClient per request leaving sockets in TIME_WAIT, or the opposite mistake of a static client that never picks up DNS changes. The fix is IHttpClientFactory with named or typed clients, sensible timeouts, and resilience policies for retry and circuit breaking. Bonus for noting that retries without a circuit breaker turn a slow dependency into an outage.

  8. 8.

    Tell me about moving code from .NET Framework to modern .NET, or maintaining something that has not moved yet.

    Why they ask it: Most .NET shops are somewhere in this migration. The interviewer wants sequencing and honesty about what did not go well.

    A strong answer: A concrete inventory step (analyzers, dependency compatibility, anything on System.Web or WCF), a strangler approach routing traffic gradually rather than a rewrite, the parts that genuinely blocked (configuration model, HttpContext differences, third-party libraries with no successor), and what you measured afterwards to prove the move was worth it.

Common questions in every interview

These come up in almost every .NET Developer interview regardless of the company or the round.

  1. 9.

    Tell me about yourself.

    Why they ask it: Opens the interview and sets the frame. The interviewer is checking whether you can select what matters for this job rather than narrate your whole history.

    A strong answer: A 60-90 second arc: where you are now, one or two proof points that match the posting, and why this role is the logical next step. Present, past, then future.

  2. 10.

    Why do you want this role?

    Why they ask it: Tests whether you read the job description or mass-applied. Weak answers are about what the candidate gets; strong answers connect to the work itself.

    A strong answer: Two specifics from the posting or the company's actual work, plus an honest line about what you want to get better at here.

  3. 11.

    Walk me through your resume.

    Why they ask it: Checks that your story holds together and that the transitions were deliberate rather than accidental.

    A strong answer: Chronological but fast, with a reason attached to each move and more time on the roles closest to this one.

  4. 12.

    Tell me about a time you failed.

    Why they ask it: Tests self-awareness and whether you own outcomes. Interviewers are listening for a real failure, not a disguised strength.

    A strong answer: A genuine miss, what you specifically got wrong, the cost, and the concrete thing you changed afterwards that has since held up.

  5. 13.

    Tell me about a conflict with a coworker or manager.

    Why they ask it: Predicts how you behave when the team disagrees. The trap is blaming the other person.

    A strong answer: The substance of the disagreement, what you did to understand their position, how it resolved, and what the working relationship looked like after.

  6. 14.

    What's your greatest strength?

    Why they ask it: Checks whether you know what you're actually good at and can prove it.

    A strong answer: One strength that maps to the posting, plus a short example where it produced a measurable result.

  7. 15.

    What's your greatest weakness?

    Why they ask it: Tests honesty and whether you're actively working on something. Rehearsed non-answers ('I work too hard') read as evasive.

    A strong answer: A real limitation that isn't core to the job, the system you built to manage it, and evidence it's improving.

  8. 16.

    Tell me about a time you had to influence someone without authority.

    Why they ask it: Almost every role depends on getting people who don't report to you to change course.

    A strong answer: What you wanted, why they resisted, the evidence or framing that moved them, and what actually shipped as a result.

  9. 17.

    Where do you see yourself in five years?

    Why they ask it: Tests whether this job fits your trajectory, which is a retention question in disguise.

    A strong answer: A direction rather than a title, and a line about the skills this role would build toward it. Vague ambition and rigid title-chasing both land badly.

  10. 18.

    Why are you leaving your current job?

    Why they ask it: Screens for red flags. Interviewers listen for how you talk about people you no longer work with.

    A strong answer: Forward-looking and specific about what you're moving toward. Criticism of a former employer costs you more than it gains, even when it's deserved.

  11. 19.

    What are your salary expectations?

    Why they ask it: Checks whether you've done market research and whether you're in range before anyone spends more time.

    A strong answer: A researched range with your target near the bottom of it, framed against the scope of the role. Deflect once if the posting has no band, then answer.

  12. 20.

    Do you have any questions for us?

    Why they ask it: The most under-prepared question in the interview, and the one that most changes the final impression.

    A strong answer: Two or three questions about how the team actually works: what the first 90 days look like, how success is measured, what the hardest part of the job is.

Related roles

All Engineering

No spam. Unsubscribe anytime.

Ready to practice as a .NET Developer?

Sign up free, no card. 3 full scored interviews, each ending in the complete scorecard: rubric scores, strengths, and what to fix next. Nothing is blurred.

  • Predefined role or paste any job description
  • Rubric scores with evidence quotes
  • 887+ roles to choose from

Questions & answers

Is the .NET Developer mock interview free?
Yes. 3 full scored .NET Developer interviews, no card. You get the complete rubric scorecard every time, with the evidence quoted from your own answers. Nothing is blurred.
Can I use my own job description instead?
Yes. Predefined roles are starting points. Paste any JD in the setup form and your AI interviewer will tailor questions to that posting.
How is scoring tailored to this role?
We pre-fill a realistic .NET Developer job description and interview format so questions and the scorecard match how this role is actually interviewed.
Should I tailor my resume before practicing?
Run a resume fit check against a .NET Developer job description first, then practice the interview with the same JD for a tighter loop.