Skip to main content
CreateCVOnline

CV advice for software engineers

How to write a software engineer CV

An engineering CV is read twice by two people who want different things: a recruiter checking it against a requirements list, and an engineer deciding whether you would be useful on their team by Friday. The document has to answer both in the top half of page one.
Write yours — freeSee a full worked example

Almost every weak engineering CV fails the same way. It lists technologies and it lists employers, and it leaves out the engineering — the systems, the constraints, the decisions that were yours and the things that broke. A reviewer who is themselves an engineer can tell the difference between someone who was in the room and someone who owned the thing within about three bullet points.

The fix is not more detail. It is different detail: what you were responsible for, how big it was, what you changed about it and what happened as a result. Everything below is about getting that into a document a recruiter can also filter on, because both readers have to say yes.

The first minute

What a hiring manager reads first — and in what order

Four things, in this sequence. Everything else on your CV is read in the light of them, so anything that answers one of these belongs above the fold rather than on page two.
  1. 1

    Your current stack, in the first ten seconds

    The recruiter screen is a matching exercise. Whoever reads first is checking the languages, frameworks and infrastructure in the advert against what appears on your page — so the stack you would be productive in on day one belongs near the top, not in a footer under your interests.

  2. 2

    The scope of what you have run

    An engineering manager then looks for size. A CRUD tool for fifty internal users and a payments service handling millions of requests a day carry the same job title and are not the same job. Requests per day, data volume, number of services, users served — one of these numbers on your most recent role changes how the rest of the page reads.

  3. 3

    What you personally did

    “The team migrated to Kubernetes” tells a reader nothing about you. Name the part that was yours: designed it, owned it, led the migration, wrote the RFC, ran the incident. Attribution is not bragging in this field — a hiring manager who cannot separate you from your team will assume the smaller version.

  4. 4

    Trajectory, and anything that needs explaining

    Last is a pattern check: increasing ownership over time, sensible tenure, and a stack that has moved this decade. Gaps and short stints are not disqualifying, but an unexplained six-month hole invites a worse story than the real one. One clause is enough.

Numbers that carry weight

The metrics that actually matter for software engineers

Not every profession is measured the same way, and using the wrong kind of number is close to using none at all. These are the figures a reader in this field recognises immediately.

Scale of the system

Requests or events per day, rows in the table you own, monthly active users served, size of the fleet. This is the single most load-bearing number on an engineering CV because every other claim is read relative to it.

Reliability

p95 or p99 latency before and after, error rate, uptime against the SLO, incidents per quarter, mean time to recovery. Latency figures are especially persuasive because they are hard to fake and easy to ask about in an interview.

Delivery speed

Deploy frequency, lead time from merge to production, build or CI duration, change failure rate. These say something about how you work rather than what you know, which is exactly what a team lead is trying to find out.

Cost and efficiency

Infrastructure spend removed, instances decommissioned, query time cut, storage reclaimed. Cost work is under-reported on engineering CVs and disproportionately well received, because it is the kind of contribution a manager can defend in a budget meeting.

Structure

Section order for this role — and what to drop

Section order is the cheapest edit available to you and one of the most effective. This is the sequence that suits the way this profession is read.

Recommended order

  1. 1Contact and linksName, city, email, phone, GitHub and one portfolio or LinkedIn URL. Written as plain text, not hidden behind icons a parser cannot read.
  2. 2Summary — three linesWhat you are, how long, the domain you know and the one thing you are strongest at. If it would still be true on someone else’s CV, delete it.
  3. 3Technical skillsDirectly under the summary. This is the fastest read on the page and the section the recruiter is filtering on. Group by language, framework, infrastructure and data, and order the groups to match the advert.
  4. 4ExperienceReverse chronological, four to six bullets on the current role, three on the previous one, one or two on anything older than eight years.
  5. 5Projects or open sourceOnly if they add something your employment does not — a language you want to be hired in, a system type you have not been paid to build, or genuine adoption.
  6. 6EducationTwo lines once you have three years of experience. Degree, institution, year. A conversion course or bootcamp goes here too, stated plainly.
  7. 7CertificationsLast, and only the current ones. Cloud certifications carry weight in infrastructure and consulting roles and almost none in product engineering.

Leave these off

  • Skill bars and percentage ratingsNobody is 80% at Python, and the reviewer is an engineer who will notice. Bars also carry no text for a parser to read.
  • Interests and hobbiesCosts you three lines of page-one attention. Keep one short line only if it is genuinely relevant — mechanical keyboards and marathon running are not.
  • A photograph, date of birth and marital statusStandard on a CV in parts of Europe and North Africa, unusual in UK tech and actively unwelcome in the US. If you are applying across markets, leave them off.
  • Every tutorial project you have ever completedA to-do app and a clone of an existing site read as filler and pull attention away from the work you were paid for.

Before and after

Three bullets rewritten

The same work, described twice. What changes is not the vocabulary but what the sentence is willing to commit to.

Rewrite 1

Weak bullet

Worked on the backend team using Java and Spring Boot to build APIs.

Rewritten

Owned the payments API (Java, Spring Boot) serving around 4M requests a day; cut p99 latency from 850 ms to 210 ms by replacing a per-request currency lookup with an in-process cache.

What changed: “Worked on” covers everything from designing the service to attending the stand-up; the rewrite keeps the stack but attaches it to a named system, a scale, and one specific change with a before and an after.

Rewrite 2

Weak bullet

Helped migrate our infrastructure to Kubernetes and improved deployments.

Rewritten

Led the migration of 14 services from EC2 to EKS over five months, writing the Helm chart conventions the other three teams adopted; deploy frequency went from weekly releases to around 30 a week and rollback time from 40 minutes to under two.

What changed: “Helped” has been replaced with the part that was actually yours, the migration now has a size and a duration, and the outcome is two operational numbers instead of the word “improved”.

Rewrite 3

Weak bullet

Mentored junior developers and participated in code reviews.

Rewritten

Ran onboarding for four new engineers and rewrote the review checklist after a post-incident review; median time-to-first-merged-PR for new starters dropped from nine days to three.

What changed: Mentoring is unverifiable as a claim, so the rewrite converts it into an artefact you produced and a team metric it moved — and names the incident that prompted it, which is how engineers describe real work.

Parsers and keywords

What a parser is likely matching for in software engineers

Screening behaviour differs from employer to employer, so treat this as a checklist of terms you have genuinely earned — not a list to paste in.

Most engineering applications pass through a parser before a human sees them, and for this job family the matching is unusually literal: the terms being searched are product names. A system looking for “Kubernetes” does not infer it from “container orchestration”, and one looking for “PostgreSQL” may not match “Postgres”.

The practical response is not keyword stuffing, which reads badly to the engineer who eventually opens the file. It is to write the technology names out properly in the skills section and then use them naturally in the bullets where you actually used them, so the term appears in context rather than in a list at the bottom.

How applicant tracking systems read a CV covers the mechanics in more detail, and the ATS-friendly templates are the layouts least likely to lose any of this.

Terms in this job family
Languages and runtimes
JavaPythonTypeScriptJavaScriptGoC#.NETNode.js
Frameworks and libraries
Spring BootReactDjangoRailsNext.jsFastAPI
Infrastructure and tooling
AWSAzureGCPDockerKubernetesTerraformCI/CDGitHub Actions
Data and messaging
PostgreSQLMySQLRedisKafkaElasticsearchDynamoDB
Practice terms
RESTgRPCmicroservicesevent-drivenunit testingcode reviewon-call

No layout and no wording can guarantee a pass: systems differ, and many engineering teams sift manually anyway. What you can control is that the file is plain text under the surface, the terms are spelled the way the advert spells them, and nothing important is trapped in a graphic.

Avoid these

Mistakes specific to software engineers

Not the generic list. These are the failures that recur in this field in particular, and that a reader in it will notice immediately.

The stack soup

Thirty technologies in one comma-separated block, some of which you touched once in 2019. It reads as either padding or an inability to prioritise, and it dilutes the four things you are genuinely strong in. Group them and be honest about depth.

Team achievements in the first person plural

A CV written as “we” gives a reviewer nothing to hire. It is fine — expected, even — to say the team shipped something, as long as the next clause says which part was yours.

A GitHub link to a neglected profile

An empty profile is not a negative; nobody assumes proprietary work can be published. A linked profile whose top repositories are an abandoned tutorial and a four-year-old fork is worse than no link at all.

A two-column layout that splits the stack

Sidebar designs look tidy and can be reordered badly by a parser, which is how a skills column ends up interleaved with your job history. In a field where the skills list is the filter, that is an expensive risk for a small aesthetic gain.

Seniority claimed by adjective

“Senior full-stack engineer with a proven track record of delivering high-quality solutions” is four seconds of nothing. Seniority shows through scope and consequence: what you owned, who depended on it, what happened when it broke.

Build order

How to write it, in 5 steps

Written in the order that wastes least time: gather the facts first, then shape them, then cut.
  1. 1

    Write the skills block first

    Open the advert next to the page and list, in groups, the languages, frameworks, infrastructure and data technologies you would be productive in on day one. Order the groups so the ones the advert leads with come first.

  2. 2

    Give every role a scale sentence

    For each job, write one line describing the system you owned and how big it was — requests, users, data volume, services, team size. This is the description line, not a bullet.

  3. 3

    Turn each responsibility into a change

    For every bullet you were about to write as a duty, ask what measurably differed afterwards. Latency, deploy frequency, error rate, cost, onboarding time. Keep the ones where you can name a before and an after.

  4. 4

    Cut the stack down to what you would defend

    Remove anything you would not want to be interviewed on. A shorter, honest list is stronger than a long one you have to hedge in the phone screen.

  5. 5

    Check it survives being turned into text

    Export the PDF, select all, and paste it into a plain text editor. If the reading order scrambles or your skills section lands in the middle of a job, change the layout before you send it anywhere.

Templates

3 templates that suit this role

Chosen for how this profession is actually read, not for how they look in a gallery. You can switch between any of them later without retyping a word.

Software Engineer

technology · one column

Free

Full Stack Developer

technology · two columns

Pro

Tech Minimal

technology · one column

Free
  • Software Engineer (one column, parsing score 5/5) — One column, ruled headings and the stack written as prose rather than as bars — the safest choice when you do not know whether the file is going into a parser, a PDF viewer or a print tray.
  • Full Stack Developer (two columns, parsing score 4/5) — Puts your stack across the top and splits employment from projects below it, which suits engineers whose open-source or side work is a real part of the case they are making.
  • Tech Minimal (one column, parsing score 5/5) — Type and space only, tightly set. Good for a long history that needs to stay on two pages, and impossible for a parser to misread.

US market

If you are applying for a US résumé instead

Applying to the US market changes the packaging rather than the substance. The document is called a resume, it is expected to be one page until roughly ten years in, and it is trimmed harder than a UK or EU CV.
  • Cut to one page by dropping older roles to a single line and removing the projects section unless it is doing real work.
  • Never include a photo, date of birth, nationality or marital status — US employers routinely discard resumes carrying them for legal reasons.
  • GPA is worth including for the first two or three years after graduating and is normally dropped after that; degree classification means nothing to a US reader, so translate or omit it.
  • Use US spellings in the technology names where they differ, and quantify in the currency of the company you are applying to.

One document, two versions

The advice above is the same profession, not a different one — which is why there is no separate résumé guide for this role. Keep one document, switch the paper size to US Letter, trim to a page and remove anything personal.

US résumé conventionsOne-page résumé templates

Software engineer CVs: common questions

The questions that come up repeatedly in this field, answered without hedging.

Directly under the summary, above your employment history. It is the section the first reader is filtering on, and burying it below two pages of jobs means a recruiter working through a stack of applications may never reach it. The exception is a very senior CV — staff, principal or engineering management — where scope and impact are the filter and the skills list can sit lower.

Related guides

Write your software engineer CV tonight

Open the editor with one of the templates above, work through the five steps, and download a PDF when it reads the way you want. Switching template later keeps every word.

Start — freeRead the worked example

Free plan includes the editor and PDF download.