Writing the Experience Section for an AI Screener

A software engineer applies to fifteen companies through their corporate ATS portals. Eleven of them produce no response within two weeks. Three produce a polite no within three days — too quick for a human to have read carefully. One generates an interview. Looking at the pattern, the engineer concludes — correctly — that most of the applications never reached a human screener. They were filtered by software, against criteria he didn't fully understand, before any person had a chance to read them.

The first reader of your resume is increasingly an applicant tracking system or an AI screener. The good news is that what the software wants and what a thoughtful human reader wants are 80% the same thing — concrete, scoped, dated, keyword-relevant. The 20% where they diverge is what trips most candidates.

TL;DR

• Use the keywords from the job description — but as accurate descriptors of what you actually did, not as stuffed filler.
• Format ATS-safe: single column, standard fonts, no tables, no headers/footers, no images of text.
• Lead with action verbs in past tense (or present for current role); name the system you worked on; quantify the outcome.
• Match section names to the conventions the ATS expects: Experience, Education, Skills.
• Make every claim checkable. ATS-passing isn't winning; it's clearing the bar to be read by a human.

The situation

You're applying through corporate ATS portals where your resume is parsed by software before any human sees it. The software is looking for specific signals — keywords from the job description, role titles that match what they're hiring for, verifiable structure that maps cleanly into their database fields. The five moves below get your resume past the software in a way that doesn't make it worse for the human screener who reads it next.

(Quick parallel resource: KredVault's free ATS Resume Scorer tells you specifically what the software is reading and what it's missing in your resume — a faster diagnostic than guessing at it.)

1. Use the job description's keywords — as accurate descriptors

Action. Read the target job description carefully. Identify the specific terms that appear: tools ("PostgreSQL," "AWS Lambda," "Looker"), methods ("agile," "experimentation," "ICP analysis"), responsibilities ("P&L ownership," "stakeholder management," "team leadership"). Use the same vocabulary in your resume — but only where it accurately describes what you actually did.

Why it works. ATS systems match candidate resumes against the job description by looking for term overlap. A resume that uses the JD's vocabulary scores higher, gets surfaced to recruiters more often, and is more likely to be read by a human. The matching isn't sophisticated — it's literal token overlap, weighted by section. Using "PostgreSQL" instead of "relational database" matters when the JD says PostgreSQL specifically.

Done right. If the JD says "experience with experimentation frameworks like Optimizely or LaunchDarkly" and you've used LaunchDarkly, the bullet should say "Built and ran A/B experiments using LaunchDarkly across 4 product surfaces, including [specific feature]." The keyword is the same as the JD's; the surrounding text is your actual specific work.

Common mistake. Keyword stuffing — listing terms without context, or claiming experience with tools you've barely touched. Two problems with this. First, human screeners notice and discount the resume. Second, you'll be asked about those keywords in the interview, and "I listed it but haven't really used it" loses you the role faster than not listing it would have. Use the keyword if and only if the underlying claim is true.

2. Format ATS-safe

Action. Use a single-column layout. Standard fonts (Calibri, Arial, Georgia, Helvetica). No tables, no text boxes, no headers or footers, no images, no graphics that contain text. Standard section names: Experience, Education, Skills, Summary. The .docx or .pdf you upload should be machine-parseable from top to bottom.

Why it works. ATS parsers strip styled formatting and pull text in reading order. Multi-column layouts break the parser — it reads across columns row-by-row, producing garbled text. Tables sometimes parse, sometimes don't. Headers and footers often get dropped entirely. Custom section names ("My Journey" instead of "Experience") fail to map to the ATS's database fields, so the experience never makes it into the searchable record. The visual flourishes that look good in print are exactly what breaks the machine reading.

Done right. A single-column document, standard fonts, standard section headers, all text in the document body. The visual hierarchy comes from bold and size, not from layout tricks. The resume looks unfancy on the page — that's the cost of being machine-readable, and it's worth it.

Common mistake. Optimizing for visual impression at the expense of machine readability. A two-column resume with a sidebar showing your skills as colored bars looks creative; it parses as gibberish. The hiring manager will never see the parsed gibberish, but the system uses it to decide whether to surface your resume at all.

3. Lead with action verbs, name the system, quantify the outcome

Action. Structure each bullet as: action verb (past tense) + specific system or scope + measurable outcome with a date. The verb tells the system what kind of work it was; the system grounds it; the outcome makes it concrete.

Why it works. Both the ATS and the human screener look for the same signal — action that produced a result. The ATS uses verbs to categorize the bullet's function; the human uses the outcome to decide whether the candidate is interesting. The combination of both — specific verb plus specific system plus specific outcome — satisfies both readers in the same line.

Done right. "Migrated the customer billing pipeline from a single-instance Postgres to a sharded Aurora cluster, completing the cutover in March 2024 with zero customer-visible downtime and reducing P95 query latency from 340ms to 80ms." That bullet has: the action (migrated), the system (Postgres → Aurora), the outcome (zero downtime + 4x latency improvement), and the date (March 2024).

Common mistake. Bullets that have action but no system, or system but no outcome. "Led migration projects" fails on system specificity. "Worked on Postgres infrastructure" fails on outcome. Each bullet needs all three layers to satisfy both readers.

4. Match section names to ATS-expected conventions

Action. Use the standard section labels: Experience, Education, Skills, Summary, Certifications. Skip the creative variants: "My Journey," "Where I've Worked," "What I Bring." The ATS maps standard labels to database fields; custom labels get parsed as headings and skipped.

Why it works. ATS parsers are pattern-matched against standard resume formats. The standard format has standard section headers. When the parser sees "Experience" it knows to populate the work-history fields below it. When it sees "My Journey" it often categorizes the section as Unknown and stops parsing.

Done right. Standard headers, in the conventional order: Summary (optional, brief) → Experience → Education → Skills → Certifications (if relevant). The hiring manager who eventually reads the resume isn't impressed by creative section names; they're looking for the same information in the same place every other resume puts it.

Common mistake. Trying to differentiate through formatting choices that fail at the ATS layer. Differentiation comes from the content of your experience section, not from renaming it.

5. Make every claim checkable

Action. For each significant bullet, identify the colleague, customer, or system that could verify it. Name the system in the bullet; keep the colleague reference available for the human screener's follow-up.

Why it works. ATS-passing is a baseline, not a win. The bullets that get past the ATS and through the human screener are the ones with specifics that hold up to scrutiny. "Built X using Y, completed Z, attested by [name]" survives the ATS (keywords present) and impresses the human (specific and verifiable). The same bullet without the verifiability — "Built X using Y, achieved significant results" — passes the ATS but reads as filler to the human.

Done right. Beyond the bullets themselves, maintain a verifiable career record where each claim has an attached attestation. The resume passes the ATS on keyword density; the record proves the claims hold up if any are checked.

Common mistake. Treating ATS-passing as the goal. Hundreds of candidates make it past the ATS for every senior role; the verification layer is what separates the ones who get interviewed from the ones who don't.

How verification finishes what ATS-passing starts

The five moves above get your resume past the software. The next move is what happens when a human picks it up — and at that point, the question shifts from "do you have the keywords?" to "are the claims real?" That shift is what most ATS-passing candidates aren't ready for.

The free ATS Resume Scorer tells you in 15 seconds whether your resume passes the software filter — the diagnostic step before you start applying anywhere. And a verifiable career record is the layer underneath, where every bullet that got the resume past the software has a signed attestation behind it for when the human screener wants to check. The software is the gate. Verification is the case.

In 2026, both layers are table stakes for a competitive job search. Most candidates address only the first.

---

Continue reading

• Should you use ChatGPT or Claude to write your resume? — the broader argument about AI's role in the resume layer
• Customizing your AI-generated resume so it doesn't look like everyone else's — what to do AFTER the AI draft passes the ATS
• What is a verifiable career record (and why your resume isn't one) — the thesis behind why ATS-passing isn't enough on its own