DEV Community: Muneeb Nawaz

My resume checker said the r/resumes template had no work history. The bug was mine.

Muneeb Nawaz — Thu, 01 Oct 2026 09:20:30 +0000

Someone in r/resumes asked whether the Google Docs template pinned in that sub is ATS friendly. Three people said yes. I maintain a resume parser, so I went to check instead of guessing.

I filled the template in with a made-up person (John Smith, Operations Manager at Northwind Traders, Business Analyst at Globex), downloaded it three ways, and ran each file through my own checker.

Plain text   95   Parses clean
Word         60   At risk
PDF          60   At risk

Same words, same order, same person. Thirty-five points apart.

The Word and PDF reports said the same thing:

No work history section   -26
Missing sections          -15
Missing links              -3

No work history section. On a resume whose first section, right under the contact line, is called WORK EXPERIENCE.

What the file actually says

A .docx file is a zip of XML, so you can look. Here is how the template sets its section names:

'WORK EXPERIENCE'  style: none   bold   underlined   12pt
'EDUCATION'        style: none   bold   underlined   12pt
'SKILLS'           style: none   bold   underlined   12pt

No heading style. They are ordinary paragraphs that happen to be bold and underlined. To a person they look like headings. To a parser that asks Word "which paragraphs are headings?", the honest answer is none of them.

My Word and PDF readers asked exactly that question. If the file did not mark a line as a heading, the scorer did not treat it as one, so it never saw a section start, so it found no work history.

The plain text reader never had that option. A .txt file has no styles at all, so it has always decided what a heading is from the words on the line. That is why the same resume got 95 there.

The report for the live Word file still shows the gap, because the format itself has not changed:

Word file    0 headings   14 paragraphs   18 bullets
Plain text   3 headings   11 paragraphs   18 bullets

The worse part

My own guide on whether to send a PDF or a Word file used this exact behaviour as advice. A rich text test file of mine marks its headings in bold, it scored 60, and the page explained that bold is not a heading.

That was a bug written up as a lesson. My own editor's importer and my plain text reader both read a bold WORK EXPERIENCE line as a heading. Only the scorer disagreed, and I had defended the scorer.

The fix

The scorer now reads the words too. A line counts as a section heading, bold or not, when all of these hold:

the whole line is a section name it knows, like "Work Experience", "Education" or "Skills"
it does not end like a sentence and does not start in lower case
it does not start with a bullet

The first rule matters most. "Experience with Kubernetes" contains a section name but is a sentence, and treating it as a heading would cut a job in half.

There is one condition, and it is the part my first correction left out: this only applies when none of the file's real headings names a section.

The reason is the opposite failure. In a file that does use heading styles, a bold "Skills:" line inside a job is a label, not a new section. When I let it switch the section anyway, every job after it was filed under skills, where nothing checks for dates, and a real problem in that resume disappeared from the report.

So if your file sets some section names as headings and only makes the others bold, the bold ones are still read as plain text. Set them all the same way.

A second bug, found while checking the first

Once the sections were found, I tried the template with short employer names, which is what most people have. "Shopify" instead of "Northwind Traders".

The template puts the employer and the dates on one line:

Shopify                    Jan 2015 – Sep 2017

With a long name, that line was read as the start of a new job. With a short one, the line was mostly dates, so the parser took it for another date line of the job above. The next line, Business Analyst Fort Collins, CO, then became a job of its own with no dates at all. The plain text file scored 82 for it, and Word and PDF did too once the first fix was in.

Now a dated line that opens with a capitalised name, right after the previous job's bullets, starts a new job. Short names score 95 like long ones.

The numbers now

The "after" column is the code running on the live site now, and I re-ran the template files there before writing this:

                              before   after
Template, filled in, Word        60      95
Template, filled in, PDF         60      95
Template, filled in, text        95      95
Same, short employer names       82      95
Rich text test file              60      95
Two column PDF test file         43      68

The two column PDF still loses points, for the columns, which is the only thing that file was ever meant to show.

The empty template, as downloaded, scores 82. That is not the format. It is the "Month Year – Month Year" placeholders: with no real dates in them, the jobs cannot be dated.

So is the template ATS friendly?

Its structure is about as plain as it gets: one column, no tables, no text boxes, nothing in the page header, name on the first line. Every word came out, in order, in all three formats.

What I cannot tell you is what Workday, Taleo or Greenhouse do with it. Those parsers are closed, and nobody outside those companies can test them properly. What I can tell you is that "bold means heading" is a guess a parser has to make, and mine guessed wrong until 30 September.

If you want to make that guess unnecessary, it costs nothing:

Use a real heading style for your section names. In Google Docs it is the dropdown that says "Normal text"; pick Heading 2. In Word, it is the Styles gallery.
Keep each section name on its own line, and use the plain words: Experience, Education, Skills.
If you use the template, replace every "Month Year", delete the "PLEASE DO NOT REQUEST EDIT ACCESS" line under the name, and delete the line about more templates at the bottom. My parser read the first as your headline and filed the second under skills.

The PDF or Word guide now says the opposite of what it said until 30 September, and says so on the page rather than quietly. If you want to see what a parser pulls out of your own file, the checker runs in your browser and the file never leaves it.

Your resume scored 70 out of 100. Nobody can tell you if that is good.

Muneeb Nawaz — Mon, 28 Sep 2026 18:39:27 +0000

Run your resume through any of the free ATS checkers, and you get a number. 72. 84. 61 out of 100. Then some advice, then usually a paywall.

Here is the thing nobody says out loud: that number is meaningless, and not because the tools are dishonest. It is meaningless because none of them publish the scale. You cannot tell whether 70 is a pass, a warning, or a disaster, because nothing anywhere states what 70 was supposed to mean.

A number without a scale is a vibe with a decimal point.

I built one of these tools, so this is a confession as much as a writeup. Here is the entire scale, the ceiling, and the arithmetic.

The bands

88 to 98   Parses clean     Should come through intact.
70 to 87   Minor issues     Will parse, with some detail lost.
40 to 69   At risk          Expect fields to go missing.
 0 to 39   Breaks           Most of this will not survive.

So 70 is the very bottom of "minor issues". One point lower and the same document is "at risk". If a checker hands you 70 and a green tick, that is a decision somebody made about presentation, not a fact about your file.

Notice the bands are uneven. "At risk" is thirty points wide and "parses clean" is ten. That is deliberate. Once a document is broken, how broken stops mattering much, and the interesting resolution is all at the top where small things separate a clean parse from a nearly clean one.

The ceiling is 98, not 100

This is the part I expect people to argue with.

/**
 * The ceiling is 98, not 100.
 *
 * No parser is guaranteed, none of them publish their rules, and a perfect
 * score would be a claim about software we cannot see. Two points is the
 * honest cost of that.
 */
export const CEILING = 98;

Workday, Taleo, Greenhouse, Lever, and iCIMS do not document how they parse. I can test against real extractors and I do, but I cannot test against systems I have no access to. A 100 would be a promise about closed software I have never run. Two points is what that uncertainty costs, and it is the same two points for everybody.

Nobody's resume gets a perfect score from this thing. That is not a bug.

The arithmetic used to be broken

The first version subtracted. Find a problem, subtract its cost, show what is left. Obvious, and wrong.

The costs added up to 197 against a ceiling of 98. So any document with a few real problems hit zero and stayed there. Fix a column layout on a resume that also had a table and a missing work history, and the number did not move, because it had already bottomed out. The top half of the range was doing nothing at all.

It multiplies now:

const value = Math.round(
  deductions.reduce((acc, d) => acc * (1 - d.cost / 100), CEILING),
);

Each finding takes a percentage of what is left rather than a flat slice of the total. Multiplying cannot reach below zero, so nothing ever clips, and every fix moves the number no matter how many problems the file has. A fatal finding costs 100, which makes its factor zero, so a scanned image reaches zero through the same arithmetic as everything else with no special case.

The side effect is that marginal gain scales with what is left to gain. Fixing a table on a nearly clean resume is worth more than fixing the same table on a wrecked one, which is also true in reality.

What the costs actually are

Not secret either:

noWorkHistory      26
undatedEntries     14
orphanEntries      10
unmappedHeadings    8
mixedDateFormats    6
ongoingWording      5

noWorkHistory sits at 26 because a resume whose career section a parser cannot locate was landing in "minor issues" at a lower weight, and "will parse, with some detail lost" is an absurd thing to say about a document whose entire work history is unmapped.

That is the kind of judgement call every one of these tools makes constantly, and none of them show you.

What to do with any ATS score

Ignore the number. Read the findings.

The number is a summary of a list, and the list is the useful part. "The first text in your file is not your name" is actionable. "You scored 74" is not, especially when you have no idea what 74 was measured against.

If a checker will not tell you its scale, its ceiling, or what each finding costs, you are looking at a lead magnet, not a measurement.

Mine is at atsresumereader.com with the full band table and the weights. It runs in the browser, so nothing gets uploaded, and there is no paid tier holding the rest of the report.

Argue with the weights. They are judgement calls, and I would rather defend them in public than hide them.

I parsed the same resume six ways to settle "PDF or Word"

Muneeb Nawaz — Wed, 16 Sep 2026 06:18:34 +0000

Search "should I send my resume as PDF or Word" and you get a few hundred articles that all say some version of the same thing. PDF is safer. Word is safer. It depends on the company. Every one of them is somebody's view, because answering the question properly means running both files through a parser and reporting what came back, and almost nobody writing those articles has a parser.

I had built one for something else. So I ran the file through it.

The setup

One resume. Same person, same words, same sections. Saved six ways, then put through the same extraction and scored out of 98, where the score is how much of the document survived into the structured record a recruiter actually searches.

Saved as	Score	What it lost
Markdown	98	nothing
PDF	95	Missing links
OpenDocument	95	Missing links
Plain text	95	Missing links
Rich text	95	Missing links
Word	80	Page header, Missing links

The question assumes the answer is in the left column. It is not.

The Word gap is not Word

Word scores 80 and PDF scores 95, and the entire 15 point difference is one finding: page header.

The .docx in that table puts the name, email and phone number in the header region, which is exactly where a Word template puts them. Plenty of parsers discard the header before they start reading the body, on the reasonable theory that headers contain page numbers and document titles rather than content. So the contact details never arrive, and the record lands in the system with nobody attached to it.

Move that one line into the body and the file is still a .docx. Nothing about the container was ever the problem.

It runs the other way too, which is the part that settles it. A PDF laid out in two columns scores 68. Being a PDF saved it from nothing, because the extractor reads a two column layout in the order the text was drawn, not the order a human reads it, and the job titles end up interleaved with the skills list.

Rich text, corrected

When I first published this, rich text scored 60, and this section explained why: the file marks its section headings by making the text bold rather than applying a heading style, and my scorer only recognised a heading by its style. It ended with "Bold is not a heading. In any format."

That was my scorer being stricter than the rest of my own code. The importer that turns an uploaded resume into an editable one, and the reader for plain text files, had always treated a line that just says WORK EXPERIENCE as a heading. Only the scorer did not, so a clean rich text file was scored as a resume with no work history. On 30 September I changed the scorer: when none of a file's headings names a section, a line holding nothing but a section name now counts as a heading. In a file that styles some section names as headings and only bolds the others, the bold ones are still read as plain text, so set them all the same way. Rich text now scores 95 and ties with the other clean formats, and the two column PDF, which had been losing points for the same reason on top of its layout, went from 43 to 68. Whether a closed ATS reads a bold heading the same way, I have no way to test, and nobody outside those companies does either.

Markdown wins for a boring reason

Markdown is the only file that scored 98, and it is not because Markdown is magic. It is the only one of the six carrying a portfolio URL written out in full. The other four clean formats tie at 95 losing the same three points for the link none of them has.

The format did not earn that. The content did. Which is the whole point.

Keeping the numbers honest

Every number on the site is recomputed from the actual fixture files on each test run. This copy is not, which is why, when that test caught the change described above on 30 September, I corrected it here by hand. The published evidence lives in a typed array, a test reads the six real documents off disk, runs them through the same extraction the product uses, and compares. Change a weight in the scorer and the test fails with the new number in the assertion message.

it(`${row.file} still scores ${row.score}`, async () => {
  const extraction = await read(row.file);
  const score = scoreExtraction(extraction, recoverFields(extraction));
  expect(score.value, `${row.file} score moved`).toBe(row.score);
});

There is a second test that matters more than it looks. It asserts the six files are the same resume, by comparing the name and email the parser recovered from each. The first version compared word overlap and read 0.84 across the six, because Markdown carries a URL and its own syntax while plain text carries neither. A threshold loose enough to pass that is loose enough to pass a different resume by the same author, so it compares recovered fields instead. If someone swaps a fixture, the scores stay plausible and the sentence next to them quietly becomes a lie. Those tests are what stand between the page on my site and being wrong six months from now. Neither can reach a copy like this one.

What to actually send

Send what the posting asks for. Somebody there knows what their system accepts, and ignoring an explicit instruction is a worse risk than either format.

Where nothing is specified, send a PDF exported from a word processor. Never one scanned or exported as an image: that file has no text layer at all and scores zero. Not a low score, nothing.

Then stop thinking about the format. Moving contact details out of a page header was worth 15 points on this document. Choosing between PDF and Word, with the layout already clean, was worth nothing at all. They tie.

The full write up, with the failure cases and the deduction table, is here: PDF or Word? The same resume, parsed both ways. The parser runs in the browser, so if you want to try it on your own file, nothing gets uploaded.