Resume Parsing

A parser reads the uploaded file, converts it to plain text, then uses pattern recognition and trained models to decide which piece of text is a job title, which is an employer, which is a date range and which is a phone number. The output is a set of fields written into the candidate record, so a recruiter can filter by skill or search a decade of applications in seconds. Most modern parsers combine rules with machine learning, because rules alone break on unusual layouts and models alone miss obvious formatting cues. The original document is normally kept alongside the parsed fields, since those fields are an interpretation rather than the source of truth. Parsing runs at the moment of upload inside an applicant tracking system, which is why a candidate record appears populated within seconds of someone applying.

Layout is the usual culprit. Multi-column designs, text sitting inside tables, headers and footers, graphics used as section titles, and skills shown as rating charts all confuse the text extraction step, because the parser reads a jumbled order rather than the visual order a human sees. Scanned PDFs and image-based files are worse, since there is no text layer at all unless optical character recognition runs first. Unusual date formats, job titles merged with company names on one line, and creative section headings such as Where I Have Worked instead of Experience also reduce accuracy. None of this reflects candidate quality, which is the uncomfortable part. A strong applicant with a designer-built CV can end up with a thinner record than a weaker applicant using a plain template, and teams leaning hard on keyword filters should know that tradeoff exists.

Accuracy varies by field. Contact details and education tend to extract reliably. Job titles, employment dates and skills are harder, and nested details such as promotions inside a single employer are the most error-prone of all. No parser is correct on every document, so the safe assumption is that the record is a good first draft rather than verified data. Review still matters for two reasons. Decisions made on a mis-parsed field, such as filtering by years of experience, quietly remove people who were qualified. Parsed data also flows into search and reporting, so errors compound over time. Practical teams spot-check parsing on a sample of applications per requisition, correct the fields that drive shortlisting, and open the attached document whenever a decision is close. Parsed fields are what resume screening software then ranks on, so parse quality sets the ceiling for everything downstream.

No, and conflating the two causes bad buying decisions. Parsing is a data step. It turns a document into fields and makes no judgment about fit. Screening is an evaluation step that takes those fields, plus answers to application questions and sometimes assessment results, and produces a ranking, a score or a shortlist. One is extraction, the other is inference. The practical implication is that a system can parse well and screen poorly, or screen sensibly on top of a mediocre parse. When comparing vendors, ask them to demonstrate both separately: upload a difficult resume and inspect the extracted fields, then ask what the screening logic actually uses and whether a recruiter can see and override its reasoning. Keeping the distinction clear also makes it far easier to work out which step produced a strange shortlist.