Question 1
Difficulty: medium
Can you walk me through how you would design a RESTful API in .NET for a business application?
Sample answer
When I design a RESTful API in .NET, I start by understanding the business workflows and the data boundaries instead of jumping straight into controllers. I usually define the resource model first, then map out the endpoints around clear nouns and predictable HTTP methods. In a typical ASP.NET Core project, I would keep controllers thin and push business logic into services, while using DTOs so the API contract stays stable even if internal entities change. I also pay attention to validation, proper status codes, pagination, filtering, and error handling from the beginning. If the API is meant for public or multi-team use, I add versioning, authentication, and logging early so support is easier later. I like to write integration tests around key endpoints because that catches routing and serialization issues that unit tests can miss. My goal is always to build something clean, maintainable, and easy for other developers to consume without surprises.
Question 2
Difficulty: hard
How do you approach debugging a performance issue in a .NET application?
Sample answer
My first step is to reproduce the problem and confirm whether it is CPU, memory, database, or network related. I do not assume the issue is in the code first, because sometimes the bottleneck is a slow query, a missing index, or too much chatty API traffic. In .NET, I often start with logging, profiling tools, and application metrics to narrow down the hot path. If I suspect memory pressure, I look at allocations, large object heap usage, and whether objects are being held longer than expected. For CPU issues, I check for unnecessary loops, synchronous blocking, or expensive serialization. I also review whether async code is being used correctly, because misuse can create thread starvation or hidden contention. Once I identify the source, I verify the fix with before-and-after measurements, not just intuition. I have found that a disciplined, evidence-based approach saves time and prevents “fixes” that only move the problem elsewhere.
Question 3
Difficulty: medium
Tell me about a time you had to work with a legacy .NET codebase. How did you improve it?
Sample answer
I have worked on older .NET codebases where the main challenge was that the application still worked, but it was hard to change safely. In those situations, I avoid rewriting everything because that usually creates more risk than value. Instead, I identify the highest-impact pain points, such as duplicated logic, fragile database access, or areas with no tests. I usually start by adding tests around the existing behavior so we can make changes with confidence. Then I refactor in small steps, introducing cleaner service boundaries, dependency injection, and clearer naming where possible. If the code is tightly coupled, I use adapters or wrapper classes to isolate the old parts while gradually improving the structure. I also communicate progress carefully with the team, because stakeholders care about stability as much as technical cleanup. The biggest lesson I have learned is that legacy improvement is mostly about patience, sequencing, and protecting the business while modernizing the codebase.
Question 4
Difficulty: easy
How do you handle dependency injection and why is it important in ASP.NET Core?
Sample answer
Dependency injection is important because it makes code easier to test, easier to maintain, and less tightly coupled. In ASP.NET Core, I use the built-in container to register services with the right lifetime based on how they are used. For example, I keep request-specific services scoped, stateless helpers transient, and shared infrastructure carefully reviewed before making them singleton. I try to depend on interfaces at the service layer so implementations can change without affecting consumers. That helps a lot when I need to mock dependencies in unit tests or swap implementations later. I also use DI to keep controllers and handlers focused on orchestration rather than business rules. One thing I am careful about is avoiding service locator patterns or overusing the container as a way to hide poor design. If I see too many dependencies in a class, I treat that as a design smell and try to split responsibilities. Used well, DI improves the whole structure of an application rather than just making it “testable.”
Question 5
Difficulty: easy
How do you ensure code quality when working in a team of developers?
Sample answer
I think code quality is mostly a team habit, not just an individual skill. In a team environment, I rely on clear coding standards, code reviews, automated tests, and CI checks so quality is built into the process instead of being caught only at the end. During reviews, I focus not only on style but also on readability, edge cases, performance, and whether the code matches the actual requirement. I also try to keep changes small and purposeful because smaller pull requests are easier to review and less likely to hide bugs. For .NET work specifically, I like using analyzers, formatting tools, and test coverage reports as guardrails, but I do not treat them as a substitute for thinking. If a team has a shared understanding of naming, layering, exception handling, and logging, the codebase becomes much easier to maintain. I have found that when people review code respectfully and consistently, the quality improves naturally and the team learns from each other too.
Question 6
Difficulty: hard
Describe a situation where you had to troubleshoot a production bug in a .NET application.
Sample answer
In production, I usually approach bugs with a calm, structured process because the pressure can make people jump to conclusions. I start by gathering facts: what changed, when the issue started, who is affected, and whether there is any pattern in the logs or monitoring data. In one case, we had an intermittent failure in a .NET API where certain requests were returning incorrect data. Rather than guessing, I traced the request flow, compared it with the expected business rule, and found that a shared cache entry was being reused too broadly across users. The code worked in testing but failed under real traffic patterns. I fixed the cache keying strategy, added logs around the affected path, and wrote a regression test so the same issue would not return. I also documented the root cause and what signals should be watched in the future. For me, the important part is not just fixing the bug but making the system more observable and less likely to repeat the same failure.
Question 7
Difficulty: medium
What is your experience with asynchronous programming in .NET, and when would you use async/await?
Sample answer
I use async/await whenever the operation is I/O-bound and can benefit from not blocking threads, such as database calls, web requests, or file operations. In ASP.NET Core, this is especially important because blocking threads under load can hurt scalability and response times. I use async methods end-to-end where possible so I do not mix synchronous and asynchronous code unnecessarily. I also pay attention to cancellation tokens, because in real systems requests get abandoned and long-running operations should be able to stop cleanly. One thing I watch carefully is not to use async just because it is available; if the operation is CPU-bound, async does not make it faster by itself. In that case I would consider background processing, parallelism, or queue-based work depending on the scenario. I also avoid common mistakes like calling .Result or .Wait() in request threads, because that can cause deadlocks or thread starvation. My rule is simple: use async where it improves responsiveness and scalability, but keep the implementation disciplined and intentional.
Question 8
Difficulty: medium
How do you decide between Entity Framework Core and writing raw SQL in a .NET project?
Sample answer
I usually start with Entity Framework Core because it speeds up development and keeps the codebase consistent, especially for standard CRUD and business workflows. It is a good fit when the domain model is fairly straightforward and I want maintainability, change tracking, and LINQ-based querying. That said, I do not force EF Core into every case. If I am dealing with a highly optimized reporting query, a complex join-heavy query, or a performance-critical path where I need precise control, I am comfortable using raw SQL or a stored procedure. The main decision point for me is not ideology but fit for purpose. I also think about team skill level and long-term support, because raw SQL can be powerful but it can also become hard to maintain if it spreads without discipline. In practice, I often use a hybrid approach: EF Core for most of the application and targeted SQL where it clearly improves performance or clarity. I prefer whichever option makes the code easier to reason about while still meeting the performance target.
Question 9
Difficulty: easy
How would you handle a disagreement with a product manager about a technical approach or timeline?
Sample answer
When I disagree with a product manager, I try to keep the conversation grounded in outcomes rather than personal preference. I start by making sure I fully understand the business priority, because sometimes what sounds like a technical disagreement is really a misunderstanding about risk, scope, or urgency. Then I explain the tradeoffs clearly: what the proposed approach would cost, what risks it introduces, and what alternatives are available. I try to offer options instead of just saying no. For example, if a full redesign is too risky for the timeline, I might suggest a smaller phased approach that solves the immediate need and leaves room for improvement later. I also make sure to bring evidence to the discussion, such as estimated effort, dependency impact, test coverage needs, or production risk. I have found that PMs usually respond well when the conversation is collaborative and focused on the product goal. My job is not to win an argument; it is to help the team make the best decision with the information we have.
Question 10
Difficulty: hard
What would you do if you inherited a .NET project with poor test coverage and frequent regressions?
Sample answer
If I inherited a .NET project with low test coverage and frequent regressions, I would not try to fix everything at once. My first goal would be to stabilize the most critical parts of the system by identifying the areas that cause the most incidents or business risk. I would add tests around those paths first, especially integration tests and unit tests for business rules that are likely to change. At the same time, I would look for patterns in the regressions: are they caused by unclear requirements, weak validation, brittle dependencies, or missing automation? That helps me target the real issue instead of just increasing test counts. I would also improve the build pipeline so tests run consistently on every change and failures are visible early. If needed, I would refactor slowly to make the code more testable by reducing coupling and separating concerns. The key is to create a safety net first, then improve the design incrementally. That approach protects the team while steadily raising quality.
