I Tested 35 Resume Summaries: Keyword-First vs Story-First

The professional summary is the three-or-four-line paragraph that sits at the very top of a resume, under your name, before any job history. It is the most-read and least-thought-about part of the whole document. People agonize over bullet points and then paste in a summary that says “Results-driven professional with a passion for excellence,” which means nothing to a machine and nothing to a human. I wanted to know what a summary should actually do, so I took 35 real summaries — mine and ones volunteers let me rewrite — and built each one two completely different ways. One version was keyword-first: lead with the exact skills and tools the job posting names, density over narrative. The other was story-first: a short arc of who you are and what you have built, written for a person to read. Then I scored every version against two judges that almost never agree — the applicant tracking system, and a human recruiter's first seven seconds.

Why the summary is a different problem than the bullets

I have written before about the bullet points in the experience section, where I ranked 30 resume bullets with 12 hiring managers and found that a concrete number beats a strong verb almost every time. The summary is not that. Bullets are evidence; the summary is a claim. A bullet earns trust by being specific about something you did. A summary's job is narrower and stranger: it has to get the resume past the first filter and then buy a few seconds of human attention so the bullets get read at all. Those are two separate gates with two separate gatekeepers, and the advice industry collapses them into one. “Put keywords in your summary” is half-right. “Tell your story” is also half-right. The interesting question is which gate each style actually clears, and what it costs at the other one.

How the test was built

For each of the 35 roles I had a real job description in hand — senior backend and platform engineering postings, the niche I know well enough to judge accuracy. For every one I wrote two summaries from the same underlying facts:

• Keyword-first. Front-load the posting's named technologies and responsibilities. Example opener: “Senior backend engineer, 8+ years in Python and Go on AWS. Event-driven systems with Kafka and PostgreSQL, Kubernetes and Terraform infrastructure, PCI-compliant payments.” Dense, scannable, slightly robotic.
• Story-first. Lead with the shape of the career and a signature achievement, technologies mentioned only where they belong in the sentence. Example: “I build payment systems that don't lose money or sleep. Over eight years I've taken a nightly-batch pipeline to sub-two-second streaming and cut a team's deploys from fifty minutes to fifteen.”

Both versions used only true facts about the same person; the difference was ordering and voice, not honesty. To judge the ATS gate I ran each resume — same body, swapped summary — through a keyword-and-formatting checker and recorded its match score. To approximate the human gate I did two things: I timed how long it took a reader to say what the candidate did (a rough proxy for the seven-second scan), and across my own live applications I tracked which summary style was attached when a recruiter screen actually came back. Three weeks of replies is a snapshot, not a law, so I weigh the pattern over the exact percentages.

The ATS gate: keyword-first wins, and it is not close

This part was predictable but worth quantifying. The applicant tracking system does not read for meaning; it reads for matches. A summary that names Kubernetes, Terraform, and PostgreSQL in the first line raises the document's keyword-match score immediately, because the summary is the densest real estate on the page and the parser weights the top of the document. Here is one of the keyword-first resumes run through the resume ATS score checker against its matching job description:

The keyword-first version scored 80/100, and the green/red grid shows exactly which posting terms the summary and body carry — and which three are still missing.

That 60% keyword-match figure and the grid underneath it are the whole ATS story in one frame: every green tile is a posting term the parser found, every red one is a term it wanted and could not see. Moving three of those missing words into the summary's first sentence — words the candidate genuinely owned — pushed several test resumes from the high-70s into the mid-80s without touching a single bullet. The story-first versions of the same resumes scored four to nine points lower on average, purely because their opening sentence spent its prime keyword space on voice (“don't lose money or sleep”) instead of on the terms the machine was hunting for. If the ATS were the only judge, the verdict would be simple: write like a robot, win the robot.

The human gate: keyword-first quietly loses

It is not the only judge. A real recruiter's first pass over a resume is famously fast — eye-tracking work puts the initial scan in the single-digit seconds, and decades of reading research show people barely read at all on a first pass: Nielsen Norman Group's data finds readers consume only a fraction of the words on a page and concentrate that attention near the top, which is exactly where the summary lives. So the summary gets the scarcest thing in hiring: undivided human attention, for about as long as it takes to read this sentence. And here the keyword-first version stumbles. When I handed readers the dense, comma-spliced opener, they could recite the technologies but not the person — “backend, AWS, Kafka, something payments” — and several said it read like a tag cloud, the resume equivalent of someone listing their skills at you instead of talking. The story-first opener, by contrast, got the candidate described back to me as a coherent human in one breath: “payments engineer who makes pipelines fast and reliable.” That is the difference between a summary that gets parsed and one that gets remembered three resumes later when the recruiter is deciding who to call.

The reply data, thin as a three-week sample is, leaned the same way once the resume cleared screening: among applications that got a human response, the openers people could actually repeat back were over-represented. The ATS does not care about that. The person who decides whether to schedule you cares about almost nothing else.

So the two gates want opposite things — except they don't

The tidy conclusion would be “keyword-first for robots, story-first for humans, pick your battle.” That is wrong, and finding out why was the useful part of the experiment. The two gates only look opposed if you treat the summary as one sentence. It is three. The fix that beat both pure styles on every test resume was a hybrid with a fixed structure:

1. First sentence — keyword-dense identity. Role, years, and the three or four exact terms the posting weights most. This is the line the ATS reads hardest and the line a human reads first. It can carry both loads because identity claims are naturally keyword-shaped: “Senior backend engineer, 8 years in Python and Go on AWS” is dense and human.
2. Second sentence — one concrete proof. A single number-bearing achievement, told like a person would say it: “built the Kafka pipeline that took data latency from nightly to under two seconds.” This is the story-first move, compressed to one line, and it is what makes the candidate repeatable.
3. Optional third — direction. What you want next, in the posting's language, so the reader closes the summary already filing you under the right req.

That structure scored within a point or two of the pure keyword-first version on the ATS — because the first sentence still carries the term density — while reading like a human wrote it, because the second sentence is a story, not a list. It is not a compromise that loses at both gates; it is a layout that wins at both, because it stops asking one sentence to do two jobs and gives each job its own line.

How to actually write the first sentence

The whole thing hinges on getting the keyword-dense identity line right, and that line fails most often because people guess at which terms to include. They pack in everything they have ever touched, the summary balloons to five lines, and the parser's signal-to-noise drops — the checker above even flagged “no excessive buzzwords” as a thing it specifically watches for, because stuffing is a known failure mode, not a strategy. The discipline is to include only the terms this posting weights and you genuinely own. The fastest way I found to get that list is to pull it straight from the job description before writing a word: paste the posting into the job description keyword extractor, take the technical terms it surfaces, keep the ones that are true of you, and build the first sentence around those three or four. I leaned on the same extractor when I split 40 applications between Easy Apply and company sites and found that tailoring — not the channel — was what actually moved replies. The summary is where that tailoring is cheapest and most visible: one sentence, rewritten per posting, doing more work than the rest of the page.

Two failure modes to avoid, both of which the checker will catch before a recruiter does. First, the buzzword summary — “dynamic, results-oriented self-starter” — which carries zero posting keywords and zero human information; it is pure filler and the parser sees nothing in it. Second, the keyword-vomit summary that is technically dense but unreadable, where you have listed fourteen technologies and the human gate slams shut even though the ATS score looks great. The hybrid structure exists precisely to sit between those two ditches. For more on how the screening pass reads a resume top-to-bottom, the U.S. government's own guidance on what a resume should include is a useful sanity check on length and section order, since federal systems are some of the strictest parsers you will ever hit.

What I changed on my own resume

I rewrote my summary into the three-line hybrid and stopped maintaining two versions. The keyword-first-only summary was getting me past the ATS and then dying on the recruiter's desk; the story-first-only one read beautifully and sometimes never got parsed far enough to be read at all. The hybrid is the only version that survives both. Concretely:

1. Line one is now a keyword-dense identity statement, rebuilt per posting from the extractor's output, never a generic adjective in sight.
2. Line two is a single proof with a number, the most repeatable thing I have done, phrased the way I would say it out loud.
3. I run the finished resume through the checker before sending, and if the keyword match is under about 70% I move one true missing term into line one rather than padding the bullets.

The summary stopped being the part of the resume I dreaded and became the part I tune first, because it is the highest-payoff sentence on the page: read hardest by the machine, read first by the human, and rewritable in under a minute once you know which words belong in it.

The honest summary of the summary: across 35 rewrites, keyword-first reliably won the machine and quietly lost the human, story-first did the reverse, and a three-line hybrid beat both at once by giving the parser its dense first sentence and the recruiter its repeatable second one. Write the identity line for the robot, the proof line for the person, pull the keywords from the posting so the first line is never a guess, and you stop having to choose which gate to lose.

If you want the pieces that make this fast, the resume ATS checker and the job keyword extractor pair naturally — one tells you which terms the posting wants in that first line, the other tells you whether a parser can actually find them once you put them there.