The core of this role is an application server written in JavaScript or TypeScript and run by Node.js. 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.
TypeScript is asked for in most job posts, more at product companies than in client work. It adds types to JavaScript so that mistakes are caught before the code runs, and a team of any size now expects it. Two frameworks give the server its shape. Express.js is the older and simpler one, a thin layer that routes each request to a function, and it is still the most asked for. NestJS is the newer and more structured one, built in TypeScript and organised in modules the way a Java or .NET application would be, and it is asked for in fewer job posts. NestJS shows up most at the start-ups selling online, the online-store tools, and in the consulting arms and services firms, where a larger team wants more structure than Express.js gives. Many job posts name both. Next.js appears on the full-stack side, where the React screens and a thin server live in one framework.
A few job posts name a second language beside Node.js. Python is the most common, usually for scripts, data jobs or LLM features. Java and Go appear in a minority, mostly where a larger company runs Node services beside older ones.
Most requests involve a database operation, reading some records or saving some. This role is the one backend role where the document database is as common as the relational one. MongoDB is the most-named database on the backend side, with PostgreSQL close behind, followed by MySQL. The pairing of React, Node.js and MongoDB, often called the MERN stack, is what the remote platforms and staffing companies ask for most, and it is common at start-ups, because a document database lets a small team change the shape of its records without planning tables first. PostgreSQL leads at the product companies that build industry software, the construction, freight and energy companies, and in client work, where records point at one another, an order at a customer, a project at a site, and a relational database keeps those links correct. SQL is asked for alongside it, because the engineer designs the tables and writes the queries behind every list, filter and report.
Around the main database sit a few helpers. Redis is the most common, holding answers that are asked for again and again so the database is not asked every time, keeping user sessions, and often doubling as the queue described further down. Elasticsearch powers search across catalogues and large amounts of text. 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 payment provider, a messaging platform such as WhatsApp, or a partner's API, 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 Node that API layer is what Express.js or NestJS is for. 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.
GraphQL deserves its own mention, because it is asked for far more in this role than in any other backend role. Instead of many URLs each returning a fixed shape, GraphQL gives the app one endpoint where it asks for exactly the fields it needs, which suits a React screen that shows many kinds of data at once. It is asked for in a large share of job posts at the retailers' GCCs, where React and Node.js sit on top of a GraphQL layer, and in a fair share at the start-ups and industry software companies. API gateways from AWS or Azure appear where the API is shared across teams or sold to partners, and OpenAPI and gRPC appear in a handful of job posts.
Most job posts want the same engineer to build the screens, and here the frontend is not a side skill but a full part of the job. React is the frontend of choice by a very wide margin, and most React job posts also ask for TypeScript. Angular is a distant second, and it is asked for mostly in the consulting arms and services firms. Vue is third. Plain JavaScript, HTML and CSS are listed in a good share of full-stack job posts, and the tools around React appear in smaller numbers: Redux Toolkit for managing state, Next.js for rendering pages on the server, Webpack for bundling, and Sass for styling. Full-stack is the norm at the start-ups, the education companies, the industry software companies and the small software firms, where one team builds the entire product. Backend-only Node work, with someone else's frontend in front of it, is found at the buyer-data companies and in the services firms. Even there, a fair share of backend job posts mention React, 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 WhatsApp messages, generating a report, processing an uploaded file, syncing orders from an online store, 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 most backend job posts, because Node.js was built for exactly this kind of work: many slow things happening at once without the server waiting on any of them.
Kafka is the broker named most, followed by RabbitMQ, and then the cloud providers' own queues, SQS and SNS on AWS, Pub/Sub on Google Cloud, and Kinesis for streams of events. In the Node world Redis often carries the queue itself, which is one reason Redis is named so often. Kafka points to a second use of the same idea. When an order is placed or a lead comes in, the server announces the event once, and every other service that cares picks it up in its own time. This is strongest at the start-ups selling online, where a sale touches checkout, stock, messaging and billing, and at the retailers' GCCs.
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, and they are everyday work in this role: a payment provider, an online-store platform or a messaging platform 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. JWT and OAuth 2.0 are the standards named most, with OpenID Connect and Auth0 in a few job posts. It is asked for in a fair share of backend job posts, most at the start-ups and in client work, and it is a must wherever payments or customer data pass through.
Calling an LLM is now a regular part of a Node backend. A user asks a question in plain words, uploads a document to be summarised, or wants a reply drafted, and increasingly the LLM is answering a customer directly over chat or WhatsApp. 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. LangChain is the library named, and the OpenAI API and Anthropic's Claude the models. LLM integration is asked for in a fair share of job posts, a little more on the full-stack side, and most at the industry software companies, the start-ups selling online and in client work. It is well established here, though not yet as common as in Python work.
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 Node.js itself.
Docker is the container tool, and Kubernetes is named almost as often. 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. AWS is the most-named cloud by a wide margin, and Google Cloud is named about as often as Azure, which is unusual. AWS leads everywhere except the consulting arms and services firms, where Azure is close to it, and the retailers' GCCs, where all three clouds are named about equally. Terraform and CloudFormation appear in a small share of job posts, where the engineer is also expected to describe the servers, networks and databases as code.
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, well ahead of Azure DevOps, Jenkins and GitLab CI, which fits a role whose code mostly lives on GitHub. SonarQube is named beside them where code quality is checked in the pipeline. Pipelines are asked for in most job posts, more on the full-stack side, and they are close to universal in client work and at the retailers' GCCs, 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. Prometheus collects the numbers, Grafana draws them, OpenTelemetry traces a single request as it hops between services, and Datadog, New Relic, Sentry and CloudWatch gather the errors and logs. Datadog and Sentry stand out here, because they are the tools product companies and start-ups pay for rather than run themselves. Even so, these tools are named in a small share of job posts, and monitoring is usually a plus rather than a requirement.
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. In full-stack job posts it is called out in a good share, because the engineer is expected to test the screen as well as the server. Jest is the tool named most, with Mocha behind it for the server and Playwright and Cypress for driving the browser. Testing is asked for most at the industry software companies and the retailers' GCCs.
Underneath all of it sits the ordinary craft of building software in a team: Git for source control, npm for packages, 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 Node engineer who writes TypeScript, knows Express.js and can find their way in NestJS, is comfortable in both MongoDB and PostgreSQL, builds React screens, can ship in a Docker container on AWS through a GitHub Actions pipeline, and understands why a slow job goes to a queue and why a webhook has to be handled twice safely, meets the core of nearly every job post. The variations belong to the employer. The start-ups selling online want React full-stack in TypeScript with Express.js or NestJS, PostgreSQL and a lot of messaging. The industry software companies want the same with GraphQL, PostgreSQL and more testing. The retailers' GCCs want React and Node.js over a GraphQL layer with Kafka and Kubernetes, and all three clouds. Client work wants Node backends on AWS or Azure with Express.js, and more Angular and NestJS than elsewhere. The remote platforms and staffing companies want the MERN stack for overseas clients. Across all of them, calling an LLM is already a regular part of the job.