How to Write a Software Developer CV
3 min read·Updated 5 Nov 2025
A developer CV is usually read by two people in sequence: a recruiter checking for keywords, and an engineer deciding whether to spend an hour interviewing you. Those two readers want different things, and a good CV serves both without pandering to either.
The recruiter needs the stack, stated plainly. The engineer needs evidence that you have shipped something to real users and dealt with the consequences.
Lead with the stack, but do not stop there
A grouped technical skills block near the top does the recruiter's job in two seconds. Group by function — language, framework, data, infrastructure, testing — rather than listing thirty items in a paragraph.
What it will not do is convince an engineer. "React, TypeScript, Node.js" is on tens of thousands of CVs. The convincing part is the sentence after it.
Write about production, not tickets
Weak
Responsible for building new features in React.
Stronger
Built the saved-search and alerting features used by roughly 40,000 monthly users, from component design through to rollout behind a feature flag.
Names the feature, gives the scale, and shows you owned the release rather than only the code.
Performance work is the strongest material you have
Performance is measurable, checkable and universally understood, which makes it the most persuasive kind of bullet point on a technical CV. Give a before and after, and the specific change that caused it.
Weak
Improved website performance.
Stronger
Cut Largest Contentful Paint on the listing page from 4.1s to 1.8s by code-splitting the map bundle and deferring third-party scripts.
A measured result and the two techniques behind it. This is the bullet that gets asked about in the interview, which is exactly what you want.
Testing, but specifically
Naming a testing library is weak — everyone lists one. Describing what you test and why is strong, especially when it connects to a real problem.
"Raised coverage of the booking flow from 34% to 81% and added end-to-end checks for the three journeys generating most support tickets" shows you understand that test effort should follow risk.
When your work is confidential
A great deal of commercial software cannot be shown or described in detail. That is normal and reviewers know it.
Describe the constraint you solved rather than the product: throughput, latency, correctness under concurrency, a migration with no downtime, an integration with a system you did not control. None of those identify an employer, and all of them demonstrate engineering judgement.
Links and side projects
- Include a GitHub link only if there is something to see — a project with a readme, merged pull requests, or code that shows how you structure things.
- Open every link before you send the CV. A dead demo is worse than no demo, because it suggests you did not check.
- Put side projects below professional experience once you have two or more jobs. Above it if you are junior or changing career.
- Describe a side project like real work: problem, approach, outcome, and how many people use it if anyone does.
Things that weaken a developer CV
- A skills list of thirty technologies with no grouping. It reads as exposure, not competence.
- Claiming full stack when the evidence is entirely front-end or entirely back-end.
- Rating your own proficiency out of five. It parses as nothing and reads as arbitrary.
- Listing every library in a framework's ecosystem. Nobody is hired for knowing a configuration package.
- A two-column design sent to a large employer's application portal.
Questions
How long should a developer CV be?
Should I include a portfolio site?
Do I need to list every language I know?
Put this into practice
The editor keeps your CV as structured content, so the section order and wording decisions in this guide are easy to apply and easy to change again.