How do I write a CV for a backend engineer role?

You have shipped services that handle real traffic, you have been woken up at 3am by a pager, and you are getting nothing back from applications. The most likely reason is not that your CV is badly written. It is that the first person to read it is a recruiter who cannot evaluate engineering, working from a requirements list, and your CV does not answer that list in the first thirty seconds. The second most likely reason is that when it does reach an engineering manager, it reads as a list of tickets rather than a record of systems you owned.

Both problems are fixable, and the fixes are specific to this job.

There are no qualifications, registrations or licences — say the true thing instead

Backend engineering in the UK has no protected title, no registration body that hiring depends on, and no licence. BCS chartership and CEng exist and are almost never a factor in getting a backend interview outside of some defence, rail and nuclear contractors. A computer science degree is common and is not required; the Level 6 Digital and Technology Solutions Professional apprenticeship and bootcamp-to-industry routes are both well represented in teams that hire well. If you have five or more years of production experience, the degree line is one line near the bottom, without the modules.

The things that do function like credentials in this field are different:

Security clearance. SC or DV clearance is a genuine gate for backend work at Home Office, MoD, GCHQ suppliers, and a lot of Crown Commercial framework consultancies. If you hold it, put it in the header with the level and whether it is current or lapsed. If you have held it and it has lapsed, say that too — lapsed clearance is far cheaper to reinstate than to start from scratch, and hiring managers in that sector know it.

Right to work. If you hold indefinite leave to remain, settled status, or a passport that needs no sponsorship, put it in one line. Sponsorship-capable employers are a minority and the ones who are not will filter you out silently rather than ask.

Domain compliance exposure. PCI DSS scope, FCA-regulated production systems, NHS DSP Toolkit, HIPAA, ISO 27001 controls you actually implemented. These are not certifications you earned, they are constraints you have worked under, and in fintech and health hiring they carry more weight than any certificate. "Built and operated services inside PCI DSS cardholder data environment scope" is a line that gets read twice.

What a backend hiring manager scans first

In order, roughly, and fast:

1. Primary language and runtime, with version. Java 8 and Java 21 are different jobs. Python 2 maintenance and modern async Python are different jobs. Go, Kotlin, C#/.NET, Node/TypeScript, Ruby, Rust, Elixir, Scala — whichever it is, it needs to be legible in the first third of page one, not buried in a skills block at the end.
2. Datastores. Postgres, MySQL, MongoDB, DynamoDB, Cassandra, and what you did with them. "PostgreSQL" on its own tells a manager nothing. "Postgres: schema design, index tuning, partitioning a table that had outgrown single-node query performance, zero-downtime migrations with a dual-write and backfill" tells them everything.
3. Whether you have run things in production. On-call rotation, incident response, SLOs, error budgets, post-incident reviews you wrote. An engineer who has only ever handed code to an ops team is a different hire from one who has been paged for their own service, and this is checked early.
4. Scale and shape of traffic. Not to impress anyone — to work out whether your instincts transfer. Request rates, data volumes, latency targets, batch sizes, number of tenants. Use your real numbers. If you do not have them, describe the shape instead: "low-volume, high-value financial transactions where correctness mattered more than throughput" is a genuinely informative sentence and is not a number you had to invent.
5. Messaging and integration. Kafka, RabbitMQ, SQS/SNS, Pub/Sub, gRPC, REST, GraphQL, webhooks. Whether you designed the contracts or consumed someone else's.

Everything else — Kubernetes, Terraform, CI pipelines, cloud provider — matters, but it is the second pass. Engineers who lead with a wall of AWS service names and bury the language are sorting themselves into the wrong pile.

Evidence in this field means systems, not responsibilities

The single biggest difference between a backend CV that gets a phone screen and one that does not is the difference between describing a role and describing a system.

A role sounds like: "Responsible for developing and maintaining microservices in a Java/Spring Boot environment using Agile methodologies."

A system sounds like: "Owned the order fulfilment service: Kotlin/Spring Boot, Postgres, Kafka consumer group processing events from the checkout service. Redesigned the consumer to be idempotent after duplicate deliveries were producing double-charged orders; introduced an outbox table so the write and the publish shared a transaction."

The second one is barely longer. It tells a manager what you know about exactly-once delivery being a lie, transactional outboxes, and the failure mode you hit. It gives the interviewer a question to ask you, which is the actual purpose of the document.

Write two or three of these per recent role. Not eight. Pick the ones where something was hard and you can explain the trade-off.

What backend engineers routinely leave off

This is the part that costs people interviews, and it is consistent.

Migrations. Monolith decomposition, Python 2 to 3, self-managed Postgres to RDS or Aurora, on-prem to cloud, REST to gRPC, one message broker to another, a major framework version bump across dozens of services. Engineers leave these off because they were not features and felt like maintenance. Hiring managers rate them very highly, because migration work is where judgement, backwards compatibility, feature flags, dual-writes, backfills and rollback plans all show up at once. If you have led one, it belongs near the top of that role.

Data modelling. "Designed the schema" is a sentence most backend engineers can write truthfully and most do not. Say what the entities were, what the tricky constraint was, and what you got wrong and had to change.

Operational work with a cost attached. Cutting cloud spend, removing a Redis cluster nobody needed, right-sizing instances, killing an N+1 that was hammering a read replica. Engineers think this is unglamorous. Anyone with a budget does not.

Incidents. Not to admit fault — to demonstrate you have been near production when it broke. "Diagnosed connection pool exhaustion under a traffic spike; introduced PgBouncer and a circuit breaker on the downstream call" is a strong line.

Testing beyond the word 'tests'. Contract testing between services, Testcontainers, property-based tests, load testing with k6 or Gatling, how you tested a migration. "Wrote unit tests" is noise. "Built contract tests between our service and three consumers so we could deploy independently" is a hiring signal.

The team and codebase shape. How many engineers, how many services you owned, how old the codebase was, whether you were the only backend engineer. Working alone on a legacy Rails monolith and working in a platform team of twelve are both respectable and neither is inferable from a job title.

Design documents and RFCs. If you are applying at senior, staff or principal level, the thing being assessed is scope of technical decision-making. Authoring design docs that other teams built against is the clearest evidence of it. Say how many, on what, and who the audience was.

The skills section, and how it usually fails

The common failure is a list of sixty technologies in one paragraph, including every AWS service you have ever opened the console for. It reads as padding and it makes a genuine strength invisible.

Group by function and keep each group short: languages, datastores, messaging, infrastructure, observability. Drop anything you would not want to be asked about for ten minutes. Do not put years next to each item and do not put proficiency bars or star ratings on anything — an engineering manager reading "Kafka ★★★☆☆" learns nothing and forms a view about the author.

If you are a full-stack engineer applying for backend roles, the skills block is where you decide what the CV is about. React, Tailwind and Figma near the top will get you read as a front-end engineer who wants a change. Keep the front-end experience — it is genuinely useful context — but put it after the backend material and describe it as what it was.

Things that are contested, honestly

Cloud certifications. AWS Solutions Architect Associate, GCP Professional Cloud Developer, CKA. In consultancies, systems integrators, AWS partner shops and parts of the public sector these are visibly weighted, sometimes because the employer's partner status depends on headcount holding them. In most product companies they are close to neutral, and a handful of senior engineers actively discount them. There is no honest universal answer. Look at whether the advert names them. If it does, put them in the header. If it does not, one line at the bottom.

GitHub links. A profile of eight tutorial repos and a forked dotfiles is worse than no link. A single deployed service with a README that explains the trade-offs, or a direct link to a merged PR in a project someone else maintains, is worth a lot. Link to the specific thing, not the profile.

Length. The one-page rule is an American convention that does not govern UK engineering hiring. Two pages is normal for a mid-level engineer, three is acceptable at staff level with a long history, and roles older than about ten years should collapse to a single line each. Front-load regardless.

Personal projects at senior level. Some managers read them as enthusiasm, some as a signal you are not getting enough interesting work. If the project demonstrates something your paid work does not — distributed systems work, a language you want to move into — keep it. Otherwise it is competing for space with your production experience and losing.

What to do next

Take the last backend advert you were rejected from without a reply. Write out the four or five things it actually asks for — the language, the datastore, the message broker, the scale, whether it wants someone who has been on-call. Then open your CV and time how long it takes to find each one. If any of them takes more than a few seconds to locate, move it up.

Then rewrite the two strongest bullets in your most recent role as systems rather than responsibilities: what it was built in, what it talked to, what broke or was hard, what you changed. Keep the real numbers you have and describe the shape where you do not.

Doing this properly for every advert is slow, which is why most people stop doing it after the first dozen applications; jobmarket.pro reads each advert in full and prepares the application from one profile it cannot add experience to.