I’ve recently talked to folks from the #100devs boot camp, which got me thinking about the software development interviewing process. Not that I’m looking for a new job, but what questions would I expect to get during a technical interview for an ASP.NET Core position. As a former hiring manager, I can tell you it’s challenging to gauge anyone’s skill set from a set of questions and interviews. So if you’re a candidate, your most significant investment is to help inform your interviewers of your skills long before entering the interview room. You can do that by learning in public, sharing ideas, and demo projects. While I am aware this is impossible for everyone, being able to do so can help you stand out.

For those going into an interview and want practice questions, I’ve crafted a few questions for a hypothetical ASP.NET Core position and what I might answer in this post. None of these questions are meant to be “gotcha” questions but instead focus on foundational concepts in ASP.NET Core that I would expect developers to know, mixed with some opinions I would expect developers to have possibly.

OK, potential future employee, please have a seat, and let’s get started.

Question #1
“Why do you think ASP.NET Core is ideal for building web applications? If not, in your opinion, what’s missing?”

The hosting model of ASP.NET Core gives me several options and approaches for solving problems. I have several techniques to choose from, like ASP.NET Core MVC, Razor Pages, and Minimal APIs to solve any particular issue I may come upon. Hosting them in a singular solution also makes it easy to change my mind without throwing away the majority of my current progress.

Can you name two or more approaches to handling a user request using ASP.NET Core? Which do you prefer and why?

The most common approach to handling a user’s request will typically be utilizing an ASP.NET Core MVC action. For example, a user’s request might be parameters on a query string or part of a form body. In the case of MVC, model binding is generally transparent, and I can work with an instance of a strongly-typed request object. In addition, with ASP.NET Core MVC, I can reply with HTML, JSON, or other response types.

If I were starting a solution today, I might look into using Minimal APIs, as it allows me to respond to a user’s request without the overhead of the ASP.NET Core MVC request pipeline. The drawback might be that only JSON requests opt into model binding. Handling other content types will require custom code on my part. While I could respond with any content type, Minimal APIs favor returning JSON.

Question #2
“ASP.NET Core has dependency injection to manage services; are you aware of the different lifetimes? What are they, and what does each mean?”

ASP.NET Core has three lifetimes of Singelton, Scoped, and Transient.

ASP.NET Core services container will create services registered as a singleton only once for the duration of the application’s lifetime. Singletons are helpful for expensive services or services with little to no internal state.

As the name suggests, with regard to scoped services, they are created within a scope. The scope is typically the lifetime of an HTTP request, but not necessarily always. I, as a developer, might create custom scopes in code, but anyone should be careful to use this technique sparingly.

Finally, ASP.NET Core creates transient services when a dependent instance asks for them. I might consider registering dependencies as transient as the “safest” approach to creating dependencies as there’s no chance for contention, race conditions, or deadlocks. Still, it can also come at the expense of performance and resource utilization.

Each lifetime has its use, and it depends on the dependency we are registering.

Question #3
“You can map routes to endpoints explicitly or through convention; which do you prefer and why?”

I prefer explicitly registering routes, as they are visible in the codebase and often easier to rationalize and debug. There is a potential drawback, though, as the more routes an application has, the more it can impact route resolution and performance of an application. Performance degradation can happen in applications when an extreme amount of route registrations occur, but many folks shouldn’t worry about it until they notice a drop in performance.

ASP.NET Core MVC is a design pattern; what classes and files might you create if you built an application vertical to manage vehicles?

Given that we’re talking about Vehicles as a resource, I would start by creating a Vehicle model, representing my data source. I’d likely then move on to creating a VehiclesController with actions for listing vehicles, getting a single vehicle, creating and updating a vehicle, and finally removing a vehicle. If this is an HTML app, I will generate view models with my Razor views. If this is an HTTP API, then response models to be serialized into JSON responses. There may be more classes to handle any additional necessary data to make the development experience easier for my team members and me.

Question #4
“What other libraries or frameworks might you use with ASP.NET Core to build your application, and for what purposes?”

Since most applications need to store data, I’d likely reach for Entity Framework Core or Dapper for data access. In addition, I’m also a big fan of FluentValidation to make validating user input easier to understand. Finally, I might use a front-end library like HTMX to leverage Razor’s HTML-generating capability to provide a compelling client-side user experience.

You have configuration values needed to access your application resources. Which configuration providers do you prefer for development, and which do you prefer for production?

Many cloud providers and docker hosting platforms support environment variables, so environment variables make much sense for production environments. However, I prefer the user secrets configuration provider for local development as there’s no way to add sensitive secrets to source control mistakenly. Finally, I like JSON configuration since it’s one of the default configuration options, and it’s easy to add and manage into source control.

Question #5
“You have a page with a form, but when you submit, nothing occurs. How would you go about debugging the issue?”

I always find it’s best to start at the beginning. In my case, I clicked a submit button on a form. But, first, I would open the dev tools in my browser and make sure the client page made a network call to the backend ASP.NET Core app.

If the page didn’t make a request, I would ensure that my form has an action attribute pointing at a known endpoint in my application and that the method matches what the app expects on the endpoint.

If the client made a request, before leaving the dev tools of the client, I would read any responses sent from the server to pinpoint the exact point of failure. A “not found” response would lead me to believe the endpoint isn’t registered in my app correctly. If the endpoint does exist, I will look at any route constraints, filters, or exceptions that may stop the request from getting to my endpoint. The typical response, in this case, is a “bad request” response. An excellent place to look is the output window of my IDE to see if any error messages are visible.

Methodically starting from the origin of the problem and working backward is an excellent way to fix issues and quickly move on to more work.


The questions and answers in this post are some I might expect in hiring an ASP.NET Core developer. Some are technical pieces of knowledge a developer might run into during a day of development. Others explore opinions that might form from using libraries and tools in the ecosystem. While there are certainly no “gotcha” questions, in my opinion, yours might be different. So, what questions have you been asked during an interview, or what are some questions you might ask another developer to gauge their understanding and expertise?

Follow me on Twitter, share this post with your question, and I’ll see if I can respond to them. As always, thanks for reading and sharing my posts with friends and colleagues.