Backend developers
Backend developers own the part of a product that remembers things. Data models, APIs, transactions, background work, authorisation and the behaviour of a system when a dependency stops answering all sit on this side of the boundary. This guide sets out what the discipline covers, the situations that make a dedicated backend engineer worth hiring, and how to evaluate one without relying on framework trivia.
What does a backend developer do?
A backend developer builds and operates the server-side of an application: the data model, the APIs other systems call, the business rules that must hold every time, the asynchronous and scheduled work that happens away from a user request, and the authorisation that decides who may see what. The role is accountable for correctness under concurrent access, for behaviour when a dependency is slow or unavailable, and for the system remaining diagnosable once it is running in production.
What separates backend work from most other engineering is that it holds state, and state outlives the release that created it. An interface defect is repaired by shipping a corrected build; a defect that writes incorrect rows leaves a residue to be located and repaired long after the code was fixed. That asymmetry is why experienced backend engineers are cautious in particular places — money, irreversible actions, anything that changes a record rather than reads one — and why the caution is a qualification rather than slowness.
The second difficulty is that a server rarely handles one request at a time. Logic that is obviously correct in isolation becomes wrong when two callers execute it at once, when a client retries a request the server already processed, or when a network call neither succeeds nor fails but simply stops answering. Reasoning about interleaving, isolation, locking, idempotency and timeouts is ordinary backend work, and it is invisible until the day it is missing.
The scope has widened alongside the infrastructure available to it. Managed queues, object storage, replicated databases and third-party APIs mean a backend engineer now makes decisions that determine operating cost and how quickly an incident can be diagnosed, not only which functions run. An API is also a product with consumers who cannot be redeployed on request, which turns contract design into a durable commitment rather than an implementation detail.
When teams need this capability
Server-side work is frequently carried by whoever is nearest until something makes that arrangement expensive. The pressures below are the ones that usually convert backend engineering from a shared duty into a dedicated role.
The data model has become the limiting factor
New features keep requiring another nullable column, another lookup table bolted to the side, or a query that joins five tables to answer a simple product question. Schemas accumulate compromises quietly, and by the time the shape of the data is visibly wrong it is already carrying production records that make changing it a migration project.
Concurrency defects have started appearing
Duplicate orders, balances that disagree with their own transaction history, records updated by two paths that each believed they were the only writer. These faults are load-dependent, rarely reproduce on a developer machine, and are almost never fixed reliably by someone reasoning about a single request at a time.
The API now has consumers you do not control
A mobile client that users decline to update, a partner integration, an internal service owned by another team. Once a contract has consumers outside the deployment, changes need versioning, deprecation and compatibility thinking — and an endpoint designed as an internal convenience becomes very costly to correct.
Incidents are diagnosed by guesswork
Something is slow or wrong, and the available evidence is a dashboard showing that it is slow or wrong. Without request tracing, structured logs, meaningful metrics and correlation across services, every incident becomes an exercise in redeploying plausible changes and watching what happens.
A workflow now has to be provably correct
Payments, billing, inventory, payroll, regulated records — anything where being approximately right is being wrong. These flows need transactional boundaries, idempotency, reconciliation and an audit trail designed in, and retrofitting them onto a workflow that grew organically is substantially harder than building them deliberately.
Core capabilities
API design
Choosing resource boundaries, error semantics, pagination, filtering and versioning so that a contract can survive its own consumers. Good API design is largely the discipline of deciding what not to expose, because every field returned becomes something a caller may depend on.
Data modelling
Representing a domain so that invalid states are hard to express — constraints, foreign keys, uniqueness and appropriate normalisation — and knowing when denormalisation is a deliberate performance decision rather than an accident. This includes planning schema change on tables that are already large and already in use.
Transactions and isolation
Knowing where a transaction should begin and end, what a given isolation level actually guarantees, and which anomalies remain possible underneath it. Read-modify-write sequences performed outside a transaction are among the most common sources of silent data corruption in production systems.
Concurrency and idempotency
Designing operations that behave correctly when they are executed twice, executed simultaneously, or interrupted midway. Idempotency keys, optimistic locking, unique constraints as a last line of defence, and an explicit view on which operations are safe to retry.
Failure handling
Timeouts on every outbound call, retries with backoff and jitter only where retrying is safe, circuit breaking, graceful degradation and backpressure. The important judgement is deciding what the system should do when a dependency is unavailable, rather than discovering the answer during an incident.
Asynchronous and scheduled work
Moving work off the request path with queues, workers and scheduled jobs, then dealing with what that introduces: ordering, duplicate delivery, poison messages, dead-letter handling, and the operational question of what happens to a backlog that has been growing overnight.
Caching
Deciding what may be cached, for how long, and how it is invalidated — and being honest that the invalidation strategy is the whole problem. This includes recognising when a cache is compensating for a query that should have been fixed instead.
Observability
Structured logs with correlation identifiers, metrics that describe user-visible behaviour rather than machine health alone, distributed tracing, and alerts tied to symptoms people care about. The test is whether an unfamiliar engineer can diagnose a novel fault from what the system already emits.
Security and authorisation
Authentication and session handling, an authorisation model enforced at the point of data access rather than in the interface, parameterised queries, secrets management, and careful handling of personal data. Most damaging server-side breaches are ordinary authorisation gaps rather than exotic exploits.
Technology ecosystem
Common technologies in backend engineering are listed below. This describes the landscape of the discipline as it is practised, not a claim about any particular engineer’s toolkit — and in backend work the transferable knowledge sits in data modelling, concurrency and failure behaviour, which move between runtimes far more readily than framework syntax does.
Languages and runtimes
- Java
- Go
- Python
- Node.js
- C#
- Kotlin
- Ruby
- PHP
- Rust
Server frameworks
- Spring Boot
- Django
- FastAPI
- NestJS
- Express
- Laravel
- Rails
- ASP.NET Core
Data stores
- PostgreSQL
- MySQL
- MongoDB
- Redis
- Elasticsearch
- ClickHouse
- DynamoDB
API and integration
- REST
- GraphQL
- gRPC
- OpenAPI
- WebSockets
- Webhooks
Messaging and background work
- Kafka
- RabbitMQ
- Amazon SQS
- NATS
- Celery
- Temporal
- Sidekiq
Observability
- OpenTelemetry
- Prometheus
- Grafana
- Jaeger
- Sentry
- Datadog
Testing and delivery
- Testcontainers
- pytest
- JUnit
- k6
- Docker
- GitHub Actions
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Product
- Business priorities
- Roadmap
- Architecture
- Sprint priorities
- Engineering standards
- Day-to-day technical collaboration
Talent.ID handles
- Employment relationship
- Payroll
- Employee benefits
- Talent administration
- Ongoing employee relationship
What to look for when hiring
Backend candidates are hard to assess from artefacts. There is no portfolio to look at, the code is rarely public, and the qualities that matter most — caution around state, clear thinking about failure — only surface in conversation about specific past decisions. These are the areas worth probing.
Data modelling judgement
Ask them to describe a schema they designed and what they would change about it now. Engineers who have lived with their own model for a couple of years talk about it very differently from engineers who handed one over and moved on.
- Uses database constraints to enforce invariants rather than relying only on application code
- Can explain a denormalisation they made and the cost they accepted for it
- Has migrated a large table in production and can describe how they avoided downtime
- Treats deleting or renaming a column as a multi-step process, not a single change
Correctness under concurrency
This is the most reliable separator between mid and senior backend engineers. Present an ordinary read-modify-write scenario and see whether they notice the race without being prompted toward it.
- Reaches for a transaction, a lock or a unique constraint at the right point
- Can explain what a specific isolation level does and does not prevent
- Designs write operations to be safely repeatable
- Distinguishes a race that loses an update from one that merely reorders work
API contract thinking
Ask how they would add a required field to an endpoint that existing clients already call. The answer reveals whether they think of an API as code they own or as a commitment made to somebody else.
- Plans additive change before breaking change, and versioning before either
- Has an opinion on error responses that is more considered than status codes alone
- Considers pagination and result limits before the dataset grows
- Documents the contract somewhere a consumer can actually use
Behaviour when dependencies fail
Every meaningful backend system calls something it does not control. Ask what their service does when that call takes far longer than usual — a strong answer is specific about timeouts, fallbacks and what the caller ultimately sees.
- Sets explicit timeouts rather than inheriting library defaults
- Retries only operations that are safe to repeat, and with backoff
- Can describe a degraded mode the product remains usable in
- Thinks about the failure’s effect on queues, pools and upstream callers
Production diagnosis
Ask them to walk through a real incident: the first signal they noticed, the possibilities they eliminated, and the evidence that finally settled it. Listen for conclusions drawn from what the system reported rather than intuitions formed early and then defended.
- Works from traces, structured logs and metrics rather than from a hunch
- Separates the trigger of an incident from its underlying cause
- Has added instrumentation in response to something they could not see
- Can describe a mitigation applied before the full diagnosis was available
Security instinct
You are not looking for a security specialist. You are looking for someone whose default is to enforce access at the data layer and to be suspicious of input, because that default prevents the large majority of ordinary server-side exposure.
- Enforces authorisation on every path to a record, not only the obvious one
- Treats identifiers arriving from a client as untrusted regardless of source
- Knows why parameterised queries matter and does not assume an ORM removes the concern
- Is careful about what appears in logs and error responses
Testing approach
Ask what they test against a real database and what they replace with a substitute. Backend suites that mock the data layer tend to pass while the actual queries, constraints and transactions remain unverified.
- Exercises real database behaviour somewhere in the suite
- Tests the boundaries — empty results, duplicates, concurrent writes
- Can name a bug their tests failed to catch and what they changed afterwards
Interview questions worth asking
The questions below are structured to surface reasoning about state and failure rather than recall of syntax. They are provided for use in your own interview process, which remains yours to run — every candidate is assessed by your team before joining it.
A client submits a payment request, the response is lost, and the client retries. What have you built so the customer is not charged twice?
What a strong answer shows
Whether idempotency is a habit or a term. Strong answers describe a client-supplied key, a uniqueness constraint that survives concurrent attempts, and a stored result returned to the repeat caller — not a check performed before an insert and hoped to be atomic.
You need to add a non-null column to a large table that is being written to continuously. How do you do it?
What a strong answer shows
Practical migration experience. Look for a staged approach — add nullable, backfill in batches, write to both, then enforce — and for awareness of locking behaviour, replication lag and the deploy ordering that keeps the old code working throughout.
An endpoint is fast on average and unacceptably slow for a minority of requests. Where do you look?
What a strong answer shows
Whether they think in distributions. Strong answers reject the average as evidence, look for a variable-cost path — a missing index, an unbounded result set, a cold cache, contention on a pool — and use tracing to find where the time is actually spent.
When would you move work into a queue, and what problems does that create?
What a strong answer shows
Balanced judgement. Anyone can list the benefits. The useful answer names the cost: eventual consistency the product must now express, duplicate delivery, ordering that is no longer guaranteed, failed jobs that need somewhere to go, and a backlog that is now an operational concern.
How do you make sure one user cannot read another user’s data through your API?
What a strong answer shows
Where they place the control. The strong answer enforces ownership in the query or the data access layer so it holds on every route, rather than in per-endpoint checks that a new handler can silently omit. Listen for how they would test it.
Tell me about a time your service was serving stale or wrong data because of a cache. How did it happen?
What a strong answer shows
Real operational history. Good answers are specific about the invalidation path that was missed, and reflective about whether the cache was solving a problem that a schema or index change should have solved instead.
You are paged for elevated errors and have logs, metrics and traces but no obvious cause. Walk me through the first fifteen minutes.
What a strong answer shows
Incident method under pressure. Look for stabilising before diagnosing, correlating with recent deploys and dependency health, narrowing by comparison, and communicating status — rather than immediately reading code.
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- An engineering team is carrying a growing API surface alongside a data model that has absorbed several years of product change. Query performance is degrading in specific flows, background jobs need reworking, and the team cannot address any of it without pausing committed roadmap delivery.
- Approach
- Additional backend capacity joins the team’s established way of working — their service ownership boundaries, their review standards, their deployment process and the architectural direction they have already set. Priorities continue to be set internally, and the added capacity picks up work from the same backlog rather than operating a separate stream.
- What this adds to the team
- The team gains room to address structural work while continuing to ship. Decisions about the data model, the API contract and the direction of the system remain with the engineers accountable for the product.
Related disciplines
Frequently asked questions
- What is the difference between a backend developer and a platform engineer?
- A backend developer builds the application logic and data model the product depends on. A platform engineer builds the infrastructure and internal tooling that application teams deploy onto — clusters, pipelines, environments, observability plumbing. The two overlap in containerisation and cloud services, and a strong backend engineer is usually comfortable operating what they build, but they are not substitutes: giving a backend developer sole responsibility for the platform tends to produce infrastructure that suits one service and nobody else.
- Does a backend developer need deep database expertise?
- Enough to design a sound schema, read an execution plan, index deliberately and understand transactional behaviour. That is a meaningful bar and many candidates do not clear it. Replication topology, storage engine tuning, sharding strategy and complex recovery planning are where a database specialist earns their place, and a team running a heavily loaded cluster generally needs both rather than one person stretched across the two.
- How much does the language matter when hiring?
- Less than the ecosystem around it. Concurrency, data modelling and failure behaviour are the durable knowledge, and they move between comparable runtimes without much friction. What transfers slowly is familiarity with a specific ecosystem’s conventions and operational tooling — so weight language experience more heavily where the engagement is brief or the runtime is unusual, and less where there is time to acclimatise in a mainstream stack.
- Should a backend developer be on call for what they build?
- Where the team’s operating model supports it, yes — engineers who carry the consequences of their design decisions tend to make better ones. What matters is that it is a team norm applied consistently, with the observability and runbooks that make being on call reasonable, rather than an expectation attached to individuals after the fact.
- When is a dedicated backend developer better than a full-stack developer?
- When the difficulty of the product sits behind the interface. High write volume, intricate domain rules, multiple integrations, regulated workflows and demanding reliability targets all reward depth in data modelling and distributed behaviour. Where the server side is mostly straightforward reads and writes and the interface carries the product, full-stack breadth usually delivers more per person.
- What seniority does backend work require?
- It depends on how much is already decided. Implementing endpoints within an established schema, service structure and testing approach suits mid-level engineers well. Setting the data model, defining service boundaries or leading a decomposition needs someone who has lived with the consequences of those choices, because the cost of getting them wrong is paid slowly and is rarely reversible.
- How do backend developers work with an existing engineering team?
- Day to day the working relationship is with your team: your architecture, your code review, your service ownership model and your sprint priorities. Technical direction stays with you. Under staff augmentation, what sits on the Talent.ID side is the employment relationship — payroll, employee benefits, talent administration and the ongoing relationship with the employee.
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.