25 ASP.NET Core interview questions

Listen for: A strong answer starts with reproducing the request, checking structured logs, correlation IDs, environment-specific configuration, connection strings, feature flags, and external dependencies. They should mention reading the exception details safely, adding targeted logging or tests, comparing local and staging settings, and avoiding random code changes without evidence.

Red flag: They immediately guess a fix or say they would just attach a debugger to staging without considering logs or configuration.

Listen for: Look for an explanation based on scope and timing in the request pipeline. Middleware is for cross-cutting behavior across many requests, endpoint filters for minimal API endpoint concerns, action filters for MVC/controller actions, and handler code for business-specific behavior. They should mention ordering, short-circuiting, and testability.

Red flag: They treat all four as interchangeable places to put any shared code.

Listen for: They should describe validating input DTOs, returning clear 400 responses, using ProblemDetails, keeping validation separate from persistence models, and testing common invalid requests. Bonus signals include FluentValidation or built-in validation, consistent error shape, avoiding exception-driven validation, and not leaking internal field or database details.

Red flag: They rely on database exceptions to catch invalid input.

Listen for: A good answer mentions thread pool starvation, reduced throughput, deadlocks in some contexts, hidden exception wrapping, and poor cancellation behavior. They should prefer async all the way, using await with CancellationToken where available, and understand that I/O-bound database and HTTP calls should not occupy threads while waiting.

Red flag: They say async is only for UI apps and does not matter on the server.

Listen for: Listen for filtering, sorting, pagination, projection to DTOs, no unnecessary Include calls, async execution, cancellation token use, and reviewing generated SQL for expensive joins or client evaluation. They should mention indexes with the team or migration owner and tests that cover empty, normal, and boundary cases.

Red flag: They load all rows into memory and filter with LINQ afterward.

Listen for: They should distinguish appsettings files, environment variables, user secrets for local development, and managed secret stores such as Azure Key Vault or AWS Secrets Manager. Strong answers mention the options pattern, validation on startup, no secrets in source control, and predictable overrides per environment.

Red flag: They put secrets in appsettings.Production.json and commit them because the repository is private.

Listen for: Strong candidates look at traces, dependency timings, database queries, connection pool exhaustion, outbound HTTP calls, retries, locks, thread pool metrics, and recent code changes. They should use OpenTelemetry, logs with request IDs, and profiler or APM data before optimizing. They separate server latency from downstream or client issues.

Red flag: They focus only on CPU and suggest adding more instances without investigation.

Listen for: They should know DbContext is typically scoped, application services often scoped or singleton depending on state, HttpClient should come from IHttpClientFactory or typed clients, and singleton services cannot depend on scoped services directly. Good answers mention avoiding captured mutable state, options snapshots, and testing lifetimes during startup.

Red flag: They register everything as singleton for performance.

Listen for: Look for JWT or cookie choice based on clients, issuer and audience validation, tenant resolution, claims mapping, policy-based authorization, resource-level checks, and avoiding trusting tenant IDs from the body alone. They should discuss token lifetime, clock skew, key rotation, and integration tests for cross-tenant access denial.

Red flag: They only check that a user is logged in and assume tenant access is valid.

Listen for: A strong answer uses backward-compatible migrations, expand-and-contract changes, nullable columns or default values where appropriate, separate deploy steps for code and schema, and migration review in CI. They understand when automatic migration on startup is risky and how to handle long-running indexes or data backfills.

Red flag: They let every app instance run migrations on startup in production without coordination.

Listen for: They should use IHttpClientFactory or typed clients, set timeouts, propagate cancellation, handle non-success responses intentionally, use resilience policies such as Microsoft.Extensions.Http.Resilience or Polly, and log without leaking secrets. Strong answers mention idempotency, retries only for safe cases, circuit breakers, and contract tests or fakes.

Red flag: They create a new HttpClient per request and retry every failure indefinitely.

Listen for: Listen for thin transport layers, request/response DTOs, application services or command handlers, explicit validation, transaction boundaries, and clear ownership of mapping and business rules. They should avoid blindly adding patterns but know when vertical slices, MediatR, or modular organization improves maintainability and testability.

Red flag: They put all validation, authorization, database access, and external calls directly in the endpoint.

Listen for: Strong answers assume at-least-once delivery and design idempotent handlers using message IDs, deduplication tables, unique constraints, state checks, and transactional updates. They should mention visibility timeouts, poison messages, retries with backoff, observability, and not holding long database transactions while calling external services.

Red flag: They assume the queue guarantees exactly-once processing and add no safeguards.

Listen for: Look for incremental modernization: mapping modules, stabilizing tests, extracting seams, improving build and deployment, reducing shared database coupling, and using strangler patterns for high-value areas. Strong candidates consider team ownership, telemetry, migration risk, and business priorities before choosing microservices or modular monolith approaches.

Red flag: They propose rewriting the whole system as microservices before understanding the domain or failure modes.

Listen for: Strong answers define practical standards: API versioning, ProblemDetails, authentication patterns, logging fields, OpenTelemetry, health checks, error handling, package management, testing expectations, and secure defaults. They balance templates and shared libraries against team autonomy, and they describe governance through examples, reviews, and maintainable documentation.

Red flag: They mandate a large internal framework that every team must use for every decision.

Listen for: They should stabilize first by reducing load, scaling if useful, disabling features, or rolling back. Investigation should check sync-over-async, blocking locks, long CPU work on request threads, connection exhaustion, and queue depth. Follow-up includes telemetry gaps, load tests, code review guidance, and clear incident notes.

Red flag: They blame developers individually or focus only on restarting the service.

Listen for: Listen for protocol and consumer-driven reasoning. Minimal APIs fit small HTTP services and vertical slices, controllers fit richer MVC conventions, gRPC fits internal low-latency typed contracts, and messaging fits async workflows and resilience. They should discuss tooling, versioning, observability, client support, and team familiarity.

Red flag: They always choose the same style because it is their personal preference.

Listen for: Strong candidates cover authentication, authorization at resource boundaries, input validation, output encoding, CSRF where cookies are used, CORS, secrets, TLS, secure headers, dependency scanning, logging redaction, rate limiting, and audit trails. They should include threat modeling and abuse cases, not just package updates.

Red flag: They treat security as only adding JWT authentication.

Listen for: They should rebalance toward meaningful tests: fast unit tests for pure logic, integration tests with WebApplicationFactory, Testcontainers for databases or brokers, contract tests for integrations, and fewer tests tied to implementation details. Strong answers mention deterministic data, parallel safety, CI runtime, and confidence during refactoring.

Red flag: They delete most tests or require only end-to-end tests for every behavior.

Listen for: Look for measuring first with traces, benchmarks, load tests, and realistic data. They should target hot paths, database access, serialization, allocations, caching, and network calls. Good answers balance readable code with optimizations, document non-obvious choices, and verify improvements under production-like conditions.

Red flag: They suggest low-level micro-optimizations before identifying the bottleneck.

Listen for: Strong designs separate command and query concerns where useful, define transaction boundaries around order creation, publish events reliably with an outbox, and protect admin operations with policy-based authorization. They should cover EF Core modeling, optimistic concurrency, idempotency for fulfillment events, ProblemDetails responses, observability, and versioned public endpoints.

Red flag: They save the order and publish the event directly to a broker with no failure-handling strategy.

Listen for: Listen for tenant resolution from trusted claims or hostnames, authorization checks on every resource, database-per-tenant versus shared schema trade-offs, EF Core query filters used carefully, tenant-aware logging, migrations, backups, and operational tooling. Strong answers include tests proving cross-tenant access is denied.

Red flag: They rely only on a tenantId field supplied by the client request body.

Listen for: Good answers stream results, page database reads, project only needed columns, use async I/O, set appropriate response headers, and consider background generation with object storage for very large exports. They should discuss cancellation, authorization, audit logging, rate limiting, and avoiding loading the full file into memory.

Red flag: They build the entire CSV in a string before writing the response.

Listen for: Strong answers consider SignalR for browser and app connections, backplane or managed service for scale-out, fallback to push notifications for offline devices, authentication on hub connections, group membership by user or tenant, message persistence where needed, and observability for connection counts and delivery failures.

Red flag: They assume in-memory connection state on one server is enough for a scaled deployment.

Listen for: Look for containerized .NET 10 builds, non-root images, configuration from environment and secret stores, readiness and liveness health checks, structured logs, OpenTelemetry traces and metrics, graceful shutdown, horizontal scaling, database migration strategy, and safe rollout practices such as blue-green or canary where appropriate.

Red flag: They bake environment-specific settings and secrets into the container image.