Most software engineer resumes fail for one reason: they describe responsibilities instead of outcomes. "Worked on backend services" is a responsibility. "Reduced p99 API latency from 800ms to 90ms on 50M daily requests by migrating from synchronous polling to an event-driven architecture" is an outcome. Recruiters at tech companies read hundreds of resumes a week; outcomes with numbers stop the scroll.
What a software engineer resume must do
A strong senior engineer resume answers three questions before a recruiter reads past the first third of the page:
- What technical problems have you actually solved? Not what technologies you've used - what you built, at what scale, with what measurable result.
- What's your technical scope? Systems design, infrastructure, full-stack, backend, ML - specific enough that the recruiter can match you to the right team.
- Does your experience map to what this role requires? The terminology you use signals whether you'd fit without a translation layer.
If a recruiter can't answer all three in 15 seconds, the resume isn't working.
Format: what works for engineers
One column, reverse chronological. Two-column layouts with a sidebar for skills break ATS parsing. Reverse chronological work experience is the standard; exceptions (functional or skills-first formats) read as attempts to obscure employment gaps and are penalized by experienced technical recruiters.
Length: 1 page for 0–5 years of experience. 2 pages for 5–15 years. Never 3 pages. If you have 15+ years, your recent 8–10 years matters most - earlier roles can be listed without bullets.
Sections in order:
- Header (name, email, phone, LinkedIn, GitHub if active, city/remote)
- Summary (2–3 sentences, optional but useful at senior levels)
- Skills
- Work Experience
- Education
- Certifications (if relevant)
Side projects, open source, and publications go at the bottom unless they're directly relevant to the role.
The skills section: how to do it right
List skills as plain text, not as bar charts or visual proficiency meters. Bar charts don't render in most ATS systems and convey no real information to human reviewers.
Useful structure:
Languages: Python, Go, TypeScript, Rust
Frameworks: FastAPI, Node.js, React, gRPC
Infrastructure: Kubernetes, AWS (EKS, RDS, S3, Lambda), Terraform, Datadog
Databases: PostgreSQL, Redis, Kafka, Elasticsearch
Practices: Distributed systems, event-driven architecture, system design, CI/CD
Order your primary languages and frameworks first - recruiters and ATS systems both weight the beginning of the skills list higher. Per-job tailoring means moving the skills that appear in the JD's requirements to the top of each category for that application. For the full ATS optimization approach, see how to write an ATS resume that gets past the filter.
Work experience bullets: the only format that works
Pattern: [strong verb] + [what you built/owned] + [at what scale or constraint] + [measurable result]
The verb must be active and specific:
- Led, Designed, Architected, Built, Migrated, Reduced, Increased, Shipped, Refactored, Automated
The "what" must name the actual technology or system:
- "the event-driven pipeline" → which technologies, which problem
- "Kafka-based event pipeline replacing a polling-based queue"
The scale or constraint gives context:
- "handling 12M daily events"
- "with a 3-person backend team"
- "under a 48-hour production incident window"
The result must be measurable:
- latency numbers, throughput, cost, error rate, deployment frequency, time-to-market
What this looks like:
❌ "Worked on improving system performance and reliability"
✅ "Led re-architecture of the order processing pipeline from a monolithic queue to a partitioned Kafka topology, reducing p99 latency from 4s to 180ms on 8M daily events"
❌ "Responsible for backend development and infrastructure"
✅ "Designed and maintained Kubernetes-based microservices infrastructure (12 services, AWS EKS) serving 2M monthly active users; reduced deploy-to-production cycle from 2 days to 40 minutes"
Three to five bullets per role is the right count. More than five dilutes the signal.
Recruiter perspective
According to Stack Overflow's Developer Survey 2024, 62% of developers who changed jobs in the past year said that the quality of their application materials - specifically resume clarity and technical specificity - was the primary factor in getting to a first interview, above both personal connections and years of experience.
— Stack Overflow's Developer Survey 2024
Summary section: when it's worth including
At senior and staff+ levels, a 2–3 sentence summary at the top of the resume gives the reader an immediate frame:
"Senior backend engineer with 8 years building distributed systems at scale (Kafka, Kubernetes, AWS). Most recent work: platform infrastructure serving 50M daily events at a Series C fintech. Open to staff-level roles in platform engineering or infrastructure."
What this does: establishes level, primary technical identity, most recent context, and what you're looking for - in three sentences. A recruiter reading a stack of resumes knows immediately whether to keep reading.
Skip the summary if it reads as a list of adjectives ("results-driven engineer with a passion for code quality"). That's the version that belongs in the trash.
How to handle the GitHub / portfolio question
For most senior engineering roles, a GitHub link on your resume is a weak signal unless you have public contributions that are directly relevant to the role. Recruiters don't regularly review GitHub profiles as part of initial screening; they do when the role is specifically about open source or when they need to verify technical depth for a staff+ hire.
Include GitHub if you have:
- Significant open source contributions to projects the company uses or cares about
- A well-maintained project that demonstrates the exact skills the role requires
- A track record of code that demonstrates craft - not just quantity
Otherwise, it's a line that takes up space without adding signal.
Cover letters and tailored resumes: the paired workflow
A strong resume establishes the evidence; a cover letter frames the most relevant part of that evidence for this specific role. They work together, not as redundant documents. For software engineer roles specifically, see how to write a software engineer cover letter for the three-paragraph structure that works.
Key takeaways
Outcomes with numbers stop the recruiter's scroll; responsibilities don't
Describe what you built, at what scale, with what measurable result - not what your job involved. One strong bullet with a latency number or throughput metric is more credible than three bullets describing responsibilities.
Per-job tailoring changes ATS performance and human first-impression simultaneously
A resume that uses the JD's terminology for your most relevant experience performs better in ATS filtering and reads as more relevant to the human reviewer. It's the same experience described in a different vocabulary - not fabrication, just translation.
Senior engineers should lead with systems, not tools
A list of technologies is entry-level framing. Senior engineers are hired for judgment about systems design, architecture decisions, and engineering at scale. The resume should lead with what you designed and owned - the technologies are evidence, not the claim.
Frequently asked questions
How long should a software engineer resume be?
One page for 0–5 years. Two pages for 5–15 years. Never three pages unless you're a distinguished researcher or executive. More length doesn't signal more experience - it signals poor editing. The first page is what recruiters read; everything on page 2 must justify its existence.
Should I include all my programming languages?
Include the languages you'd use on day one without needing a refresher, and that appear in the roles you're targeting. A language you used once in college in 2015 is noise, not signal. If you're applying for a Go-heavy role and Go is buried at the bottom of your languages list, move it up for that application.
Do I need a summary section?
No - but it helps at senior levels. The summary is useful if your most recent job title doesn't clearly establish your level or domain, or if you're making a transition (e.g., from IC to engineering manager). For straightforward career progressions, the work experience section alone tells the story.
How should I list side projects?
Put projects that demonstrate relevant skills in a "Projects" section after work experience. Include: what it does, what tech stack it uses, and one measurable signal (users, stars, throughput). Skip projects that are tutorials or boilerplate. "Built a CRUD app with React and Node" is not a signal; "Designed and deployed a distributed task queue processing 1M jobs/day, open-sourced with 400+ GitHub stars" is.
Should I include non-engineering jobs from earlier in my career?
For 5+ years of experience: typically no. Keep the last 8–10 years of engineering experience. If earlier non-engineering work is directly relevant (e.g., domain expertise for a fintech role), include a one-line entry. Otherwise, recruiters are evaluating engineering depth, not career history breadth.
Bottom line
- Lead with outcomes, not responsibilities - action verb + what you built + scale + measurable result
- One-column layout, reverse chronological, 1–2 pages depending on experience level
- Skills section as plain text, ordered with most relevant technologies for this role first
- Per-job tailored version mirrors the JD's terminology for your most relevant experience
- Summary section is optional but useful at senior+ levels to establish frame immediately
Find senior tech roles and see your match before applying: hire.monster/jobs.