Your CV Is a Parsing Problem: Why Good Candidates Get Lost Before a Recruiter Reads Anything

dk017 — Sun, 26 Apr 2026 16:12:52 +0000

Most CV advice focuses on the obvious things:

use action verbs
add measurable achievements
tailor your CV to the job
keep it short
avoid spelling mistakes

All of that matters.

But there is another layer that rarely gets explained properly:

Before a recruiter reads your CV, software often has to parse it.

And parsing documents is messy.

As developers, we know this already. Give the same data to five systems in five different formats and you will get five different failure modes. A CV is no different. It may look perfect to a human, but to an Applicant Tracking System, it is just an input file that needs to be extracted, normalized, matched and ranked.

That is why a good CV is not only a writing problem.

It is also a document structure problem.

Career services and resume guidance from multiple sources repeatedly warn against formatting choices that make resumes harder for ATS systems to read: headers, footers, tables, text boxes, heavy templates, unusual symbols and overly designed layouts. Columbia’s career guidance, for example, recommends avoiding headers, footers, tables, templates, borders, lines and symbols, and the University of Illinois at Chicago gives similar warnings about formatting and file readability.

Think of your CV as structured data

A recruiter sees this:

Senior Python Developer
XYZ Org
Feb 2026 – Present

An ATS may need to extract:

{
"job_title": "Senior Python Developer",
"company": "XYZ Org",
"start_date": "2026-02",
"end_date": "present"
}

That looks simple until the CV uses:

two columns
icons instead of labels
dates inside text boxes
contact details in the header
skills in a sidebar
custom fonts
sections without standard headings
PDF layers from design tools
tables used for layout

Now the parser has to guess.

And when software guesses, it sometimes guesses wrong.

That is the hidden reason why some visually impressive CVs perform badly. They are designed for the eye, not for extraction.

The most common ATS-breaking CV patterns

Important information in headers and footers

Many people put their name, phone number, email and LinkedIn URL in the header.

It looks clean.

But some parsers ignore or mishandle header/footer content. If your contact details are not extracted correctly, the rest of the CV may still be readable, but the candidate record can become incomplete.

Better:

Michael Hans
Phoenix, USA
michael@example.com
linkedin.com/in/example

Put this in the main body of the document, not only inside a header/footer.

Two-column layouts

Two-column CVs are popular because they look modern. The left column usually contains skills, tools, languages and contact information. The right column contains experience.

Humans understand this visually.

A parser may not.

It might read left-to-right across columns instead of top-to-bottom. That can mix unrelated text together:

Python English SAP Ariba Django Dutch Backend Developer...

Now your structured career history becomes noisy.

This is why many ATS-focused resume guides recommend simple, single-column layouts. Recent ATS formatting guidance also points out that multi-column designs can cause parsing problems because systems may read across columns instead of down the page.

Tables used for layout

Tables are useful in documents, but risky in CVs.

A table may visually align dates and job titles nicely:

2022 - 2024 | Backend Developer | Company X
2020 - 2022 | Software Engineer | Company Y

But extraction can produce strange ordering, duplicate text or missing columns.

For ATS readability, plain text structure is safer:

Backend Developer
Company X
June 2022 – February 2024

Built REST APIs using Java and Spring Boot.
Improved batch processing performance by 35%.

The parser has a much easier job.

Icons instead of text labels

A phone icon looks nice.

An email icon looks nice.

A location icon looks nice.

But a parser does not “understand” your visual intent the way a human does.

Instead of:

📞 +31 6 12345678
✉️ name@example.com
📍 Amsterdam

Use:

Phone: +31 6 12345678
Email: name@example.com
Location: Amsterdam

A little less fancy, much more explicit.

Creative section names

Developers love naming things.

Unfortunately, CV section names are not the place to be creative.

Instead of:

Where I made impact
My toolkit
Things I have shipped
A bit about me

Use standard headings:

Profile
Work Experience
Education
Skills
Certifications
Languages

The parser, recruiter and hiring manager all understand these instantly.

Keywords matter, but not in the way people think

A lot of ATS advice says:

“Add keywords from the job description.”

That is true, but incomplete.

Keyword stuffing does not help if the CV is vague.

For example, this is weak:

Worked with Java, Spring Boot, REST APIs, microservices, SQL, AWS.

This is better:

Built Java and Spring Boot REST APIs for invoice processing workflows, using SQL for data access and AWS S3 for archived document storage.

The second version does three things:

It includes relevant keywords.
It explains context.
It shows what the person actually did.

ATS systems may help filter and rank applications, but humans still make the hiring decision. A good CV has to work for both.

A developer-friendly checklist for an ATS-readable CV

Here is the practical version.

Structure

Use:

Name
Contact details
Profile
Work Experience
Education
Skills
Certifications
Languages

Avoid:

sidebar-only skills
hidden headers
text boxes
tables for layout
icons without labels
Dates

Use clear date formats:

June 2022 – February 2024
Feb 2020 – May 2022
2020 – 2022

Avoid:

'22 - '24
Q1 22 - Q2 24
2 yrs at Company X

Clear date formatting helps both ATS systems and recruiters understand your timeline. Recent resume formatting guidance also recommends standard date formats rather than abbreviated or ambiguous date styles.

Job descriptions

Bad:

Responsible for backend development.

Better:

Developed Java Spring Boot APIs for customer onboarding workflows and reduced manual processing by automating validation checks.

Bad:

Worked on database.

Better:

Optimized SQL queries and reduced report generation time from 40 seconds to under 10 seconds.

Bad:

Handled support tickets.

Better:

Resolved production issues related to payment failures, API timeouts and data synchronization errors.

The better examples are not just “more impressive”. They are also easier to classify.

The best CV format is boring on purpose

This is hard to accept because job seekers want to stand out.

But your CV should not stand out because of design complexity.

It should stand out because your experience is clear.

For many applications, especially in markets like the Netherlands, a reverse-chronological CV is a safe default: most recent work first, clear role/company/date structure, and concise bullet points. Netherlands-focused CV guidance commonly recommends reverse chronological order, clear role descriptions and practical, direct presentation.

A good CV layout is like a good API.

It should be:

predictable
easy to parse
hard to misuse
clear under edge cases
boring in the best possible way
A simple way to test your CV

You can do a lightweight manual test before sending your CV.

Test 1: Copy-paste test

Open your PDF. Select all text. Copy it. Paste it into a plain text editor.

Ask:

Is the order still logical?
Are job titles near the right companies?
Are dates still readable?
Did your contact details appear?
Are skills mixed into unrelated sections?
Are strange symbols appearing?

If the pasted text is chaotic, a parser may also struggle.

Test 2: Section heading test

Scan your CV and check if these words are easy to find:

Profile
Work Experience
Education
Skills

If your CV uses creative labels, rename them.

Test 3: Vacancy match test

Take the job description and highlight recurring terms:

Java
Spring Boot
REST API
Kafka
AWS
SQL
Microservices
CI/CD

Now check whether your CV uses those terms naturally in your work experience, not only in a skills list.

Bad:

Skills: Java, Kafka, AWS, SQL

Better:

Built Kafka-based event consumers for order synchronization and stored processed records in PostgreSQL.
Why I built a small tool around this

I have been working on WerkCV.nl, a Dutch CV builder focused on simple, ATS-friendly CVs for the Netherlands.

The idea is not to create the fanciest CV template.

It is the opposite:

clean Dutch CV layouts
no unnecessary visual complexity
no subscription model
free to build
one-time payment only when downloading the PDF

I also added tools like an ATS CV checker and CV score pages because many people do not need “more design”. They need to know whether their CV is readable, structured and clear.

If you are applying in the Netherlands, you can try the free ATS checker here:

WerkCV ATS CV Checker

And if you want to improve your CV structure before rebuilding it:

CV optimaliseren

Final thought

A CV is not just a personal branding document.

It is also a machine-readable input file.

That means the best CV is not always the most beautiful one.

The best CV is the one that:

gets parsed correctly
shows the right information in the right order
matches the role honestly
helps the recruiter understand your fit quickly
does not hide important data inside design tricks

In software terms:

Your CV should fail gracefully.

If the design layer disappears, the information should still make sense.

That is the real test of an ATS-friendly CV.

DEV Community: dk017

Your CV Is a Parsing Problem: Why Good Candidates Get Lost Before a Recruiter Reads Anything