Resume Tips for Software Engineer Roles: Complete 2026 Guide

TL;DR

• A software engineer resume that converts to phone screens is one page, five sections (header, experience, projects, education, skills), with at least one number in every bullet.
• Each bullet must answer three questions: what you did (specific action verb), how you did it (technology and scale), and what was the impact (latency, RPS, dollars saved, retention lift).
• Tailor lightly for FAANG and heavily for your dream company, upload as PDF for ATS, and rewrite weak bullets like 'worked on backend services' into specific ones like 'built a Go-based rate limiter handling 15K RPS that cut on-call pages from 40/week to 6/week.'

Introduction

Your resume buys you 30 to 60 seconds of a recruiter's attention. The ones that convert to phone screens share a specific shape: one page, numbers in every bullet, keywords that match the job posting, and a projects section that proves you ship. This guide is the complete 2026 playbook for SWE resumes at FAANG, top-tier startups, and hedge funds.

Table of Contents

• The One-Page Rule (Almost Always)
• The 5-Section Layout
• The Golden Rule for Every Bullet
• Action Verbs That Work
• Quantification: The Numbers That Count
• Tech Stack Section
• Projects Section for New Grads
• ATS and Keyword Optimization
• FAANG-Specific Format Preferences
• Before and After: 8 Real Bullet Rewrites
• Common Resume Mistakes
• FAQ
• Conclusion

The One-Page Rule (Almost Always)

One page for new grads: non-negotiable.

One page for 1 to 7 years of experience: strongly recommended.

One page for 8 to 15 years: still ideal, though two pages acceptable if the second page is highly dense.

Beyond 15 years: two pages acceptable.

Why: recruiters skim. A second page costs you more attention than it buys you. The typical 2-page resume is 1 page of strong material and 1 page of filler. Cut the filler.

The 5-Section Layout

A strong SWE resume has exactly five sections, in this order:

1. Header. Name, phone, email, LinkedIn, GitHub, personal site. No full mailing address. No photo. No objective statement.
2. Experience. Reverse-chronological. Company, title, dates. 3 to 5 bullets per role.
3. Projects. For new grads: 2 to 4 projects. For experienced engineers: optional, or only 1 or 2 standout side projects.
4. Education. Degree, university, year. GPA only if 3.5+.
5. Skills. Languages, frameworks, cloud, databases. One line per category.

Omit everything else. No "summary". No "interests". No "references".

The Golden Rule for Every Bullet

Every bullet must answer three questions:

1. What did you do? (action verb, specific).
2. How did you do it? (technology, scale, method).
3. What was the impact? (number, business outcome, technical metric).

Bad: "Worked on backend services."

Good: "Built a Go-based rate limiter service using Redis, handling 15K RPS across 4 regions, reducing API abuse incidents by 87 percent and cutting the team's on-call pages from 40/week to 6/week."

One bullet. Three questions answered. This is the bar.

Action Verbs That Work

The opening verb of each bullet shapes the bullet's weight. Strong SWE verbs:

• Built / Designed / Architected — for new systems.
• Migrated / Refactored / Rewrote — for system changes.
• Scaled / Optimized — for performance work.
• Led / Drove / Owned — for cross-team ownership.
• Debugged / Diagnosed / Resolved — for incident response.
• Automated / Orchestrated — for tooling.
• Mentored / Coached — for people investment.

Avoid: "Helped", "Assisted", "Worked on", "Involved in", "Responsible for". All vague and low-signal.

Quantification: The Numbers That Count

Every bullet needs at least one number. Acceptable types:

• Performance metrics. Latency in ms, throughput in RPS, uptime percentage.
• Scale metrics. Users, requests, data size in GB or TB, transactions.
• Cost metrics. Dollars saved, infrastructure cost reduction, team hours saved.
• Quality metrics. Bug count, test coverage, incident count.
• Business metrics. Revenue impact, retention lift, signup conversion.
• Team metrics. People mentored, team size, cross-team engagement.

If you cannot quantify a bullet, either find the number in your work (ask a data engineer, check a dashboard, estimate reasonably) or cut the bullet. Unquantified bullets are weak signal.

Tech Stack Section

Keep it tight and honest. Format:

Languages: Go, Python, TypeScript, SQL Backend: gRPC, REST, Kafka, PostgreSQL, Redis Cloud / Infra: AWS (EKS, S3, DynamoDB), Terraform, Kubernetes Tooling: Grafana, Datadog, CI/CD (CircleCI)

Rules:

• Only list technologies you can pass a 30-minute discussion on. Recruiters cross-check.
• Group logically.
• Do not list HTML, CSS, Git, or anything too basic to be a signal.
• Order within each category: most used first.

Projects Section for New Grads

For candidates with fewer than 2 years of experience, the projects section is often MORE important than experience. Rules:

• 2 to 4 projects. No more.
• Each should have a one-line summary, the stack used, and a measurable result.
• Prefer shipped projects with real users.
• Prefer deep over broad. One complex project beats four simple CRUD apps.
• Link to the GitHub repo AND a live demo if possible.

Example:

Distributed URL Shortener — github.com/you/shortlink · short.ly Go, PostgreSQL, Redis, AWS Lambda. Handles 2K RPS on a $20/month infrastructure budget. Used by 400 weekly users; 99.98 percent uptime over 6 months. Wrote a blog post explaining the consistent-hashing cache strategy that got 12K views on Hacker News.

That one entry is worth more than 4 "built a todo app" lines.

ATS and Keyword Optimization

Most large companies use Applicant Tracking Systems (ATS) to keyword-filter resumes before a human sees them. To pass:

• Match the job posting's keywords. If the posting mentions "distributed systems", "Go", "Kubernetes", and "on-call", make sure those exact words appear in your resume.
• Use standard section headers. "Experience", "Education", "Projects". ATS systems use these to structure parsing.
• Avoid tables, columns, or fancy fonts. Many ATS systems mangle them.
• Upload as PDF, not as .doc. PDFs render predictably.
• No graphics, no images, no bars or charts. ATS cannot read them.

The cleanest check: paste your resume into plain text. Does it still read? Good. That is what the ATS sees.

FAANG-Specific Format Preferences

Google: prefers highly structured, data-dense resumes. Google recruiters skim for specific language and infra keywords. Projects matter heavily for new grads.

Meta: values shipping and iteration. Bullets that mention "shipped", "launched", and measurable user impact perform best.

Amazon: leadership-principle-mapping bullets score higher. Use the implicit language of the LPs (Ownership, Dive Deep, Deliver Results) without naming them.

Apple: values craft and depth. A single project described in 3 bullets can outweigh 5 shallow bullets. Do not spray — go deep.

Microsoft: values growth mindset. Bullets about mentoring, learning new domains, and cross-team collaboration score well.

Hedge funds / quant: prioritize performance, correctness, and rigor. Emphasize latency-critical work, math-heavy projects, competitive programming ranks.

Before and After: 8 Real Bullet Rewrites

Before 1: "Worked on API performance optimization."

After 1: "Optimized the top 10 REST endpoints in our billing API by replacing N+1 queries with batched DataLoader pattern; reduced p95 latency from 840ms to 110ms and cut RDS CPU by 35 percent."

---

Before 2: "Helped team migrate to microservices."

After 2: "Led migration of the payments monolith (400K LOC) to 6 Go microservices over 9 months; zero production incidents during cutover; enabled independent deploys for 3 downstream teams."

---

Before 3: "Built a frontend dashboard."

After 3: "Built the customer analytics dashboard in Next.js and D3.js used by 1,200 sales reps; reduced their weekly report-creation time from 4 hours to 20 minutes."

---

Before 4: "Improved code quality."

After 4: "Raised team test coverage from 42 to 81 percent by writing characterisation tests for the legacy billing module; caught 3 critical regressions in the subsequent quarter."

---

Before 5: "Participated in on-call rotation."

After 5: "Led 4 incident post-mortems as the primary on-call; authored 2 SRE runbooks that reduced mean time to resolution by 40 percent on the top 3 alert categories."

---

Before 6: "Mentored junior engineers."

After 6: "Mentored 3 junior engineers over 18 months; 2 were promoted to mid-level and one led their own feature by month 12."

---

Before 7: "Wrote tests for the frontend."

After 7: "Introduced Playwright end-to-end test coverage for the 8 critical user journeys in our web app; reduced regression bugs in release weeks by 62 percent."

---

Before 8: "Worked on Kubernetes infrastructure."

After 8: "Migrated 14 services from raw EC2 to EKS with Argo CD GitOps deploys; cut deploy time from 25 minutes to 90 seconds; reduced deploy-related incidents by 3x."

The pattern is consistent: specific verb, specific technology, specific number, specific outcome.

Common Resume Mistakes

1. Listing every technology you have ever touched. Cuts credibility. List only the ones you can defend.
2. Generic one-liners. Any bullet that could apply to any SWE anywhere is dead weight.
3. Fluff words. "Passionate", "team player", "results-driven". Cut.
4. Objective statement. Gone from modern resumes. Use the space for experience or projects.
5. Different fonts or colors. Use one font, black on white, 10 to 11pt body text.
6. Links that don't work. Test every hyperlink in the final PDF before submitting.
7. Past-tense for current job. Use present tense for your current role, past tense for previous.
8. Inconsistent date formats. Pick one (e.g., "Aug 2022 – Present") and use it throughout.
9. Spelling or grammar errors. One typo can kill a resume at a company that gets 1000 applications per req. Proofread.
10. Buzzword salads. "Leveraged agile methodologies to synergize cross-functional deliverables." Trash. Cut it.

Frequently Asked Questions

Should I tailor my resume for each application?

For FAANG: yes, but lightly. Adjust 2 to 3 bullets to match the team's focus.

For your #1 dream company: yes, heavily. Rewrite.

For volume applications: keep one strong generic version.

How often should I update my resume?

Every 6 months minimum, even if not job-hunting. Fresh achievements fade from memory; write them down while you can quantify them.

Should I include a photo?

No, in the US, Canada, UK. Some European countries (Germany especially) expect one. Know your market.

Should I link my blog?

If you have 3+ technical posts that aren't embarrassing, yes. One post, no. Ten average posts, consider omitting.

Is it okay to have employment gaps?

Yes. Never hide them. Brief gaps need no explanation. Long gaps (6+ months) should be reasonable (parental leave, education, health, travel, self-directed learning).

Should I list programming certifications?

Generally no. Interviewers don't weight them. Exceptions: vendor-specific senior certifications (AWS Solutions Architect Pro, Kubernetes CKAD) for infra-focused roles.

Conclusion

A SWE resume is not a brag sheet. It is a high-density signal document for a recruiter's 30-second skim. One page, 5 sections, numbers in every bullet, tight tech stack, cleanly formatted for ATS. Invest 2 hours doing this right once, then update every 6 months. It is the cheapest 2 hours you will spend on your career.

Frequently asked questions

Should a software engineer resume be one page or two?

One page for new grads — non-negotiable. One page for 1-7 years of experience — strongly recommended. One page for 8-15 years — still ideal, with two pages acceptable only if the second is highly dense. Beyond 15 years, two pages is acceptable. Recruiters skim for 30-60 seconds; a second page costs more attention than it buys.

What does a strong SWE resume bullet point look like?

Every bullet must answer what you did (specific action verb), how (technology, scale, method), and the impact (a number). Weak: 'Worked on backend services.' Strong: 'Built a Go-based rate limiter using Redis handling 15K RPS across 4 regions, reducing API abuse by 87% and cutting on-call pages from 40/week to 6/week.' One bullet, three questions answered, with one quantified outcome.

How do I get past Applicant Tracking Systems (ATS) as a software engineer?

Match the job posting's exact keywords (if it says 'distributed systems', 'Go', 'Kubernetes', 'on-call' — those words must appear in your resume). Use standard section headers like Experience, Education, Projects. Avoid tables, columns, fancy fonts, graphics, and bars. Upload as PDF, not .doc. The cleanest ATS check: paste your resume into plain text and confirm it still reads.

Should I include a projects section if I have professional experience?

For new grads with under 2 years of experience, projects are often more important than experience. For experienced engineers, projects are optional — include only 1-2 standout side projects with real users, not throwaway tutorials. One distributed URL shortener handling 2K RPS with a blog post that hit Hacker News beats four 'built a todo app' lines.

Do FAANG companies have different resume preferences?

Yes. Google prefers highly structured, data-dense resumes with strong infra keywords. Meta values shipping language ('shipped', 'launched') and measurable user impact. Amazon scores leadership-principle-mapped bullets higher (use Ownership, Dive Deep, Deliver Results language without naming them). Apple values craft and depth — one project in 3 bullets beats 5 shallow bullets. Microsoft values growth mindset, mentoring, and cross-team collaboration.