A software engineer resume has 2 readers who want opposite things.
On this page
The parser wants boring structure: 1 column, standard headings, selectable text.
The human gives it 20 seconds and wants evidence with numbers in it.
Write for both. Keep the layout dull and put a measured outcome in every bullet.
Most engineers optimise for a third reader who does not exist: someone with time.
I have screened hundreds of resumes as a hiring manager at Zalando. I hired more than 10 engineers from them.
Here is what actually survives both passes.
What is each reader actually doing?
The parser extracts fields and fails on 2-column layouts, images and tables.
The human spends 20 seconds on one question. Is this person plausibly at the level we are hiring for?
Everything else on the page waits for a second pass that may never happen.
The parser wants name, contact, companies, dates, titles, skills.
When it fails, a human may still read you, or may never see you.
The outcome depends on how the company filters.
The human looks at your most recent role and your company. Then 2 or 3 bullet points.
What software engineer resume structure works?
One column, in this order. Name and contact, then an optional 3-line summary.
Experience comes next, newest first, then skills, then education.
No photo, no skill bars, no competencies cloud, no dates in a sidebar.
Two pages is fine after about 8 years and 1 page is fine before that.
- Name, 1 line of contact, location, and a link to LinkedIn or GitHub.
- A 3-line summary. Only if it says something specific.
- Experience, newest first.
- Skills.
- Education.
- Anything else, if it earns the space.
Nobody has ever rejected a good engineer for a second page.
Plenty have been rejected for cramming 8 years into one.
Does a software engineer resume need a summary?
Only if you can make it specific in 3 lines. It exists to state your level, your domain and what you want.
If you cannot write 3 specific lines, skip it.
An empty summary costs nothing. A generic one costs you the first 4 seconds of a 20-second read.
Bad, and typical:
Passionate software engineer with a proven track record of delivering high-quality solutions in fast-paced environments.
The passionate-engineer summary describes nobody. Delete it and the page gets better.
Better:
Backend engineer, 8 years, mostly Python and Go on payment systems. Currently leading a team of 4 at a European marketplace. Looking for a staff-level IC role in Berlin or fully remote.
Level, domain, scale, and what you want. A hiring manager can route that in 4 seconds.
The experience section is the whole resume
Each role gets 1 line of context and then 3 to 5 bullets.
The context line matters more than people think. “Zalando, Berlin. Deputy Engineering Manager, 2021 to now.
AdTech, team of 5, 27 markets.” Now every bullet underneath has a scale attached to it.
The bullet formula
Every bullet needs 3 things: what you did, what changed, and a number.
Most engineers write only the first.
Writing only the task produces a job description.
A job description lists what your role was. The reader still cannot tell if you were good.
Weak: Responsible for improving the CI pipeline.
Better: Removed 100 flaky tests from the CI suite.
Right: Removed 100 flaky tests and raised coverage from 60% to 70%. Deploys went from 4 a week to more than 10.
The last one is the same work described 3 levels deeper.
The deeper version took 30 extra seconds to write. That is the difference between a screen and a rejection.
Where to find your numbers
Engineers tell me they do not have numbers. They almost always do, they just have not looked.
- Time: how long did something take before and after?
- Money: cost saved, revenue enabled, a contract renegotiated.
- Volume: requests, users, markets, videos, records, deploys.
- Quality: incidents, bugs, coverage, p99 latency.
- People: how many did you hire, mentor, or lead?
If the exact number is not yours to share, use a ratio. Or an order of magnitude.
“Cut the provider cost by roughly a third” works.
“Improved cost efficiency” says nothing.
The verb matters
Start with what you did, not with your relationship to it.
Delete these openers: responsible for, worked on, helped with, involved in, participated in, assisted.
Use these: built, designed, migrated, removed, reduced, automated, hired, led, negotiated, shipped, replaced.
The second list makes claims. The first list avoids them, and a reader notices avoidance.
How should you list skills?
Group them and be honest about depth.
A flat list of everything you have ever touched reads as noise. The human skips it.
Four groups is usually enough: languages, backend, cloud, and whatever your speciality is.
Leave out anything you would not want to be interviewed on. Every line is an invitation.
Languages Python, Go, TypeScript, PHP
Backend Django, Node, PostgreSQL, Kafka
Cloud AWS, GCP, Docker, Kubernetes, Terraform
AI OpenAI API, LLM integrations, MCP, agent pipelinesWhat does an ATS actually break on?
Six things, and all of them are layout.
Two columns, text inside images or icons, or tables used for layout.
Unusual section headings, or contact details in a header or footer.
PDFs exported as vector outlines break it too.
Open your own PDF and try to select a line. If you cannot, neither can the parser.
- 2 columns. The parser reads across, and your job titles end up interleaved with your skills.
- Text in images or icons. Invisible to the parser. Your email disappears.
- Tables for layout. Same problem as columns.
- Unusual headings. “My Journey” instead of “Experience” means the parser finds no experience section.
- Headers and footers. Many parsers skip them entirely, so contact details there vanish.
- PDF exported from a design tool. Some export text as vector outlines.
Send a PDF unless asked otherwise. Check it by opening it and selecting the text.
Should you match keywords from the job ad?
Match the language of the job ad where it is honest.
If they say “distributed systems” and you say “large-scale backend”, use their phrase too. Do not stuff.
White text, keyword blocks and invisible lists get detected. When a human finds one you are finished.
The purpose is to be findable.
The 20-second software engineer resume test
Give your resume to someone outside your team for 20 seconds, then take it away.
Ask the reader 3 questions. What level am I? What do I work on? What is the most impressive thing on the page?
If they cannot answer all 3, the page is not doing its job.
No amount of formatting will fix that.
Common questions
How long should a software engineer resume be?
One page under 8 years of experience, 2 pages after that. Nobody has ever rejected a good engineer for a second page. Plenty have been rejected for cramming 8 years onto one. A third page only earns its place for publications, patents or a long consulting history.
Should you tailor your resume for every application?
Tailor the summary and the top 3 bullets, leave the rest alone. That takes 10 minutes and covers most of the benefit. Rewriting the whole document per application takes an hour and buys almost nothing. The reader only reaches the older roles on the second pass.
What do you do about an employment gap?
Put it on the page with 1 line of explanation and move on. Parental leave, illness, study, a failed startup, a layoff. A stated gap costs almost nothing. An unexplained gap makes a screener guess. Screeners guess badly when they have 20 seconds.
Do you need a portfolio or GitHub link?
Link it only if it holds something you want read. An empty GitHub with 3 tutorial forks is worse than no link. A screener who clicks it comes back with a lower opinion. One real project with a readme that explains the decisions beats 20 repositories with none.
What is an ATS resume?
An ATS resume is one a parser can read. Single column, real text, standard section headings, no tables and no images. That is the whole requirement. There is no ATS score to optimise for. Broken formatting removes you before a human reads a word.
The short version
1 column, standard headings, PDF with selectable text. A 3-line summary only if it is specific. Every bullet gets a number.
Verbs that make claims. Skills grouped and honest.
Hand the page to a stranger for 20 seconds. See what they can tell you.
I do this professionally. A written review of your resume and LinkedIn, plus a 60-minute call.
The review is 200 euro, and the report lands within 48 hours.
The next post lists 11 resume lines that get people screened out.