How to write it
Quantify the invisible
Nobody sees a backend service that works, so the resume has to describe it in numbers or it describes nothing. The good news is that backend work generates more measurable outcomes than almost any other specialism, and most of them are sitting in a dashboard you already look at.
Requests per second, p99 latency, availability, rows migrated, queue lag, monthly spend. Any two of those in a bullet make it concrete. "Improved system performance" uses the same number of words to say nothing at all.
- Throughput: requests/second, jobs/hour, events/day
- Latency: p95 and p99, before and after
- Reliability: availability, error rate, incident count
- Data: rows, tables, tenants, storage volume
- Cost: monthly infrastructure spend removed
Reliability ownership is a seniority signal
The line between a mid-level backend developer and a senior one is usually the pager. Someone who has been on call for a system they built, has run a postmortem without blaming anyone, and has set an SLO they had to defend is operating at a different level from someone who has only written features.
Say so explicitly. On-call, incident response, SLOs, error budgets, and process you introduced rather than merely followed. This is the part of the job most resumes leave out, which makes it unusually cheap signal.
Migrations are the best story you have
Changing a schema on a live system with real customers is the hardest routine thing in backend engineering, and describing one well proves more than any framework claim. The details that matter are the scale, the safety, and the fact that nothing broke: "online migration of 1.2B rows with no write downtime".
The same is true of decomposition work — pulling a service out of a monolith, moving off a shared database, replacing a batch job with a stream. Say what the old thing cost and what the new one made possible.
Show data judgement, not ORM familiarity
"Experience with SQL and ORMs" is a claim every applicant makes. What a hiring team is actually trying to find out is whether you can model a domain, choose an index, spot an N+1, and know when a relational database is the wrong tool.
You demonstrate that with specifics: the composite index that took p99 from 2.3s to 400ms, the denormalisation you chose deliberately, the queue you added because the write path didn't need to be synchronous. One such bullet answers the question the interview would otherwise have to.