The core of this role is an application server written in C# and run on .NET. It accepts a request, works out what is being asked, and sends back a response. Everything else is about the way that response is built, or about keeping the server running.
ASP.NET Core is the framework that gives the server its shape, and it is the one most job posts name. ASP.NET MVC is its older form, and it is still asked for in a good share of job posts, usually beside ASP.NET Core, because the employer has applications built before .NET was rewritten and wants an engineer who can work in both. That pairing of new and old runs through the whole role. The product companies building electronic health records, insurance agency systems and property-management software have code bases that are ten or twenty years old, and the engineer is expected to add new services beside them rather than replace them. Entity Framework is the layer that talks to the database, and it is named in a fair share of job posts, most at the GCCs and the industry software companies.
A few job posts name a second language beside C#. Python is the most common, and Java with Spring Boot appears in a minority. Both are concentrated at Accenture, whose job posts often list several stacks in one post because the engineer may be placed on any of them.
Most requests involve a database operation, reading some records or saving some, and in this role the database is more central than in any other backend role. SQL is named in more job posts than any framework, because a .NET application traditionally puts a great deal of its logic in the database itself, in stored procedures, views and carefully designed tables, and the engineer is expected to write and tune that SQL rather than leave it to Entity Framework. SQL Server is the database, named in a large share of job posts and in most at the GCCs and the industry software companies. The records these systems hold, a policy and its claims, a patient and their visits, a property and its leases, a car and its service history, point at one another and have to stay correct for years, which is exactly what a relational database on SQL Server is for.
The other databases are a long way behind. Oracle appears in a minority of backend job posts, mostly at finance companies and services firms with older systems. PostgreSQL and MySQL appear in a small share, more at the newer product companies. MongoDB, Redis and Elasticsearch are each named in only a handful of job posts, which says that caching, document stores and search engines are far less part of everyday .NET work than they are elsewhere.
Not every response comes from a database the server owns. Many requests are answered by calling another service, a payment processor, a credit bureau, a government registry or an older internal system, and shaping what comes back.
The user never talks to the database directly. The web page or desktop application they use sends a request to the server, the server does the work, and the app shows what comes back. The REST API is the set of URLs the app calls to make those requests, so it is the entry point to everything the server does. In .NET that API layer is built with ASP.NET Core. REST itself is assumed in every job post rather than listed as a skill. What job posts call out separately is API design as a discipline: clear names, errors that make sense, versions that do not break existing callers, and limits on who may call what. The tools named with it are mostly Microsoft's. Azure API Management appears where the API is shared across teams or sold to partners, with Amazon API Gateway in a few job posts. gRPC and OpenAPI appear in a handful. GraphQL is named in a fair share of full-stack job posts, but almost all of them are at Accenture. API design is called out most at the finance companies and in the backend-only job posts, where the .NET service sits behind someone else's screen.
Most job posts want the same engineer to build the screens, and the choice of frontend follows the kind of company. Angular is the frontend of choice, ahead of React, which is the reverse of every other backend role. Angular dominates at the GCCs of the healthcare, insurance and logistics groups and at the investment and insurance software companies, where long-lived business applications were built when Angular was the enterprise choice. React leads at the energy, car-dealer and newer industry software companies. Vue is third and is asked for mostly at Accenture. TypeScript goes with either framework and is named in a fair share of job posts, most at the GCCs. Plain JavaScript, HTML and CSS are listed in a good share, and jQuery still appears, most at the GCCs, because older ASP.NET MVC screens were built with it. Bootstrap and Angular Material appear as ready-made component sets.
Some requests take too long to finish on the spot, so the server triggers a background task instead. Generating a batch of invoices or policy documents, running a nightly billing or payroll cycle, importing a claims file, syncing with a partner's system, or calling a slow outside service are all jobs of this kind. The server accepts the request, records the job, replies straight away with a job id, and puts the job on a queue. Background workers pick jobs off the queue, finish them, and try again if something fails. Messaging is asked for in a smaller share of job posts here, because many .NET systems still do this work with scheduled jobs and the database rather than a message broker.
Where a broker is named, it is usually Microsoft's. Azure Service Bus is the queue named most on the backend side, with Event Hubs for streams of events, and together they are the clearest sign that the application lives on Azure. Kafka is named about as often as Azure Service Bus, mostly at the industry software companies and in client work, and RabbitMQ, SQS and SNS appear in a few job posts. Messaging is asked for most at the industry software companies, the GCCs and the finance companies, and least at Accenture.
The next part is communication of task status. When a job finishes, the server might update a status that the app keeps checking, push a notification, or call a webhook, which is an address another system has given it to call when something happens. Webhooks run in the other direction too: a payment processor or a partner system calls the server to report that something happened, and the server has to accept that call safely even when the same message arrives twice. Checking who is calling and whether they may is the authentication and security skill. In this role it is tied to Microsoft's identity tools: OAuth 2.0 and OpenID Connect are the standards named, and Entra ID and Active Directory are where a company's staff accounts live. It is asked for in a fair share of backend job posts and a small share of full-stack ones, and it is a must where financial or health records move.
Calling an LLM is appearing in .NET backends, asked for in a smaller share of job posts than in Python work but a larger one than in Java. A user asks a question in plain words, uploads a document to be summarised, or wants a reply drafted. The server gathers the right data, sends it with the question to the LLM, checks what comes back, stores it, and returns an answer the app can show. It works much like a background task, because LLM calls are slow, and it uses everything above: the API takes the request, permissions decide what data the LLM may see, the queue carries the call, and the database keeps the answer. The OpenAI API is the model named when one is named at all, with LangChain and LangGraph in a handful of job posts. LLM integration is asked for most at Accenture and the industry software companies, more on the full-stack side, and least at the GCCs.
A server that works on the engineer's laptop still has to run the same way in testing and in production, serve many users at once, handle peak traffic, and keep going when a machine fails. Cloud is asked for in most job posts, and in this role the cloud is Azure. It is named well ahead of AWS, and at the GCCs it is named in most job posts. AWS is second and appears most at the finance and industry software companies, and GCP is a distant third. At Accenture both clouds are named less, because its job posts describe the stack in general terms.
Containers are asked for less here. Docker and Kubernetes are named in a minority of job posts, most at the industry software and finance companies, and least at Accenture. Many .NET applications still run on Windows servers or on Azure's own app hosting rather than in containers, so a .NET engineer is less often expected to run a cluster. Terraform and Bicep, Microsoft's own tool for describing Azure resources as code, appear in a small share of job posts.
A service in the cloud also changes often. Customers ask for features, regulations change, bugs need fixing, and copying files to servers by hand would be slow and risky. A build-and-release pipeline takes over: every change is tested, built, and rolled out step by step, and can be rolled back if something goes wrong. Azure DevOps is the pipeline named most in .NET work, by a wide margin, and at the GCCs it is named in a very large share of job posts. GitHub Actions is second, with Jenkins, TeamCity and GitLab CI behind it, and TeamCity stands out at the finance companies. SonarQube is named where code quality is checked in the pipeline. Pipelines are asked for in most full-stack job posts and in a smaller share of backend ones, and they are close to universal at the GCCs and the industry software companies.
Once the server is running, the team needs to know when something breaks, ideally before the users notice. Splunk, Grafana, AppDynamics, Datadog and Prometheus are each named in only a handful of job posts, and no one tool stands out. Monitoring is a plus rather than a requirement in this role, and in practice it is often done through Azure's own tools, which job posts do not list as a separate skill.
Tests are what the pipeline runs, so the two travel together. NUnit and xUnit are the testing tools of .NET, named about equally, and they are the whole of the testing ask on the backend side. In full-stack job posts testing is called out more often, because the engineer is expected to test the screen as well as the server, and Jasmine and Karma appear for Angular, Jest for React, and Selenium and Playwright for driving the browser. Testing is asked for most at the GCCs and the industry software companies, and least at Accenture.
Underneath all of it sits the ordinary craft of building software in a team: Git for source control, pull requests and reviews, issue tracking, and a rhythm of regular releases. Job posts count these as given and almost never list them as skills.
A .NET engineer who knows C# and ASP.NET Core well and can read older ASP.NET MVC code, who can write and tune real SQL on SQL Server and use Entity Framework on top of it, who builds Angular or React screens, and who can deploy to Azure through an Azure DevOps pipeline with NUnit or xUnit tests, meets the core of nearly every job post. The variations belong to the employer. The finance companies want Angular and Azure in front of a large .NET core, with AWS more common than elsewhere and TeamCity pipelines. The industry software companies want the full stack, SQL Server, Entity Framework, containers and Kafka or Azure Service Bus, and they ask for LLM work and testing more than most. The GCCs want Angular, Azure and Azure DevOps above all, with NUnit tests and jQuery on the older screens. Accenture wants full-stack .NET with Angular, React or Vue, described in general terms, with Python and GraphQL often listed beside it. Across all of them, the database comes first, and an engineer who is strong in SQL will find that strength asked for everywhere.