Fixing what the parser got wrong before a person sees it
Reconciling parsed employment history against the source document and flagging the fields that disagree, rather than presenting parser output as fact. Formatting into the house template comes after that, because formatting wrong data neatly is not an improvement.
The parser reads the resume, then somebody corrects the employment dates it merged, which is most of the time it was supposed to save.
Resumes arrive in every format that has ever existed, including scans with no text layer and designed templates in two columns that get read in the wrong order. Parsing is nearly always a third-party component, and its characteristic failure is employment history: dates written as ranges with words in them produce merged employers and wrong tenure.
- Textkernel
- Bullhorn
- JobDiva
When this is the wrong thing to build
Pick something else if you intend to rank candidates on the output. That crosses from enrichment into selection and brings the whole compliance surface with it.
The constraint that shapes it
This is the sector where the boundary is sharpest, and it is worth stating plainly: rejection is the regulated act, not enrichment. More on how this sector works.
A file arrives. The fields come back typed and checkable. Read what this shape is, or start from one of these.
- Reading dates out of a ratified contract
- Abstracting a commercial lease into dated fields
- Filling an MLS input sheet from the listing agreement
- Turning a docket entry into a calendar
- Turning a delivered transcript into a usable set of cites
- Coding a filing fee to the matter that will repay it
- Why does my resume parser merge two jobs into one?
- How do I check parsed employment dates against the original document?
- Can a parser get tenure right when a date says present?
- Why did the parser file a job title under the wrong employer?
- Should a formatted resume wait until the parsed fields are corrected?
Back to recruiting and staffing, or see how this is priced and scoped.