Can you elaborate on the exact layout syntax these ML idiot savant agents want to read? Lack of an industry wide standard data interface makes this terrible.
Even that can fail. I’ve had multiple cases now where my name (!) was auto-parsed wrong in a way human would never do, not even after copy-pasting into Notepad.
The reason? My resume lists my name as follows, where I means the initial for my middle name:
Firstname I. (Nickname) Lastname
And yes, even professionally I do use my nickname and my last name, except for things which must match my government ID, such as offer letters and payroll/tax records, where of course I omit Nickname and use the legal Firstname as well as sometimes the middle initial or full middle name.
With this format, how does Personio parse my name? It thinks I’m called Firstname Nickname. No human would make this mistake, nor would a copy-paste into Notepad cause a human to do that.
And if it has any LLM intelligence at all, it should know that this is unlikely, because Nickname is actually a very common nickname for Firstname, so it should suspect a disperse and have a human double-check its conclusion. Alas.
I’ve also had other issues with these systems misparsing my employment history, since they don’t always properly parse jobs that span corporate acquisitions (changing title and employer at that point but being the same job) and are accurately reflected as such on the resume.
>Even that can fail. I’ve had multiple cases now where my name (!) was auto-parsed wrong in a way human would never do, not even after copy-pasting into Notepad. [...]
sounds like they did something like:
first_name, last_name = name.split(" ")
which is an issue, but unrelated to what everyone else is talking about, which seems to be how text data is being parsed/encoded inside pdfs. Pasting into notepad would check for that issue, but obviously wouldn't do anything for bad first name/last name extraction logic.
I felt that the general topic was "software failing to do the right thing parsing the text in PDF resumes in ways a human would get right", which includes all of these types of problems, not specific to encoding issues. But, sure.
I think mashing up of names happens a lot, since they are not common words. Personally I don't see what the problem is of your name being mangled in a parsed resume, other than when it would look offensive. The name mangling can get easily cleared up after first contact with a real person.
I’ve indeed cleared it up quickly every time it’s happened, but in my opinion, it makes the company look unprofessional in an easily avoidable way. (And yes, I’ve been in the hiring manager role myself - I’d feel the same way if this happened to one of my candidates.)
I call this easily avoidable because name is usually a separate field in the application or referral forms, so this is the bad auto-parsing overriding accurate manual input.
Parsing names is like writing a time library. Sounds easy until you learn the hard way that it definitely isnt.
Some examples that come to mind from my experience are applicants with Chinese names that also use a western name professionally ("Yu-Chen Liew, but I go by Janet"), Spanish names that include patronymics ("Penelope Cruz Sanchez") and cultures that place the family name first ("Park Lee"). Maybe (f,l) = split(name, " ") works in some very homogeneous country like Iceland, but it sure doesnt work in the US.
Yes, agreed - except that the Spanish name convention you describe isn't about patronymics exactly. Patronymics are something like a given language's version of "son [or daughter] of X" where X is a given name of the parent (usually the father).
By contrast, Spanish last names simply use two last names, with a child taking one last name from each parent. Traditionally this is the father's first last name followed by the mother's first last name, though efforts toward gender equality have made the law more flexible nowadays in both Spain and many other countries.
It doesn't violate Spanish naming conventions for given names to be reused in the next generation, and some families do that, but that isn't patronymic since it's not a "son/daughter of X" name, just a reused given name.
I can only speak for what worked for me. A shorthand heuristic might be that if the resume can be read in linear fashion by a screenreader without any weirdness or non sequiturs, it's probably pretty good (another argument in favor of paying attention to accessibility!)
In my case, I had a simple layout with sections clearly delineated and very simple formatting (bulleted lists). Dates were spelled out eg September 2024 rather than 9/24. UTF-8 throughout. No difficult latex packages, just classic ones like enumitem and fancyhdr.
Word/Google Docs -> PDF conversion is perfectly fine, and every system will understand it. Just don't try to get fancy with layouts and stick to headings, subheadings and bullets. People reading the resume will appreciate this as well.
This is how I formatted my resume using Pandoc to generate a word document from a Markdown file. Having everything in Markdown also made it easy to quickly create customized resumes by reordering specific sections or lists in a section as well as tracking changes in Git.
There is an industry standard - HR-XML[0] (disclaimer: I was on the committee for a little while). But I would be surprised if any of the job boards let you import it directly.
Frankly, plain text rendered to PDF is probably going to be the most easily parsed by their systems. If they let you add attachments separate from your resume, then stick your "beautified" resume there.
I've spoken with two technical recruiters who say they prefer reading templates instead of hand-crafted Resumes on top of them also parsing better in the ATS system ):
Can confirm a similar attitude from an HR person - they prefer a single-column, easy to scan resume that follows a tried and trusted standard structure and layout.
