Skip to content

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?
One page up to about five years of experience, two after that. If you are trimming, cut older roles to a single line rather than shrinking the font.
Should I include a portfolio site?
Not necessarily. A deployed project with a clear readme does the same job. If you do build one, make sure it loads fast on a phone — reviewers notice when a front-end developer ships a slow site.
Do I need to list every language I know?
No. List the ones you would be productive in on day one, and mention others in the context of the project where you used them.

The same structure, applied to a field

Each of these works through a complete fictional CV for that profession, including the conventions where the general advice above does not hold.

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.