HR & Behavioural .NET Full Stack Interview Questions

In my final-year project (Situation) our team needed async file uploads, but I only knew synchronous code. My task was to build the upload API within a week. I read the official async/await docs, built a small console demo, then refactored our controller to use async methods and IFormFile streaming. The result was uploads that no longer blocked requests, and I shared a short note with my team.

I enjoy building complete features, from database to screen, and .NET lets me do that with one strong, typed language on the back end. It is widely used by IT services firms, banks and product companies in India, so there are steady opportunities. I have built projects with ASP.NET Core and React, and I like that the platform is open source, cross-platform and keeps improving every year.

In my last project (Situation) an invoice module had one 900-line class with duplicated GST logic. My task was to add a new tax rule without breaking billing. I first wrote unit tests around current behaviour, then extracted tax rules into strategy classes and moved data access into a repository, merging in small pull requests. Result: the new rule took one day, and bugs in that module dropped noticeably the next quarter.

I avoid theory first. I take a real piece of our code, like a controller that talks to the database directly, and pair with them to move logic into a service behind an interface, then write a unit test with a mock. Seeing how much easier testing becomes explains SOLID better than slides. I then review their next pull request with specific comments and point them to one or two good examples in our codebase.

In my previous role (Situation) a daily reconciliation job took 40 minutes and sometimes missed its window. My task was to bring it under 10 minutes. I profiled it and found nested loops over two large lists and one database call per row. I replaced the inner loop with a Dictionary lookup and batched the database reads. Result: the job ran in about 4 minutes, and I documented the approach for the team.

Last year (Situation) our order API started timing out during a sale. My task was to restore service fast. I checked dashboards, saw thread count climbing with low CPU, and took a dump that showed threads blocked on a .Result call added in a recent release. Action: I hotfixed it to proper async and rolled out within an hour. Result: latency returned to normal, and I added an analyser rule to block sync-over-async.

In my last project (Situation) we needed a leave-management API for 3,000 employees. My task was the full design. I modelled resources like /employees/{id}/leaves, used DTOs separate from EF entities, JWT with role policies for managers, FluentValidation, ProblemDetails errors and paging on every list. I documented it in OpenAPI and agreed the contract with the Angular team first. Result: front and back ends were built in parallel and launched on time.

On a dashboard feature (Situation) the React team wanted one endpoint returning everything, while I worried about payload size. My task was to agree a design quickly. I set up a short call, we listed exact screen needs, and I proposed one aggregated endpoint with paging and optional fields. We wrote the OpenAPI spec together. Result: payload dropped by half, the UI got one call, and the spec became our template for later features.

Microsoft ships a major .NET version every November, so I plan for it. I read the official What's New pages and the .NET blog, watch .NET Conf sessions, and try new features in a small side project before suggesting them at work. For example, when ExecuteUpdate arrived, I tested it on a sample and then proposed replacing a slow loop in our cleanup job, which cut its runtime significantly.

On a reporting module (Situation) the manager wanted everything in EF Core for consistency, but one report was too slow. My task was to recommend a fix without derailing the plan. I measured the EF query against a Dapper version with a hand-tuned SQL query, showed the 8x difference and explained that we would use Dapper only for that read path. Result: the manager approved, the report loaded in under a second, and the rest stayed in EF Core.

Early in my job (Situation) I ran an UPDATE on a test copy that I believed was staging, but it was a shared QA database, and 2,000 test orders lost their status. My task was to fix it fast. I told my lead immediately, restored the rows from the nightly backup with the DBA, and verified counts. Result: QA lost only an hour. Since then I always wrap manual updates in a transaction and run a SELECT with the same WHERE first.

My strength is that I go deep when debugging; I like reading execution plans and logs until I find the real cause, which has helped my team fix slow queries. A weakness was that I spent too long polishing code before asking for feedback. I now open small draft pull requests early and ask for review, which has made me faster and helped me learn from seniors sooner.

During my internship (Situation) a client demo was moved two days earlier, and the reports page was not ready. My task was to deliver the SQL queries and API for it. I listed must-have reports with my mentor, wrote and tested the three critical queries first, and postponed exports. I stayed in touch with the UI developer every few hours. Result: the demo went well, and we added the remaining features the next week.

In five years I want to be a senior full stack engineer who can design a complete .NET system, from database and APIs to front end and cloud deployment, and guide newer developers. In the near term I want to master ASP.NET Core, EF Core and SQL Server performance, then grow into Azure and system design. I would like to grow inside one company where I can take on bigger modules over time.

I built an online bus-pass system (Situation) as my final project with two classmates. My task was the API and database. I designed SQL Server tables, built an ASP.NET Core Web API with EF Core and JWT login, and connected an Angular front end with reactive forms and route guards. I deployed it on Azure App Service. Result: it handled pass applications, approvals and PDF passes, and our college used it for a semester demo.

In one sprint (Situation) the product owner changed a checkout screen twice. My task was to deliver without losing quality. I asked for a quick meeting to understand the reason, split the work into a stable API part and a flexible UI part, and agreed with the team which change would move to the next sprint. Result: we shipped the core flow on time, and the team started confirming acceptance criteria before sprint planning.

As tech lead (Situation) I owned a vendor-payments module touching Angular, three APIs and SQL Server. My task was to deliver it in six weeks with four developers. I broke it into vertical slices, defined API contracts first, set up feature flags and reviewed every pull request within a day. When one developer struggled with EF Core, I paired with them. Result: we released on time with no critical bugs and two juniors grew into module owners.

I can contribute on both sides of a feature: I have built ASP.NET Core APIs with EF Core and SQL Server, and front ends in Angular and React, and deployed them myself. I write clean, tested code and I am comfortable reading logs and execution plans when things break. I learn quickly, ask questions early and take ownership, so you can give me a module and trust that it will be completed properly.

A struct is a good fit because the point is small, logically a single value and created in huge numbers. Structs avoid heap allocation and GC pressure when stored in arrays or locals. Make it a readonly struct so it is immutable and avoids defensive copies. Choose a class instead if the type is large, needs inheritance, or is frequently boxed through interfaces, since copying and boxing remove the benefit.

Each += creates a new string and copies everything built so far, so the cost grows quadratically. Replace it with a StringBuilder, ideally created with an estimated capacity, and call Append or AppendLine in the loop, then ToString once at the end. For very large output, write directly to a StreamWriter or the response stream instead of building the whole string in memory.