A backend developer CV has a specific job. It has to convince a technical reader, often a hiring engineer rather than a recruiter, that you can build and run systems that hold up under real load. Listing languages is not enough. Plenty of candidates know the same languages. What separates a strong backend CV is evidence of judgement: what you built, what it had to survive, and what you decided when it broke.

Put a real tech stack section near the top

A backend role is screened partly on stack fit. Make it easy. Group your technologies so a reader scans them in seconds: languages, frameworks, databases, infrastructure and tooling.

Be honest about depth. There is a difference between a language you ship production code in daily and one you used once in a side project. If a CV lists fifteen technologies as if all are equal, the interview exposes the gap fast. List the ones you can defend, and put the strongest first.

Describe systems, not just tasks

The weak version of a backend bullet is "developed REST APIs using Node.js". It tells the reader nothing about scale, reliability, or the problem the API solved.

The strong version names the system and its constraints:

Built the payments API handling 300 requests per second at peak, with idempotency keys to make retries safe after a duplicate-charge incident.

That line shows the technology, the scale, and a real engineering decision driven by something that actually went wrong. A technical interviewer reads it and already has three follow-up questions, which is exactly what you want.

Show numbers a backend reader cares about

Frontend metrics and backend metrics are different. For backend work, the numbers that land are about throughput, latency, reliability, and cost. Requests per second. The p99 latency you brought down. Uptime you held. The percentage you cut off a cloud bill by fixing a query.

Cut p99 latency on the search endpoint from 1.2s to 280ms by adding a read replica and a caching layer.

If you do not have hard production numbers from a job, use the scale you do know: database size, number of services, size of the team, deployment frequency.

Include the parts that are not just code

Backend work is not only writing endpoints. Mention the things that show you can own a system in production: designing a schema, setting up monitoring and alerting, handling an incident and the post-mortem, writing the migration that moved data without downtime.

These signal seniority more clearly than another framework name. A developer who has been on call and shipped a zero-downtime migration is a different hire than one who has only written feature code, and the CV should make that visible.

Keep it to the relevant work

Two pages at most, one if you are early-career. Recent and relevant roles get the detail; older ones get a line or two. A backend CV that runs to four pages because every CRUD endpoint is documented signals weak judgement about what matters, which is the opposite of what you are trying to prove.

If your day-to-day already lives on LinkedIn, Postulit can pull it into a structured CV draft, which gives you a clean base to add the system-level detail a backend role needs.

Take your two most recent roles and rewrite one bullet each into the system-and-constraint form: name the system, the scale it handled, and one decision you made under pressure. That is the bullet a backend interviewer stops on.