The .NET Interview Roadmap: What to Study and How to Think

Most Developers Prepare for the Wrong Interview

They spend weeks memorising:

• Design patterns
• SOLID principles
• Framework APIs
• Random interview questions off a list

Then they walk into the interview and get stuck.

Why? Because most backend interviews are not testing memorisation. They're testing how you think.

Interviewers want to know:

• Can you break down a problem?
• Can you explain your reasoning?
• Can you discuss tradeoffs?
• Can you identify risks?
• Can you make decisions with incomplete information?

---

The Difference Between a Weak Answer and a Strong Answer

Consider caching. A weak answer:

"Redis improves performance."

A stronger answer:

"Redis reduces database load and improves response times, but it introduces cache invalidation complexity and consistency challenges — you have to decide whether stale data is acceptable and for how long."

The second answer demonstrates engineering thinking. That's what interviewers notice.

The same pattern applies to every topic:

| Topic | Weak | Strong | |---|---|---| | async/await | "It's non-blocking" | "It frees threads during I/O using a state machine — but blocking with .Result causes deadlocks and ValueTask avoids allocations for hot paths" | | Microservices | "They scale independently" | "They improve deployment isolation but add network complexity, distributed tracing overhead, and eventual consistency challenges most teams aren't ready for" | | Database indexing | "Indexes make queries faster" | "Indexes speed reads but slow writes and cost storage — you choose them based on your actual query patterns, not to index everything" | | Message queues | "They decouple services" | "They smooth traffic spikes and absorb downstream failures, but require idempotent consumers and dead-letter queue handling to be reliable" |

Senior interviews are rarely about finding the "correct" answer. They're about understanding the consequences of your decisions. Because in real-world software engineering, every solution has tradeoffs.

The candidates who stand out are not the ones who know the most. They're the ones who think like engineers.

---

The Roadmap

Here is the order that builds the strongest foundation — each layer supports the next.

1. C# Fundamentals Deeply

Not just syntax. Understand the runtime: value vs reference types, how memory is managed, what the GC does, and why it matters for performance.

Key areas:

• Value types vs reference types and boxing
• string immutability and StringBuilder
• Nullable reference types (string? vs string)
• record, struct, class — when each is appropriate
• Generics and constraints
• Pattern matching

Study: C# Fundamentals

---

2. OOP and SOLID in Real Scenarios

Don't memorise definitions. Be able to show a real example from code you've written where a SOLID principle improved things — or where breaking it caused a problem.

What interviewers actually ask:

• "Show me a class that violates SRP and how you'd fix it"
• "Why would you use composition over inheritance here?"
• "How does DIP let you test this without a database?"

Study: SOLID Principles in .NET

---

3. LINQ, async/await, Collections

These three are tested in every mid-level and senior interview. They reveal whether you understand the runtime, not just the syntax.

LINQ: deferred execution, IEnumerable vs IQueryable, expression trees, performance traps (multiple enumeration, .Count() > 0 vs .Any()).

async/await: state machines, ConfigureAwait, cancellation tokens, deadlocks, ValueTask, parallel async with bounded concurrency.

Collections: choosing the right structure (List vs HashSet vs Dictionary), Span<T>, concurrent collections, when to use ImmutableCollections.

Study:

• LINQ Deep Dive
• async/await Patterns
• C# Collections Guide

---

4. ASP.NET Core Lifecycle

Know the request pipeline end-to-end: how a request enters, how middleware processes it, how routing works, how the controller is resolved, and how the response is formed.

Key areas:

• Middleware pipeline and ordering
• Action filters vs middleware
• Model binding and validation
• Response types and problem details

Study: ASP.NET Core Web API | Middleware Pipeline

---

5. Dependency Injection

DI is everywhere in .NET. Understanding lifetimes deeply — especially captive dependency bugs — separates mid-level from senior.

What to know:

• Singleton, Scoped, Transient — and what goes wrong when misused
• Captive dependency anti-pattern
• Registering multiple implementations
• IOptions<T> and configuration binding
• Factory pattern for conditional resolution

Study: Dependency Injection | Service Lifetimes

---

6. EF Core and SQL Performance

Most production .NET performance problems are database problems. You need to understand what SQL EF Core generates, not just how to write LINQ.

What to know:

• N+1 queries and how to detect them
• Include vs ThenInclude vs explicit loading vs projections
• AsNoTracking for read-only queries
• Indexes, covering indexes, query plans
• Migrations and schema evolution
• Concurrency tokens

Study: EF Core Guide | EF Core Performance | EF Core Queries

---

7. Authentication and Authorization

JWT, OAuth 2.0, refresh tokens, role-based and policy-based authorisation — these come up in every API interview.

What to know:

• How JWT works end-to-end (sign → send → validate)
• The difference between authentication and authorisation
• Claims and ClaimsPrincipal
• Role-based vs policy-based vs resource-based authorisation
• Refresh token rotation

Study: JWT Auth from Scratch | OAuth and OpenID Connect | Role and Claims Auth

---

8. Caching, Redis, Message Queues

These topics demonstrate backend systems maturity. Being able to discuss invalidation strategies and idempotency shows you've thought past "make it faster."

Caching: in-memory vs distributed, cache-aside pattern, TTL vs event-driven invalidation, cache stampede prevention.

Message queues: producer/consumer, durability, retries, dead-letter queues, idempotent consumers, outbox pattern.

Study:

• Redis Caching in .NET
• Caching Fundamentals
• Message Queues: RabbitMQ and Azure Service Bus

---

9. Clean Architecture and Tradeoffs

Don't just know the pattern — know when not to use it. A CRUD API doesn't need full Clean Architecture. A complex domain does.

What to know:

• The dependency rule (dependencies point inward)
• Application layer: commands, queries, handlers
• Infrastructure layer: EF Core, external services
• When CQRS adds value vs when it's over-engineering
• Vertical slice as an alternative

Study: Clean Architecture in .NET | CQRS and MediatR | Vertical Slice Architecture

---

10. System Design Basics

Even junior interviews increasingly include system design. You don't need to design Twitter — you need to show you can reason about scale.

What to know:

• Horizontal vs vertical scaling
• Stateless vs stateful services
• CAP theorem basics
• When to use a queue vs a direct call
• Database read replicas and caching layers
• Trade-offs: availability vs consistency

Study: System Design Complete Guide

---

11. Production Debugging Mindset

This is what separates good engineers from great ones. Can you diagnose a memory leak under production load? Can you correlate a latency spike to a GC pause?

What to know:

• Structured logging and correlation IDs
• Distributed tracing with OpenTelemetry
• dotnet-trace for CPU profiling
• dotnet-dump for memory analysis
• dotnet-counters for live metrics
• Common failure patterns: N+1, thread starvation, connection pool exhaustion

Study: Production Debugging in .NET

---

12. Communication and Explaining Decisions

The last skill is the one most developers underestimate. You can know everything above and still fail an interview if you can't explain your reasoning clearly.

Practice this:

• "I chose X because..." (explicit reasoning)
• "The tradeoff is..." (acknowledge the downside)
• "In this context that's acceptable because..." (situational judgment)
• "An alternative would be Y, but..." (show you considered options)

Interviewers don't expect perfect answers. They expect honest, structured thinking. Say what you know, say what you don't, reason out loud.

---

The Interview Question Library

Use these to test yourself across all levels:

• Junior Level Questions (Q1–Q80) — C# basics, OOP, REST, DI
• Mid Level Questions (Q61–Q160) — LINQ, async, EF Core, architecture
• Senior Level Questions (Q81–Q250) — system design, performance, advanced patterns

---

How Long Does This Take?

If you study deliberately — not just reading, but writing code and explaining concepts out loud:

| Starting point | Estimated time | |---|---| | 0–1 years .NET | 12–16 weeks | | 2–3 years .NET | 6–8 weeks | | 4+ years .NET | 3–4 weeks review |

The goal isn't to cover everything. It's to go deep enough on each topic that you can answer follow-up questions confidently.

One hour of deliberate practice (write code, explain it out loud, find the edge cases) is worth five hours of passive reading.

---

Start Here

If you're not sure where to start, use this sequence:

1. Read C# Fundamentals — close gaps in the language
2. Build something with EF Core — you'll hit the real questions
3. Read async/await Patterns — understand what you've been writing
4. Read Clean Architecture — see where DI, repos, and layers fit
5. Practice with Junior Q&A → Mid Q&A → Senior Q&A

The engineers who get hired aren't the ones who memorised the most. They're the ones who can think clearly, communicate honestly, and reason about tradeoffs under pressure.

That's what this roadmap is building.