The Software Engineer Resume Guide (2026)

Most resume guides treat "software engineer" as a role title and offer the same advice they would give to a marketing manager: lead with action verbs, quantify every bullet, end with a measurable outcome. The advice is correct. It is also not specific enough to be useful for engineers.

A software engineer's resume has three load-bearing things no other resume has: a skills block of technical specifics, links the recruiter will actually click and read in the first thirty seconds, and quantifiers that mean something to an engineering hiring manager and almost nothing to anyone else. This guide covers those three. For the underlying structure (length, the four-zone layout, the three-sentence summary, the bullet anatomy), How to write a resume in 2026 is the entry point, and the rest of this post assumes that shape.

One frame before the specifics. The bar for software engineering resumes has moved up since 2024. Recruiters now click your GitHub during the first review, not after. LLM-augmented screening passes read a "Spearheaded distributed-systems initiatives" bullet against the rest of the file and flag the inflation. The window for a generic engineering resume is narrowing, and the difference between a strong file and a weak one shows up in places general advice doesn't reach.

The skills section: three lines, not twenty adjectives

The skills section on a software engineer's resume has one job: tell the parser and the human what role you are targeting next. Most candidates use it as the kitchen-sink list of everything they have ever touched. A 23-skill section with proficiency dots reads as someone who has not decided what they are applying for.

Three lines, three categories, no proficiency labels.

Languages. What you would write code in tomorrow if hired. Two to four, ordered by how recent and load-bearing each is. "Go, TypeScript, Python" reads cleaner than "Go (Expert), TypeScript (Intermediate), Python (Familiar), Java (Studied), Rust (Hobby)." A reader assumes you can write each one at the level of the role you are applying for; the proficiency label adds doubt where there should not be any.

Frameworks and libraries. The frameworks and major libraries you build with day to day. React, Next.js, Django, FastAPI, gRPC, Kafka. Cap at six to eight. A list of fifteen frameworks is the same red flag as the language list, padded.

Infrastructure and tooling. What you ship to and how. AWS or GCP and which services, Kubernetes if you have actually run it (not only heard of it), Terraform, Postgres or whichever database is load-bearing in your work, your CI tooling, your observability stack. Cap at six to eight.

A clean three-line skills block reads like this:

Languages: Go, TypeScript, Python
Frameworks: gRPC, React, Next.js, Postgres, Redis
Infrastructure: AWS (EKS, RDS, S3), Terraform, GitHub Actions, Datadog

Three lines. A reader knows in two seconds what kind of role you are shaped for. A 2026 LLM screen pulls the keywords cleanly from this format and matches them against the job description without confusion.

What does not belong in this section: soft-skill pseudo-tags ("Communication," "Problem-solving"), methodologies as skills ("Agile," "Scrum" — every team uses these), generic categories that are not technologies ("Best Practices," "Clean Code"), and ambiguous abbreviations the reader has to expand ("DS" for data structures or distributed systems or design systems).

External proof: GitHub and side projects

Your GitHub link and any side projects you list are the parts of the resume the reader will follow up on. Treat them as an extension of the document, not a footnote.

The GitHub link

If you list a GitHub URL on your resume, the recruiter is going to click it. Five years ago this was true mostly for technical recruiters; today it is true for non-technical recruiters too, because LinkedIn-driven LLM screening tools cross-reference your GitHub username automatically. The link you put on the resume is the start of the second pass, not a citation.

Three implications follow.

Make sure the link works and lands on the right account. Recruiters check your handle against LinkedIn, your company alumni page, sometimes a previous employer's engineering blog. If the GitHub URL on your resume does not match the username they expected, or if it points to a profile with three forks and no original work, the resume is done before they reach your bullets.

Pin the repos that prove the resume. GitHub's pinned-repos block is your second-most-read surface after the resume's top third. Pin three to six repos that match the role you are applying for: a backend system in the language you claim, a small library or tool with real adoption, an open-source contribution where the merged PRs are visible. A pinned repo without a README is worse than no pinned repo; it implies you do not ship documentation.

Recent activity matters more for juniors than seniors. A senior engineer with a dormant GitHub for six months is fine; they have been shipping at work behind a private repo. A junior engineer with no contribution graph activity in the last year reads as someone who codes only when paid, which is a question mark for hiring managers looking for the trait of "engineers who code on weekends."

Side projects, by career stage

Side projects work differently at different career stages.

Junior engineers and career-changers. Side projects are how you demonstrate that you can ship without an employer's tooling and process around you. A bootcamp graduate with three real, deployed side projects (each with a working URL and a README) signals more than the bootcamp does. Two paragraphs of resume real estate is correctly spent here.

Mid-level engineers (3 to 6 years). Side projects can supplement work bullets when the work bullets are thin (a year of maintenance work after a year of greenfield, for example), but they should not displace work bullets. One side-project section with two or three projects, each one line plus a link.

Senior and staff engineers. Side projects rarely belong on the resume at this level. The signal a hiring manager wants is not "this person codes on weekends" but "this person can lead a fourteen-month replatform across four teams." Save the side-project content for your URL or your GitHub, and use the resume page for work that earns the seniority.

There is one specific exception across all levels. A side project with real adoption (a library a few hundred companies depend on, an open-source tool that is the default in a niche) is a credential, not a hobby. Put that one on the resume even at staff level, with the user count and the maintenance commitment. "Maintainer of [tool], 1,400 GitHub stars and 60 production users at companies including [two named]" is a different artifact than "I built a habit tracker for fun."

What does not belong as a side project on the resume: tutorials you completed, "cloned X but with feature Y" without users, coursework, and any project that does not have a working URL or a public repo for the reader to inspect.

Bullets by level: density, phrasing, quantifiers

This is the section where SWE-specific advice diverges most from general resume guides. The bullet that earns a promotion to senior is shaped differently than the bullet that earns a promotion to staff, and the resume should reflect what level you are applying for.

Junior (0 to 3 years)

Three to four bullets per role. Each bullet is a single deliverable: a feature shipped, a system migrated, a bug class eliminated. The scope is your task or your team's sprint, and that is appropriate. The strong shape:

Implemented the email-verification flow for new user signup, including the token rotation and rate-limiting layer, and shipped behind a feature flag to 100% over four weeks.

What is strong: a specific feature, named subsystems (token rotation, rate-limiting, feature flag), a duration. What is not in the bullet: claims of cross-team leadership, business outcomes, or scope a junior would not have owned. The reader trusts the level because the bullet does not pretend.

Mid-level (3 to 6 years)

Four to five bullets per role. Each bullet's scope is now a service or a multi-month project. Outcomes should appear, but they are operational outcomes (latency, throughput, error rates) rather than business outcomes. The strong shape:

Owned the migration of the notifications service from synchronous webhooks to a Kafka-based event bus over five months, reducing p95 dispatch latency from 2.3s to 180ms across 12M monthly notifications and eliminating the daily backlog incidents.

What is strong: ownership scope (the service), duration, before-and-after with units, two distinct outcomes (latency plus reliability). What is missing: cross-team coordination claims, hiring or org outcomes; those would read as inflated for a mid-level engineer.

Senior IC (6 to 10 years)

Four to six bullets per role. The scope expands to multi-service or platform-level work. Bullets should mix operational outcomes with at least one business or org-level outcome: usage growth, cost reduction, an incident class eliminated, a major migration. The strong shape:

Led the platform-side of a four-team replatform from a Rails monolith to Go services over fourteen months, ending with deploy frequency at 31 per week (up from 4), p95 across the gateway under 80ms (from 410ms), and three sev-1 outage classes eliminated.

What is strong: cross-team reference (four-team), duration, three quantifiers including a deploy-frequency metric that signals you understand engineering velocity. What is not yet present: company-level claims, hiring claims, or executive influence; those would read as overreach.

Staff and lead (10+ years)

Five to seven bullets per role. At least one bullet should reflect cross-team or org-level scope. Bullets should reflect what your work let other engineers do, not only what you built yourself. Mentorship, technical leadership, and architecture decisions belong here for the first time. The strong shape:

Architected the cross-region failover plan adopted across three product groups (payments, auth, data), authored the runbook now used by 80+ on-call engineers, and led the staff-level review of every related design doc for two consecutive years.

What is strong: scope spanning product groups, an artifact that reaches beyond your own team (runbook, design review), a duration that proves it was not a one-off. What is intentionally not in this bullet: per-service deploy or latency numbers. At staff level, the adoption and scope numbers carry more signal than per-service operational metrics, and a senior engineering reader will infer the operational competence from the architecture work.

A general note on density. A junior engineer's three bullets can be tight one-liners. A staff engineer's six bullets each carry more clauses and more numbers, but they are not flowery; they are dense with facts. If you find yourself adding adjectives to fill out a bullet, the bullet's underlying work is not strong enough; go find another bullet rather than padding the one you have.

Quantifiers that work for engineers

Engineering bullets should quantify with numbers a hiring engineer recognizes as real, not generic business numbers. Pick from this list before reaching for "improved" or "enhanced."

Velocity numbers. Deploys per week or per day, change-failure rate, lead time for changes (the four DORA metrics). A bullet that says "deploys went from 4 per week to 31 per week" lands harder than "improved engineering velocity" because the reader can compare it to their own team's number.

Latency numbers. p50 / p95 / p99 latency in milliseconds, with the workload named. "p95 read latency under 80ms across 14M monthly checkout sessions" is checkable; "improved performance" is not.

Throughput and scale. Requests per second sustained or at peak, MAUs/DAUs, transaction volume, queue depth, dataset size. The unit matters: "12M monthly notifications" tells the reader more than "high volume."

Reliability numbers. SLO target and attainment, error rate, sev-1 or sev-2 frequency, MTTR, error-budget burn. "Reduced sev-1 frequency from 2.4 to 0.6 per quarter" is a senior-level engineering claim with a clean before-and-after.

On-call numbers. Frequency of pages, percentage of pages requiring escalation, number of on-call rotations covered. On-call data signals operational maturity; a candidate who tracks this is one who understands the operational side of the role.

Cost numbers. Cloud spend reduction in absolute dollars, cost per request, cost per transaction. "Cut monthly cloud spend by $84k by right-sizing 240 over-provisioned database instances" is a senior+ bullet because it requires both technical depth and cost awareness.

Numbers that read as filler: "reduced latency by 40%" without a baseline, "improved scalability," "worked on high-performance systems," "optimized critical paths." These are word-clouds, not numbers; they do not survive an LLM-augmented screen.

A bullet, rewritten

Take a real-shape weak bullet and walk through what fixes it.

Weak.

Worked on the company's payment system to improve performance and reliability for customers.

What is wrong: "Worked on" is proximity, not action. "The payment system" is generic. "Improve" is a wish without a number. "For customers" is everyone. The bullet would survive on every backend engineer's resume in the world, which means it does not belong on yours.

Stronger first pass.

Improved the payment system's performance and reduced bug reports by 30%.

Better but still soft. "Improved" is unspecific. "Reduced bug reports by 30%" is one number with no scope; what was the baseline, over how many months, in which segment of the system?

Strong.

Rewrote the payment authorization path from a synchronous Stripe call into an event-driven flow over four months, dropping p95 charge latency from 1.4s to 240ms across 6M monthly transactions and eliminating the once-a-week timeout incident class entirely.

What changed: the action verb is now real ("Rewrote"). The system is named with specifics ("payment authorization path," "synchronous Stripe call into event-driven"). Duration is given ("four months"). Numbers are paired and have a denominator ("p95 from 1.4s to 240ms across 6M monthly transactions"). A second outcome lands a separate claim ("once-a-week timeout incident class eliminated"). The bullet now belongs to one engineer doing one specific job.

What to cut

Engineering resumes accumulate clutter faster than other resumes because there is always one more language, one more side project, one more conference talk to add. Audit zone four ruthlessly.

• Coursework. Drop after the first two years of your career. By year three the courses are noise; the projects and roles do the work.
• Bootcamp logos. Your bootcamp goes one line in education, no more. Multiple bullets under a bootcamp listing read as compensating; let your subsequent work speak for the program's value.
• "Tech enthusiast" or hobby section. Cut it. If you have a real open-source contribution, it goes in projects. If you compete in CTFs and the role is security-adjacent, mention it in projects with one line. Generic enthusiasm is filler.
• Skills with proficiency bars. Cut the bars. The bars themselves are an ATS-hostile design choice (no parser reads them); the proficiency labels add doubt where there should not be any.
• Every framework you have ever touched. Cut to the ones you would be happy to work in tomorrow. The list communicates intention, not biography.
• Personal projects without a working URL or repo link. Either deploy and link, or remove. A project the reader cannot see does not exist on the resume.
• Photos. The norm in most US, UK, Canadian, and Australian software hiring is no photo. Continental Europe and parts of Asia differ; default to no photo unless you know the local convention requires one.
• Long objective statements. Replace with the three-sentence summary covered in the underlying guide.
• High school education. After your bachelor's, do not list it. After three years of work, do not list it. This applies across functions; it is particularly common to see on entry-level engineering resumes.

A specific anti-pattern worth naming. "Familiar with: [list of 30 technologies]" sections are net-negative. They imply you have done none of them deeply enough to claim expertise, and they pad the file with terms an LLM screen will count as keyword stuffing rather than evidence.

A second anti-pattern: listing every conference talk you have ever given. One named talk at a recognized venue (KubeCon, QCon, Strange Loop, RailsConf) is a credential. Five Meetup talks at the local JS group are filler that displaces a work bullet. Same logic for blog posts — link to your one or two best from your URL or your GitHub README, not from a "Selected publications" section that fills half a column.

Where to read next

For the structural fundamentals (length, the four-zone layout, the three-sentence summary, the bullet anatomy), see How to write a resume in 2026.

For verbs that work harder per character, 200+ resume action verbs, sorted by what they claim is a categorized list with usage rules.

For composite three-sentence summaries across roles, including a software engineer worked example, see Resume summary examples.

For what specific applicant tracking systems weight and what they do not, the ATS resume guide covers the seven major platforms.

A ProPage page renders your resume as both an ATS-safe PDF and a public URL that includes your projects, your GitHub link, and your contact information. For an engineer applying with a public GitHub, having the page-the-recruiter-googles match the resume-they-uploaded removes the cross-check inconsistency that screens out otherwise strong candidates.