A strong software engineer resume reads like a changelog of impact, not a list of responsibilities. Each experience bullet names what you built, the technology you built it with, and the measurable result — latency cut, scale handled, cost saved, revenue moved. Recruiters and engineering hiring managers skim for that signal in seconds, and an ATS scans the same document for the exact stack keywords in the job description. Get both right and you clear the two filters that reject most candidates: keyword parsing and the six-second human skim. One page for under ten years of experience, two pages above that, single column, no graphics.
What separates a good SWE resume from a forgettable one
Most engineering resumes fail in the same boring way: they describe what the person was assigned, not what they accomplished. "Responsible for backend services," "Worked on the payments team," "Participated in code reviews." All technically true, all invisible. The reviewer — a recruiter first, then an engineering manager — is scanning for evidence that you can ship things that matter. Responsibilities don't show that. Outcomes do.
The fix is mechanical. Every experience bullet should answer three questions: what did you build, what did you build it with, and what happened as a result? "Built X using Y, which produced Z." When you can put a number on Z — milliseconds, requests per second, dollars, percentage points — the bullet stops sounding like a job description and starts sounding like a track record.
Rewrite your bullets for impact
Here is the single highest-leverage change you can make. Same work, same person — only the framing changes, and the second version is the one that gets an interview.
Responsible for backend services and APIs in Python.
Rebuilt the order-fulfillment API in Python (FastAPI), cutting p99 latency from 850ms to 140ms and absorbing a 3x traffic increase during peak season with no added instances.
Added the framework, a real metric, and the scale it held under.
Worked on migrating the database for better performance.
Led the migration from a single Postgres instance to a sharded cluster across 8 nodes, raising sustained write throughput from ~4k to ~22k TPS and eliminating the nightly replication lag that had caused 3 prior incidents.
Scope (led), concrete before/after numbers, and the incident pain it removed.
Improved CI/CD pipeline and reduced build times.
Reworked the CI pipeline (GitHub Actions, parallelized test sharding, layer caching), dropping median build time from 22 to 6 minutes and saving ~40 engineer-hours of waiting per week across a team of 30.
Quantified the speedup and translated it into time saved for the org.
Helped reduce cloud costs.
Identified and right-sized over-provisioned EKS workloads and moved batch jobs to Spot instances, cutting monthly AWS spend by $14k (31%) with no SLO regressions.
A dollar figure plus the guardrail (no SLO regressions) that proves it was done well.
Send the right tech-stack signal
Engineering hiring is stack-sensitive in a way most fields aren't. A backend role on Go and Kubernetes wants to see Go and Kubernetes — not "proficient in modern backend technologies." Two rules:
- Keep a plain-text Technical Skills section near the top. Group it lightly (Languages, Frameworks, Infrastructure, Data) and write the actual names: Go, TypeScript, Python; React, gRPC; Kubernetes, Terraform, AWS; PostgreSQL, Kafka, Redis. This is what the ATS reads, so use the same spellings the job description uses — "PostgreSQL" if they wrote PostgreSQL, "CI/CD" if they wrote CI/CD.
- Prove the stack inside your bullets. A skill listed in a section is a claim; the same skill named in an impact bullet ("sharded the Postgres cluster," "wrote the Terraform modules") is evidence. List broadly, but make sure the technologies that matter for the target role appear in your actual accomplishments too.
Resist the urge to list everything you've ever touched. A skills section with 40 technologies reads as noise and invites questions you can't answer. List what you can defend in a whiteboard conversation, weighted toward the role you're applying for.
Projects vs. experience, by level
The ratio of personal projects to professional experience should shift as you advance. Early on, a strong side project is legitimate evidence you can build. By senior level, side projects compete for space against shipped production work — and production work wins. What a reviewer is looking for changes at each rung:
| Level | Typical titles | What reviewers look for | Projects vs. experience |
|---|---|---|---|
| Entry / Junior | SWE I, Junior Engineer, New Grad | Can you write clean code and ship a feature end to end? Foundations: data structures, a language, a framework, basic testing. | Projects carry real weight. A polished GitHub or a deployed app can substitute for thin work history. |
| Mid | SWE II, Software Engineer | Consistent execution with limited hand-holding. You own features, debug production issues, and your code holds up under review. | Experience leads; one strong project is fine as supporting evidence. Tutorial clones add nothing. |
| Senior | Senior SWE, SWE III | Ownership and judgment. You design systems, mentor, make tradeoffs, and your work has measurable blast radius across a service or team. | Production work dominates. Side projects are mostly noise unless they’re genuinely impressive or directly relevant. |
| Staff+ | Staff, Senior Staff, Principal | Cross-team and organizational impact. You drive technical direction, resolve ambiguity, and influence beyond your immediate team. | Experience only. The resume should read as a series of organization-level outcomes, not features. |
Layout and the ATS
None of the above matters if the parser can't read your file. Applicant tracking systems read top-to-bottom, left-to-right, and they choke on the things designers love. Per Jobscan's breakdown of how ATS platforms parse resumes, the reliable choices are boring on purpose:
- Single column. Two-column layouts with a skills sidebar frequently lose the sidebar entirely — the parser reads across and scrambles the order.
- No tables, text boxes, or graphics. Skill bars, rating dots, and logos are invisible to the parser. Plain text only.
- Text-selectable PDF. Export so every line can be selected and copied. Open your PDF, try to select your name and a bullet — if you can't, neither can the ATS.
- Standard section headings. "Experience," "Education," "Technical Skills," "Projects." Clever headings ("Where I've Made Dents") confuse the field mapping.
The summary line (optional, and short)
A two-line summary at the top can help by front-loading your level, primary stack, and a headline result. "Senior backend engineer, 7 years building distributed systems in Go and Kubernetes; scaled a payments platform from 5k to 500k req/min." Skip the objective statement — "seeking a challenging role where I can grow" wastes the most valuable real estate on the page and tells the reader nothing.
The honest summary
A great software engineer resume is one page (until you've earned a second), single column, and parseable; it names the real stack in the recruiter's vocabulary; and every bullet pairs a technology with a measurable outcome. Match the framing to the level you're targeting, prove your strongest stack inside your accomplishments, and cut anything you couldn't defend in an interview. For overall career trajectory and demand context, the BLS Occupational Outlook for software developers is a useful baseline. Do this well on a handful of well-matched roles and your response rate climbs sharply — the resume stops being a filter and starts being an asset.
Common questions
- Should a software engineer resume be one page or two?
- One page if you have under about ten years of experience — that covers everyone through senior at most companies. Go to two only when you genuinely have more relevant, recent material than fits, and never pad to reach a second page. Staff and principal engineers with a long track record can justify two; an SWE II almost never can.
- Do I need a GitHub or portfolio link on my resume?
- Link it only if it helps you. A GitHub with real, readable projects (a few repos with commits, a README, and tests) is a strong signal early in your career or when switching stacks. A GitHub that is empty or full of tutorial forks hurts you — leave it off. For most senior engineers, shipped work at named companies matters more than side projects.
- How many bullets should each job have?
- Three to five for your current and most recent role, dropping to two or three for older jobs. Lead with your highest-impact work. Roles from more than ten years ago can collapse to a single line or a "Earlier experience" summary — nobody is interviewing you on a job you held in 2012.
- Where do I put my tech stack so an ATS finds it?
- In a dedicated, single-column "Technical Skills" section near the top, written as plain comma-separated text — not a graphic, not a skills bar, not a sidebar. Then repeat the few technologies that matter most inside your experience bullets, since that is where the stack reads as real rather than aspirational.
Sources
Keep reading
What does an ATS-friendly resume look like?
An ATS-friendly resume is single-column and plain-text, with standard headings, readable dates, and no tables or graphics. Here is the exact anatomy.
How long should a resume be?
Most resumes should be one page; two pages once you have ~10+ years of relevant experience. The real rule: every line has to earn its place.
Why is my resume getting rejected by ATS?
ATS rejection has two causes: parse failures from bad formatting and keyword gaps against the job description. Here is how to diagnose and fix yours.
Why do software engineer resumes get rejected?
Most software engineer resumes are rejected before a human reads them — keyword mismatch, weak bullets, wrong-level targeting, and unparseable layouts.