How Skills Extraction Works

Skills extraction is the step where a parser reads your document text and produces a list of named skills attached to your record. It works almost entirely by matching strings against a vocabulary — a list of skill names the system already knows — rather than by understanding what you did. That single fact explains most of what looks arbitrary about it, and it points at a fix that costs you nothing: write the plain name of each skill somewhere in readable text.

What a skills vocabulary is

A parser does not invent skills. It carries a dictionary of them: Python, financial modelling, phlebotomy, AutoCAD, contract negotiation. Each entry is a name, usually with a set of alternate spellings, and often a category (programming language, laboratory technique).

Extraction is then a search problem. Take the text stream produced by text extraction and reading order, scan it for anything that matches a vocabulary entry, and record a hit.

That is a smaller and dumber operation than most advice implies. It is not reading your bullet point and forming a view. It is asking, thousands of times per document, “does this phrase appear?”

The consequence: describing a skill is not the same as naming it

Here is the failure that catches careful writers. Consider two ways of saying the same thing.

What you wrote: Rebuilt the monthly close so the finance team stopped hand-keying journal entries, cutting the cycle from nine days to four.

What a vocabulary matcher extracts: nothing.

There is no skill name in that sentence. It is a genuinely better bullet than the alternative — it says what changed and by how much — but “month-end close,” “journal entries,” and “process automation” as vocabulary terms are all absent or only implied.

What you wrote: Rebuilt the monthly close (journal entries, reconciliations) in Excel and SQL, cutting the cycle from nine days to four.

What a matcher extracts: month-end close, reconciliations, Excel, SQL.

Nothing was inflated. The work is identical. The second version simply spends four words naming the things it already did.

This is the honest version of “use keywords,” and it is worth stating precisely, because the dishonest version — pasting in skills you don’t have — is a different act entirely. Naming a real skill is accuracy. Naming an absent one is a lie that gets tested in the first interview.

Where hits come from, and where they don’t

A skill can be picked up from anywhere in the extracted text, but not all locations survive equally well.

• A skills section is the most reliable place, because the text is short, unambiguous, and sits under a heading the parser recognised.
• Experience bullets work fine as long as the skill name appears as text, and they carry the advantage of context — a recruiter reading the record can see where you used it.
• A skills graphic — the five-dot proficiency meters, the bar charts, the word cloud — contributes nothing, because images store no text. This is the single most common way people delete their own skills section by accident.
• A skills table or sidebar may survive or may be shredded, depending on how columns and tables interleave during extraction.

Proficiency and recency mostly don’t survive

You will often see resumes annotate skills with a level: Python — advanced, Spanish (conversational), five stars out of five. Some systems store a proficiency value; many simply record that the skill is present and discard the qualifier.

The same goes for recency. Unless a skill name appears inside a dated job entry — and unless the parser correctly associated that entry with its dates — the record may show COBOL with no indication that you last touched it in 2006.

Two practical implications:

1. Don’t rely on a proficiency marker to do important work. If the distinction between “I have written a shell script” and “I maintain build systems” matters, put it in the experience bullet, in words, where a human will read it.
2. Attach current skills to current jobs. A skill named inside your most recent role is more likely to end up dated correctly than the same word sitting in a flat list at the bottom.

Multi-word terms and where they break

Vocabulary matching handles single tokens well and multi-word phrases less well, because a phrase can be broken by things you cannot see.

• Line wrapping can split machine learning across two lines. Most extractors rejoin these correctly; some leave a hard break in the middle.
• A hyphen inserted by justification turns nego- tiation into two fragments.
• A slash list — Python/SQL/R — may or may not be split into three terms depending on the tokeniser. Commas are safer: Python, SQL, R.
• Bullet glyphs and tab characters occasionally end up glued to the adjacent word, producing •Python, which no longer matches Python.

None of these are worth losing sleep over individually. Together they are the argument for the comma-separated, single-column, plain-text skills list: it has the fewest places to go wrong.

What extraction cannot do for you

It is worth being clear about the limits, because a lot of the anxiety in this subject comes from imagining the software is cleverer than it is.

Extraction does not judge quality. It does not know whether your Python is good. It does not know that “stakeholder management” in your case meant chairing a steering committee for three years. It produces a list, that list goes into a database, and a human — or a query, or a scoring rule — works from it later.

So the goal at this stage is narrow and achievable: make sure the list is complete and true. Every real skill you’d be happy to be asked about in an interview should appear once, in ordinary words, in text a machine can copy.

Check it

Open your resume, select all, copy, paste into a plain text editor. Then read only the pasted version and write down every skill name you can see. That list is very close to what extraction will produce.

If a skill you consider central to your candidacy isn’t in it, you now know exactly why the record is thinner than the person. Fix it by naming the thing you actually did — not by adding things you didn’t. There is a fuller version of this exercise in how to test your resume like a parser would.