The core of this role is an application server written in Java. 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.
Java has one framework that matters: Spring Boot appears in nearly every job post, backend or full-stack. What varies is how much of the wider Spring family is asked for with it, and each member points to a kind of work. Spring MVC is the part that handles web requests. Spring Data JPA and Hibernate are the part that talks to the database, and the two are asked for about equally. Spring Security handles login and permissions. Spring Cloud is the set of pieces for running many small services together, and it is asked for in a large share of backend job posts, which shows how much of this role is microservices rather than one big application. Spring Batch is for jobs that process large files or large sets of records on a schedule, and it shows up more in client work and at the banks. JEE, the older enterprise Java standard, still appears in a fair share of job posts, mostly where a bank or an older company has systems that predate Spring Boot. Maven is the usual build tool, with Gradle some way behind.
A few job posts name a second language beside Java. Python is the most common, usually where the team also writes scripts, data jobs or LLM features. Kotlin is asked for mainly at the travel booking companies. Go and C# appear only in a small minority.
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 order at a customer, a payment at an account, a claim at a policy, 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. SQL is asked for in a large share of job posts, because the engineer designs the tables and writes the queries behind every list, filter and report rather than leaving everything to Hibernate. PostgreSQL is the most-named database, followed by MySQL, and then Oracle. Oracle dominates at the banks, the core-banking and credit companies, and in the systems a large company has run for years, and SQL Server and IBM Db2 appear in the same places.
Around the main database sit a few helpers. MongoDB is the most common, for records whose shape changes from one customer or product to the next. Redis holds answers that are asked for again and again so the database is not asked every time. Elasticsearch powers search across catalogues and large amounts of text. Cassandra holds very large volumes of simple records spread across many machines, and together with Elasticsearch it marks the retailers, marketplaces and travel sites, where a product catalogue or a booking search has to answer millions of users. DynamoDB and Amazon RDS appear where the application lives on AWS.
Not every response comes from a database the server owns. Many requests are answered by calling another service, a partner's API, a card network 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. In Java that API layer is built with Spring MVC or Spring Boot's web layer. 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, more on the full-stack side and at the retailers and marketplaces. API gateways from AWS or Azure appear where the API is shared across many teams or sold to partners. OpenAPI descriptions appear where other teams need to use a service without asking how it works. gRPC appears in a handful of high-throughput services. API design matters most where other software, not a person, is the main caller, and in Java that is the microservices world of the banks, retailers and payment networks.
Many job posts want the same engineer to build some of the screens. React is the frontend of choice, followed by Angular, and the gap between the two is smaller here than in any other backend role. Angular is strongest at the credit bureaus, the lenders and the medical-device companies, and in client work, and React is strongest in the GCCs of the banks and insurers. TypeScript goes with either. Vue is a distant third. Plain JavaScript, HTML and CSS are listed in a good share of full-stack job posts, and older job posts still name jQuery and JSP. Full-stack Java is the norm at the payment networks, the insurers' GCCs and at Accenture, and a plus elsewhere, though a fair share of plain backend job posts still mention React or Angular.
Some requests take too long to finish on the spot, so the server triggers a background task instead. Sending a batch of statements or notifications, settling the day's transactions, importing a file with thousands of rows, running a nightly risk calculation, 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. Spring Batch is the tool for the scheduled, file-and-records kind of job, and a message broker carries the rest.
Kafka is the broker named most, by a wide margin, and it is the single clearest marker of the kind of Java work a job post describes. It is asked for most at the retailers, marketplaces, travel sites and supply-chain companies, and often at the banks. RabbitMQ is a distant second, and JMS, IBM MQ and ActiveMQ appear in the banks' older systems. SQS, SNS and Pub/Sub appear where the cloud provider's own queue is used instead.
Kafka points to a second use of the same idea. When an order is placed or a payment clears, 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 a retailer keeps its store, stock, delivery and billing services loosely connected, and how a bank keeps dozens of systems in step. Messaging in either form is asked for in a large share of backend job posts and in fewer full-stack ones.
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 card network 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, and in Java it is done with Spring Security. OAuth 2.0 and JWT are the standards named most, SSO and Entra ID 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, and it is called out most at the security and supply-chain product companies, the banks and the payment networks, and in client work.
Calling an LLM is starting to appear in Java backends, though it is asked for far less than in Python work. 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. LLM integration is asked for in a small share of backend job posts and a larger share of full-stack ones, and it is most common in the GCCs of the retailers, banks and insurers, and least common in client work. In Java it is still an add-on rather than an expected 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 Java and Spring Boot.
Kubernetes is named a little more often than Docker in this role, which says that a Java engineer is expected to run services on a cluster, not only to pack them into a container. Docker packs the server with exactly what it needs so it runs identically everywhere, and Kubernetes runs many copies, adds more when traffic rises, and replaces any that fail. OpenShift, Helm and EKS appear in the same job posts. AWS is the most-named cloud overall, with Azure behind it and GCP third, but the order flips by employer. Azure leads at the retailers' GCCs, which are among the most Azure-heavy employers in the market, and at the insurers and supply-chain companies, while AWS leads at the banks and the product companies. Terraform, CloudFormation and Bicep appear where the engineer is also expected to describe the servers, networks and databases as code, and that is more common in client work than at a product company 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. Jenkins is the pipeline named most in Java work, ahead of GitHub Actions, Azure DevOps and GitLab CI, and SonarQube is named beside them where code quality is checked in the pipeline. Pipelines are asked for in many backend job posts and in most full-stack ones, and they are close to universal at the retailers' GCCs and in client work, where the engineer owns the route from code to production.
Once the server is running, the team needs to know when something breaks, ideally before the users notice. Splunk is the tool named most in Java work, for gathering and searching logs, with Grafana and Prometheus behind it for numbers and dashboards, and Datadog, New Relic and CloudWatch in a few job posts. These tools are named in a small share of job posts overall, and that share is concentrated in the retailers' and banks' GCCs, where the engineer runs in production what they build. Elsewhere monitoring is usually someone else's dashboard and appears as a plus.
Tests are what the pipeline runs, so the two travel together. JUnit is the testing tool of Java, and Mockito goes with it for standing in for the parts a test does not want to call for real. In backend job posts these two are the whole of the testing ask, and they are named most in client work and at the banks. In full-stack job posts testing is called out far more often, because the engineer is expected to test the screen as well as the server, and Selenium, Cucumber, TestNG, Jest and Playwright appear beside JUnit. REST Assured is named for testing the API itself.
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 Java engineer who knows Spring Boot well, understands Spring Data JPA or Hibernate over a relational database and can write real SQL, can ship in a container on Kubernetes through a Jenkins or GitHub Actions pipeline with JUnit tests, and understands why an event goes onto Kafka, meets the core of nearly every job post. The variations belong to the employer. The retailers, marketplaces and travel sites want microservices at scale, with Kafka, Kubernetes, Cassandra and Elasticsearch, often on Azure. The banks, core-banking and credit companies want correctness, Oracle, Spring Security and a full-stack engineer with React or Angular. The supply-chain and security product companies want Spring Boot services on Kubernetes and Kafka. Client work wants the same stack built quickly and tested well, with Spring Batch and JUnit asked for more than elsewhere. Across all of them, calling an LLM is only beginning to appear, and it is still a plus rather than an expectation.