A.M. is a senior software engineer with nine years of experience. Strong companies. Real numbers. The kind of resume that should be getting callbacks — $240M in payment volume, 62% latency reduction, SOC 2 Type II on the first attempt. This person can clearly do the work.
We built A.M.'s resume twice. Same job titles. Same companies. Same bullet points. Same four roles at Company A, Company B, Company C, and Company D. Everything identical — except the format.
One version went into a clean, single-column document. Standard headers. Plain text throughout. A professional summary up top. Dates formatted consistently across every role. Skills listed as plain text in organized categories. The kind of resume that looks a little plain to a human but reads perfectly to a machine.
The other version went into a multi-column template. Skills and certifications in a left sidebar. Contact info in a styled header with icons. An objective statement instead of a summary. Dates formatted three different ways across four roles. The kind of resume that looks polished on screen and probably took hours to put together.
Then we ran both through ParseProof.
A 37-point gap. Same person. Same nine years. Same four companies. The only variable was the template.
What Actually Broke
The multi-column version didn't fail because it looked bad. It failed because of how it was built. Here's exactly what the parser did — and didn't — find.
The Two-Column Layout
This is the biggest one. Most ATS systems — especially the legacy enterprise platforms that dominate Fortune 500 hiring — parse resumes in a linear flow. Left to right, top to bottom.
When a resume has two columns, the parser reads across the row — not down each column separately. So instead of extracting the skills list cleanly from the sidebar, it reads across and merges sidebar content with experience content. Job titles end up in the wrong fields. Skills get scrambled or missed entirely.
A.M.'s technical skills in the sidebar — Python, AWS, Go, PostgreSQL, Docker, React, TypeScript, Kafka, Kubernetes, Redis, Terraform, dbt — twelve strong, relevant terms. The parser extracted three of them. The other nine were invisible to the system.
When I open a candidate's record in an ATS and their skills section shows three items, I don't assume they have limited skills. I assume their resume has a formatting problem. But most recruiters don't stop to investigate — they move to the next application. There are usually hundreds more waiting.
Contact Info in a Styled Header
The multi-column template put A.M.'s phone number, email, and LinkedIn URL in a designed header block — each one with a small icon next to it. Looks clean. Professional, even.
The parser read the icon characters as garbage text and had trouble cleanly extracting the contact fields. The LinkedIn URL — formatted as a hyperlink inside a styled header — didn't extract at all. From the system's perspective, A.M. had an incomplete contact record.
That matters. Recruiters filter candidates by contact completeness. If your LinkedIn URL didn't parse, you might not surface in a search — even if everything else about your application is strong.
Three Date Formats Across Four Roles
This one is subtle but it's a real problem. Look at how the multi-column version handles dates:
- Company A: March 2022 – Jan '25
- Company B: Aug. 2019 – Feb 2022
- Company C: 6/2017 – 7/2019
- Company D: September 2015 – May 2017
Four roles. Four different date formats. ATS systems use dates to calculate tenure and build a work history timeline. When formats are inconsistent, the system can't normalize them reliably. Two of A.M.'s roles had dates the parser flagged as unreadable — which means the tenure calculation was wrong. A recruiter filtering for candidates with five-plus years of backend engineering experience might not see A.M. in results, even though that experience is clearly there.
The single-column version used one format throughout: Month YYYY – Month YYYY. Every role. Every date. Consistent. The parser read all four correctly on the first pass.
An Objective Statement Instead of a Summary
"Results-driven engineer seeking to leverage technical expertise in a challenging senior role at an innovative company."
That's the opening line of the multi-column version. It's not wrong exactly — but it's a fifteen-year-old convention that wastes prime resume real estate on what the candidate wants instead of what they bring. More practically: ATS systems don't score objective statements. They look for summaries. A well-written professional summary gives the parser a dense block of relevant keywords right at the top of the document, right where it's looking first.
A.M.'s single-column version opened with a professional summary that named the industries, the technical specialties, and the type of role they're targeting. Three sentences the parser could actually use.
The Skills That Weren't There
Beyond the column extraction problem, the multi-column version listed "Core Strengths" separately from technical skills — Team Leadership, Cross-functional Collaboration, Agile/Scrum, Communication, Problem Solving. Soft skills buried in a sidebar under their own section header, competing for parser attention with the technical list.
The single-column version organized technical skills by category: Languages, Frameworks & Tools, Infrastructure, Data & Messaging. Every term in plain text. The parser found all twelve on the first pass.
| What We Checked | Multi-Column Template | Single-Column Document |
|---|---|---|
| Technical skills extracted | 3 of 12 | 12 of 12 |
| LinkedIn URL parsed | Not extracted | Extracted correctly |
| Date formats consistent | 3 different formats — 2 flagged | Consistent throughout |
| Opening section | Objective statement | Professional summary, keyword-rich |
| Work history parsed correctly | Scrambled across columns | Clean extraction |
| ParseProof score | 47 / 88 | 84 / 88 |
Why This Keeps Happening
Nobody tells candidates this. Career coaches focus on content — bullet points, action verbs, keyword density. Resume template builders focus on design — layouts that look modern and differentiated. ATS compatibility is an afterthought, if it comes up at all.
The entire advice ecosystem is optimized for impressing a human. Which makes sense — a human is the end goal. But the human never sees the resume the parser couldn't read. That's the step nobody talks about.
I've reviewed resumes inside legacy enterprise ATS environments for over twenty years. The formatting failures look the same regardless of when the resume was submitted. The templates change. The parser problems don't.
What the Clean Version Did Right
The single-column document wasn't beautiful. It was a standard document with standard formatting. Here's what made it work:
- Single column, top to bottom. Every line reads in sequence. The parser never has to guess which column to follow.
- Contact info as plain text, first line. Name, city, phone, email, LinkedIn URL — no icons, no styled header boxes, no hyperlinks buried in design elements.
- Professional summary up top. Three sentences naming the industries, technical stack, and role target. Dense with relevant terms right where the parser looks first.
- One date format throughout. Month YYYY – Month YYYY on every role. No mixing. No abbreviations. No shortcuts.
- Skills as organized plain text. Categorized by type, easy to parse. Every term found on the first pass.
- Standard section headers. "Professional Experience," "Technical Skills," "Education." Not creative alternatives — just the language every parser recognizes.
None of that is exciting advice. It won't get shared as a LinkedIn carousel. But it's the difference between a 47 and an 84 — and between showing up in a recruiter's search or not. See where your resume lands with ParseProof's free ATS resume checker — the same result, on your actual resume.
Which version does your resume look like?
ParseProof checks your actual resume against the same parsing infrastructure hiring software uses — and shows you exactly what it extracted. Free. No job posting needed.
Get Your Free ScoreThe Fix Is Simpler Than You Think
If you've been using a multi-column template, you don't need to rewrite your resume. You need to reformat it. The content is probably fine. The structure is what's costing you.
Start with a blank document. Move your content in, one section at a time. Single column. Standard headers. Pick one date format and use it on every role. Put your skills in plain text. Run it through ParseProof before you send it anywhere — see what the system actually reads before a recruiter ever opens your file.
A.M.'s experience didn't change between the two versions. The score did. Yours can too.