Resume Parse

Where One Job Entry Ends and the Next Begins

Sectioning gets a lot of attention: the parser finds the experience section, and everything under it is work history. But that is only half the job. Inside that section sits a run of text that has to be cut into separate records — one per role, each with its own employer, title, dates and description. Nothing in the file says where one record stops. The parser has to infer the boundaries.

Get those boundaries wrong and every field is still populated, every date still parses, and the record is still wrong: bullets attached to the wrong employer, a role that never existed, or four jobs merged into two.

What a record boundary is made of

A parser looking for entry boundaries is working from a small number of signals, all of them visual or positional rather than semantic.

Vertical space. A larger gap between blocks than between lines within a block is the strongest cue. This is the one you have the most control over and the one most often broken by a document tightened to fit one page.

A date range appearing. A line containing something recognisable as Mar 2022 – Jun 2024 is a strong hint that a new entry has started or is starting, because dates are the anchor of the whole section — see job titles, dates, and the fields parsers look for.

A repeated line pattern. If lines 1, 6 and 11 all match “phrase — Capitalised Words, Location” and the lines between them all start with a bullet character, the shape of your document is the boundary rule. Parsers exploit this heavily.

Bullet characters. A bulleted line is almost never the start of a new entry. A non-bulleted line following bullets very often is. Bold or larger text is a weaker signal than it looks, because formatting often does not survive extraction at all.

Notice what is not on that list: the meaning of the words. A parser does not know that “Northwind Ltd” is a company and “Lead Analyst” is a job. It knows that one of them appears where employers usually appear in this particular document.

The four ways the cut goes wrong

Two entries merge. The gap between them is the same size as the gap between the title line and the date line, so the parser reads one entry with two date ranges. Typical outcome: the second employer disappears, its bullets are appended to the first job, and the merged role gets a single span from the earliest start to the latest end. That span then feeds the arithmetic in how software counts your years of experience, producing a tenure you never had.

One entry splits. A blank line inside a job — inserted to separate “Responsibilities” from “Achievements,” or landing there because of a page break — creates a second record with bullets and no employer. It shows up in the parsed view as a role with an empty title, or the bullets get filed as unclassified text.

Bullets migrate. The boundary is placed one line late, so the last bullet of job A becomes the first line of job B, or vice versa. The most quietly damaging version: the achievement you are proudest of is now credited to the wrong employer, and any human reading the parsed record sees a claim that will not survive a reference check.

The current role is wrong. If the boundary error changes which entry holds the Present end date, your current title is wrong everywhere it is displayed and filtered on.

The pattern that segments cleanly

There is no magic layout, only a consistent one. What follows is not a template to copy so much as a set of properties to satisfy.

EXPERIENCE

Lead Analyst — Northwind Ltd., Columbus, OH
Mar 2022 – Present
· Bullet
· Bullet

Senior Analyst — Calder Group, Columbus, OH
Jan 2019 – Feb 2022
· Bullet
· Bullet

The properties that do the work:

  • A bigger gap between entries than inside them. One clear blank line between roles, none inside a role. If your document is tight on space, take it out of the margins, not out of this gap.
  • Every entry has the same number of lines in the same order before the bullets: header line, then dates. Not dates-first for one role and dates-last for the next.
  • The dates are on their own line, adjacent to the entry they belong to. Dates hanging at the right margin of the header line work too, provided you do it with a tab stop and not a table cell.
  • Every bullet is a real bullet, produced by the list formatting, not a manually typed dash on some entries and a bullet on others.
  • No blank lines inside an entry, ever, and no internal sub-headings like Achievements: on their own line. Those look like entry headers and invite a split.

Two roles at one employer

The structure people most often reach for here is a company header with roles nested underneath:

Northwind Ltd., Columbus, OH
  Lead Analyst          Mar 2022 – Present
  Senior Analyst        Jan 2019 – Feb 2022

It is elegant and it is the highest-risk structure in the section, because the nesting is expressed purely through indentation and the employer name appears exactly once. If the parser treats each role line as a full entry, one or both roles end up with no employer; if it treats the block as one entry, you get a single role with two titles.

The safe alternative is to repeat the employer name on every entry and let the two roles be two ordinary records. Repetition reads as slightly redundant to a human and as unambiguous to a machine, and the promotion still reads clearly from the dates — the question of how to present a promotion at all is covered in job titles, dates, and the fields parsers look for.

Indentation as your only structural signal is generally a bad bet. It may not survive extraction, and where it does survive it arrives as leading spaces that the parser must decide whether to interpret.

Consistency beats cleverness

The single highest-value habit in this whole area: use one entry template and never vary it. A parser can often infer your document’s own conventions if it has one to infer. Alternating between Title — Employer and Employer: Title, or putting dates above the header for recent roles and beside it for older ones, guarantees that at least one entry gets read against the wrong rule. That is the same mechanism behind the ambiguity described in parser confidence and the unclassified block.

Consistency costs nothing visually. It is often the thing that makes a resume look considered rather than assembled.

Check it

Paste your resume into a plain text editor and read only the experience section.

  1. Number the entries you intended. Then read the plain text and number the entries a stranger would count. The two numbers should match.
  2. Check the last bullet of every job. Confirm it sits above the next employer’s header line and not below it.
  3. Look for a blank line inside any entry. Delete it.
  4. Ask whether the boundaries are still obvious from spacing and line patterns alone, now that the formatting is gone. If you can only tell where a job starts because you remember, a parser cannot tell at all.
  5. Read the date ranges as a list, in order. Any overlap or gap you did not intend is a symptom that a boundary landed in the wrong place.
parsingformattingats