📁 Sangam Dhakal - Portfolio v2.0 - Netscape Navigator 4.0
_
□
×

πŸ“š .NET Interview Questions

377 questions for senior .NET engineer interviews, each with a 30-second answer, the full answer, a deep dive, the follow-ups interviewers ask next, and real-world production problems.

  1. What does DRY really mean, and when does removing duplication make a .NET codebase worse?

    Don't Repeat Yourself as single source of knowledge, not identical text; accidental versus true duplication; the wrong abstraction; where DRY matters most.

    Mid-Level Theory Additional Principles Β· πŸ”— 3 follow-ups Β· πŸ›  1 real-world
  2. What does KISS mean in practice for a .NET engineer, and how do you tell simple from merely easy?

    Keep It Simple: essential versus accidental complexity, simple versus easy, readable code over clever code, and how to argue for simplicity in design reviews.

    Mid-Level Theory Additional Principles Β· πŸ”— 3 follow-ups Β· πŸ›  1 real-world
  3. What is YAGNI, and how do you balance it against designing for future requirements?

    You Aren't Gonna Need It: costs of building speculative features, the difference between speculative features and keeping options open, and reversible versus irreversible decisions.

    Mid-Level Theory Additional Principles Β· πŸ”— 3 follow-ups Β· πŸ›  1 real-world
  4. What is Separation of Concerns, and how does it show up in an ASP.NET Core application?

    Separation of Concerns at method, class, project and service level; layers versus vertical slices; cross-cutting concerns via middleware and filters; the cost of over-separation.

    Mid-Level Architecture Additional Principles Β· πŸ”— 3 follow-ups Β· πŸ›  1 real-world
  5. What is high cohesion, how do you recognise low cohesion in C# code, and how do you improve it?

    Cohesion as how strongly the parts of a module belong together; types of cohesion; symptoms such as utility classes and feature envy; measuring with LCOM; refactoring by feature.

    Mid-Level Theory Additional Principles Β· πŸ”— 3 follow-ups Β· πŸ›  1 real-world
  6. What does low coupling mean, what kinds of coupling exist in .NET systems, and how do you reduce the harmful ones?

    Coupling as the degree of dependency between modules; types from content to data coupling; temporal, deployment and database coupling in distributed systems; techniques to reduce it.

    Senior Architecture Additional Principles Β· πŸ”— 3 follow-ups Β· πŸ›  1 real-world
  7. What is the Law of Demeter, and how do you apply it in C# without banning fluent APIs and LINQ?

    Principle of least knowledge: talk only to immediate collaborators; train-wreck chains; why fluent builders and LINQ are not violations; refactoring by moving behaviour.

    Mid-Level Theory Additional Principles Β· πŸ”— 3 follow-ups Β· πŸ›  1 real-world
  8. What does Tell, Don't Ask mean, and how does it change the way you design domain classes in C#?

    Tell objects what to do instead of querying state and deciding outside; anaemic versus rich models; invariants; where querying is fine (CQRS reads, DTOs).

    Mid-Level Theory Additional Principles Β· πŸ”— 3 follow-ups Β· πŸ›  1 real-world
  9. What does fail fast mean in .NET, and how do you apply it without making the system fragile?

    Detect invalid state at the earliest point: guard clauses, ArgumentNullException.ThrowIfNull, options validation on start, ValidateOnBuild; fail fast versus resilience at boundaries.

    Mid-Level Theory Additional Principles Β· πŸ”— 3 follow-ups Β· πŸ›  1 real-world
  10. What is the principle of least astonishment, and how do you apply it to C# APIs and library design?

    Code and APIs should behave as users expect: naming, side effects, .NET conventions (Try pattern, Async suffix, CancellationToken last), equality, exceptions and defaults.

    Mid-Level Theory Additional Principles Β· πŸ”— 3 follow-ups Β· πŸ›  1 real-world
  11. What is convention over configuration, and where does .NET use it in ASP.NET Core and EF Core?

    Sensible defaults that remove boilerplate: EF Core key and relationship conventions, ASP.NET Core routing and configuration conventions; overriding defaults; risks of hidden magic.

    Mid-Level Theory Additional Principles Β· πŸ”— 3 follow-ups Β· πŸ›  1 real-world
  12. When should you not introduce an abstraction in a .NET codebase, and how do you decide whether an interface or base class is earning its keep?

    Costs of abstraction, the one-implementation interface debate, test seams versus speculative layers, leaky abstractions over EF Core and HttpClient, and criteria for adding or removing an abstraction.

    Senior Architecture Senior-Level Judgment Β· πŸ”— 3 follow-ups Β· πŸ›  1 real-world
  13. When is code duplication acceptable or even preferable, and how do you explain that decision in a code review?

    Rule of three, the wrong abstraction, duplication across bounded contexts and services, test code, and how to justify keeping duplication to reviewers.

    Senior Architecture Senior-Level Judgment Β· πŸ”— 3 follow-ups Β· πŸ›  1 real-world
  14. How do you detect over-engineering in a .NET system, and how do you reverse it without a rewrite?

    Signals of over-engineering (layers, patterns, microservices, configurability), metrics to prove it, communicating with the team, and incremental simplification.

    Senior Architecture Senior-Level Judgment Β· πŸ”— 3 follow-ups Β· πŸ›  1 real-world
  15. How do you plan and execute a large refactoring in a production .NET system without stopping feature delivery?

    Refactoring strategy: characterisation tests, strangler fig, branch by abstraction, parallel change, feature flags, small pull requests, measuring progress, and when to stop.

    Senior Architecture Senior-Level Judgment Β· πŸ”— 3 follow-ups Β· πŸ›  1 real-world
  16. How do you manage technical debt as a senior engineer: identifying it, prioritising it and getting time to pay it down?

    Technical debt quadrants, making debt visible, measuring interest, prioritising with business impact, debt registers, capacity allocation and communicating with product owners.

    Senior Behavioral Senior-Level Judgment Β· πŸ”— 3 follow-ups Β· πŸ›  1 real-world
  17. What is evolutionary architecture, and how do you design a .NET system so its architecture can change safely over time?

    Evolutionary architecture: fitness functions, incremental change, last responsible moment, reversible decisions, modular monolith to services, ADRs, and architecture tests in CI.

    Staff / Architect Architecture Senior-Level Judgment Β· πŸ”— 3 follow-ups Β· πŸ›  1 real-world

🌐 Sangam's Webring

βͺ Previous 🏠 Main Next ⏩
πŸ’¬ Chat with me