Software Engineer resume example
A software engineer resume example built to survive both a keyword filter and a six-second skim, with a full breakdown of why each line is written the way it is. Free to copy into an editor and download as PDF.
Mid-level, 4–7 years · Updated 2026-08-05
What this resume has to prove
A software engineer resume gets read twice by two readers who want opposite things. A recruiter, often non-technical, is checking whether your stack overlaps with the posting — that read takes seconds and is essentially a matching exercise. An engineer on the hiring team reads it later and is looking for the opposite of a keyword list: evidence that you have owned something difficult end to end. Write only for the first reader and you get screened in and then rejected; write only for the second and you never reach them.
The example below tries to satisfy both by putting the stack somewhere scannable and keeping the bullets about consequences. Notice that no bullet is a description of a technology. Every one names a change and what happened because of it, with the technology mentioned in passing as the means. That is the format that survives both readers, because the recruiter still finds 'Go' and 'Kubernetes' on the page while the engineer gets something to ask about in the phone screen.
One structural note: Experience comes before Education here, and Education is two lines with no coursework. That is correct at four to seven years and wrong at zero — a new graduate should invert it. If you are early in your career, the projects section is where the substance goes, and it should be longer than the one entry shown here.
The decisions worth copying
The summary states scope, not adjectives
Backend engineer, 6 years, mostly on payments and other systems where being wrong is expensive.
Almost every engineering summary opens with 'passionate' or 'results-driven', which tells a reader nothing and is indistinguishable from every other resume in the stack. This one gives three facts — discipline, years, problem domain — and one sentence of attitude that is actually a claim about the kind of work. A reader who wants a payments engineer knows in one line. A reader who does not has been saved a minute, which is a favour to both of you.
Numbers are attached to the decision, not sprinkled on top
Cut p99 checkout latency from 1.9s to 340ms by replacing a synchronous fan-out with a queue.
The common advice to 'quantify everything' produces bullets like 'improved performance by 82%', which invites the question 82% of what. Naming the metric, both endpoints of the change, and the mechanism makes the claim checkable, and a checkable claim reads as true. It also gives the interviewer an obvious question to ask, which means you get to talk about work you actually did rather than answering something you prepared for.
The skills section is grouped and short
Twenty-line skill dumps that include 'Microsoft Word' and 'Agile' hurt you: they dilute the terms that matter and signal that you cannot judge relevance. Three or four labelled groups is enough. Put the languages you would be comfortable being interviewed in, not every language you have compiled once — the interview will find the difference and it is a bad way for it to be found.
Vocabulary that belongs on a software engineer resume
Take the terms that are true of you and put them where they belong in your own sentences. Pasting a keyword block at the bottom of a resume is visible to a human and does nothing a parser rewards. Check yours against a specific posting rather than against a generic list.
- Terms most backend postings actually contain
- distributed systemsREST APImicroservicesCI/CDcode reviewon-callobservabilitydatabase schema designunit and integration testing
- Stack, only if it is true of you
- GoPythonTypeScriptPostgreSQLKubernetesAWSTerraformKafkaRedis
- Scope words that separate mid-level from junior
- owneddesignedled the migrationmentoredwrote the design docincident response
Where these resumes usually go wrong
Listing every technology you have ever touched
A parser will match on all of them, so it feels free. It is not: a human decides whether to call you, and a skills list with 40 entries reads as either padding or a lack of depth. Worse, it makes the interviewer's job easy in the wrong way — anything on that list is fair game, and being caught out on a framework you used for a week in 2022 is a genuinely bad outcome for a line you did not need.
GitHub link to an empty or abandoned profile
A link is a promise that there is something at the other end. If your public repos are three forks and a tutorial from four years ago, the link is worse than no link, because someone will click it. Either link to something you would present, or leave it off and let the work history carry the resume.
Describing team results as if they were yours
'Scaled the platform to 10 million users' is a company fact, not a personal one, and experienced interviewers probe it immediately. Name your part of it. 'Owned the sharding migration that let the platform pass 10M users' is smaller on the page and much larger in the interview, because you can defend every word.
Opening this in the editor replaces the placeholder content with fields you can type over. Nothing is uploaded and there is no account — the draft stays in this browser, and the PDF downloads free.