The Software Engineer Resume

Software engineering resumes are scanned in two stages. First, a recruiter scans for stack keywords and rough seniority. Second — if you pass — a technical reviewer scans for evidence of ownership and impact. The resume has to satisfy both readers in under two minutes.

Here is what each of them is looking for, and how to give it to them.

Stage one: the recruiter scan

A recruiter with a role open is scanning for specific signals:

• Stack match. The languages, frameworks, and platforms the role requires. If the job is Go and Kubernetes, the resume needs to mention Go and Kubernetes. If it does not, the recruiter will not infer "but they probably know it".
• Seniority signal. Years of experience, team sizes, scope of roles. A recruiter has to place you in a band fast.
• Company signal. Familiar employers reduce risk. Startups and known tech companies both help; unknown companies need a supporting bullet that clarifies scale.
• Education and credentials. A CS degree is often a filter — not a hard requirement, but a factor. If you do not have one, make your work legible enough to compensate.

What makes the recruiter scan hard: stack buried inside prose. If "Kubernetes" only appears in the fourth bullet of the third role, the recruiter will miss it. Put the stack in a Skills section, and use it naturally in bullets.

Stage two: the technical reviewer

Once the recruiter passes you through, an engineer or engineering manager reads the resume. They are looking for evidence of four things:

• Ownership. Did you own something end-to-end, or did you contribute to something someone else owned? "Designed and built" vs "worked on" is the difference.
• Systems thinking. Can you talk about trade-offs, reliability, scale, cost? Bullets that mention these signal a senior engineer.
• Impact. Did your work change something measurable? Latency, cost, deploy time, error rate, user retention, revenue. Numbers make impact verifiable.
• Breadth and depth. What is your primary stack, and what else can you work in? Reviewers look for a shape, not a checklist.

Bullets that work

The strongest engineering bullets combine three things:

• What you built — the concrete technical work.
• What it changed — the measurable outcome.
• How you built it — the technologies that make it legible.

Example: "Designed and shipped a feature-flagging service in Go backed by PostgreSQL, used by 200+ engineers across the org. Reduced rollout time from days to minutes and removed 6 months of legacy deploy scripts."

Every part of this bullet is doing work. The role can see what you built, what it does, what it is written in, and what it replaced.

Bullets that do not work

These patterns read as weak even when the underlying work was strong:

• "Worked on the payments team." — No ownership, no outcome, no scope.
• "Improved system performance." — No metric, no starting point, no target.
• "Responsible for maintaining services." — Presence, not outcome.
• "Wrote code in React, TypeScript, and Go." — Stack declaration, not a result.
• "Collaborated with cross-functional teams." — True but generic; every engineer says it.

Each can usually be rewritten to carry a stronger signal. "Worked on the payments team" becomes "Designed and shipped the reconciliation pipeline processing 4M+ daily transactions at 99.98% accuracy".

The Skills section

Group skills by category for readability:

• Languages: Go, Python, TypeScript, SQL
• Frameworks: React, Next.js, Django
• Infrastructure: Kubernetes, Terraform, AWS (EKS, RDS, S3)
• Databases: PostgreSQL, Redis, BigQuery
• Tools: GitHub Actions, Datadog, Linear

Only list what you would be comfortable being interviewed on. Padding the skills section with tools you have touched once is one of the most common engineering resume mistakes.

Projects worth including

For early-career engineers, projects can carry the resume. But only some projects earn space:

• Shipped projects with users — anything deployed and used by anyone real, even if small.
• Open-source contributions with merged PRs — especially to projects the team would recognize.
• Technical projects that demonstrate depth — a compiler, a distributed cache, a query engine, a WASM runtime.

Course work that only ever ran on your laptop does not earn space unless it demonstrates something specific. Hackathon wins count, but only if the project itself has substance.

Length and format

One page for engineers below staff level. Two pages for staff, principal, or engineering managers with significant team scope.

Single column is safest for ATS. Two-column is acceptable but can break parsing in older systems — if the role uses Workday or Taleo, go single column.

No photo. No skills bars. No infographic timers. These are decorative and often misread by ATS.