Software engineer resume example and wording that survives parsing
Engineering resumes fail for two reasons: the projects section reads like a changelog, and the stack is scattered across headers the parser cannot follow. This example fixes both.
A summary that carries a number
Backend engineer with five years building payment and scheduling services in TypeScript and Go. Reduced p95 latency on the checkout API from 900 ms to 240 ms by replacing per-request pricing lookups with a cached rules table.
Replace every figure with your own. If you never tracked the metric, use the scale you can defend — team size, volume per shift, contract size, or how long the situation lasted.
Keywords a software engineer search looks for
- TypeScript
- Node.js
- React
- PostgreSQL
- REST API
- Docker
- AWS
- CI/CD
- unit testing
- system design
Use the ones that are true of your work, spelled the way the posting spells them. Skills belong in a plain list with one item per entry — icon rows and rating bars frequently extract as a single unreadable string.
Five bullets to adapt
- Rebuilt the invoice service as three idempotent endpoints, cutting duplicate charges to under one per 100,000 attempts.
- Moved the nightly reconciliation job from cron to a queue with retries, so a failed batch no longer blocks the next day.
- Added contract tests around the partner API, catching breaking schema changes before release instead of after a support ticket.
- Cut median page load on the customer dashboard from 4.1 s to 1.6 s by paginating a single oversized query and memoizing the summary call.
- Documented the deploy runbook; new engineers ship to production in their first week without a pairing session.
Skills section
TypeScript · Node.js · Go · React · PostgreSQL · Redis · Docker · GitHub Actions · Playwright · AWS
Name the system, then the change
Each bullet should contain a system (invoice service, partner API, dashboard) and a change (rebuilt, moved, cut). Reviewers who skim for ten seconds get both facts. "Responsible for backend development" contains neither and reads as filler to a human and to a keyword matcher.
Put the stack where a parser expects it
Keep languages and frameworks in a plain "Skills" list with one item per entry. Skill badges, icon rows, and two-column tables look sharp but frequently extract as one unbroken string — a parser searching for "PostgreSQL" cannot find it inside "TypeScript Node.js React PostgreSQL".
Projects without a company
Self-taught engineers and career switchers need one project section with the same shape as a job: name, one line of what it does, the stack, and one measurable outcome. A repository link is worth keeping if the README explains the tradeoffs; a bare clone of a tutorial is not.
Questions about this page
- Should a software engineer resume be one page?
- Under about eight years of experience, one page keeps the reader inside the first screen. Beyond that, a second page is acceptable when it holds real scope — team size, systems owned, or cross-team work — not a longer list of the same framework.
- Do side projects belong on an engineering resume?
- Yes when they prove something the job history cannot: an unfamiliar language, a production concern such as caching, or ownership end to end. Keep each project to three lines and always state the outcome.
- How many keywords should the skills section hold?
- Roughly ten to fifteen that you can defend in an interview. A list of forty tools dilutes the ones the posting actually asks for and invites questions you cannot answer.