Senior .NET interviews ask about sagas, concurrency, messaging, observability, and CI/CD. If you have only built CRUD apps, you do not have answers to those questions yet. This workshop gives you those answers -- backed by code you wrote yourself.
6 Sessions
~2 hour each
Saturdays 5 PM UK / 9:30 PM IST
Live Remote
How It Works
You build an order-processing backend -- placing orders, reserving inventory, calling a payment service. The business domain is intentionally simple. Each session, I break the system in a way interviewers love to ask about. You see the failure, understand why it happens, and implement the fix yourself. Every session starts from a prepared branch, so you are never blocked by unfinished code from the previous week.
Session Breakdown
Session 1
"Why did the customer get charged twice?"
Order States, Compensation Logic, and the Timeout Problem
After this: you can explain why retry risks double-charging and how PaymentUncertain handles it safely.
What you will do
Start with a working synchronous order flow across Order, Inventory, and a simulated Payment service
Run two failure scenarios: a payment decline that leaks inventory, and a payment timeout where you do not know if the customer was charged
See the damage through a built-in consistency checker
Introduce an OrderStatus enum -- Created, InventoryReserved, Completed, PaymentFailed, PaymentUncertain
Add compensation logic that releases inventory on definitive failures
Handle timeouts with a PaymentUncertain state that flags orders for manual review instead of blindly retrying
What this pattern is called
Choreography-based saga with compensation -- you will have both the working code and the vocabulary
Interview relevance: "What happens when service B fails after service A has already committed?" is the most common senior backend question. You will answer it with a real before-and-after. The timeout scenario alone separates senior answers from mid-level ones -- most candidates say retry, you will explain why that is dangerous and what to do instead.
Session 2
"Two users booked the last seat -- who gets it?"
Optimistic Concurrency, Row Versioning, and Conflict Resolution
After this: you can explain why "just add a lock" kills throughput and what to do instead.
What you will do
Two orders hit the same inventory at the same time and the system oversells
Fix this using EF Core row versioning and optimistic concurrency against SQL Server
See how a second update fails cleanly and retries without data corruption
Learn when to serialise, when to partition by entity, and why global locking is rarely the right answer
Interview relevance: "Two users buy the last item at the same time -- what happens?" You will not say "add a lock." You will say "I partition by entity -- orders for the same product are serialised, orders for different products run in parallel." That level of nuance is what separates senior from mid-level.
Session 3
"The payment service went down -- now what?"
Event-Driven Messaging with MassTransit
After this: you can explain real trade-offs of async messaging, not textbook answers about decoupling.
What you will do
Understand what a message bus is, what consumers and message contracts look like, and how to configure MassTransit
Replace direct synchronous calls with event-driven communication
API publishes OrderCreated and returns immediately -- response time drops from seconds to milliseconds
See how the consumer picks up the message and processes the order asynchronously
In production you would swap InMemory transport for RabbitMQ or Azure Service Bus -- consumer code stays identical
Interview relevance: "When would you use messaging vs a direct HTTP call?" Most candidates give vague answers about decoupling. You will say "I rebuilt a sync flow as event-driven. The API response time dropped from 3 seconds to milliseconds. The trade-off is eventual consistency." That is a real trade-off discussion, not a textbook answer.
Session 4
"The event never arrived -- and then it arrived twice"
Transactional Outbox, Retry Policies, Dead Letter Queues, and Idempotent Consumers
After this: you can explain why exactly-once delivery is essentially impossible and what you do instead.
What you will do
Discover the first problem: if the process crashes after DB commit but before the event publishes, the event is lost forever
Fix this with the transactional outbox pattern -- write the event to an OutboxMessages table inside the same DB transaction, and a background processor publishes it reliably
Discover the second problem: a consumer throws an exception, the message goes back to the queue, fails again -- infinite loop
Configure retry with exponential backoff, then route poison messages to a dead letter queue
Make the consumer idempotent so reprocessed messages do not cause duplicate side effects
Interview relevance: "How do you handle duplicate messages in a distributed system?" Most people say "use exactly-once delivery." You will say "exactly-once is essentially impossible in distributed systems. You design for at-least-once delivery and make consumers idempotent." That shows you understand the fundamental constraint.
Session 5
"Something failed in production -- how do you find it?"
Correlation IDs, Structured Logging with Serilog, and Distributed Tracing with OpenTelemetry
After this: your answer to "how do you debug production issues" will sound senior, not junior.
What you will do
Add a correlation ID that flows from the original HTTP request into downstream calls
Use Serilog structured logging so every log line carries the same ID
Simulate a failure and trace the root cause in seconds by searching for a single correlation ID
Interview relevance: "How do you debug issues in production?" If your answer is "I check the logs" you sound junior. After this session you will say "structured logging with Serilog so every entry is queryable by OrderId or CorrelationId, distributed tracing with OpenTelemetry to follow a request across services." That is specific and exactly what hiring managers want to hear.
Session 6
"Prove it works -- testing and shipping"
Testcontainers, Integration Testing, Docker, and CI/CD with GitHub Actions
After this: you can describe a real CI/CD pipeline you built yourself, not one someone else set up.
What you will do
Containerise the system with Docker using a pre-provided Dockerfile and docker-compose -- understand what each line does, build the image, and run the full system locally
Write integration tests that spin up a real SQL Server container using Testcontainers
These tests catch issues that mocks hide -- connection behaviour, transaction semantics, constraint enforcement
Set up a GitHub Actions pipeline that runs the same tests on every push
Interview relevance: Two questions this covers. "What is your testing strategy?" -- unit tests on business logic, integration tests with Testcontainers against a real database, not mocks. "Walk me through your CI/CD pipeline." -- you will describe a real pipeline you built yourself.
Pricing
Per Session
4,500
INR
$54.25
USD
£41
GBP
Pay per session. No commitment beyond the session you are joining.
How it works: Pay for the session you want to attend. Each session is standalone -- you pay only for what you join. If you attended Session 1 and want to continue, pay for Session 2 before it starts, and so on.
After payment, send your confirmation to me on LinkedIn along with your name, email, and WhatsApp number.
What You Leave With
⚙
A GitHub repo you can link on your CV that demonstrates production patterns, not just CRUD
💡
Concrete answers to 6 common interview questions backed by code you actually wrote and can walk through
▶
A working CI/CD pipeline that shows you understand shipping, not just coding
✅
Integration tests against real infrastructure -- something most candidates cannot demonstrate
🔍
Structured logging and distributed tracing across services with correlation IDs
📦
Docker-based local setup for the complete system with SQL Server
Tech Stack
Everything used in the workshop is free, widely adopted in the Indian and global .NET market, and relevant to what employers are hiring for right now.
.NET 8
Current LTS runtime
ASP.NET Core
API framework
EF Core
Data access
SQL Server (LocalDB)
Database -- comes with VS2022, zero setup
MassTransit
Messaging abstraction
Serilog
Structured logging
OpenTelemetry
Distributed tracing
Docker
Containerisation
Testcontainers
Integration tests against real infrastructure
GitHub Actions
CI/CD pipeline
xUnit
Testing framework
Swagger
API documentation
Prerequisites -- What You Should Already Know
Comfortable writing C# and .NET
Built at least one REST API with ASP.NET Core
Basic EF Core usage
The workshop builds on top of these skills from day one. Please make sure you are comfortable with them before joining.
Not Required to Know Beforehand
You do not need prior experience with any of the following. They are introduced during the workshop:
MassTransit
Docker
Distributed systems patterns
Serilog or OpenTelemetry
Testcontainers
Note on depth: Tools like MassTransit, Docker, Serilog, and OpenTelemetry are each deep topics that could be full courses on their own. This workshop does not aim to cover them in exhaustive detail. You will learn the configuration and usage needed to apply them effectively in the project. The goal is practical, working knowledge -- enough to use these tools confidently on a real codebase and explain them clearly in an interview.
What You Will Need
GitHub account free
.NET 8 SDK installed
Docker installed
Visual Studio 2022 Community edition is free. Workshop assistance is only available for VS2022.
SQL Server LocalDB included with VS2022 installation
What This Workshop Does Not Cover
This is a technical workshop focused on how production systems are built, tested, debugged, and shipped. To set clear expectations, it does not cover:
-- Job search strategy or career advice
-- CV or resume formatting
-- Mock interviews
-- LinkedIn profile reviews
-- Guaranteed interview calls, promotions, or role changes
Frequently Asked Questions
I am a junior developer. Is this for me?
If you are comfortable with C#, have built at least one ASP.NET Core API, and used EF Core for basic data access, you should be fine. If you just finished a bootcamp and are still getting comfortable with the language, this workshop might be one step ahead of where you are right now.
What if I miss a session?
Each session starts from a prepared branch, so missing one session will not block you from continuing. You will be able to pick up the correct starting point for the next session regardless.
What if I get stuck during a session?
We will assist you so you are up and running before the next session. Nobody gets left behind.
Will this help me in interviews?
This workshop is built around questions that come up repeatedly in .NET backend interviews. You will not get mock interview practice or career coaching. What you will get is hands-on experience with the exact patterns interviewers ask about, and a codebase you built yourself that you can walk them through. There are no guarantees -- but developers who can explain what they built and why tend to do well.
Can I join from any session or do I have to start from Session 1?
Each session starts from a prepared branch with all the previous work already in place. So you can technically join at any point. That said, starting from Session 1 will give you the full context of the system and how each piece connects.
What is the time commitment each week?
Each session is 90 to 120 minutes on Saturday evenings. There is no mandatory homework, but reviewing the code between sessions will help you get more out of it.
Can I get an invoice for my employer?
Yes. If your employer is sponsoring your participation, reach out to me directly and I will provide a proper invoice.
Is this a one-time workshop or will there be more cohorts?
This is the founding cohort. Future cohorts may be announced later.