What gets your resume rejected before a human reads it

You applied to forty roles and heard nothing from thirty-six of them. The usual explanation offered is that the market is hard, which is true and also not the whole story. A meaningful share of those applications were never read by anyone, because the software that received them could not work out what your resume said.

This is not about keyword stuffing, and it is not about beating a machine. It is about a document being machine-readable at all, which is a structural property and has nothing to do with how impressive your experience is.

What an applicant tracking system actually does

The software does not see your layout. It extracts the text stream from the PDF — roughly in the order the characters were placed on the page — and then tries to reconstruct structure from that stream: where a job title ends, which dates belong to which employer, what is a skill and what is a company name.

Everything that goes wrong follows from that one fact. A design that communicates structure visually, to a human eye, communicates nothing to a parser reading a flat sequence of characters.

The two-column problem

This is the single most damaging and the least visible. A two-column resume puts a skills sidebar and a job entry on the same horizontal band. The extractor often reads straight across both.

What comes out is a line like: Skills Senior Analyst, Kotak Mahindra Python SQL Mar 2021. The job title is welded to a programming language, the employer sits between two skills, and the date belongs to nothing. No human ever opens that record, so nobody tells you it happened.

You cannot spot this by looking, which is the trap. The PDF renders perfectly in every viewer, which is exactly why the template looked worth paying for. There is a two-second test: select all the text in your resume, paste it into a plain text editor, and read what appears. That is close to what the parser received.

If the pasted text does not read as a sensible document, the problem is not your experience. It is that your experience never arrived.

The rest of the list, in order of damage

• Text inside images. A resume exported as a picture, or with a header rendered as a graphic, contributes nothing at all — your name and contact details included. Some systems run OCR, most do not.
• Tables for layout. A parser may read a table row-first or column-first, and it rarely tells you which. Dates in one cell and employers in another frequently end up transposed.
• Headers and footers. Contact details placed in the page header are dropped entirely by several extractors, which is how a resume arrives with no phone number.
• Non-standard section names. Where I Have Worked is clear to a person and invisible to a parser looking for Experience, Employment or Work History.
• Icons in place of labels. A phone glyph beside a number is a picture, not the word phone. Keep the label as text.
• Unusual fonts and heavy ligatures. Some embedded fonts extract as mojibake, turning whole sections into characters nobody can match against anything.
• Dates written inconsistently. Mar 2021, 03/21 and March '21 in the same document make it harder to build a timeline, and a missing timeline reads as a gap.

What actually helps, once the parsing works

Only once the document is readable does the content matter — and then it matters a great deal. The system scores your text against the job description, and the mismatch that costs most people is vocabulary rather than capability.

If the posting says stakeholder management and your resume says client handling, you have done the work and not said the word. That is not dishonesty to fix; it is translation. Read the posting, list the terms it uses for things you have genuinely done, and use its words for those things.

This is also why one resume sent to forty companies performs poorly. A document tuned for a data engineering posting will score badly against an analytics one, and that is the system working correctly rather than failing. The point is a tailored version per role — usually fifteen minutes of editing, not a rewrite.

A format that survives

1. 1One column, top to bottom. Boring to look at and reliably readable.
2. 2Standard section headings: Summary, Experience, Education, Skills, Certifications.
3. 3Employer, title and dates on their own line, in a consistent order throughout.
4. 4A common font — Calibri, Arial, Times New Roman, Garamond. This is not about taste; it is about reliable text extraction.
5. 5PDF, unless the posting asks for something else. Export from the source document rather than printing to PDF, which sometimes rasterises.
6. 6Contact details in the body of the first page, never in the page header.

What this will not do

A clean file does not make a weak application strong. If the role wants five years of a specific tool and you have none, perfect parsing simply means a human reads the truth sooner. The purpose of this work is to stop good applications being discarded for mechanical reasons — not to manufacture a fit that is not there.

It also cannot tell you how a particular employer's system is configured. Systems differ, and some are considerably better at handling layout than others; a resume that fails one may pass another. The checks above address the faults common to most of them, which is the best available answer without knowing which software sits behind a given application form.

And no tool can confirm a human saw your file. Silence after an application is not evidence of a parsing failure, and treating every rejection as a formatting problem is its own trap. Fix the structure once, properly, then judge the content on the responses you get afterwards.