Why Your Resume Gets Rejected in 6 Seconds (And How to Fix It)

A resume gets rejected in six seconds because that is roughly how long a recruiter looks before deciding whether to keep reading: about six seconds in TheLadders' 2012 eye-tracking study, 7.4 in its 2018 rerun. In that glance they read your name and title, your latest role and your skills. A layout the software cannot parse, or bullets with no outcome, lose you the read. The fix is a single-column layout, specific bullets with numbers, and lines you can defend, because the engineers who interview you will read the same page next.

What happens in the first six seconds

The same TheLadders research found that recruiters scan in predictable shapes, often an F-pattern: across the top third of the page, then down the left edge. So:

• Your name and current title must be visible at the top, without a logo or a photo pushing them down.
• Your most recent role gets the most attention, so its first two bullets should be your best two.
• Your skills should be scannable at a glance: a short block near the top, grouped by kind, not a paragraph at the bottom.
• Anything below the fold on page one is easy to miss entirely, so nothing that decides the read belongs there.

Notice what the scan is for. It is not a judgment of your career; it is a sort into "read properly" and "not now". Everything in the first third of the page exists to win the second, slower read.

What an applicant tracking system does with your file

Before a recruiter's glance, most applications pass through an applicant tracking system (ATS). It stores your file, parses its text into fields such as name, employers, dates and skills, and lets recruiters search and filter on them. Some setups add screening questions or rank applications against the posting. The common failure is less a robot rejecting you for one missing keyword than a parser that reads your layout wrong, so your experience lands in the wrong fields or never turns up in a search.

Ten formatting rules that keep you readable

1. One column, top to bottom.
2. A standard typeface at 10 to 12 points.
3. Margins of half an inch to an inch.
4. No graphics, icons, skill bars or photos.
5. One page if you have under about ten years of experience.
6. One date format throughout.
7. Bullet points, not paragraphs.
8. An action verb at the start of each bullet.
9. A measurable outcome wherever there honestly is one.
10. Keywords from the posting, used where they are true.

Bullets that survive the scan

The formula for a strong experience bullet is action, what you did, and a measurable result. Laszlo Bock, who ran People Operations at Google, put it this way:

"Accomplished [X] as measured by [Y], by doing [Z]."
- Laszlo Bock, former SVP of People Operations at Google, giving his formula for a resume bullet (LinkedIn, 2014)

Every bullet becomes an interview question

The resume's job does not end when a recruiter says yes. The engineers who interview you read it too, often in the minutes before the call, and the opening questions usually come from it. A strong bullet earns follow-ups; a vague one invites the ones you least want.

Take the first strong bullet above. It invites at least four questions:

• "How did you measure p99, and over what period?"
• "What was the bottleneck, and how did you find it?"
• "What was your part, and what did the rest of the team do?"
• "What did it cost you: complexity, money, a new way to fail?"

If you can answer all four for a couple of minutes each, the bullet is an asset: it hands the interviewer a story you know well, on ground you chose. If you cannot, the same bullet becomes the moment the interview turns, because a claim you cannot explain reads as a claim you did not earn. The more impressive the number, the harder the follow-up.

The defend-it test before you apply

1. Mark the three lines you would least like to be asked about. Those are the ones that will be asked.
2. Write the follow-ups for each and answer them out loud, timed. About two minutes an answer is right; longer usually means you are hunting for the point.
3. Rewrite any bullet you cannot defend. Make the number one you can explain, or replace it with what you actually did.
4. Check the verbs. "Led" invites a question about the people you led, "architected" about the options you rejected, and every technology in your skills block is fair game for a technical question.
5. Prepare the opening. Interviews that start from your resume usually start with "walk me through your background", so get "tell me about yourself" right first.

Practice the interview your resume will get

Reading your own bullets is not the same as being questioned on them by someone who wants specifics. A resume-based mock interview covers that part. Devana reads the resume you upload and runs a round built from it. Choose behavioral and you get three questions, each naming a real role or project from your resume and aimed at a different competency, such as ownership, a disagreement or a setback, with follow-ups. Choose coding and the two problems are framed in the domain of your work; choose system design and the problem is the one closest to systems you have built.

The file is read in memory and never stored, and it runs on the Free plan: 3 interviews a month of up to 20 minutes each. How a resume-based mock interview works shows every step. The aim is the same as the defend-it test, with someone else asking: find the line that falls apart after two follow-ups now, while you can still rewrite it.

Three guides go further. How to prepare for interview questions about your resume has a one-page template for each project and scripts for gaps; resume-based interview questions for software engineers gives fifteen of them with example answers; and how to practice a mock interview based on your resume covers every free way to rehearse.

Skills and keywords

Recruiters often search their applicant tracking system by keyword, so the words in the posting matter. If the job asks for Kubernetes three times and your resume never says it, a search for it will not find you, however much of it you have done. A systematic approach:

• Extract the keywords from the posting: languages, frameworks, tools, practices.
• Use them where they are true, inside your experience bullets, not stuffed into a hidden list.
• Write acronyms both ways: "Amazon Web Services (AWS)" matches either search.
• Group your skills by kind: languages, frameworks, databases, cloud, tools.
• Cut what you cannot discuss. A technology listed is a technology you may be asked about.

Education and certifications

With three or more years of experience, education is a single line near the bottom. For new graduates it can sit higher, with relevant coursework and projects. Certifications such as AWS Solutions Architect or Google Cloud Professional are worth listing when the posting asks for them, and are, again, something to be ready to talk about.

The pre-submit checklist

• Run it through a resume checker such as Jobscan to see how a parser reads it.
• Have a non-technical friend read it; if they cannot tell what you achieved, rewrite it.
• Check for typos, because an error near the top undermines everything below it.
• Check that every link works (GitHub, LinkedIn, portfolio) and that your GitHub has pinned repositories.
• Make sure you can talk for two minutes about every line, and that you have done it out loud.

Frequently asked questions