How to write a software engineer resume

What belongs on the first half page

Reviewers read in a predictable order: your current title, your most recent employer, and the technologies you name. Everything else is read only if those three survive the first pass.

So lead with them. A two-line summary naming your discipline, your years in it, and the stack you work in does more than a paragraph about being passionate about technology. Then experience in reverse order, then skills, then education.

Education moves up only if you graduated within the last year or two. After that it is the least predictive thing on the page and it should not be occupying the top of it.

Name technologies the way the industry does

Filters match on terms, and terms have conventional spellings. Write PostgreSQL rather than Postgres SQL, Node.js rather than NodeJS, and CI/CD rather than continuous integration if the postings you want say CI/CD. This is not pedantry; it is the difference between appearing in a search and not.

Name versions and surrounding tools only where they carry information. React 18 says nothing that React does not. Kubernetes with Helm and Argo CD says something specific about how you deploy.

Resist listing everything you have touched. A skills section with sixty entries tells a reviewer you cannot judge your own depth, and it dilutes the terms that matter. Fifteen you could be interviewed on is stronger than sixty you have met.

Write bullets about outcomes, not duties

The most common failure in engineering resumes is describing the job rather than the work. Responsible for maintaining the payments service tells a reviewer nothing they could not have guessed from the title.

A good bullet names what you did, what changed, and ideally by how much. Numbers do not have to be revenue; latency, build times, error rates, deployment frequency, test coverage and the number of engineers affected are all measurable and all meaningful to the person reading.

• Weak: Responsible for the front-end codebase and improving performance.
• Better: Cut Largest Contentful Paint from 4.1s to 1.6s across the dashboard by code-splitting the editor and deferring analytics.
• Weak: Worked on migrating services to Kubernetes.
• Better: Migrated eleven services from EC2 to Kubernetes with no customer-visible downtime, cutting deploy time from forty minutes to four.

Projects, open source and the no-experience case

If your commercial experience is thin, substantial projects belong in the same section as work rather than in a footnote. What makes a project count is that it was finished, used by someone other than you, and that you can describe a decision you made and why.

Link to the code, and make sure the link goes somewhere a reviewer can understand in a minute. A repository with a readme explaining the problem is worth more than three with none. Open-source contributions are strong evidence precisely because they are externally verifiable.

The habits that make reviewers stop reading

Engineering reviewers are fast and unforgiving, and the same handful of things end a read early.

• Skill bars and star ratings, which assert a level nobody can verify and most reviewers distrust.
• A two-column layout that a parser scrambles before a human ever sees it.
• Three pages for five years of experience, which reads as an inability to prioritise.
• The same four bullets repeated under every role, which suggests nothing changed across your career.
• Buzzwords with no object: synergy, leveraged cutting-edge solutions, passionate about innovation.