Back-end work has a presentation problem that front-end work does not. Nobody can see it. A front-end developer can link to something and the reviewer immediately understands the surface. A back-end developer writes "Built REST APIs using Node.js and PostgreSQL" and the reviewer learns almost nothing — not whether the API served forty requests a day or forty thousand a second, not whether it was a greenfield service or a migration off a fifteen-year-old system, not whether it stayed up.
Almost every weak back-end CV has the same underlying fault: it lists the technologies and omits the scale and the ownership, which are the two things being screened for.
State the scale, always
Scale is what converts a technology list into evidence. It is usually the fastest single improvement available to a back-end CV, and most people have the numbers and simply do not think to include them.
Useful dimensions, depending on your system:
- Traffic — requests per second, daily API calls, peak versus steady state.
- Data — rows, table size, ingest rate, retention.
- Throughput — messages processed, jobs per hour, batch sizes.
- Latency — p50, p95, p99. Naming p99 rather than "average response time" signals you know which number matters.
- Availability — uptime against a target, incident count, error budget.
- Money — transaction volume, payment throughput, infrastructure cost.
- Blast radius — how many services or downstream consumers depended on yours.
Compare: "Built REST APIs using Node.js and PostgreSQL" against "Built and ran the order-ingest API in Node.js and PostgreSQL — 3,000 requests per second at peak, p99 under 120ms, serving six downstream services." Same work. The second one is a candidate.
Ownership is the second signal
Interview loops for mid-level and above are heavily weighted toward what you did when something broke, because that is where the difference between someone who ships features and someone who runs a system shows up. Your CV should establish that you have been on that side of the line.
Concretely, that means bullets covering:
- On-call. That you carried a pager, and roughly what the rotation looked like.
- An incident you owned. What broke, how you found it, what you changed so it could not recur. This is the highest-value bullet on a back-end CV and it is very frequently missing.
- A migration you ran. Schema changes on live tables, a datastore move, a language or framework upgrade — with the zero-downtime strategy named, because that is the interesting part.
- Something you deleted or simplified. Removing a service, collapsing a redundant layer, retiring a queue. Senior signal, rarely claimed.
Bullet rewrites
Weak: "Responsible for maintaining microservices architecture."
Better: "Owned four services in a 30-service estate, including the payments gateway; carried a one-in-five on-call rotation and cut our page volume by roughly half over two quarters by fixing the top three recurring alert causes."
Weak: "Optimised database queries for better performance."
Better: "Traced a checkout latency regression to an unindexed join added in a prior release; added a covering index and rewrote the query, taking p99 from 2.4s to 180ms on a 40-million-row table."
Weak: "Worked with Kafka for event processing."
Better: "Moved order fulfilment from synchronous HTTP calls to Kafka, handling roughly 12 million events a day; designed the idempotency and replay strategy so duplicate deliveries could not double-charge customers."
Notice that each rewrite names the mechanism. "Optimised queries" is a claim; "added a covering index and rewrote the query" is a demonstration. Interviewers read for the mechanism because it is the part that cannot be faked.
Keywords that determine whether you surface
Recruiters search their applicant database by keyword, so the practical function of a technology name on your CV is to put you in the result set. Name specifics, not categories.
Languages and runtimes: the specific ones — Java, Go, Python, Node.js, C#, Rust, Kotlin — with versions or major frameworks where they matter (Spring Boot, .NET, Django, FastAPI, Express, NestJS).
Data: PostgreSQL, MySQL, MongoDB, Redis, Cassandra, DynamoDB, Elasticsearch, ClickHouse. Name the actual engine, not "SQL databases".
Messaging and streaming: Kafka, RabbitMQ, SQS, Pub/Sub, Kinesis.
Infrastructure: AWS, GCP or Azure with the specific services you actually used, plus Docker, Kubernetes, Terraform.
Practices: CI/CD, observability, distributed tracing, load testing, blue-green or canary deploys.
Write both forms where a field uses both: "container orchestration (Kubernetes)". And only list what you would be comfortable being questioned on for ten minutes — a padded skills section is a list of topics you have invited into the interview.
Structure by level
Junior. Projects carry the CV when employment does not. A deployed side project with a real database, tests and a public repository is worth more than three coursework entries. Show that you have shipped something that runs.
Mid-level. The centre of gravity is ownership of a service or component, plus evidence of production responsibility. This is where the on-call and incident bullets start mattering most.
Senior and above. Scope widens to design decisions, trade-offs and influence beyond your own code — the migration you led, the standard you set, the engineers you brought along. Reviewers are reading for judgment, so bullets should show a decision and its reasoning, not just an outcome.
Formatting
One page under about ten years, two beyond it. Single column, standard headings, contact details in the body rather than a document header, real text rather than images, and a GitHub link only if the profile there is worth opening.
Skip the skill rating bars. Claiming "Python: 4/5" invites a question about what the missing fifth is, and it is not text a parser can read anyway.
Check the parse by pasting your PDF into a plain text editor, or use the free ATS checker to see the extracted fields. For interview preparation, our back-end developer interview guide covers the questions these CVs get tested against.