Engineering managers do not read resumes for potential. They read for evidence of shipped work: what you built, the constraints you handled, and whether the numbers suggest you understand the system you touched. A resume full of technologies and no outcomes reads as a list of things you have been near.
Here is how a strong software engineering resume is put together, with examples you can adapt.
The header and title
Name, city, email, phone, GitHub or portfolio. Then the target title: "Software Engineer — Backend" or "Senior Frontend Engineer". Do not use "Ninja" or "Full Stack Rockstar"; the posting's title is the keyword the recruiter searches for.
The summary: scope plus stack plus result
Three lines that say what kind of engineer you are and what you have operated at scale.
Backend engineer with 6 years building Python services for high-volume marketplaces. Owned a payments platform processing 4M transactions/month at 99.98% availability. Led migration from monolith to event-driven services, cutting p95 latency from 850ms to 210ms.
Note what it does not do: it does not list every language you have touched. The stack appears in service of the result.
Experience bullets
Each bullet should contain four things: an action, the system or scope, the technical decision, and the measurable outcome. Order matters — put the outcome early so a skimming reader sees it before the implementation detail.
| Weak bullet | Strong bullet |
|---|---|
| Worked on microservices using Python and Kubernetes | Rebuilt checkout as three Python services on Kubernetes, reducing p95 latency 41% and enabling independent deploys for four teams |
| Improved application performance | Cut API response time from 1.2s to 180ms by replacing N+1 queries and adding Redis caching for the top 20 endpoints |
| Participated in code reviews | Led design reviews for a 12-engineer group; introduced ADR templates that reduced rework on two major integrations |
| Wrote tests | Raised coverage on the billing module from 34% to 87%, catching three production bugs before release |
Pick three to five bullets per role
If a role has more, choose by relevance to the target job. For each bullet, ask: would an interviewer want to ask me about this for ten minutes? If yes, it belongs. If it only proves you were present, it can go.
Keep the most recent role to five bullets, older roles to two or three. A 2014 support role does not need the same airtime as your current platform work.
The skills section: grouped and honest
Group by category and put the target stack first:
- Languages: Python, TypeScript, Go, SQL
- Frameworks: Django, FastAPI, React
- Infrastructure: AWS, Kubernetes, Terraform, GitHub Actions
- Data: PostgreSQL, Redis, Kafka
Leave out anything you could not discuss for five minutes. "Familiar with Rust" in a skills list is an invitation to be tested on it; if you want credit for a learning curve, put it in a project bullet instead.
Projects and open source
For newer engineers, projects carry the resume. Describe them the way you would describe a job: what it does, the stack, the users or scale, and the outcome. A project with 400 GitHub stars and no evidence of maintenance is less persuasive than a small tool with real users.
Common mistakes engineering managers notice
- A wall of technologies with no outcomes.
- Bullets that describe the team's work rather than yours ("we built...").
- Numbers that do not make sense (a 400% improvement with no baseline).
- Two-column layouts and graphic skill bars that break ATS parsing.
- A GitHub link that leads to an empty profile.
Checklist before you send
Every bullet starts with a verb, every recent role shows measurable impact, the stack in the skills section matches the bullets, and the file is a clean, single-column PDF. Run the ATS checker to catch structure and keyword gaps, then read it as an engineer: would you interview this person for your own team?
Pick a clean, ATS-safe layout and open it straight in the builder.