The 7 things that quietly get a software engineer's resume auto-rejected (and the fixes)

Noam Livnat — Fri, 26 Jun 2026 23:59:20 +0000

Most rejections aren't about your code. They're about a resume that fails before a human reads it. It gets filtered out by the ATS (the software that screens applications), or skimmed past in a few seconds once a recruiter does open it.

I review a lot of software engineering resumes, and the same handful of mistakes show up over and over. Almost none of them mean you're a weak engineer. Here's the list with concrete fixes, plus a section at the end for engineers whose first language isn't English, which almost nobody covers.

1. Two-column layouts and text boxes can break the parser

Those clean two-column templates with a skills sidebar look great to you, and they can scramble on some parsers. The same goes for content inside tables, text boxes, headers/footers, or graphics. Many parsers read top to bottom, left to right, so a sidebar gets interleaved into your bullets or dropped. The real problem: you have no way of knowing which ATS a given company runs, so single column is the rational default.

Fix: single column, plain text, standard headings (Experience, Education, Skills, Projects). Put your name and contact in normal body text, not in the document's header region. To see what the machine sees, copy-paste your PDF into a plain text editor. If it comes out jumbled, so does the parse.

2. Your bullets describe duties instead of results

This is the difference between a callback and silence. "Responsible for maintaining backend services" tells me your job title. It tells me nothing about whether you were good at it.

The pattern that works: lead with the outcome, put a number on it, then name the technical move.

Before: Responsible for backend services and improving performance.

After: Cut p99 read latency 40% by adding a read-through cache, holding a 3x traffic spike on the same hardware.

You don't need a number on every line. "Reduced deploy time from 25 min to 4 min" works. A specific honest estimate beats a vague true statement.

3. Weak verbs make strong work sound passive

Words like assisted, helped, worked on, participated in, responsible for, and utilized make you sound like a bystander. Swap them for verbs that say you drove the work: built, designed, architected, automated, reduced, migrated, shipped, debugged, optimized, owned.

Before: Helped with migrating the monolith to microservices.

After: Migrated 4 high-traffic services out of the monolith, cutting deploy blast radius and unblocking independent releases.

4. The skills section is a keyword dump

Listing 40 technologies in one wall tells me nothing about depth, and a human reading 40 flat keywords assumes you're padding.

Fix: group them (Languages / Frameworks / Infra & Tools / Databases) and only list things you could defend in a follow-up. Then match the exact stack string from the job description if it's genuinely true for you ("PostgreSQL," not "Postgres," if that's what the posting says).

5. One generic resume blasted at every job

The same resume sent everywhere matches nothing in particular. Recruiters search the ATS for the posting's terms, so the true ones need to be in yours. Tailoring isn't a rewrite, though. It's usually reordering your bullets so the most relevant ones sit at the top, and swapping two or three terms to match the posting's language. Ten minutes, not an hour.

6. If English isn't your first language, a few specific patterns quietly give you away

This rarely gets covered, so I'll be concrete. Strong international engineers lose callbacks not because of accent, but because translated-sounding phrasing makes a recruiter see them as a riskier hire before the technical screen. The technical content is almost always there. It's the phrasing carried over from textbook English or word-for-word translation. The patterns I see most, with rewrites:

"Responsible for" everywhere. A safe textbook construction in many languages; in a US resume it reads passive. Replace it with an action verb and a result.
Over-formal calques. "I have realized a system for the monitoring of the servers." In US tech writing "realized" reads as "became aware of," not "built," so it sounds wrong here. English also wants "server monitoring system," not "system for the monitoring of the servers." Fix: "Built a server-monitoring system that cut incident detection from 15 min to under 1 min."
Articles and prepositions. "Developed feature for improve the performance of database" becomes "Developed a feature that improved database performance by 35%." Small on its own, but it stacks across 15 bullets, and the cumulative read is "this needs editing."
Tense drift. "Lead a team of 4 and design the CI pipeline" becomes "Led a team of 4 and designed the CI pipeline, cutting build time 60%." A past job stays in past tense throughout.
Vague intensifiers instead of numbers. "Significantly improved the performance of the API" becomes "Cut p99 API latency 40% by adding a Redis cache." A number is stronger, shorter, and sidesteps the grammar.

Quick self-check: read every bullet out loud. The stiff or telegram-sounding ones are usually the calques. Tools like LanguageTool catch the article and preposition slips, but they won't catch "realized" used to mean "built." That needs a careful reread or a native-English pass.

Two more things that trip up international applicants. Skip the photo, icons, and skill-level bars common on European resumes; they parse as nothing, and US employers often discard resumes with photos to avoid any appearance of bias. And state your work authorization plainly near the top if it's relevant.

7. One page, ordered by impact, no filler

Under ~10 years of experience, keep it to one page. Within each role, order bullets most-impressive-first, and assume the reader stops after two. Drop the objective summary unless you're making a non-obvious pivot. Drop "References available on request." Drop soft skills from the skills section; show them in your bullets or leave them out.

The one-question gut check

For every line, ask: "would a hiring manager skip the interview and just believe this?" If a bullet is a duty rather than evidence, rewrite it as evidence or cut it.

Turning one "responsible for X" line into a results line usually does more than any other single change, and it's easier to spot on someone else's resume than your own. Happy to look at a weak bullet if you drop one in the comments.

DEV Community: Noam Livnat