Software Engineer Resume: Complete Guide + Examples (2026)

A software engineer resume has one job: get you to a screen with the hiring manager. It's not a portfolio, not a project log, and not an autobiography. The version that does the job well is shorter, more specific, and more boring than most candidates think.

This guide covers what to include at each career stage (new grad, mid-level, senior, staff+), the formatting that actually parses, and how to write bullets a hiring manager can scan in 8 seconds. There's also a complete example at our software engineer resume example.

The structure that works for engineers

One column, plain text, in this order:

1. Contact block — Name, city/state, email, phone, LinkedIn, GitHub, portfolio URL if relevant.
2. Professional Summary — 2–3 sentences. Skip if you're a new grad with a strong projects section.
3. Work Experience — Reverse chronological. The single most important section past your first job.
4. Technical Skills — Grouped. Don't list every tool you've ever touched.
5. Projects — For new grads, career changers, or if you have a flagship side project relevant to the role.
6. Education — At the bottom past your second job; at the top for new grads.

That's it. No "Hobbies." No "References available upon request." No "Objective" section.

The contact block

Three lines, in body text, not in a Word header (ATS often strips those):

Alex Chen
San Francisco, CA · alex.chen@email.com · (415) 555-0123
linkedin.com/in/alexchen · github.com/alexchen · alexchen.dev

Notes: City and state, not full address. A real-looking email (not codeninja420@aol.com). LinkedIn URL customized. GitHub if it has activity worth showing — an empty GitHub or one with only forks looks worse than no link.

The professional summary

Two to three sentences answering: What kind of engineer am I, what's my specialty, and what's the biggest thing I've shipped?

Good:

Backend engineer with 6 years building distributed systems on AWS. Led migration of a monolithic payments service to event-driven microservices serving 2M+ daily transactions. Strongest in Go, Python, and Kafka.

Bad:

Passionate software engineer seeking to leverage skills in a dynamic team environment.

The bad version says nothing a hiring manager couldn't have guessed. Skip the summary entirely if you can't make it concrete.

Work experience: where 80% of the signal lives

Format each role:

Senior Software Engineer · March 2022 – Present
Acme Corp, San Francisco, CA
• Bullet one (impact + method)
• Bullet two
• Bullet three

3–6 bullets per role, more for recent jobs and fewer for older ones. Each bullet should answer "what did you do, what was the result, and how did you do it." The XYZ formula:

Accomplished [X] as measured by [Y] by doing [Z].

Engineer-specific examples:

• Reduced p95 API latency from 800ms to 120ms by introducing a Redis caching layer and consolidating 4 sequential database calls.
• Led migration of payments service from a Rails monolith to 6 Go microservices, increasing throughput 4x and decreasing on-call pages by 60%.
• Mentored 3 junior engineers through their ramp, including running weekly code review sessions that decreased PR rework rate by 40%.
• Built an internal CI/CD platform on GitHub Actions used by 80+ engineers, reducing average deploy time from 25 minutes to 4.

Weak versions of the same bullets:

• Worked on improving API performance.
• Helped migrate to microservices.
• Mentored junior team members.
• Built CI/CD pipelines.

The weak versions could describe a junior engineer or a staff engineer; the hiring manager has no way to tell. The strong versions force the writer to confront how much they actually owned, and they give the reader something to ask about in an interview.

What metrics to use (and what to do if you don't have any)

Engineers underestimate how many metrics they have. Things that count:

• Latency, throughput, error rate (p50, p95, p99 — be specific)
• Users, requests, events, transactions per day/month
• Cost — infrastructure savings, vendor bills cut
• Team size, number of services, lines of code (use sparingly)
• Time — deploy time, build time, time-to-onboard
• Quality — incidents reduced, bug count, code coverage
• Business outcomes — revenue, conversion, retention if you owned anything tied to them

If you genuinely don't have numbers, use qualitative scale: "the company's most-used feature," "the first production service in Go," "the only engineer on the project." But push hard on actual numbers first — most engineers can dig them up with 30 minutes in their old Jira or Datadog.

The skills section: grouped, not exhaustive

Three to four categories, 4–8 items each:

Languages: Python, Go, TypeScript, SQL
Infrastructure: AWS (EC2, S3, Lambda, RDS), Kubernetes, Docker, Terraform
Data: PostgreSQL, Redis, Kafka, Snowflake
Frameworks: FastAPI, Django, React

Don't:

• List languages you haven't used in 5 years.
• Pad with things every engineer is assumed to know (Git, Linux, REST APIs).
• Include skill ratings ("Python ★★★★☆"). They're not parseable and recruiters don't trust them.

Projects: when and how to include them

Include a projects section if:

• You're a new grad and your work experience is internships or coursework.
• You're a career changer demonstrating engineering ability.
• You have a flagship project (open-source library with traction, a shipped product) that's more impressive than your day job.

Format each project:

Project name · Tech stack · github.com/you/project
One sentence on what it does, then 1–2 bullets on impact or interesting technical decisions.

Skip projects that are course assignments unless they're genuinely substantial. "Built a Twitter clone in React" is on every bootcamp grad's resume; "Built a Twitter clone in React with 2,000 monthly active users running on a $5/month VPS" is interesting.

Resume by experience level

New grad (0–1 years)

Order: Education → Projects → Internships/Work Experience → Skills. Keep to one page. Lead with your strongest project and the technical specifics — interviewers love something concrete to ask about. GPA only if 3.5+ and you're applying to companies that care.

Mid-level (2–5 years)

Order: Summary → Work Experience → Skills → Education. One page is doable; two is fine. Drop coursework, drop projects unless they add a dimension your jobs don't. Each role's bullets should focus on individual technical contribution and emerging scope (started leading a feature, ran a project).

Senior (5–10 years)

Order: same as mid-level. Two pages. Bullets emphasize scope: cross-team work, technical leadership, design decisions, mentoring. Roles older than 8 years get 1–2 bullets each or get rolled into a brief "Earlier Experience" section.

Staff / principal (10+ years)

Order: same. Two pages, maybe a bit more if you have a publications or speaking section. Bullets focus on org impact: technical strategy, hiring, multi-quarter initiatives. Show evidence of influence beyond your immediate team. Specific design docs, RFCs, or systems you authored matter more than feature lists.

Engineer-specific resume mistakes

• Listing every language and framework as equal. Pick a strongest stack and own it. "Polyglot" reads as "no specialty."
• Vague tool name-dropping. "Used Kafka" is meaningless. "Designed Kafka topic schema for an event-sourced order system processing 50k events/min" tells a story.
• GitHub link to an empty profile. If your GitHub is a graveyard of half-finished tutorials, leave it off.
• Putting "Languages" before "Work Experience". Languages don't make hires; impact does.
• Bullets that describe the team's work, not yours. "Our team launched the new search system" doesn't tell anyone what you did. Use "I" implicitly: "Implemented the ranking layer of the new search system."
• Including a 4-month stint that ended badly. If it was a contract or you can plausibly leave it off without a date gap, do.

One full bullet, transformed

Original:

Worked on the backend team to improve performance and reliability of various services.

Step 1, add a verb: "Led performance and reliability improvements across backend services."

Step 2, add numbers: "Led performance and reliability improvements across 4 backend services, reducing p95 latency by 40% and incidents by 60%."

Step 3, add the how: "Led performance and reliability improvements across 4 backend services by introducing connection pooling, query optimization, and a Redis read-through cache — reducing p95 latency by 40% and on-call pages by 60%."

Final bullet is 35 words, takes 5 seconds to read, and gives the interviewer 3 specific things to ask about.

FAQ

Should I include a "Languages" line with proficiency levels?

Programming languages: yes, grouped under Skills. Spoken languages: only if relevant to the role or you're applying internationally.

Do I need a Leetcode score or coding contest mention?

Almost never. Leetcode performance correlates poorly with job performance and most hiring managers don't care. If you've placed in a major competitive programming event (ICPC finals, Codeforces Grandmaster) it's a unique signal — otherwise skip.

How do I handle a gap between jobs?

Honestly, briefly: "Career break — caregiving / travel / health" as a one-line entry. Open source, contracting, or learning don't need to fill the gap; recruiters care about what you did when you came back to work.

Should I include hobbies?

Only if they're remarkable (competitive athletics, published novels, building open-source tools used by thousands). "Reading, hiking, cooking" adds nothing and costs a line.