Most developer CVs fail for the same reason: they read as a wall of languages and frameworks with almost no evidence of what was actually built, shipped or improved. A long list of tools tells a reviewer what you have touched, not what you can do with it. The CVs that get interviews prove delivery. They show the software you built, the problems you owned, and the difference your work made, with the stack in support of that story rather than standing in for it.
What employers (and engineers) actually want
A developer CV is usually read twice: once by an applicant tracking system, and once by an engineer or hiring manager who has built things themselves. Both are looking past the keyword list for evidence of three things: that you can ship working software, that you can work in a team, and that you can own a problem end to end. Naming a language proves none of that. Showing what you delivered with it, how it behaved in production, and how you worked with others to get it there is what earns a proper read.
Lead with what you built and shipped
Open with a short profile that names real projects and outcomes, not a tools inventory. A reader should learn, in the first few lines, what kind of systems you build, the scale you work at, and the sort of problems you solve. 'Backend developer who has shipped payment and identity services handling millions of requests a day' says more than any list of frameworks. Keep the detail for the roles below, but make the opening about delivery.
Structure your skills and tech section so it is scannable
You still need a technical section, but it should be quick to read. Group it by category, such as languages, frameworks, databases, cloud and tooling, so a reviewer can find what they are checking for in seconds. Match it to the stack named in the advert and put those items first. Do not pad it with everything you have ever opened, and be honest about levels. A shorter, accurate list you can talk to in an interview beats a long one you cannot.
Quantify impact
Numbers turn claims into evidence, and engineering has plenty of them: performance gains, scale and user numbers, latency, reliability and uptime, deployment or build time, and cost. Where exact figures are confidential, use percentages or ranges: 'cut p95 latency by around 40%' or 'reduced build times from roughly 20 minutes to under 5'. The point is the size and direction of the change, which you can almost always share safely. If a piece of work moved a metric, say which one and by how much.
Get past the ATS and the engineer
Plain formatting is what survives parsing: standard headings, no tables or columns for key content, and no skills graphics or rating bars, which the software cannot read and reviewers tend to distrust. Use the real keywords from the advert, in context, rather than a keyword-stuffed block. But remember the second reader. Once your CV is in front of an engineer, it needs to make sense to a human who will spot vague or inflated claims immediately. Write plainly, be specific, and only claim what you can defend.
Signal the right seniority
A reviewer reads scope to place your level. Task-level bullets ('fixed bugs', 'wrote tests') read as junior even when you are not. Show the scope you actually own: the systems you are responsible for, architectural or design decisions you drove, trade-offs you weighed, and people you mentored or led. If you set technical direction, made build-versus-buy calls, or owned a service in production, say so. The gap between doing tasks and owning outcomes is exactly what separates one seniority band from the next.
Tailor to the stack and domain in the advert
A role building high-throughput backend services is not the same as front-end product work or data engineering, even where the languages overlap. Read the advert for its stack and its domain, then bring the matching experience forward and use the same terms they do. Tailoring is not about rewriting your history; it is about ordering and emphasis so the fit is obvious to both the parser and the person.
A worked example
The difference is easiest to see in a single bullet. Before: 'Worked on the payments service.' After: 'Rebuilt the payments service in Go, cutting p95 latency by 40% and supporting a 3x rise in transactions.' The second version names the work, the technology, and two measurable outcomes. (The figures here are illustrative.) The reviewer now knows what you did, how, and why it mattered, from one line.
Common mistakes to avoid
- Opening with a long tools list instead of what you have built and shipped
- Task-level bullets that hide the scope you actually own
- Skills rating bars and graphics that the ATS cannot read
- Padding the tech section with tools you barely use
- Describing activity rather than the outcome or metric it moved
- Ignoring the specific stack and domain named in the advert
Common questions
What should a software developer CV focus on?
Evidence of what you have built and shipped, and the difference it made. Lead with projects and outcomes rather than a wall of languages, keep the tech section scannable and matched to the advert, and quantify impact where you can. A technical reviewer wants proof you can deliver working software and own a problem end to end.
How long should a developer CV be?
Two pages is right for most mid-career developers. Give your recent, relevant roles room to show impact and the stack you used, and keep older or less relevant roles brief. One page is fine early in your career; going beyond two pages usually means detail that could be cut.
Do I need a portfolio or GitHub link on my CV?
A link helps if it shows real, maintained work a reviewer can look at, such as a project you are proud of or meaningful contributions. Only include it if it adds evidence. An empty or abandoned profile can weaken your case, so leave it off if it does not show you at your best.