jobhunt

Writing

What the scanner sees, what the human sees

At a basic level, an applicant tracking system stores applications and supports a hiring workflow. Implementations vary. Some parse a résumé into fields such as employers, titles, and dates. Some use knockout questions a person configured. Some add ranking or matching features. A recruiter may search or skim the resulting queue. There is no single robot, and no single secret score that every employer uses.

The parser and the human do fail you in different ways, though, and it's worth knowing both.

Parsing tools can struggle with structure. Columns, tables, headers, footers, and unusual section names give extraction software more ways to read something differently than you intended. The exact behavior depends on the product and configuration. A conservative document uses a simple reading order, standard section names, consistent dates, and contact details in the body of the page.

A human skim has a different constraint: time. A hurried reader may start with your current role, recent work, and dates, then decide whether to keep going. Adjectives are easy to skip. Specifics sometimes earn another look: a number, a recognizable system, the name of the thing you built. Relevant experience buried deep in the document is easier to miss.

The text can be right while the page is wrong, in other words, and we ended up building a separate check for the rendered page. jobhunt uses restrained résumé layouts, but we have not finished validation against real applicant-tracking vendors and do not claim that every generated PDF parses correctly. Before you download, a vision model also looks at images of the rendered pages, because there's a class of problem no text-level check can see: a bullet list split across a page break, a section heading orphaned at the bottom of a page, a line quietly overflowing its margin. That check is advisory. It flags, you decide. It's also been humbling about how many ways a correct document can still look wrong.

So when people ask what to optimize for, the honest answer is: give both readers fewer reasons to struggle. Use a straightforward structure. Put relevant material where a hurried person can find it, in the posting's own vocabulary, with specifics instead of adjectives. The useful part of keyword advice survives in domesticated form: the words need to be there when they truthfully describe your work, because software and people may search for them. They also need to survive a follow-up question.

What doesn't survive is the idea that one universal robot can be beaten with one universal score. That story sells software, but it hides the variation between employers and products. The practical fix is duller than a robot war: use a page with a clear reading order, say the relevant thing early, and keep every claim ready for a person to ask about.