An ASP.NET Core order system has 8 modules, 3 teams, and one shared SQL Server database; which boundary would you extract first if fulfillment needs independent releases and 5 times the write capacity?

I would first isolate fulfillment as a business capability, but only after giving it an explicit contract and data ownership inside the monolith. - I map the reservation, packing, and shipment invariants and keep operations that need one transaction inside the fulfillment boundary. - Other modules stop writing fulfillment tables directly and call an in-process facade before that facade becomes HTTP, gRPC, or messaging. - A transactional outbox publishes order-ready events, while fulfillment owns its write model and idempotently consumes those events. - Extraction is justified when the separate worker and database prove the required 5 times write capacity without cross-service transactions.

Checkout calls pricing, inventory, and fraud services and must answer within 600 ms; which calls should use gRPC and which work should become asynchronous?

I would keep only decisions required for the response synchronous and move downstream state propagation to durable messages. - Pricing and inventory reservation can run concurrently over gRPC with a shared deadline near 450 ms, leaving time for checkout to compose the result. - Fraud uses a synchronous fast decision only if checkout cannot proceed without it; deeper review becomes a pending workflow rather than another long hop. - Confirmation email, analytics, and warehouse projection consume outbox events after the checkout transaction commits. - I reject a chain where each service gets its own 600 ms timeout because latency and failure probability compound at every hop.

Design an ASP.NET Core catalog API for 100,000 requests per second, 95% reads, and p99 below 120 ms across 3 availability zones.

I would keep the request path stateless, cache read models aggressively, and cap every shared dependency. - Kestrel instances sit behind a zone-aware load balancer, expose readiness separately from liveness, and keep at least 30% capacity after losing one zone. - A CDN handles public immutable responses, Redis stores shared product projections, and a small IMemoryCache absorbs the hottest versioned keys. - EF Core projects only required columns with AsNoTracking, while SQL Server connection concurrency is bounded instead of growing with pod count. - Load tests use the real key distribution and require p99 below 120 ms at 125,000 RPS with one zone removed.

An ASP.NET Core API needs forwarded headers, exception handling, HSTS, routing, CORS, authentication, authorization, rate limiting, and endpoint execution; put the middleware in a defensible order.

I would order middleware by which request state each component must establish or protect. - Forwarded headers run first for trusted proxies, then exception handling and HSTS establish correct scheme and consistent failures before application work. - Routing selects endpoint metadata before CORS, authentication, authorization, and endpoint-specific rate limiting use that metadata. - Authentication must precede authorization, while CORS must run before the response is produced so even rejected cross-origin requests receive correct headers. - I verify the order with integration tests for preflight, unauthenticated, forbidden, rate-limited, and throwing endpoints rather than trusting visual inspection.

A service will expose 180 minimal API endpoints to 12 clients; how would you organize contracts, validation, authorization, and OpenAPI without rebuilding an MVC controller layer?

I would group minimal APIs by capability and make every endpoint's contract explicit at registration. - MapGroup applies route prefixes, tags, authorization policies, and shared conventions to bounded areas such as orders or billing. - TypedResults and named request records keep response unions and OpenAPI metadata compile-time visible instead of returning arbitrary IResult everywhere. - Endpoint filters handle reusable request validation, while middleware remains for pipeline-wide concerns such as correlation and exception mapping. - Contract tests generate OpenAPI and compare all 180 operations for accidental removals, new required fields, and changed status codes.

An ASP.NET Core upload endpoint accepts files up to 2 GB and must keep process memory below 1 GB with 200 concurrent uploads; design the request path.

I would stream each body directly to durable storage and reject oversized or slow uploads before buffering them. - Kestrel and the reverse proxy enforce the 2 GB limit, header timeout, and minimum data rate consistently so limits cannot be bypassed at another layer. - The endpoint reads Request.BodyReader in bounded segments and writes to blob multipart upload without calling ToArray or binding the whole file. - A semaphore caps active storage writes from measured bandwidth, while request cancellation aborts the multipart upload and releases resources. - The load test runs 200 maximum-size streams and proves managed memory stays bounded instead of scaling with uploaded bytes.

A public ASP.NET Core API has 4,000 partner integrations and a 12-month compatibility promise; how do you add a required delivery preference?

I would add the concept without making it required for existing clients and run the breaking semantic change as a migration. - The first contract adds an optional deliveryPreference with server behavior matching the old default when it is absent. - OpenAPI compatibility checks reject removal, type narrowing, and newly required fields on the existing version. - Usage telemetry identifies callers still omitting the field, and migration guidance includes their exact endpoint and last-use date. - Only after 12 months would a new dated version require the field; the old version keeps its original meaning until retirement.

Kubernetes restarts all 80 ASP.NET Core pods when SQL Server is unavailable for 40 seconds; how should liveness, readiness, and startup checks be defined?

I would keep dependency outages out of liveness and use readiness to stop routing requests to pods that cannot serve them. - Liveness checks only whether the process and its internal loop can make progress, so a SQL Server failure does not create an 80-pod restart storm. - Readiness can include a short database probe when the API truly cannot serve without it, with hysteresis to avoid rapid endpoint flapping. - Startup covers migrations, configuration validation, or warmup that may legitimately exceed ordinary liveness timing. - Tests remove SQL Server for 40 seconds and require zero pod restarts, no traffic to unready pods, and automatic recovery afterward.

Six ASP.NET Core services share payment configuration, but only credential rotation may reload at runtime; how would you implement and validate it?

I would separate immutable startup options from the small versioned secret that is safe to reload. - Bind endpoint, timeout, and retry limits to strongly typed options and call ValidateOnStart so invalid values prevent readiness. - Credentials come from a managed secret provider through IOptionsMonitor, while consumers replace the complete immutable credential snapshot atomically. - A reload never partially changes endpoint and credential, and the previous credential remains usable during a documented overlap window. - Integration tests rotate the secret under 1,000 concurrent calls and assert no request observes a mixed configuration.

A parser handles 100,000 UTF-8 headers per second and currently allocates 600 bytes for every 2 KB input; where would Span help and where would it not?

I would use spans to slice and parse the existing buffer without substrings, but only after an allocation profile confirms this parser is hot. - ReadOnlySpan can scan delimiters and parse numeric fields directly from the request buffer without creating temporary strings. - The span cannot be stored on the heap or remain live across await, so any data needed later must become an owned value or Memory . - Returning a span into a pooled buffer is unsafe after that buffer is returned, making ownership more important than the zero-allocation claim. - BenchmarkDotNet must show lower allocation and improved throughput on real header distributions, not only a tiny synthetic input.

A pipeline reads 64 KB frames, awaits decompression, and passes slices through 3 asynchronous stages; choose between Span , Memory , and copying.

I would carry owned Memory across asynchronous boundaries and create short-lived spans only inside synchronous parsing steps. - Span cannot remain live across an await, while Memory can be stored in the stage item and sliced without copying. - The owner must outlive all 3 stages, so a pooled IMemoryOwner is disposed only after the final consumer completes. - A stage that retains data beyond that ownership window receives a copy, because use-after-return corruption is worse than one measured allocation. - A stress test delays stages independently and verifies checksums to expose lifetime bugs that normal throughput tests may miss.

A hot method needs a temporary buffer whose size comes from input and ranges from 32 bytes to 256 KB; define a safe stackalloc policy.

I would stack-allocate only a small fixed upper range and use pooled or heap memory above it. - A policy such as stackalloc up to 1 KB bounds stack consumption independently of attacker-controlled input. - Larger buffers rent from ArrayPool inside try-finally, and sensitive bytes are cleared before return. - stackalloc inside a loop is avoided because repeated allocations remain until the method returns and can exhaust the stack. - Benchmarks include recursion depth and concurrent request load, not just the isolated method's nanoseconds.

JSON serialization creates 20 GB per minute of temporary byte arrays, mostly between 128 KB and 1 MB; would you introduce ArrayPool ?

I would pool the large reusable buffers if profiling ties them to Gen 2 or LOH pressure and ownership can remain simple. - ArrayPool may return a larger dirty array, so callers track the valid length and clear customer data before returning it. - Every rent is paired with return in finally, and no async operation may retain the array after that return. - I cap retained bucket sizes or use a custom pool if occasional 20 MB payloads would keep excessive memory resident. - The decision requires lower allocation rate and GC pause time under the same throughput, not merely a faster microbenchmark.

A metrics formatter boxes 15 million integer values per second through an object-based API; how would you remove the cost without making every value type a struct?

I would remove the object boundary on the measured hot path with generics or span-based formatting. - A generic method with constrained formatting can keep value types unboxed, while TryFormat writes directly into a destination span. - I inspect IL or allocation profiles to confirm boxing rather than assuming every interface call allocates. - Structs remain small, immutable, and value-like; converting large mutable domain objects to structs would add copying and semantic risk. - The benchmark reports operations per second and allocated bytes, with the existing object API retained outside the hot formatter if compatibility requires it.

Two UTF-8 parsers differ by 25 ns in a quick Stopwatch test; design a BenchmarkDotNet experiment that can justify changing the production parser.

I would benchmark representative payloads and allocations under a controlled harness, then validate the winner in the end-to-end path. - The suite covers small, median, large, valid, and malformed inputs with the current parser marked as Baseline. - MemoryDiagnoser reports allocated bytes and GC counts, while warmup and multiple iterations reduce JIT and timer noise. - Inputs are consumed so dead-code elimination cannot remove parsing, and each benchmark uses the same runtime and deployment architecture. - A 25 ns microbenchmark win matters only if the parser is a measured production bottleneck and improves service throughput or CPU materially.

An API allocates 90 KB response buffers at 8,000 requests per second and must keep GC pauses below 50 ms; explain the generation and LOH implications.

Those buffers normally land on the Large Object Heap, so sustained churn can force expensive Gen 2 collections and threaten the pause target. - Gen 0 is optimized for short-lived small objects, but LOH objects are collected with Gen 2 even when their lifetime is brief. - At 8,000 allocations per second, I first stream, reduce, or pool the 90 KB buffer rather than tune GC around avoidable churn. - dotnet-counters and a trace must correlate allocation rate, LOH size, Gen 2 frequency, and pause duration with request load. - Pooling is accepted only with bounded retention and safe ownership because a large pool can trade pauses for resident memory.

A trading calculation runs for 400 ms every second and requires no GC pause above 2 ms during that window; would you use SustainedLowLatency or NoGCRegion?

I would prefer a tightly budgeted NoGCRegion only if the 400 ms allocation ceiling is measured and enforceable. - TryStartNoGCRegion receives enough space for the known allocation budget, and the code handles failure to enter rather than assuming the guarantee. - EndNoGCRegion runs in finally, while monitoring catches an unexpected GC caused by exceeding the budget. - SustainedLowLatency is broader and may defer intrusive collections at the cost of heap growth, so it suits a longer bounded period with less predictable allocation. - I first reduce allocations because latency modes cannot make an allocation-heavy path free.

A containerized ASP.NET Core service has 2 CPU cores and a 768 MB limit; how would you choose and validate server GC versus workstation GC?

I would benchmark both modes in the actual container because server GC can trade more heaps and memory for throughput. - Server GC uses dedicated collection threads and multiple heaps, which may help sustained parallel load but consume meaningful memory inside 768 MB. - Workstation GC may fit a small constrained process better when request concurrency and live set are modest. - The test compares throughput, p99 pause, GC CPU, heap size, and working set at the same load and CPU quota. - I leave non-GC headroom for thread stacks, native buffers, JIT code, and libraries before choosing the faster result.

A .NET service runs in a 512 MB pod and is OOM-killed although GC heap size never exceeds 330 MB; set a defensible memory budget.

I would budget the whole process, not equate managed heap size with container memory. - Thread stacks, native HTTP buffers, compression, JIT code, mapped files, and allocator fragmentation can explain the remaining 182 MB. - A GC heap hard limit leaves measured native headroom, for example 300 MB only after observing peak non-GC use under realistic traffic. - Tightening the heap raises collection frequency, so I compare p99 latency, GC CPU, and allocation rate before rollout. - The pod limit and heap limit are tested with maximum concurrency and large payloads, including a safety margin rather than the average working set.

A cache lookup completes synchronously 97% of the time and runs 4 million times per second; should its API return Task or ValueTask ?

I would consider ValueTask only after proving Task allocation is material at this call volume and preserving single-consumption semantics. - The synchronous hit can return the value without allocating a new Task , while the 3% asynchronous miss wraps the real operation. - ValueTask is a larger struct and should normally be awaited once, not cached, stored broadly, or consumed repeatedly. - If the implementation already returns cached Task instances, ValueTask may add complexity without removing allocations. - Benchmarking must include callers because copying, AsTask conversions, and async state machines can erase the local gain.

.NET Developer interview questions

100 real questions with model answers and explanations for Senior .NET Developer candidates.

See a .NET Developer resume example →

Practice with flashcards

Spaced repetition · Hunter Pass

Questions

system-designcapacityaspnet

I would first isolate fulfillment as a business capability, but only after giving it an explicit contract and data ownership inside the monolith.

I map the reservation, packing, and shipment invariants and keep operations that need one transaction inside the fulfillment boundary.
Other modules stop writing fulfillment tables directly and call an in-process facade before that facade becomes HTTP, gRPC, or messaging.
A transactional outbox publishes order-ready events, while fulfillment owns its write model and idempotently consumes those events.
Extraction is justified when the separate worker and database prove the required 5 times write capacity without cross-service transactions.

Why interviewers ask this: The interviewer is evaluating bounded contexts, data ownership, migration order, and whether extraction solves the stated scaling need.

asyncgrpcpricing

I would keep only decisions required for the response synchronous and move downstream state propagation to durable messages.

Pricing and inventory reservation can run concurrently over gRPC with a shared deadline near 450 ms, leaving time for checkout to compose the result.
Fraud uses a synchronous fast decision only if checkout cannot proceed without it; deeper review becomes a pending workflow rather than another long hop.
Confirmation email, analytics, and warehouse projection consume outbox events after the checkout transaction commits.
I reject a chain where each service gets its own 600 ms timeout because latency and failure probability compound at every hop.

Why interviewers ask this: A strong answer separates response-critical work from eventual work and budgets the synchronous path quantitatively.

designavailabilityaspnet

I would keep the request path stateless, cache read models aggressively, and cap every shared dependency.

Kestrel instances sit behind a zone-aware load balancer, expose readiness separately from liveness, and keep at least 30% capacity after losing one zone.
A CDN handles public immutable responses, Redis stores shared product projections, and a small IMemoryCache absorbs the hottest versioned keys.
EF Core projects only required columns with AsNoTracking, while SQL Server connection concurrency is bounded instead of growing with pod count.
Load tests use the real key distribution and require p99 below 120 ms at 125,000 RPS with one zone removed.

Why interviewers ask this: The interviewer is checking ASP.NET Core scaling, layered caching, database protection, and failure headroom.

endpointsrate-limitingcors

I would order middleware by which request state each component must establish or protect.

Forwarded headers run first for trusted proxies, then exception handling and HSTS establish correct scheme and consistent failures before application work.
Routing selects endpoint metadata before CORS, authentication, authorization, and endpoint-specific rate limiting use that metadata.
Authentication must precede authorization, while CORS must run before the response is produced so even rejected cross-origin requests receive correct headers.
I verify the order with integration tests for preflight, unauthenticated, forbidden, rate-limited, and throwing endpoints rather than trusting visual inspection.

Why interviewers ask this: The interviewer is evaluating concrete middleware dependencies and whether ordering is verified through behavior.

endpointsopenapiauth

I would group minimal APIs by capability and make every endpoint's contract explicit at registration.

MapGroup applies route prefixes, tags, authorization policies, and shared conventions to bounded areas such as orders or billing.
TypedResults and named request records keep response unions and OpenAPI metadata compile-time visible instead of returning arbitrary IResult everywhere.
Endpoint filters handle reusable request validation, while middleware remains for pipeline-wide concerns such as correlation and exception mapping.
Contract tests generate OpenAPI and compare all 180 operations for accidental removals, new required fields, and changed status codes.

Why interviewers ask this: The interviewer is checking whether minimal APIs remain structured and contract-safe at a nontrivial endpoint count.

designaspnetconcurrency

I would stream each body directly to durable storage and reject oversized or slow uploads before buffering them.

Kestrel and the reverse proxy enforce the 2 GB limit, header timeout, and minimum data rate consistently so limits cannot be bypassed at another layer.
The endpoint reads Request.BodyReader in bounded segments and writes to blob multipart upload without calling ToArray or binding the whole file.
A semaphore caps active storage writes from measured bandwidth, while request cancellation aborts the multipart upload and releases resources.
The load test runs 200 maximum-size streams and proves managed memory stays bounded instead of scaling with uploaded bytes.

Why interviewers ask this: The interviewer is evaluating ASP.NET Core streaming, server limits, cancellation, and memory arithmetic.

aspnetapipromises

I would add the concept without making it required for existing clients and run the breaking semantic change as a migration.

The first contract adds an optional deliveryPreference with server behavior matching the old default when it is absent.
OpenAPI compatibility checks reject removal, type narrowing, and newly required fields on the existing version.
Usage telemetry identifies callers still omitting the field, and migration guidance includes their exact endpoint and last-use date.
Only after 12 months would a new dated version require the field; the old version keeps its original meaning until retirement.

Why interviewers ask this: The interviewer is checking additive API evolution, semantic defaults, telemetry, and an enforceable deprecation window.

kuberneteshealth-checkssql

I would keep dependency outages out of liveness and use readiness to stop routing requests to pods that cannot serve them.

Liveness checks only whether the process and its internal loop can make progress, so a SQL Server failure does not create an 80-pod restart storm.
Readiness can include a short database probe when the API truly cannot serve without it, with hysteresis to avoid rapid endpoint flapping.
Startup covers migrations, configuration validation, or warmup that may legitimately exceed ordinary liveness timing.
Tests remove SQL Server for 40 seconds and require zero pod restarts, no traffic to unready pods, and automatic recovery afterward.

Why interviewers ask this: The interviewer is evaluating orchestrator semantics and protection against restart amplification.

validationconfigaspnet

I would separate immutable startup options from the small versioned secret that is safe to reload.

Bind endpoint, timeout, and retry limits to strongly typed options and call ValidateOnStart so invalid values prevent readiness.
Credentials come from a managed secret provider through IOptionsMonitor, while consumers replace the complete immutable credential snapshot atomically.
A reload never partially changes endpoint and credential, and the previous credential remains usable during a documented overlap window.
Integration tests rotate the secret under 1,000 concurrent calls and assert no request observes a mixed configuration.

Why interviewers ask this: The interviewer is checking options validation, safe reload scope, atomic publication, and rotation behavior under load.

memory

I would use spans to slice and parse the existing buffer without substrings, but only after an allocation profile confirms this parser is hot.

ReadOnlySpan<byte> can scan delimiters and parse numeric fields directly from the request buffer without creating temporary strings.
The span cannot be stored on the heap or remain live across await, so any data needed later must become an owned value or Memory<byte>.
Returning a span into a pooled buffer is unsafe after that buffer is returned, making ownership more important than the zero-allocation claim.
BenchmarkDotNet must show lower allocation and improved throughput on real header distributions, not only a tiny synthetic input.

Why interviewers ask this: The interviewer is evaluating Span<T> benefits, ref-struct lifetime limits, ownership, and measurement discipline.

asyncmemoryci-cd

I would carry owned Memory<byte> across asynchronous boundaries and create short-lived spans only inside synchronous parsing steps.

Span<byte> cannot remain live across an await, while Memory<byte> can be stored in the stage item and sliced without copying.
The owner must outlive all 3 stages, so a pooled IMemoryOwner<byte> is disposed only after the final consumer completes.
A stage that retains data beyond that ownership window receives a copy, because use-after-return corruption is worse than one measured allocation.
A stress test delays stages independently and verifies checksums to expose lifetime bugs that normal throughput tests may miss.

Why interviewers ask this: The interviewer is checking async memory lifetimes, zero-copy limits, and explicit ownership across stages.

I would stack-allocate only a small fixed upper range and use pooled or heap memory above it.

A policy such as stackalloc up to 1 KB bounds stack consumption independently of attacker-controlled input.
Larger buffers rent from ArrayPool<byte> inside try-finally, and sensitive bytes are cleared before return.
stackalloc inside a loop is avoided because repeated allocations remain until the method returns and can exhaust the stack.
Benchmarks include recursion depth and concurrent request load, not just the isolated method's nanoseconds.

Why interviewers ask this: The interviewer is evaluating stack capacity, input bounds, pooling fallback, and realistic benchmark scope.

serialization

I would pool the large reusable buffers if profiling ties them to Gen 2 or LOH pressure and ownership can remain simple.

ArrayPool<byte> may return a larger dirty array, so callers track the valid length and clear customer data before returning it.
Every rent is paired with return in finally, and no async operation may retain the array after that return.
I cap retained bucket sizes or use a custom pool if occasional 20 MB payloads would keep excessive memory resident.
The decision requires lower allocation rate and GC pause time under the same throughput, not merely a faster microbenchmark.

Why interviewers ask this: The interviewer is checking pooling benefits, data safety, ownership, retention cost, and production-relevant evidence.

monitoringapitypes

I would remove the object boundary on the measured hot path with generics or span-based formatting.

A generic method with constrained formatting can keep value types unboxed, while TryFormat writes directly into a destination span.
I inspect IL or allocation profiles to confirm boxing rather than assuming every interface call allocates.
Structs remain small, immutable, and value-like; converting large mutable domain objects to structs would add copying and semantic risk.
The benchmark reports operations per second and allocated bytes, with the existing object API retained outside the hot formatter if compatibility requires it.

Why interviewers ask this: The interviewer is evaluating boxing mechanics, constrained generics, struct trade-offs, and scoped optimization.

experimentsdesign

I would benchmark representative payloads and allocations under a controlled harness, then validate the winner in the end-to-end path.

The suite covers small, median, large, valid, and malformed inputs with the current parser marked as Baseline.
MemoryDiagnoser reports allocated bytes and GC counts, while warmup and multiple iterations reduce JIT and timer noise.
Inputs are consumed so dead-code elimination cannot remove parsing, and each benchmark uses the same runtime and deployment architecture.
A 25 ns microbenchmark win matters only if the parser is a measured production bottleneck and improves service throughput or CPU materially.

Why interviewers ask this: The interviewer is checking benchmark validity and whether micro-results connect to production economics.

api

Those buffers normally land on the Large Object Heap, so sustained churn can force expensive Gen 2 collections and threaten the pause target.

Gen 0 is optimized for short-lived small objects, but LOH objects are collected with Gen 2 even when their lifetime is brief.
At 8,000 allocations per second, I first stream, reduce, or pool the 90 KB buffer rather than tune GC around avoidable churn.
dotnet-counters and a trace must correlate allocation rate, LOH size, Gen 2 frequency, and pause duration with request load.
Pooling is accepted only with bounded retention and safe ownership because a large pool can trade pauses for resident memory.

Why interviewers ask this: The interviewer is evaluating generational GC, the LOH threshold consequence, and mitigation based on measured allocation.

I would prefer a tightly budgeted NoGCRegion only if the 400 ms allocation ceiling is measured and enforceable.

TryStartNoGCRegion receives enough space for the known allocation budget, and the code handles failure to enter rather than assuming the guarantee.
EndNoGCRegion runs in finally, while monitoring catches an unexpected GC caused by exceeding the budget.
SustainedLowLatency is broader and may defer intrusive collections at the cost of heap growth, so it suits a longer bounded period with less predictable allocation.
I first reduce allocations because latency modes cannot make an allocation-heavy path free.

Why interviewers ask this: The interviewer is checking precise latency-mode semantics, memory budgeting, and fallback behavior.

validationcontainersaspnet

I would benchmark both modes in the actual container because server GC can trade more heaps and memory for throughput.

Server GC uses dedicated collection threads and multiple heaps, which may help sustained parallel load but consume meaningful memory inside 768 MB.
Workstation GC may fit a small constrained process better when request concurrency and live set are modest.
The test compares throughput, p99 pause, GC CPU, heap size, and working set at the same load and CPU quota.
I leave non-GC headroom for thread stacks, native buffers, JIT code, and libraries before choosing the faster result.

Why interviewers ask this: The interviewer is evaluating GC mode trade-offs in containers rather than relying on server defaults.

memorydata-structures

I would budget the whole process, not equate managed heap size with container memory.

Thread stacks, native HTTP buffers, compression, JIT code, mapped files, and allocator fragmentation can explain the remaining 182 MB.
A GC heap hard limit leaves measured native headroom, for example 300 MB only after observing peak non-GC use under realistic traffic.
Tightening the heap raises collection frequency, so I compare p99 latency, GC CPU, and allocation rate before rollout.
The pod limit and heap limit are tested with maximum concurrency and large payloads, including a safety margin rather than the average working set.

Why interviewers ask this: The interviewer is checking container memory accounting, heap hard-limit costs, and capacity validation.

cachingapiasync

I would consider ValueTask<T> only after proving Task allocation is material at this call volume and preserving single-consumption semantics.

The synchronous hit can return the value without allocating a new Task<T>, while the 3% asynchronous miss wraps the real operation.
ValueTask<T> is a larger struct and should normally be awaited once, not cached, stored broadly, or consumed repeatedly.
If the implementation already returns cached Task<T> instances, ValueTask may add complexity without removing allocations.
Benchmarking must include callers because copying, AsTask conversions, and async state machines can erase the local gain.

Why interviewers ask this: The interviewer is evaluating when ValueTask is justified and whether its usage constraints are understood.

Locked questions

21
A hot ASP.NET Core handler has 12 tiny async wrapper methods and allocates 1.5 KB per request; what does the compiler generate, and what would you optimize?
asyncoptimizationaspnet
22
A shared library is used by ASP.NET Core and a WPF desktop client; where should ConfigureAwait(false) appear, given that ASP.NET Core has no request SynchronizationContext?
aspnetconfigasync
23
An ASP.NET Core request has a 700 ms server deadline, may be canceled by the client, and calls SQL Server plus HttpClient; design cancellation propagation.
designresilienceaspnet
24
An endpoint returns up to 5 million audit rows and clients usually stop after the first 10,000; choose between Task<List<T>> and IAsyncEnumerable<T>.
endpointsasync
25
A component flushes a 16 MB encrypted buffer to remote storage during cleanup; should it implement IDisposable, IAsyncDisposable, or both?
componentsencryptionresource-management
26
A worker receives bursts of 50,000 items, each retained item is 8 KB, and consumers sustain 5,000 items per second; configure a Channel without exceeding 160 MB for queued payloads.
configdata-structures
27
At 2,000 concurrent requests, a service calls Task.Result around asynchronous SQL and HTTP APIs; estimate the scaling risk and redesign the path.
asyncconcurrencyhttp
28
You must process 10,000 independent HTTP items, but the downstream permits 200 concurrent calls and 1,000 requests per second; configure Parallel.ForEachAsync.
concurrencyhttpconfig
29
A service protects a 100 microsecond in-memory state update and separately limits 40 concurrent calls to a dependency; choose lock, SemaphoreSlim, or both.
memorydependenciesconcurrency
30
A state flag moves from Pending to Running exactly once, while completion updates status, timestamp, and result together; where would you use Interlocked and where a lock?
31
A singleton reloads a 5 MB routing table every minute while 200 threads read it without locks; how do you publish updates safely?
concurrency
32
ConcurrentDictionary.GetOrAdd builds a $0.05 remote client, and under contention the factory runs 30 times for one key; how do you prevent duplicate side effects?
concurrency
33
A read-heavy authorization cache has 50,000 rules, 100,000 lookups per second, and 10 updates per minute; choose immutable snapshots or a concurrent mutable collection.
concurrencyimmutabilityauth
34
Map DI lifetimes for an ASP.NET Core request that uses a stateless formatter, DbContext, tenant context, and a thread-safe metadata cache shared by all requests.
ormcachingconcurrency
35
A singleton pricing cache constructor receives a scoped DbContext; the service passes development tests but fails scope validation in production mode. Fix the captive dependency.
pricingcachingdependencies
36
A singleton BackgroundService processes 500 messages per second and needs DbContext plus a scoped tenant resolver for each message; define scope ownership.
ownershipconcurrencyorm
37
A request resolves 3 disposable transient services and one scoped DbContext; who disposes each, and what changes if code constructs one transient manually?
orm
38
A service has 4 payment providers selected by merchant and needs decorators for metrics and retries; can the built-in .NET container handle it without a third-party container?
containersmonitoringdependencies
39
An EF Core endpoint reads 20,000 orders, updates 5 of them, and currently tracks the entire result; choose tracking, no-tracking, or identity resolution.
ormendpoints
40
An EF Core endpoint returns 100 orders with 8 lines each but executes 101 SQL statements and misses a 150 ms p95 target; reshape it without over-fetching.
sqlormendpoints
41
An EF Core query Includes 2 collections with 40 and 60 rows per parent, multiplying one parent into 2,400 joined rows; choose a single or split query.
queriesorm
42
One EF Core lookup runs 80,000 times per second, returns one row by key, and already uses the correct index; would a compiled query help?
indexesqueriesorm
43
A multi-tenant API uses DbContext pooling, and 0.1% of requests query the previous tenant after a context is reused; redesign tenant state handling.
queriesormapi
44
An EF Core inventory update may race, transient SQL retries are enabled, and 50,000 rows need the same status change; design concurrency, transaction, and bulk-update behavior.
sqltransactionsorm
45
A protobuf contract has 30 consumers running mixed versions for 9 months; add a delivery window and retire an old enum value safely.
46
A server-streaming gRPC method may send 1 million records, has a 30-second client deadline, and some clients read 100 times slower than others; design the call.
designstreaminggrpc
47
An internal pricing API needs 200,000 calls per second with 4 KB payloads, while browsers and partners need the same data; choose gRPC, JSON HTTP, or both.
httpgrpcpricing
48
A reflection-based serializer adds 120 ms to startup across 300 serverless .NET instances; would you build an incremental source generator?
serializationgenerators
49
Publishing with trimming reduces a service image by 35%, but plugins discovered by assembly scanning disappear; make the application trimming-safe.
50
A small ASP.NET Core API must cold-start below 100 ms and use under 120 MB, but it relies on dynamic proxies and reflection-heavy JSON; would you adopt Native AOT?
decision-makingapiaspnet
51
A .NET API heap grows from 1.2 GB to 7.8 GB over 6 hours, Gen 2 collections rise from 2 to 40 per hour, and pods restart at 9 GB; how do you find the retained objects?
data-structures
52
An image API allocates 120 KB to 4 MB buffers, LOH fragmentation reaches 48%, and p99 GC pause rises from 35 ms to 620 ms under 3,000 RPS; what do you change?
api
53
After moving a service into 1-CPU containers, p99 stop-the-world time rises from 20 ms to 280 ms with server GC enabled and throughput unchanged; how do you decide whether to switch GC mode?
throughputcontainers
54
GC pauses exceed 900 ms every 4 minutes, the live set is 6 GB in a 10 GB process, and SustainedLowLatency is already enabled; what is your response?
concurrency
55
A service holds only 2 GB of managed heap but its 6 GB container is OOM-killed after 90 minutes; 25,000 objects wait for finalization. How do you investigate?
containersdata-structures
56
A high-throughput socket service shows 3 GB of free space inside managed segments but cannot allocate contiguous 2 MB buffers; GC traces show 180,000 pinned objects.
throughput
57
Working set grows by 400 MB per hour while GC heap remains flat at 900 MB; the release added a native compression library and memory-mapped files. What evidence do you collect?
memorydata-structures
58
IMemoryCache grows from 300 MB to 5 GB in 2 hours because 2 million tenant keys have a 24-hour TTL; traffic cannot tolerate a full cache flush.
caching
59
A WPF client freezes when a button handler calls LoadAsync().Result; LoadAsync awaits HttpClient and the continuation needs the UI SynchronizationContext. Walk through the deadlock and fix it.
asynclocking
60
A legacy ASP.NET application hangs at 400 concurrent requests after a helper changed from await to .Wait(); CPU is 18% and request threads keep growing.
asyncconcurrencyaspnet
61
An ASP.NET Core API receives 6,000 RPS, ThreadPool queue length rises from 0 to 90,000, CPU stays at 45%, and p99 reaches 12 seconds; how do you prove starvation?
concurrencydata-structuresapi
62
A developer wrapped CPU-heavy PDF rendering in Task.Run inside every request; at 500 concurrent requests CPU reaches 100% and latency exceeds 30 seconds. What do you change?
concurrencyasynclatency
63
A timer callback uses async void, throws twice per day, and sometimes terminates the process without a correlated job ID; redesign it.
asyncconcurrencycallbacks
64
Clients cancel 35% of report requests after 2 seconds, but SQL queries continue for 40 seconds and consume 120 database sessions; how do you trace and fix cancellation loss?
sqldatabasequeries
65
SemaphoreSlim limits an external API to 50 calls, but after several timeouts CurrentCount reaches 0 permanently and 4,000 requests wait; find the bug and recover.
resilienceapi
66
An unbounded Channel grows to 12 million messages and 18 GB after consumers slow from 80,000 to 25,000 items per second; the producer cannot lose accepted work.
67
An EF Core read endpoint p99 rises from 180 ms to 1.9 seconds after a change starts tracking 35,000 entities per request; database time remains 90 ms.
databaseormendpoints
68
A production endpoint serving 200 orders executes 201 SQL commands, drives SQL CPU from 30% to 88%, and p99 reaches 4.2 seconds; how do you prove and remove N+1?
sqln+1endpoints
69
Adding two collection Includes changes an EF Core query from 12,000 to 2.8 million result rows and p99 from 300 ms to 9 seconds; choose the production fix.
queriesorm
70
A team deploys EF.CompileAsyncQuery to fix a lookup whose p99 is 1.3 seconds; profiling shows EF compilation takes 0.4 ms and SQL takes 1.2 seconds. What do you decide?
sqldeploymentprofiling
71
At 2,500 RPS, SqlClient pool waits reach 8 seconds, all 200 connections are busy, and request timeouts exceed 35%; how do you distinguish slow SQL from leaked connections?
sqlresilience
72
A singleton repository accidentally holds one DbContext; tracked entities grow to 700,000, memory rises by 4 GB, and stale reads appear across requests.
ormmemory
73
An EF Core transaction stays open during a 3-second payment API call; under load, lock waits reach 18 seconds and 600 requests queue behind 40 rows.
transactionsormapi
74
SQL Server reports 900 deadlocks per hour after two EF Core workflows began updating Account and Ledger in opposite order; how do you correct and retry safely?
sqllockingorm
75
One parameterized EF Core query takes 40 ms for most tenants and 11 seconds for the largest tenant after a plan-cache change; how do you investigate parameter sensitivity?
queriesormcaching
76
A batch uses ExecuteUpdate to change 80,000 rows, but a long-lived DbContext still returns old statuses and later overwrites some updates; how do you repair the flow?
ormbatch
77
An ASP.NET Core release raises p99 from 220 ms to 1.8 seconds only above 4,000 RPS, while CPU, SQL duration, and error rate look normal; how do you use dotnet-trace?
sqlaspnet
78
CPU rises from 35% to 92% after enabling a feature flag, but request count is unchanged; design a low-risk .NET profiling comparison.
designprofilingfeature-flags
79
Lock contention time reaches 42% and p99 is 3 seconds on a cache used by 96 cores; the hottest lock protects one Dictionary for 70 microseconds per request.
caching
80
A new validation path throws 250,000 exceptions per minute for expected input misses, increasing CPU by 28% and allocations by 14 GB per minute.
validationerror-handling
81
JSON response serialization accounts for 46% of CPU and 9 GB per minute of allocations at 20,000 RPS; what do you profile and change first?
serialization
82
Outbound calls begin failing at 7,000 RPS; hosts show 120,000 TIME_WAIT sockets, and code creates a new HttpClient per request. How do you recover without pinning stale DNS forever?
dns
83
A gRPC server-streaming endpoint retains 6 GB when 300 clients read at 50 KB/s but producers generate 2 MB/s per client; where is the backpressure failure?
endpointsgrpcbackpressure
84
Kestrel active requests remain at 10,000, application queue time reaches 6 seconds, and dependency latency is only 80 ms; how do you locate the delay?
latencydependenciesdata-structures
85
Polly, HttpClient, and a service mesh each allow an original payment call plus 2 retries; during an outage, 1,000 logical payments can produce up to 27,000 attempts. What do you change?
service-mesh
86
A BackgroundService accepts 40,000 jobs in memory, deployment sends SIGTERM with a 30-second grace period, and 6,000 accepted jobs disappear on every release.
memorydeployment
87
A Native AOT canary starts in 70 ms instead of 480 ms but returns 500 for 3% of routes using reflection-created validators; do you continue rollout?
validationdeployment-strategies
88
An incremental source generator raises clean build time from 90 seconds to 11 minutes across 200 projects; incremental builds also rerun most stages after one file changes.
generators
89
A singleton BackgroundService captures a scoped SDK client and DbContext; after 8 hours, connections grow from 40 to 900 and tenant data becomes stale.
orm
90
A runtime configuration reload changes retry count from 1 to 8 before the new 200 ms timeout arrives, causing a 5-minute traffic spike; how do you make reload atomic?
resilienceconfigconcurrency
91
A mid-level .NET engineer submits a handler with Task.Run around EF Core, two .Result calls, and no CancellationToken two days before a 5,000-RPS launch; how do you review it?
ormresilienceasync
92
A junior engineer fixed a memory issue by calling GC.Collect after every 500 requests; p99 improved briefly but throughput fell 38%. How do you mentor them?
throughputmemorymentoring
93
An engineer responds to pool exhaustion by raising Max Pool Size from 100 to 1,000; SQL CPU is already 92% and 600 commands are blocked. What feedback do you give?
zero-to-onesqlfeedback
94
A capable engineer repeatedly uses broad Include chains in EF Core; their latest endpoint returns 3 million rows for 500 parents and misses p99 by 7 seconds. How do you coach them?
ormendpoints
95
During review, a senior engineer argues that ConfigureAwait(false) must appear after every await in an ASP.NET Core service or performance will degrade by 20%; how do you resolve it?
asyncperformanceconfig
96
A mentee's BackgroundService lost 14,000 in-memory jobs during deployment because they used fire-and-forget Tasks; how do you run the follow-up?
memorydeployment
97
Two .NET engineers disagree on using a lock or ConcurrentDictionary for a cache updated 5 times per minute and read 200,000 times per second; the argument has blocked review for 4 days.
conflictcachingconcurrency
98
A mid-level engineer's source generator works but adds 6 minutes to every build because it calls GetSymbolsWithName across the compilation for each syntax node; how do you guide the rewrite?
generators
99
An engineer investigating 800 ms GC pauses wants to change 12 runtime knobs at once before capturing a trace; release is in 3 days. How do you redirect the work?
100
A staff engineer approves a singleton DbContext workaround that cuts allocations by 2% but causes 0.4% cross-request stale reads; you are not their manager. What do you do?
orm

Questions

1An ASP.NET Core order system has 8 modules, 3 teams, and one shared SQL Server database; which boundary would you extract first if fulfillment needs independent releases and 5 times the write capacity?

2Checkout calls pricing, inventory, and fraud services and must answer within 600 ms; which calls should use gRPC and which work should become asynchronous?

3Design an ASP.NET Core catalog API for 100,000 requests per second, 95% reads, and p99 below 120 ms across 3 availability zones.

4An ASP.NET Core API needs forwarded headers, exception handling, HSTS, routing, CORS, authentication, authorization, rate limiting, and endpoint execution; put the middleware in a defensible order.

5A service will expose 180 minimal API endpoints to 12 clients; how would you organize contracts, validation, authorization, and OpenAPI without rebuilding an MVC controller layer?

6An ASP.NET Core upload endpoint accepts files up to 2 GB and must keep process memory below 1 GB with 200 concurrent uploads; design the request path.

7A public ASP.NET Core API has 4,000 partner integrations and a 12-month compatibility promise; how do you add a required delivery preference?

8Kubernetes restarts all 80 ASP.NET Core pods when SQL Server is unavailable for 40 seconds; how should liveness, readiness, and startup checks be defined?

9Six ASP.NET Core services share payment configuration, but only credential rotation may reload at runtime; how would you implement and validate it?

10A parser handles 100,000 UTF-8 headers per second and currently allocates 600 bytes for every 2 KB input; where would Span<T> help and where would it not?

11A pipeline reads 64 KB frames, awaits decompression, and passes slices through 3 asynchronous stages; choose between Span<byte>, Memory<byte>, and copying.

12A hot method needs a temporary buffer whose size comes from input and ranges from 32 bytes to 256 KB; define a safe stackalloc policy.

13JSON serialization creates 20 GB per minute of temporary byte arrays, mostly between 128 KB and 1 MB; would you introduce ArrayPool<byte>?

14A metrics formatter boxes 15 million integer values per second through an object-based API; how would you remove the cost without making every value type a struct?

15Two UTF-8 parsers differ by 25 ns in a quick Stopwatch test; design a BenchmarkDotNet experiment that can justify changing the production parser.

16An API allocates 90 KB response buffers at 8,000 requests per second and must keep GC pauses below 50 ms; explain the generation and LOH implications.

17A trading calculation runs for 400 ms every second and requires no GC pause above 2 ms during that window; would you use SustainedLowLatency or NoGCRegion?

18A containerized ASP.NET Core service has 2 CPU cores and a 768 MB limit; how would you choose and validate server GC versus workstation GC?

19A .NET service runs in a 512 MB pod and is OOM-killed although GC heap size never exceeds 330 MB; set a defensible memory budget.

20A cache lookup completes synchronously 97% of the time and runs 4 million times per second; should its API return Task<T> or ValueTask<T>?

Locked questions