How to write a software engineer resume that passes ATS in 2026
A practical guide to the four sections that move a software engineer resume past the ATS filter — Skills, Experience, Projects, and the GitHub link. Plus the specific keyword vocabulary modern engineering JDs scan for.
Engineer resumes are scored differently than every other category. Hiring managers for engineering roles are themselves engineers; they write JDs that list specific tools, languages and frameworks; ATS engines weight those exact terms heavily. A resume that says "built scalable systems" without naming the stack scores below one that says "built event-driven service in Go using Kafka, deployed on EKS with Terraform." Specificity wins both ATS scoring and human screening — the same vocabulary unlocks both.
This post covers the four resume sections that actually determine whether your engineer resume gets a recruiter call, and the modern keyword vocabulary that ATS engines (especially Workday and Greenhouse) match against engineering JDs in 2026.
Why engineer resumes are different
Most resume advice you'll find online is calibrated for sales, marketing and operations roles — verb-heavy bullets, soft-skill language, generic "led cross-functional initiative" framing. None of this lands for engineering. Engineering JDs are written by engineers, who include specific stacks ("must have 3+ years Postgres in production"), specific patterns ("event-driven architecture experience required"), and specific scale ("services serving 10M+ daily active users").
ATS engines for engineering roles are calibrated to surface candidates whose vocabulary mirrors that JD. The match isn't full-text semantic search — it's keyword-presence with stemming. If the JD says "Kubernetes" and your resume says "container orchestration" but never "Kubernetes," you won't match the literal keyword. The hiring manager might still rate you well in the human screen IF your resume reaches them, but recent studies put the probability of a human seeing a low-ATS-score resume at well under 20% for any role with more than 50 applicants.
The fix isn't to game the keywords — it's to write specifically about what you actually built, with the actual tool names. The honest specificity is the optimization.
Section 1 — The Skills section
The Skills section is where most engineer resumes leak score. The two most common mistakes are opposites of each other:
Listing too few skills. A senior engineer who lists "Languages: Python" loses to a senior engineer who lists "Languages: Python, Go, TypeScript, Bash" — even when both have similar real experience. ATS engines look for the literal terms; missing terms = missing matches. Be honest about what you can speak to in interview, but don't artificially limit the list.
Listing skills as a wall. A 60-skill list reads as keyword stuffing to both ATS engines (which down-weight extreme density) and human readers (who skip the section entirely). Anything over 25 skills total is into wall territory.
The format that wins:
Languages: Python, TypeScript, Go, SQL, Bash
Frameworks: FastAPI, Next.js, React, Django, gRPC
Infrastructure: AWS (EKS, RDS, Lambda, S3), Kubernetes, Terraform, GitHub Actions
Data: PostgreSQL, Redis, Kafka, Elasticsearch, Snowflake
Observability: Datadog, Sentry, OpenTelemetry, Prometheus, Grafana
A few notes on this format:
- Group by category. Recruiters scan, ATS engines parse — both want structure. The categories themselves don't have to be perfect; what matters is that they create predictable visual chunks.
- Name versions only when they matter. "Python" alone is fine; "Python (3.11+)" only if the version is actually relevant to the role. Avoid version-cluttering for its own sake.
- List supporting tools next to platforms. "AWS (EKS, RDS, Lambda, S3)" matches the JD better than just "AWS" — JDs often list the specific services.
Section 2 — Experience bullets that name the stack
The biggest single improvement most engineer resumes can make: every bullet should name the technology behind what you built. The pattern is:
Verb + outcome + tech + scale
Not all four every time, but as many as honestly fit.
Weak:
"Built scalable backend services that processed millions of requests."
Strong:
"Built event-driven order-fulfillment service in Go + Kafka, scaling from 50K to 4.2M daily orders without re-architecting."
The strong version names: the architecture pattern (event-driven), the language (Go), the broker (Kafka), the domain (order fulfillment), and the scale (50K → 4.2M daily orders). Every one of those is a keyword that an engineering JD would scan for, and every one is honest signal that you actually shipped the thing.
Some patterns that consistently land:
- "X using Y" — the X (what you built) tells the human what mattered; the Y (how you built it) gives ATS the keyword match.
- "Reduced X by N% via specific change" — quantification + specificity in one bullet. ATS scores this near-maximum on the impact axis.
- "Owned end-to-end from N to M" — signals senior IC scope; common in JD requirements for staff/principal levels.
Avoid:
- "Worked on..." — adds zero information; passive enough to trigger weak-verb rules in some ATS engines.
- "Helped with..." — same problem; also signals you weren't the owner.
- "Responsible for..." — the most-flagged weak verb across every analyzer. "Led" / "Owned" / "Built" / "Drove" are all stronger and more specific.
Section 3 — A real Projects section
For senior engineers, the Projects section is often optional. For mid-level and junior engineers, it's frequently the difference between getting interviews and not. Why: when you don't have 10 years of job history to demonstrate range, your projects do the demonstrating.
A strong projects section includes:
- 2-4 projects, not 10. Each one with enough detail to be interesting; not a laundry list of weekend tutorials.
- Tech stack named explicitly per project. Same rule as Experience bullets — name what you built it with.
- Live demo or repo link. A clickable URL beats a description. Recruiters and engineers actually click these.
- One sentence on what makes it interesting. Why this project, not why you can build a CRUD app.
Example:
Projects
LSI Resume Analyzer · github.com/keko/lsi-analyzer
Open-source ATS resume scanner running entirely in-browser. Simulates 5 ATS
engines (Workday, Greenhouse, Lever, Taleo, plain-text) and produces a 6-axis
score with 19 diagnostic rules. Built with Next.js 15, pdf.js and TypeScript;
deployed on Cloudflare Pages with edge-runtime.
OpenTelemetry Collector for Bun · github.com/keko/otel-bun
First production-ready OTel exporter for Bun runtime; adopted by 4 OSS projects
in the Bun ecosystem. Written in TypeScript with Zig native bindings.
Two projects, but each one is concrete enough that an engineer reader can immediately tell whether you built something real.
Section 4 — The GitHub link
The single highest-signal item on an engineer resume is a working GitHub link in the page header. Not in the projects section — in the header, alongside email and LinkedIn. Recruiters click it. Hiring managers click it. ATS engines extract it as a contact field.
A few details that matter:
- The username should be searchable. "github.com/keko" is fine; "github.com/jdoe2847" is impersonal and harder to remember.
- The pinned repos should be your best work. First impression for any engineer who clicks. Pin 4-6 repos that demonstrate the range you want hired for.
- Activity should be visible. Empty contribution graph for the last 12 months reads worse than no GitHub link at all. If you don't push code outside work (legitimate), make sure your projects section makes up for it.
Side note: contribution graphs are not a perfect signal. Engineers at companies that block external GitHub or who do most work in private repos have legitimately empty public profiles. But if your resume claims you ship a lot of code, an empty profile contradicts the claim. Fix one or the other.
Modern engineering keyword vocabulary
The keyword universe for engineering roles in 2026 has shifted significantly from 2020. Some terms that used to be high-signal are now table-stakes; some that used to be cutting-edge are now expected baseline.
Still high-signal:
- Distributed systems vocabulary: event-driven, eventual consistency, CRDT, gossip protocol
- Modern infra: Kubernetes, Terraform, OpenTelemetry, eBPF
- Data engineering: streaming (Kafka / Pulsar), data warehouses (Snowflake, BigQuery, Databricks)
- ML infrastructure: MLflow, Kubeflow, model serving, vector databases
- Modern languages: Rust (especially for infra), Zig, TypeScript with strict mode
Becoming table-stakes:
- Cloud (AWS / GCP / Azure) — required, but no longer differentiating
- React / Next.js for frontend — required, no longer impressive
- Docker — assumed for any backend role
- CI/CD — assumed for any IC role above junior
Out of fashion (still acceptable but no longer high-signal):
- jQuery, AngularJS, Backbone (frontend)
- Java EE / Hibernate (backend; still common but the modern equivalent is Spring Boot or one of the JVM alternatives like Kotlin)
- Self-hosted CI servers (Jenkins) — many companies have moved to GitHub Actions or CircleCI
The full curated keyword library for software engineer resumes is available here — 85 hand-curated terms across the 30/30/25 core/secondary/tools tiers our analyzer scores against.
Common mistakes that cost interviews
- Skill-stuffing. Listing 60 skills you've barely used. Recruiters and ATS engines both notice; both penalize.
- No GitHub link, no projects. For mid-level and below, this is often the disqualifier. Even a small portfolio of real projects beats none.
- Bullets without tech names. "Built scalable systems" reads as marketing copy. Name the stack.
- Generic seniority claims. "Senior engineer with 10+ years" is weaker than "Built a 5-person platform team from scratch; shipped X, Y, Z over 3 years."
- Ignoring the JD. Engineering JDs are specific. A resume tailored to the JD's literal keyword vocabulary outranks a generic version every time.
Test your engineering resume
The free LSI Resume Analyzer scores engineering resumes against the curated software engineer keyword library, runs all five ATS engine simulators, and surfaces every issue with snippet + suggested fix. Drop your PDF, see in 4 seconds where you're losing score, and which specific keywords from the JD universe you're missing.
If you'd like to see how your resume holds up against each engine and which curated keywords are missing for your target role, the analyzer does both checks side by side.
Test your own resume against everything in this post
The free analyzer runs in your browser, simulates 5 ATS engines, and surfaces every issue with a snippet + fix. No signup, fully private.