ATS and tailoring a CV: what software reads and people judge

An ATS is a category of software, not one exam

An applicant tracking system helps an employer manage candidates and recruitment stages. The available features depend on the platform and the employer's setup. Knowing that a company uses an ATS does not tell you whether it relies on a candidate database, full-text search, filters, an additional AI feature or primarily manual review.

The mix of vendors also differs by country, so guidance written for one market often describes software your employer does not use. A candidate applying in Poland frequently meets local platforms such as eRecruiter, Traffit or HRlink, while an international employer may run something else entirely. The principle survives the difference: each product exposes different features, and each employer configures them differently.

This matters because advice that promises to help you ‘pass the ATS’ often collapses several different mechanisms into one mysterious score. You can test whether a CV is technically readable and whether it reflects a particular job description. You cannot honestly claim that one percentage reproduces every employer's process.

Step one: a parser extracts information

A parser turns a document into information that can populate a candidate profile. It may identify contact details, job titles, employers, dates, education and skills. When the layout is difficult to interpret, content can end up in the wrong field or fail to appear in the profile at all.

A safer CV uses selectable text, familiar headings and a predictable reading order. Scanned pages, text embedded in images, complicated columns, important content in headers or footers and decorative graphics can increase parsing risk. This is not a ban on thoughtful design. It means the design should not depend on a structure that loses meaning when the text is selected or copied.

Machine readability does not replace a clear message for people

This is where formatting stops working for you and judgement takes over. A perfectly parsed CV can still fail to communicate a candidate's level. Software may identify a Senior Frontend Developer title, React and five years of experience. Those fields alone do not show whether you made decisions, owned an outcome or solved increasingly complex problems.

You need both layers at once. The machine layer lets software read the file: clear sections, actual text and accurate names for relevant skills. The human layer lets a person understand the experience: concrete scope, decisions, constraints, impact and evidence that supports the target level. The first is pointless without the second, and the second may never be read without the first.

Step two: search and filters reflect the employer's criteria

Back to the machine layer for a moment, because once an application is stored, some systems let recruiters search CVs for words and phrases. They may also offer filters or Boolean queries that combine terms, such as a role title and a technology. This is not a secret master list of keywords. The criteria come from a particular vacancy, team and user configuration.

If you genuinely used an important technology named in the job description, it should be easy to find in your CV. Do not leave it only in a skills list: connect it to experience that shows the practical scope. Do not hide React behind ‘a user-interface library’, but do not manufacture five variants of the same name either.

Start tailoring with three evidence buckets

List the most important requirements and assign each one to one of three groups. Evidence means the CV already contains a specific example. Hidden evidence means you have the experience, but the document buries it or describes it too broadly. A gap means you have no honest basis for claiming the skill.

Only the second group needs an exposure fix. The third does not become evidence after you add a keyword. If you have not used Kubernetes, placing it in a skills section might satisfy a simple search, but it creates a problem as soon as someone asks what you did with it.

Tailor visibility. Do not tailor the facts.

Turn each requirement into a question about proof

Job descriptions use broad labels: scalability, ownership, architecture, quality or stakeholder work. Do not answer a label with another label. Ask which event from your work would let the reader see that capability without taking it on trust.

Ownership might be a problem you carried from diagnosis to outcome. Architecture might be a decision shaped by a real constraint. Stakeholder work might be a scope or priority you helped resolve. A label supports scanning; evidence creates credibility.

Change the hierarchy, not your career history

You do not need a completely new CV for every application. Keep a strong base version and change its priorities deliberately. Move the summary, projects and bullets that answer the most important criteria higher. Compress experience that is true but secondary for this role.

For a performance-focused position, foreground diagnosis, Web Vitals, monitoring and outcomes. For a design-system role, give more space to component APIs, accessibility, versioning and the effect on other teams. The same career can support different truthful foregrounds.

Matching and AI are optional features, not the definition of every ATS

Some platforms offer candidate matching or an assistant that supports screening. Such a feature may consider skills, job history and criteria configured for a vacancy. That does not mean every ATS automatically gives every candidate the same kind of score.

Greenhouse provides a useful example: it describes Talent Matching as a separate feature that must be enabled and calibrated, and presents its output as assistance for recruiters rather than an automatic accept-or-reject decision. Another platform or employer may use a different process entirely. Honest optimisation therefore starts with the job and the quality of your evidence, not with guessing one algorithm.

The human layer: what happens after 5, 10 and 20 seconds

Within the first few seconds, the current role, headings, employers, dates and document density attract attention. Around the ten-second mark, the reader starts looking for something that supports the claimed level: a decision, outcome, scale or scope of responsibility. By twenty seconds, a working story may have formed — performance specialist, product-minded frontend engineer, reliable executor or a profile that remains difficult to describe.

This is not a real hiring decision or a prediction of an application outcome. It is a model of first impression based on the document alone. You cannot control every interpretation, but you can make the strongest truthful evidence easier to find than generic duties and secondary technologies.

A practical pre-submission test

Start with extraction. Open the PDF, select all of the content and paste it into a plain-text editor. Check whether job titles, employers, dates and bullets still follow a logical order. If an application form extracts details from the upload, review the populated fields and correct mistakes before submitting.

Then compare the CV with the job description. Check whether the three most important requirements lead to specific experience. Remove skills added only because they appeared in the advert, and make genuine but vague experience more precise.

Finally, read the first page as someone who does not know your story. Within a short scan, is the target role clear, does the document communicate an appropriate level and is the strongest evidence easy to find? A readable file enables assessment. It does not perform that assessment for you.

What an ATS checker can test — and what it should not promise

A checker can usefully test whether text can be extracted, sections are recognisable, relevant terms from a specific job have supporting evidence and the format creates obvious parsing problems. That is document hygiene, not a prediction of a hiring outcome.

Be cautious when a tool presents a high percentage without explaining its criteria, claims compatibility with every system or implies that adding words guarantees an interview. A useful finding should point to a specific part of the CV and distinguish a parsing problem, missing visible evidence and genuinely absent information.