What actually comes up when someone asks you about .NET architecture
I spent about six years doing backend work in Cbefore moving into lead roles, and I can tell you the interview questions have shifted a lot. They used to be about ASP.NET Web Forms lifecycle and GAC registration. Now they want to know whether you understand dependency injection containers, distributed tracing, or how to structure a microservice mesh without creating a support nightmare. The people who interview for these positions usually ask the same ten things but phrase them differently each time. Start with dependency injection. Almost every interviewer wants to hear about lifetimes. Transient, scoped, singleton. A transient service gets created every time you request it. Scoped lives once per HTTP request. Singleton lives for the application's entire duration. The mistake most candidates make is not mentioning that injecting a scoped service into a singleton creates a captured scope bug. I remember a production incident where someone registered a DbContext as singleton by accident in an older .NET Framework app, and connection leaks happened every single deployment. You fix it by being explicit about lifetimes and using the factory pattern when you need to resolve scoped dependencies inside a longer-lived object. Next they will ask about layered architecture patterns. N-tier is the baseline. Presentation, business logic, data access. Clean architecture and hexagonal architecture come up more often now. The question is whether you understand why those exist. They exist to separate concerns so your business rules do not depend on frameworks or databases. Repository pattern belongs here too. It abstracts data access so you can swap implementations without touching business code. Most teams overcomplicate it though. A simple repository with generic CRUD methods is enough for most applications. Do not introduce repositories until you actually need multiple data stores or you want to mock data access for unit tests.
Microservices is the third topic. Everyone mentions it. Few people explain it well. The interview question is usually whether microservices are worth the complexity. My answer is they are not worth it for small teams working on simple CRUD apps. Split your system when you have independent scaling needs, different deployment cadences, or distinct bounded contexts that do not share the same database. Otherwise stick with a modular monolith. I have seen teams decompose a working monolith into fifteen services and spend six months dealing with distributed transactions and network latency before realizing they should have kept everything together.
Advanced patterns and what interviewers really want to hear
CQRS comes up a lot. Command Query Responsibility Segregation. Separate reads from writes. The reason this exists is that read and write workloads have different characteristics. Writes need consistency and validation. Reads need speed and can tolerate some staleness. MediatR is the common implementation in .NET. It handles in-process messaging between commands, queries, and handlers. The downside is extra indirection. Every operation goes through a pipeline with behaviors for logging, validation, and caching. You can write the same thing with direct method calls faster. Use CQRS when your domain has genuinely complex write operations or when your read model needs to be optimized differently than your write model. Event sourcing is another pattern that separates the signal from the noise in interviews. Instead of storing the current state of an entity, you store every event that changed it. You reconstruct state by replaying events. This gives you full audit history and makes certain types of bugs easier to debug. The tradeoff is complexity. Your queries become harder because you cannot just SELECT from a table. You need event stores, projection handlers, and migration paths for schema changes. I worked on a system where we tracked inventory changes through event sourcing because regulatory compliance required us to prove every transaction. The query layer took three months to build because we had to materialize views from events into readable tables. Outbox pattern is practical and frequently tested. When you publish a message to a queue and update a database in the same operation, you can end up with inconsistent state if the message publishes but the database commit fails. The solution is writing the message to an outbox table in the same transaction as your domain change, then having a separate process relay messages from that table to the broker. MassTransit and NServiceBus handle this automatically in newer .NET versions. Before that, people wrote custom polling loops that checked for unprocessed outbox records every few seconds.
Get the Full Details
Specific scenarios interviewers use to test real understanding
One question I encountered repeatedly involves caching strategy. How do you handle cache invalidation across distributed services? The naive answer is distributed cache like Redis. The better answer explains why Redis alone does not solve the problem. You still need cache consistency strategies like cache-aside, write-through, or time-based expiration with probabilistic refresh. I designed a system where product prices changed frequently and cache stampedes nearly killed the database during flash sales. The fix was using stochastic cooling for cache refresh rates instead of refreshing every cache entry at the same time when the price changed. Another common scenario is handling long-running operations. You cannot keep HTTP connections open for minutes while a report generates. The options are background jobs with Hangfire or Quartz, message queues with async processing, or server-sent events for pushing progress updates. I chose Hangfire for a data processing pipeline because it gave us retry logic, monitoring, and delayed execution out of the box. The downside is that scheduled jobs can pile up if your processing capacity is lower than your ingestion rate. We hit that limit once when a vendor sent three months of data in a single batch file. The queue backed up for two days. Distributed locking is a third topic that separates people who have built production systems from people who have only read about them. You need it when multiple instances try to update the same resource simultaneously. Redis REDIS, SQL Server advisory locks, and Azure Distributed Lock Manager are common approaches. The pitfall is forgetting about lock renewal. If your lock expires while a process is still running, another instance acquires it and you get duplicate execution. I wrote a lock manager with automatic renewal that extended the lock lease every ten seconds while the critical section was active. It prevented the exact race condition that caused duplicated payment processing in our finance module.
What good candidates do differently
The people who get hired usually connect their answers to business outcomes. They do not just describe a pattern. They explain when it saves money or prevents outages. They mention monitoring because every architecture decision needs observability. Without structured logging, metrics, and tracing, you are flying blind in production. They also admit what they do not know. .NET has a huge ecosystem now. If someone asks about service mesh with Istio and you only know Ocelot or YARP as API gateways, you say that. pretending expertise in areas where you have no hands-on experience shows up immediately when they ask follow-up questions about sidecar injection or mTLS configuration. Finally, they understand that .NET architecture is not about choosing the most modern tools. It is about matching the architecture to the team size, the domain complexity, and the operational maturity. A startup with four engineers should not build a service mesh. They should build a well-structured monolith with clear module boundaries so migration is possible later if needed. I have recommended against microservices in interviews more often than I have recommended them. Most teams do not need them, and the cost of getting them wrong is measured in lost productivity and production incidents.
