USA
Canada
UK
Europe
Australia
Singapore
Japan
IndiaQ1. What is the middleware pipeline and why does order matter?
Short answer: An ordered chain processing requests; each middleware can act or short-circuit.
Strong answer: ASP.NET Core handles requests through an ordered middleware pipeline configured at startup; each component can inspect/modify the request, short-circuit, or call next(). Order is critical — e.g., exception handling first, then routing, authentication before authorization, CORS before endpoints. Wrong order causes subtle bugs.
Likely follow-up: Why must UseAuthentication precede UseAuthorization?
What the interviewer is checking: Core framework understanding.
Common mistake: Registering middleware in the wrong order.
Q2. How does dependency injection and service lifetime work?
Short answer: Built-in container with Singleton, Scoped and Transient lifetimes injected via constructors.
Strong answer: ASP.NET Core’s built-in DI registers services with a lifetime: Singleton (one for the app), Scoped (one per request), Transient (one per resolution). Constructor injection is standard. Choosing correctly matters — e.g., DbContext is Scoped; injecting a Scoped service into a Singleton (captive dependency) is a bug.
Likely follow-up: What is a captive dependency?
What the interviewer is checking: DI/lifetime knowledge.
Common mistake: Injecting Scoped services into Singletons.
Q3. What are minimal APIs and when would you use them?
Short answer: A lightweight way to define endpoints without controllers, good for small services.
Strong answer: Minimal APIs let you map routes to handler delegates directly with less ceremony than MVC controllers — ideal for small services, microservices and simple endpoints. Controllers still suit large apps needing conventions, filters and model binding at scale. Choose by app size and complexity.
Likely follow-up: When would you still prefer controllers?
What the interviewer is checking: Modern .NET awareness.
Common mistake: Being unaware of minimal APIs in current .NET.
Q4. How do you implement authentication and authorization?
Short answer: Authentication schemes (JWT/cookies/OIDC) plus policy/role-based authorization.
Strong answer: Configure authentication (JWT bearer for APIs, cookies for web, OIDC for SSO) and authorization with roles or policies (requirements/handlers) applied via [Authorize] or endpoint metadata. Use claims for fine-grained rules. For APIs, validate tokens properly and keep them stateless.
Likely follow-up: Policy-based vs role-based authorization — when each?
What the interviewer is checking: Security implementation.
Common mistake: Rolling custom auth instead of using the built-in schemes.
Q5. How do you handle configuration across environments?
Short answer: Layered configuration providers with environment overrides and secrets from a vault.
Strong answer: ASP.NET Core layers configuration from appsettings.json, environment-specific files, environment variables and secrets, with later providers overriding earlier. Use the Options pattern (IOptions) for typed config, User Secrets in dev, and a secrets manager/Key Vault in production — never commit secrets.
Likely follow-up: What is the Options pattern and why use it?
What the interviewer is checking: Configuration best practice.
Common mistake: Hardcoding environment-specific values.
Q6. How do you handle errors and validation in an API?
Short answer: Model validation plus centralized exception handling returning consistent responses.
Strong answer: Validate input with data annotations/FluentValidation and [ApiController]’s automatic 400 responses, and centralize exceptions with exception-handling middleware (or IExceptionHandler) returning ProblemDetails with correct status codes. Keep controllers clean and responses consistent.
Likely follow-up: What is the ProblemDetails format?
What the interviewer is checking: API robustness.
Common mistake: Try/catch in every action with inconsistent error shapes.
Q7. How do you make an ASP.NET Core API performant and scalable?
Short answer: Async everywhere, caching, pooling, minimal allocations, and horizontal scaling.
Strong answer: Use async I/O end to end, response/output caching and distributed cache, DbContext pooling, efficient serialization, and avoid unnecessary allocations. Keep it stateless to scale horizontally behind a load balancer, add health checks, and profile hot paths. ASP.NET Core is already fast — don’t undo it with blocking calls.
Likely follow-up: Why do blocking calls hurt throughput here?
What the interviewer is checking: Performance awareness.
Common mistake: Mixing blocking (.Result) calls into async request handling.