The core of this role is an application server written in Python. 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.
There are three popular Python application servers: Django, FastAPI and Flask. Django is in the most demand, followed by FastAPI and then Flask, and the gap between the three is small. Many job posts ask for all three, which means the employer runs services built at different times and wants someone who can move between them. When a job post asks for only one of them, the choice tells you the kind of work. Django is the most common one to be asked for on its own, and it dominates at the product companies that build large business applications. It comes with its own database layer, login, permissions and a ready admin screen, which is what a team wants when it is building something with many screens and many kinds of records and expects to keep it for years. FastAPI is the next most common one to be asked for on its own. It is built for services whose main caller is other software: it handles many requests at once, checks every incoming field, and writes its own API description. It is the one asked for most in the GCCs of banks and healthcare groups and in work built for clients, and it is the usual choice when the service sits in front of an LLM feature. Flask is the older, lighter option. Job posts asking for Flask usually ask for one of the other two as well, and where it is asked for alone the work is mostly small services and client systems that have run for a while.
Most requests involve a database operation, reading some records or saving some, and for this role the database is relational first. Business records point at one another, an employee at a team, an invoice at a customer, a payment at an invoice, and a relational database keeps those links correct while many people edit at once, and saves a set of changes together or not at all. PostgreSQL is the clear favourite, with MySQL some way behind. SQL itself is asked for alongside them, because the engineer designs the tables and writes the queries behind every list, filter and report rather than leaving everything to the framework. Oracle and SQL Server show up only where new services have to read from systems a bank or an older company has run for a long time, which in practice means the GCCs and the payments companies.
Around the main database sit a few helpers, each for a specific job. Redis is the most common of them. It holds answers that are asked for again and again so the database is not asked every time, and it often doubles as the queue described further down. MongoDB is asked for about as often, for records whose shape changes from one customer to the next, such as custom forms, settings or stored documents, and it is mostly a product-company ask. Elasticsearch is a smaller but steady request wherever users search through large amounts of text. Cloud-hosted databases, Amazon RDS, Aurora and DynamoDB, are named where the whole application lives on AWS, which is most often work built for clients.
Not every response comes from a database the server owns. Many requests are answered by calling another service, a partner's API, a payment provider or an internal system that holds the customer record, and shaping what comes back. The engineer publishes an API and consumes several.
The user never talks to the database directly. The web page or mobile app 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. 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 show where that discipline is taken seriously. GraphQL appears in a minority of job posts, usually at product companies. API gateways from AWS or Azure appear where the API is sold or shared across teams. OpenAPI descriptions appear in the GCCs, so that other teams can use a service without asking how it works. gRPC appears in a handful of high-throughput services. None of these is universal. API design matters most where other software, not a person, is the main customer, and that is truest in the GCCs and the data companies.
Many job posts want the same engineer to build some of the screens. These full-stack job posts lean a little more on Django, because a framework that ships templates, forms and an admin suits a team where one person owns both halves. React is the frontend of choice by a wide margin, usually with TypeScript. Angular is next, strongest in the GCCs and in client work, and Vue is a distant third. Next.js is beginning to appear where the React side has grown into a product of its own. Full-stack is the norm in the GCCs and in client work, where teams are small and the engineer is expected to ship a feature end to end. At product companies it is a plus rather than a requirement, though a fair share of plain backend job posts still mention React or Angular, which is the employer saying the engineer should be able to help on the screen when needed.
Some requests take too long to finish on the spot, so the server triggers a background task instead. Sending a batch of emails or notifications, building a large report, importing a file with thousands of rows, calling a slow outside service, or settling the day's figures overnight 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. In the Python world Celery on Redis or RabbitMQ is the classic way to do this. RabbitMQ and Kafka are the brokers named most, in roughly equal measure, and Amazon's SQS and SNS and Google's Pub/Sub appear where the cloud provider's own queue is used instead.
Kafka points to a second use of the same idea. When a new employee is added or an order is paid, the server announces the event once, and every other service that cares picks it up in its own time, instead of the server calling each one directly. This is how large organisations keep many services loosely connected. Messaging in either form is asked for in a good share of backend job posts and in fewer full-stack ones, and it is strongest in the GCCs and at product companies with a lot of background work.
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 provider calls the server to report that a payment went through, 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. OAuth 2.0 and JWT are the tools named most, and SSO where the users are a company's staff. Every backend needs some of this, but it is a must where money or personal data moves, which is why the payments, financial data and security products ask for it well above the average.
Calling an LLM is now a normal part of a Python backend. 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 so it can be shown again, checked and improved. LangChain, LangGraph and LlamaIndex are the libraries job posts name, and the OpenAI API and Anthropic's Claude the models. LLM integration is asked for across every kind of employer, a little more on the full-stack side, and most of all in the GCCs. It is no longer a specialist skill.
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 and containers are asked for in more job posts than anything except Python itself.
Docker is the container tool, and it is named in most job posts. It packs the server with exactly what it needs so it runs identically everywhere. Kubernetes comes next, and it runs many copies of that container, adds more when traffic rises, and replaces any that fail. AWS is the most-named cloud by a wide margin, with Azure and Google Cloud some way behind and many job posts naming more than one. Terraform, and to a lesser extent CloudFormation and Ansible, appear where the engineer is also expected to describe the servers, networks and databases as code rather than set them up by hand. That is more common in client work and the GCCs than at product companies with a separate platform team.
A service in the cloud also changes often. Customers ask for features, rules 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, packed into a container and rolled out step by step, and can be rolled back if something goes wrong. GitHub Actions is the pipeline named most, with Jenkins, Azure DevOps and GitLab CI behind it, and the choice usually follows where the code is hosted. Pipelines are asked for in most job posts, a little more on the full-stack side, and they are close to universal in the GCCs and in client work, where the engineer owns the route from code to production rather than handing it to another team.
Once the server is running, the team needs to know when something breaks, ideally before the users notice. Prometheus collects the numbers, Grafana draws them, OpenTelemetry traces a single request as it hops between services, and Splunk, Datadog and CloudWatch gather the logs. These tools are named in a small share of job posts overall, and that share is concentrated almost entirely in the GCCs of banks and healthcare groups, where the engineer runs in production what they build. At product companies and in client work monitoring is usually someone else's dashboard and appears as a plus.
Tests are what the pipeline runs, so the two travel together. In backend job posts testing is assumed and rarely called out on its own; pytest is the tool when it is named. In full-stack job posts it is called out far more often, because the engineer is expected to test the screen as well as the server, and Cypress, Playwright and Jest appear beside pytest. It is most expected in the GCCs and in client work, where there is no separate test team.
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 small, frequent releases. Job posts count these as given and almost never list them as skills.
A Python engineer who knows one of the three frameworks well and can work in the others, who can design tables and write real SQL on PostgreSQL, who can ship in a Docker container on AWS through a pipeline with tests, and who understands why a slow job goes to a queue, meets the core of nearly every job post. The variations belong to the employer. Product companies go deeper on Django and the stores around the database, and some keep Go beside Python for the parts that need the most speed. Payments and financial data companies care most about correctness, SQL and who is allowed to do what. The GCCs want FastAPI services that talk to each other through messages, a React and TypeScript screen on top, and the monitoring to run it all. Client work wants speed across new projects, cloud databases and a pipeline with tests from day one. Across all of them, a Python service that calls a language model has become an ordinary part of the job.