Nearly every large employer runs applications through an applicant tracking system before anybody reads them. The system is not a judge. It is a database: it reads your CV, tries to work out which bit is a job title and which bit is a date, files the result, and lets a recruiter search across everything it has filed.
That distinction matters, because it tells you what a good CV has to do first. Not impress. Parse.
What the software actually does with your CV
Parsing comes first: the system extracts your contact details, employment history with dates, education, skills and certifications, and stores them as fields. Then filtering, against whatever criteria the recruiter set — a location, a qualification, a right-to-work answer. Then ranking, when a recruiter searches the pool and gets results ordered by how well each record matches.
If the parse goes wrong, nothing downstream can go right. A CV whose dates landed in the wrong field does not get rejected; it simply never comes back in a search. That is the real failure mode, and it is quieter than rejection.
The myth worth dropping
You will have read that these systems automatically bin most CVs. They do not. Almost everything submitted remains available to a human who goes looking for it. What varies enormously is whether your record is findable, complete and near the top of the list when they do.
So the goal is not to defeat a hostile machine. It is to clear a low technical bar so a person can assess you on the content.
Layout: one column, plain headings
Multi-column layouts are the most common cause of a mangled parse. Reading order is inferred, and a two-column CV frequently comes out interleaved — your job titles spliced into your skills list. Anything you would describe as design-led is a risk: text boxes, tables, sidebars, icons, logos, a photograph, a skills chart with little dots.
Contact details belong in the body of the document, not in the header or footer, which some systems never read at all.
- One column, top to bottom, no sidebars.
- Standard section headings: Professional Summary, Work Experience, Education, Skills, Certifications. Not 'My Journey'.
- A common font at 10 to 12 point. Arial, Calibri, Georgia. Nothing scripted.
- Dates in a consistent format throughout — MM/YYYY is safest — and no gaps left unexplained.
- No tables, text boxes, graphics, icons or photos.
File format
A .docx file is the most reliably parsed thing you can send. A PDF exported from a word processor is fine almost everywhere. What fails is anything that is really an image: a scanned PDF, a .png or .jpg, a design-tool export with the text outlined, or a proprietary format the system has never seen.
If the application form specifies a format, use that one. If it does not, .docx or an exported PDF, named with your name and the role rather than 'CV_final_v3'.
Three shapes that work
There is no magic template, but there are three structures that parse cleanly and suit different situations.
- Chronological: summary, then roles newest first, then skills and education. Best when your history is continuous — the linear list is also how a system calculates your years of experience.
- Hybrid: summary, then a short skills block, then the chronological history. Best for career changers and anyone with a gap, because the skills sit high without hiding the timeline.
- Minimal: the same as chronological with every flourish stripped out. Best for public sector and large conservative employers, where the software is often older.
The shape to avoid
A purely functional CV — skills grouped by theme with the employment history reduced to a list of company names — parses badly and reads worse. Recruiters have seen it used to hide gaps and short tenures, so it invites the question you were hoping to avoid. If you have a gap, put it in the timeline with a line of explanation.
Keywords, without the stuffing
Ranking works on the language of the posting, so your CV needs to use it. Take the job description apart and sort what you find into hard skills, soft skills, job titles and the tools named. Then work those terms into your bullet points where they are true.
The difference between optimisation and stuffing is context. 'SEO, data analysis, Google Analytics' in a list tells a reader nothing. 'Rebuilt the SEO strategy from an audit in Google Analytics, lifting organic traffic 45% in six months' contains the same three terms and an actual claim. And the white-text trick — pasting the job description into your CV in white — is trivially detected and gets you binned by the human, which is worse.
Spell out acronyms once, with the short form beside them: Chartered Financial Analyst (CFA). Recruiters search for both.
Then write it for the person
Once it parses, the CV has to persuade. That means quantified achievements rather than duties: an action verb, what you did, what changed. 'Led the migration of the reporting stack, cutting overnight run time 40% and removing £200k of annual licence cost' does more work than a paragraph about responsibilities.
Replace any 'Objective' line with a two or three sentence summary aimed at this specific role. It is the first thing read and the last thing most people tailor.
The check before you send
Single column, standard headings, common font, .docx or exported PDF, contact details in the body, keywords drawn from the posting and used inside real achievements, acronyms spelled out, dates consistent, spelling matched to the market you are applying into, and no tables or graphics anywhere.
Apply Engine does this pass for you on every application — the documents come out in a structure these systems parse cleanly, matched against the posting in front of them — but the rules are worth knowing whether or not something else is applying them on your behalf.
