The software engineer resume: a 2026 field guide.

I've been a hiring manager for engineering teams for most of the last decade. I've also been in the seat on the other side of that table plenty. Software engineering resumes have their own pathologies — we all write them the same wrong way, copying each other's mistakes across generations.

This is what I wish someone had told me when I was writing my third resume, and what I now tell every engineer who asks me to look at theirs.

The structure that works

For 95% of SWEs, this is the order:

1. Header — name, one-line summary ("Senior backend engineer, distributed systems"), contact.
2. Experience — reverse-chronological, 2–4 bullets per role, outcomes.
3. Skills — short, specific, grouped.
4. Projects — only if load-bearing (see below).
5. Education — degree, institution, graduation year. Move this up only if you're under 3 years out or it's directly relevant.

Objective statements, "Professional Summary" paragraphs of four sentences, hobbies, languages spoken (unless relevant), references — all cut. None of them change the outcome of the screen.

The skills section, rebuilt

Most engineering skills sections are a mess. They list 40 things. They include "Microsoft Office." They don't distinguish between languages you can write tests in and languages you'd call yourself proficient in. They lie about React when the candidate has done three tutorials.

Here's the rebuild:

The "After" version is more useful because it's honest. "Primary" tells me what you'll be productive in on day one. "Comfortable" tells me you can ramp in a week. "Recent" gives me something to ask about in the interview. A recruiter can still keyword-match — every technology is still named — but the human reader gets real information.

Experience: outcomes over stacks

The most common SWE-resume sin is bullets that describe a stack instead of a result.

Notice: the stack is still there, in a parenthetical. But the bullet is about what changed because the service exists. The reader gets both the technology signal and the judgment signal.

Good SWE bullet patterns

• Latency / throughput: "…p99 from X to Y", "…throughput 4×".
• Reliability: "…incidents in this area dropped from N/quarter to 0", "…SLO met for 4 consecutive quarters."
• Scope: "…serving 18M MAU", "…across 6 microservices", "…team of 5 engineers."
• Cost: "…cloud spend down 31% YoY on this service."
• Velocity: "…CI pipeline from 38 to 6 minutes", "…release cadence weekly → daily."
• Adoption: "…library used by 14 services across 3 teams."

Patterns to avoid

• Verb stacking: "Developed, implemented, architected, deployed, maintained…" — one verb.
• Buzzwords: "Synergized cross-functional stakeholders to drive agile outcomes." Delete and rewrite.
• Team-credit without your role: "Our team built X" — say what you did.
• Complexity LARPing: If you wrote a thin wrapper, don't call it "an ML platform."

Side projects: when they help, when they don't

Projects are most valuable when the resume needs them most. That usually means:

• You're early-career and don't have enough work experience to fill the page.
• You're switching stacks or specializations and need to demonstrate range.
• A project is genuinely notable (adoption, paper, influence) and strengthens the story.

If you're a senior engineer with 8 years of shipping, a "todo app in Rust" project dilutes the resume. The project bar rises with seniority. At senior+ levels, include a project only if it would be interesting to someone who's already seen a lot.

How to write a project bullet

Same pattern as work bullets: what it is, what you built, what happened.

On linking your GitHub

Your GitHub link does less work than you think. Here's what actually happens: the reviewer clicks through, sees your profile, and forms an impression based on:

• Pinned repos and their READMEs.
• The activity graph (is anything recent?).
• A sample commit or two on whatever's at the top.

That entire review takes under a minute. If your pinned repos are class projects from four years ago, you'd be better off not linking. If you have genuinely interesting work, link it — but also put the specific repo in the project bullet. Most reviewers won't dig past the profile page.

What changes by level

Intern / new grad

Education section moves above Experience. Projects count as experience. Relevant coursework is fine if genuinely relevant — "Operating Systems, Compilers, Distributed Systems" — not "CS101." Ship one or two real projects with writeups, not 12 tutorials.

Mid-level (2–5 years)

Experience section is now the centerpiece. Cut your CS coursework. Move Education below Skills. Bullets become about outcomes and ownership, not tasks and languages.

Senior (5–10 years)

Outcomes, scope, and technical judgment are what's being evaluated. "Led migration…", "owned service X…", "reduced incident rate…". Remove all bullet content that would be indistinguishable from a mid-level IC.

Staff / Principal

Your resume should read like a portfolio of technical strategy bets. "Proposed and led the company's platform consolidation initiative — 9 services → 3, operating cost down 40%, on-call rotation cut in half." Include influence beyond code: documents you wrote, initiatives you seeded, mentorship at scale.

Manager (EM / Director)

Different document. Orgs led, team outcomes, hiring, attrition, process changes, business-metric impact. You can keep two bullets of IC work near the bottom of older roles if they're genuinely relevant, but your case is no longer made on code.

Before/after rewrites

Backend engineer, mid-level

Frontend engineer, senior

FAQ

Should I list every language I've used?

No. List the ones you'd confidently work in tomorrow. An interviewer asking about a language you "know" is uncomfortable if you've forgotten the syntax.

Do I include my GPA?

If you're within 2–3 years of graduation and it's above 3.5, sure. Otherwise, drop it.

Should I mention open source contributions?

If they're substantive (merged non-trivial PRs, maintainer on a notable project), yes, in Projects. If they're "added a comment to a README," skip it.

What about certifications (AWS, etc.)?

Useful when the role specifically asks for them or when you're early-career trying to show cloud fluency without prior work experience. Most senior roles don't weight them.

How do I handle a gap year?

Name it briefly and move on: "Career break — travel / family / learning (2023)." A matter-of-fact one-line treatment is much better than trying to pretend the gap isn't there.

Should I use a LaTeX template?

You can, but you shouldn't have to. A clean LuckyResume export produces the same quiet, typographic feel without the LaTeX tax. The reader will not know the difference.