All articles
Career/

The software engineer resume
that gets past big-tech screening

9 Minutes read
Jobiz Team

Jobiz Team

Product Team

Share this article


Annotated software engineer resume showing the six sections in order with what matters most highlighted and the common mistakes crossed out
Summary

Every engineering resume looks the same, which is the whole problem. Here's the specific structure that actually gets read, with what to cut and what to add.

Open ten software engineering resumes in a row and a pattern emerges. Same structure, same phrases, same bullets. "Developed scalable backend services using [stack]." "Collaborated with cross-functional teams to deliver features." "Improved performance and reliability."

The recruiter glazes over by the third one. By the tenth they're scanning for anomalies, not signal: anyone who looks slightly different from the template is getting more attention than the ones who look like the template.

This post is about how to be in the second group. Not by being weird for the sake of it, but by making the specific editorial choices that separate a readable engineering resume from a generic one. What to cut, what to add, and where the signal actually lives.

The sections, in the order they should appear

For most engineering roles, the correct section order for a one- or two-page resume is:

  1. Header: name, one-line role, contact, links (GitHub, LinkedIn, portfolio if relevant)
  2. Summary: 2–3 sentences, optional but usually worth having
  3. Experience: reverse chronological
  4. Projects: only if they're strong and recent
  5. Education: later in the document for anyone with 3+ years of experience
  6. Skills: at the bottom for most candidates; at the top only for junior roles

This is the US/Anglo convention. For DACH markets, reorder (see the country-specific guide). The structure below assumes Anglo conventions.

Header: the part you get wrong fastest

Your header is roughly 10% of the visual real estate. It gets read in the first half-second. Surprisingly many engineers waste it.

What belongs:

  • Name (bold, largest)
  • One-line role description ("Senior Backend Engineer · Distributed Systems")
  • City + country (not full address)
  • Email
  • GitHub username, LinkedIn, one portfolio link if relevant
  • Nothing else

What doesn't:

  • Photo (in Anglo markets: see country guide)
  • Full address
  • Date of birth
  • Nationality
  • A "personal statement" that's actually a paragraph
  • Marital status (don't laugh, still happens)

The one-line role description is the most useful element most candidates skip. "Software Engineer" tells the reader nothing. "Senior Backend Engineer · Distributed Systems" tells them what kind of engineering you actually do. This is your positioning in five words.

Summary: the case for including it

Engineering resumes often skip the summary. That's usually a mistake. Two or three sentences at the top give the reader context before they dive into bullets.

Weak summary:

Software engineer with 7 years of experience building scalable applications. Passionate about clean code and mentorship.

That describes 400,000 engineers. It's a negative-information sentence.

Stronger:

Senior backend engineer with 7 years at B2B SaaS companies, focused on platform work. Led the migration of Acme's billing service from monolith to event-driven architecture (40M daily writes). Most comfortable in the systems-design layer; weakest at frontend.

The stronger version tells you exactly what they do, one specific achievement, and even (unusually) a real weakness. This is memorable. The generic version is not.

The summary is also where you name the pivot, if you're making one. "Returning to IC backend engineering after three years as EM; looking for a senior+ role at a systems-focused company." One sentence. Removes the question the reader was about to ask. For the structural breakdown of what makes a summary land, see the three-line resume summary that works.

Experience: where the real work is

Three rules for the experience section.

Rule 1: lead each role with the scope, not the role description

Don't make the reader piece together what you did. State it upfront.

Good:

Senior Engineer · Acme Corp · 2022 – Present Backend platform team (7 engineers). Owner of the billing and payments service: 40M daily events, 99.95% uptime target.

Bad:

Senior Engineer · Acme Corp · 2022 – Present Responsibilities included designing and implementing backend services...

The good version tells the reader what you owned and at what scale in one line. The bad version makes them read bullets to figure it out.

Rule 2: bullets are about outcomes, not activities

Most engineering bullets describe activity ("developed," "implemented," "deployed"). Strong bullets describe outcome ("reduced p95 from 180ms to 62ms," "eliminated 3 weekly on-call pages," "cut infra cost by $180K/year").

The test: can someone other than you have shipped the same thing? If yes, the bullet is too generic. Add the specific thing your version did that theirs wouldn't.

Bad:

Improved the performance of the billing service.

Better:

Reduced billing webhook p99 from 800ms to 120ms by batching DB writes; eliminated the Monday-morning pager spike.

The better version is not longer; it's specific. Numbers, specific systems, specific outcomes.

Rule 3: 3–5 bullets per recent role, 2–3 for older ones

The most recent role gets the most space. The role five years ago gets less. Don't give equal weight to every role: the reader doesn't care about 2018 the way they care about now.

If you've been at your current company for more than 3 years, break it up by internal role if possible:

Acme Corp · 2019 – Present Staff Engineer · 2023 – Present [bullets] Senior Engineer · 2019 – 2023 [bullets]

This shows growth and gives you more room to demonstrate scope.

Projects: when to include them

Projects belong on your resume in three cases:

  1. You're early-career and your work history is thin. Projects show you can build things.
  2. You're pivoting into engineering from another field. Projects are proof of capability.
  3. You have a truly impressive personal project: open source with significant users, a tool that shipped to real customers, something widely cited.

Projects do not belong on your resume if:

  • They're "tutorials I followed" (to-do apps, calculator, the same Twitter-clone everyone builds)
  • They're stale (last commit three years ago)
  • They're hosted on a dead link

A one-line project entry that goes to a github repo which shows three commits from 2021 is actively negative signal. Either the project is strong and current, or it's off the resume.

For senior engineers with strong professional experience, the project section is usually optional and often skipped entirely.

Education: shorter than you think

For engineers with 3+ years of professional experience, education is a 2–3 line entry near the bottom.

BSc Computer Science · Carnegie Mellon · 2015

Maybe one more line if you have a distinction, relevant coursework that's not obvious, or a thesis that's directly relevant to the work you want. That's it.

Do not include:

  • High school
  • Individual courses (unless they're graduate-level and directly relevant)
  • GPA, unless you're in your first year or two out and it was high (>3.5/4.0)

For career-changers who did a bootcamp, list it as education (or in a dedicated "Education & Training" section). Bootcamps are well-understood by most recruiters in 2026 and don't need defending.

Skills: the least important section

Controversial take: the skills section is the least useful part of most engineering resumes, and yet it's the one candidates spend the most time agonizing over.

Why it's low-value: if the skill is real, it's already in your bullets. "Led the migration to Kafka" implies Kafka expertise more credibly than a skills line saying "Kafka." If the skill is not in your bullets but only in the skills section, it reads as aspirational.

The section is still worth having, briefly, because ATS systems sometimes scan for specific keyword tokens and a skills section ensures they find them. Keep it minimal and accurate:

Languages: Go, Python, TypeScript Infrastructure: Kubernetes, AWS (EC2, S3, RDS), Terraform Data: Postgres, Redis, Kafka, ClickHouse

Three or four category lines. Don't pad.

Do not:

  • List every language you've ever touched
  • List soft skills ("leadership," "communication," "problem-solving")
  • Rate yourself out of 5 stars or percent-proficiency. It's meaningless and reads as junior

The anti-patterns

Specific things recruiters actively filter out:

The "scalable" epidemic. "Built scalable microservices." Every engineer says this. It no longer means anything. If you built something that handled scale, say what scale: "handled 12K RPS at steady state." For a full list of the verbs and adjectives that drain signal, see resume action verbs: most lists are wrong.

The "team player" section. Adjectives like collaborative, driven, passionate, detail-oriented belong nowhere on an engineering resume. If they're true, your bullets will show it. If you need to claim it, you don't have evidence.

Tech stack soup. A skills section listing 40 technologies. The reader assumes you're shallow in most of them. Fewer, more credible.

Self-taught TypeScript certifications. A one-week Udemy certificate on your resume subtracts signal. If it's from Coursera and it's a 3-month program from a real university, that can stay. "Udemy TypeScript" should not.

Buzzword soup in the summary. "Passionate engineer leveraging cutting-edge technologies to deliver innovative, scalable solutions." Delete.

Over-decoration. Three columns, four colors, icons next to every section. ATS will mangle it, and human readers will skim less of it than a clean one-column layout.

The one-page vs two-page question

Under 10 years of experience: one page. Not because "one page is law", but because if you can't make 6–8 years fit into one page, the resume isn't edited tightly enough. Forcing yourself to one page produces better editing.

10+ years: two pages is fine. Three is too many. Keep ruthlessly current: the role from 2012 does not need four bullets. It needs one, or nothing at all.

The meta-point

A lot of engineering resume advice is optimization around the wrong thing. Candidates worry about font choice, column count, whether to include hobbies. None of that moves the needle.

What moves the needle is: specific, scope-forward bullets with real outcomes, a summary that positions you as someone specific rather than generic, and the discipline to cut everything that isn't pulling weight. Do those three things and you're already above the median engineering resume a recruiter will see this week.


If drafting from scratch for every role is what's burning the time, Jobiz handles the per-application adjustments so you're editing sentences, not formatting paragraphs.


Get career tips in your inbox
Join thousands of job seekers getting weekly insights on landing their dream job.

No spam. Unsubscribe anytime.

Related Articles