Recruiters spend about seven seconds on the first pass of a software engineer CV. The ones who get past that pass already know the format. The ones who don't usually fail for the same handful of reasons: a wall of frameworks with no context, a summary that reads like a LinkedIn About copy-paste, and bullets that describe the job description instead of what the person actually shipped.
This is the version of the CV I'd write today for a backend or full-stack role at a mid-sized company. It works for senior positions too — the structure doesn't change, the proof does.
Lead with what you shipped, not what you used
The top of a developer CV should answer one question: what did this person build, and did anyone use it. "Built a Kafka pipeline" is not an achievement. "Built a Kafka pipeline that replaced a nightly batch job and cut order-status latency from 20 minutes to under 30 seconds" is.
Three rules I apply to every bullet:
- Start with the verb, not the tech.
- Include a number — users, latency, error rate, cost, anything measurable.
- Cut anything that just paraphrases the role title.
The technologies belong further down. Recruiters skim them, but engineering managers read the bullets first to decide if you can think.
Structure that works in 2026
A software engineer CV in 2026 looks roughly like this, top to bottom:
- Name, role you want, location, GitHub, portfolio, email. No photo.
- A short summary, three lines max, written for the role you're applying to.
- Experience, reverse chronological, four to six bullets per role.
- Selected projects, only if they're public and recent.
- Skills, grouped (languages, infra, tools).
- Education and certifications, at the bottom.
One page if you have under five years of experience. Two pages if you're senior or have built shipped products that genuinely deserve the space. Three pages is for academic CVs, not engineering ones.
The summary is the hardest part
Most developer summaries either say nothing ("passionate full-stack developer with strong attention to detail") or list every technology twice. A good summary is closer to a positioning statement: who you are, what you've built, and what you're looking for next.
Backend engineer with seven years on payments and ledger systems at fintech and marketplace companies. Comfortable owning a service end-to-end, from database schema to on-call. Looking for a senior role on a small team where the codebase isn't a museum.
That's specific enough that the recruiter knows whether to keep reading. Generic summaries get skimmed past, even when the experience underneath is strong.
Tech stack: list what you'd ship with on Monday
The skills section is where most developer CVs leak credibility. Listing twenty languages and forty frameworks tells a recruiter you don't know which ones you actually use. List the stack you'd be comfortable opening a pull request in tomorrow. Keep the rest in a smaller "familiar with" line if you must mention them at all.
Group them so an engineering manager can scan in two seconds:
- Languages: TypeScript, Go, Python
- Infra: AWS (ECS, Lambda, RDS), Terraform, Postgres, Kafka
- Tooling: Datadog, Sentry, GitHub Actions
No ratings ("Python ★★★★☆"). No years per skill. Both signal lack of confidence.
Open source and side projects
A single linked GitHub repo with a clean README beats a paragraph about open source contribution. If you have one project that demonstrates real engineering — production-grade, tested, deployed — link it and write one bullet about what it does and what was hard. Skip the seventeen forks of tutorials.
The same applies to side projects. The bar is: someone other than you uses it, or it taught you something you couldn't learn at work. Otherwise it's noise.
ATS realities for a developer CV
Most engineering teams use an ATS, even the ones who say they don't. The CV needs to survive being parsed by software before a human reads it. Practically, this means:
- Save as PDF, but generate it from a text-based source (no scanned images).
- Use a single-column layout. Two columns confuse most parsers.
- Use real headers (
Experience,Skills), not creative variants. - Include the keywords from the job description in your actual experience, not stuffed into a footer.
If you're going from a LinkedIn profile to a CV, Postulit handles the structural and ATS parts so you can focus on rewriting the bullets.
What to cut
A short list of things that take up space without earning interviews:
- Hobbies, unless they're directly relevant (you maintain a popular library, you organize a meetup).
- A photo. Standard practice in some European markets, but adds bias risk and ATS noise everywhere else.
- References available on request. Implied.
- A list of every certificate you ever earned. Pick two.
- Soft skills as a section. Show them in the bullets instead.
The goal of the CV is to get to the phone screen, not to compress a career into a single document. Anything that doesn't move the reader closer to scheduling that call is taking up space something else could use.