What’s actually wrong with most software engineer resumes (and how to fix it)

Here’s what I keep seeing: candidates who can explain a distributed system clearly in a mock interview, but their software engineer resume says “worked on backend microservices.” That gap between what someone can do and what their resume communicates is, in my experience, the most common reason good engineers don’t get past the screen.

This post goes through the mechanics of fixing that. Not templates. Not “use action verbs.” Actually useful specifics.

A quick note on scope: I’m focused on individual contributors applying for mid-to-senior IC roles at product companies. Staff+ and management resumes are a different conversation.

How much time your resume actually gets

The Ladders eye-tracking study found recruiters spend an average of 7.4 seconds on the first pass of a resume. They updated this in 2018 using actual hardware eye-trackers on professional recruiters, not a survey. That number gets cited a lot, sometimes dismissively, but it maps to what we observe too: a recruiter at a company getting 500 applications for one SWE role is not reading your third bullet point about code reviews.

What they do look at in those seconds: your most recent company name and title, the top bullet under that role, and your skills section. That’s most of the 7.4. So the structural implication is that your best, most specific achievement needs to be the first bullet under your most recent job. Not second. First.

Separately: the BLS projects software developer employment to grow 15% through 2034, which is faster than most occupations. That’s a real demand signal, but it doesn’t mean the 2026 market is easy. Entry-level and mid-level roles are competitive in a way they weren’t in 2021. Your resume has to work harder.

The bullet problem

Most resume bullets describe a responsibility, not an achievement. The difference matters a lot.

Responsibility-framing sounds like:

Achievement-framing sounds like:

The second one tells me what you actually did, at what scale, and how you thought about the problem. It also tells me you know what a full table scan is, which is a meaningful signal for a backend role.

The formula for this is sometimes called XYZ: accomplished X, measured by Y, by doing Z. I think the formula framing is a bit rigid, but the underlying idea is right. You want a number, or at minimum a scope signal, and you want a brief “how.”

“I don’t have numbers” is the most common pushback. You probably do, you just haven’t looked. Ask yourself: how many users touched this feature? How much did latency change? Did test coverage go up? Did deployment frequency change? If you genuinely can’t find a number, scope indicators work: “platform-wide,” “across 4 engineering teams,” “serving 3 internal product lines.” That’s better than nothing.

Structure: what goes where

For most engineers, the right order is: contact info, work experience, education, skills. That’s it. The skills section goes at the bottom, not the top. I know some templates put it first; I think that’s wrong for anyone with more than a year of experience. Recruiters want to know where you’ve worked and what you shipped.

A few specific rules that are worth stating clearly:

• One page for most people. Two pages is fine if you have 10+ years of directly relevant experience. Three pages is never fine for an IC software engineer resume.
• Your most recent role gets the most bullet points (4-6). Roles from 5+ years ago get 2-3.
• GPA only if it’s 3.5+, you’re within 3 years of graduation, and you’re applying somewhere that actually cares (Jane Street, D.E. Shaw, some quant shops). Most product companies don’t look at it.
• No objective statement. “Seeking a challenging role where I can grow” tells the recruiter nothing and uses space you need for another bullet point.
• No soft skills in the skills section. “Communication, teamwork, leadership” in a list next to Python and Kubernetes looks odd. If you want to demonstrate those qualities, they belong inside a bullet point with an actual example.

Projects section: include it if you’re entry-level or if you have a meaningful gap in employment. Skip it if you have 3+ years of relevant work experience, because those slots are better used for additional experience bullets.

ATS is real but people overcorrect

ATS systems (Greenhouse, Lever, Workday, iCIMS) do parse resume text and some do keyword matching. But most software engineers I talk to have the opposite problem from what they think: they’re not failing ATS because of their layout. They’re failing the human screen because their bullets are too vague. Fix the bullets first.

That said, a few formatting rules that do matter for ATS:

• Single-column layout. Multi-column resumes with tables or text boxes parse unpredictably in Workday especially.
• PDF with selectable text. Not an image PDF. Paste your resume text into a plain text file and check if it’s readable. That’s roughly how ATS sees it.
• Use the exact technology names from the job description. If they write “Kubernetes” and you wrote “k8s,” that can miss a keyword match depending on the parser.
• Standard section headers: Experience, Education, Skills. Not “Where I’ve Worked” or “Things I Know.” Some parsers are brittle.

The skills section is not a keyword dump

I’ve seen resumes with 47 technologies listed in the skills section. That’s not more impressive. It’s actually suspicious, because it implies you’re either lying or you listed every technology you touched once in a tutorial.

A reasonable format:

Tailoring: how much actually matters

You should maintain one strong base resume and make small adjustments for each application, specifically: reordering bullet points so the most relevant achievements lead, and checking your skills section against the job description for exact keyword parity.

Full rewrites for each application are not realistic and probably not necessary. The companies where it would matter most (FAANG, Stripe, Notion, that tier) have enough applicants that small keyword differences won’t be the deciding factor. What matters is whether your bullets are specific and whether your experience level genuinely matches the role.

One opinion I hold that I think is a little contrarian: I don’t think “tailoring” is the bottleneck for most people. The bottleneck is that the underlying bullets are weak. Tailoring a vague resume just means you’re submitting a slightly differently-ordered vague resume to each company.

What we see in resume-to-interview gaps at LastRound AI

This is qualitative rather than a hard number, but it’s consistent: when we work with candidates using our interview copilot, we often see a real gap between how clearly they explain their past work in an interview versus how it reads on their resume. Candidates who can walk through an architectural decision with real tradeoffs in a live session often have a resume bullet that says “improved system reliability.” Same project, very different signal.

That gap matters because a recruiter reading your resume has no way to ask follow-up questions. The resume is your only shot at communicating the thinking behind the work, not just that the work happened. The candidates who close that gap, by writing bullets that include a specific technical decision and a measurable result, tend to get further in screening than their peers with similar actual experience.

Quick mistakes worth calling out

A few things that come up constantly:

• Starting every bullet with “Responsible for.” It’s passive framing. Start with an action verb: Built, Led, Reduced, Migrated, Shipped, Redesigned.
• The tech laundry list bullet. “Used React, Redux, TypeScript, Node.js, Express, MongoDB, Docker, Kubernetes…” I still don’t know what you built or whether it worked.
• Including jobs from 10+ years ago that aren’t relevant. That customer service role from 2013 is taking space from another achievement bullet in your most recent role.
• Listing Microsoft Office. It’s 2026. Remove it.

The GitHub question

Worth including your GitHub link if you have 3-5 pinned repos with real READMEs, where “real” means someone could understand what the project does and why in under two minutes. Leave it off if your pinned repos are mostly tutorial clones or half-finished side projects you abandoned. Recruiters do click through, and an empty or messy profile creates a negative signal that wasn’t there before they clicked.

The contribution graph doesn’t matter to most hiring teams. A few companies specifically look for consistent activity, but they’re the exception.

Before you submit

Once you get past the resume screen, you’ll want to be able to talk through everything on that page clearly and under pressure. That’s a different skill set. The two posts I’d recommend reading next: our breakdown of how to pass coding interviews and the FAANG interview questions we see in 2026. And if behavioral rounds are what’s tripping you up, the “tell me about yourself” breakdown is worth reading before your next screen.