Production-Grade .NET Backend Interview Playbook
A professionally designed seven-page field guide covering DI lifetimes, async cancellation, EF Core diagnosis, idempotency, retries, transaction boundaries, and 16 senior interview scenarios with answers.
What this playbook covers
This seven-page field guide is designed for senior .NET backend interview preparation. It connects dependency injection lifetimes to ownership and disposal, explains end-to-end cancellation and timeout budgets, provides an evidence-first EF Core query diagnosis playbook, and treats idempotency, retries, outbox delivery, and transaction boundaries as correctness decisions.
How to use it
Read one deep-dive chapter, answer its scenario questions aloud in 30 to 60 seconds, then take the linked production assessment in the Production-Grade .NET Backend Interview Path. The final pages contain 16 scenario checks, a concise answer key, and a scoring rubric.
Sample incident and answer
A payment provider times out, but the API does not know whether the payment was accepted. A teammate proposes retrying with a new payment ID. What would you change?
Worked answer: Preserve the identity of the original logical operation. Use the provider’s supported idempotency contract, query its status where possible, and keep enough durable state to reconcile the result. A timeout proves that the response was not received in time; it does not prove that no side effect occurred. A local transaction cannot roll back an arbitrary external payment.
Trace the crash window
- Record the logical payment identity and its request payload before contacting the provider. Two callers using the same identity must refer to the same operation; conflicting payloads must not quietly share a result.
- Send that operation using the provider-supported idempotency identity. A local timeout leaves the result pending or unknown until there is evidence of the outcome.
- If the provider succeeded but the process crashed before recording success, reconcile the original operation using the provider's supported lookup or replay contract. Do not create a second payment identity to escape the uncertainty.
- Persist the confirmed result and any durable event record in the intended local transaction. A dispatcher may deliver the event again after a crash, so its consumer must also handle duplicates.
- Give one component ownership of reconciliation and expose a stable pending status to the caller. Escalate unresolved cases rather than reporting failure and encouraging a second charge.
Follow-up: A connection reset, 429, or 503 can be transient. That alone does not make replaying a payment safe. Check the original operation's identity, the provider contract, and the remaining deadline before retrying.
Verification exercise: Trace four histories: duplicate requests arrive together; the response is lost after provider success; the process crashes before saving success; the event is delivered twice. For each, state which durable record identifies the operation and what evidence permits the next transition. These are design exercises, not executed payment, database, or service tests.
Use the seven-page PDF to connect this case to cancellation budgets, dependency lifetimes, database diagnosis, and the sixteen-scenario answer key.
Primary references
- Dependency injection guidelines
- Linked CancellationTokenSource API
- EF Core efficient querying
- Stripe idempotent-request contract, as one provider-specific reference; use your own provider's contract for its actual guarantees.