Wat een ATS-parser echt met je cv-bestand doet

"We konden je bestand niet lezen": wat die zin eigenlijk meldt

Je besteedt een avond aan je cv. Het is strak, het past op twee pagina's, de witruimte klopt, en voor één keer ben je er een beetje trots op. Je uploadt het en er gebeurt drie weken lang niets, of er komt een regel terug dat het bestand niet gelezen kon worden. Geen diagnose, geen aangewezen onderdeel, geen hint over wat er sneuvelde. Die stilte is het hele probleem, want wat er misging is prima te achterhalen en niemand vertelt het je.

Een parser leest je cv niet zoals jij het ziet. Hij haalt een lineaire tekststroom uit het bestand en probeert die over databasevelden te verdelen, dus alles waarvan de betekenis in de opmaak zit in plaats van in de volgorde van de tekst, kan verschuiven, samensmelten met het buurveld of wegvallen.

De letterlijke foutmelding is smaller dan mensen denken. Hij dekt een korte lijst oorzaken, allemaal in het bestand zelf: een gescande of uit afbeeldingen opgebouwde pdf met een lege tekstlaag, een document met wachtwoord of kopieerbeveiliging, een bestand waarvan de extensie niet klopt met de inhoud, of een formaat dat het uploadformulier simpelweg niet accepteert. Het is een leesfout op byteniveau. Die melding zegt niets over je ervaring.

Eén afbakening voordat we verdergaan, want twee verschillende vragen lopen constant door elkaar. Deze pagina gaat over hoe het bestand zelf stukgaat bij binnenkomst. Of een geautomatiseerd systeem je daarna op inhoud wegfiltert is een andere discussie, en die voerde ik in het stuk over of een ATS cv's automatisch afwijst. Die ga ik hier niet overdoen.

En de toegeving, meteen in plaats van weggestopt aan het eind, want dit is het sterkste bezwaar tegen deze hele pagina. Je zou je cv niet moeten hoeven ontwerpen rond software die geen twee kolommen kan lezen. Dat is een technisch falen aan de leverancierskant, niet aan die van de kandidaat. Wie een uitnodiging misliep door een fout in de leesvolgorde heeft niets verkeerd gedaan, en niemand zou de binnenkant van documentformaten moeten leren om te kunnen solliciteren. Ik schrijf de pagina toch, om één smalle reden: weten kost je niets, en de afwijzingsmail gaat het je nooit vertellen.

Je cv is een tekening. De parser wil een databaserij.

Een pdf slaat glyphs op coördinaten op, geen structuur. Die ene zin verklaart het grootste deel van wat volgt, dus dit is wat hij betekent in gewone taal. Een pdf-pagina is een set tekeninstructies: zet dit teken, in dit lettertype, op deze x- en y-positie. Er staat niet "dit is een kop", "dit is een tabelcel", "dit blok is de zijkolom". Tenzij het bestand een toegankelijkheidsstructuur meedraagt, wat de meeste cv's uit een ontwerpprogramma niet doen, bestaat die informatie alleen in jouw ogen.

De extractie moet die dus reconstrueren door te gokken. Glyphs worden tot woorden gegroepeerd op basis van de tussenruimtes, woorden tot regels op basis van hun gedeelde basislijn, en regels tot blokken op basis van nabijheid. Elk van die stappen is een aanname die meestal klopt. Elke storing verderop op deze pagina is zo'n aanname die ontspoort op een opmaak die het gokken lastig maakte.

Een docx is een ander beest. Onder de motorkap is het een zip met XML waarin een alinea een alinea-element is, een tabel een tabelelement, en een kop een benoemde stijl draagt. De structuur staat er, in plaats van dat hij wordt afgeleid. Dat betekent niet dat je altijd Word moet sturen. Veel parsers gaan prima om met pdf, een pdf ziet er op elke machine hetzelfde uit, en heel wat werkgevers accepteren maar één van de twee. Volg altijd eerst de instructie in de vacature. Wat wel klopt is smaller: een docx geeft de parser structuur die hij anders zou moeten raden.

De andere helft van het werk is het toewijzen. Zodra er een tekststroom is, probeert het systeem velden te vullen. Dit zijn de velden die ertoe doen, en elke storing hieronder is het falen van één ervan.

• Naam
• Contactgegevens: e-mail, telefoon, woonplaats
• Werkgever, per functie
• Functietitel, per functie
• Begindatum en einddatum, per functie
• Vaardigheden
• Opleiding en diploma's

Je hebt het resultaat van dat toewijzen allang gezien zonder dat iemand erbij zei wat het was. Als een sollicitatieformulier je het bestand laat uploaden en daarna dezelfde drie banen in vakjes laat overtypen, zijn de vakjes die vooringevuld binnenkwamen dat toewijzen dat zijn werk laat zien, en de vakjes die verkeerd binnenkwamen zijn datzelfde toewijzen dat voor je ogen faalt. Of die stap betekent dat een mens iets controleert is een andere vraag, en die beantwoordde ik in het stuk over je cv uploaden en dan tóch het formulier invullen.

"De zijkolom wordt midden in je werkervaring ingelezen"

Die zin komt van iemand op r/resumes die zegt beroepsmatig cv's te verwerken en beschreef wat er misging in een steekproef van 3.835 bestanden die diegene naar eigen zeggen had verwerkt. Ik kom terug op hoeveel dat getal kan dragen. De zin zelf heeft geen steekproef nodig om overeind te blijven, want hij volgt rechtstreeks uit de manier waarop de leesvolgorde wordt gereconstrueerd, en het is de duurste storing op deze hele pagina.

Denk aan de opmaak die vrijwel elk modern sjabloon meelevert: een smalle linkerkolom met vaardigheden en talen, een brede rechterkolom met je werkervaring. Op het scherm zijn de twee kolommen overduidelijk gescheiden. In het bestand zijn het alleen glyphs op coördinaten, en de glyphs in de linkerkolom liggen op dezelfde horizontale basislijnen als die in de rechterkolom. Een extractie die per regel groepeert, in plaats van eerst de kolomgrens te vinden, gooit ze er samen uit.

Lees het tweede blok zoals een machine dat zou doen. De regel die je functietitel zou moeten dragen luidt nu "Python Business controller". Een systeem dat op die regel een titel zoekt, krijgt een titel met een programmeertaal ervoor gelast. Je vaardigheden zijn geen lijst meer, ze zijn het eerste woord van vier ongerelateerde regels. En als de extractie in plaats daarvan per blok groepeert en de zijkolom ertussen laat vallen waar de nabijheid dat suggereert, kan de vaardighedenkolom tussen twee banen belanden, waardoor de data erna aan de verkeerde functie plakken. Dat is het mechanisme achter een cv dat op het scherm de juiste tien jaar toont en in de database de verkeerde.

Het eerlijke voorbehoud: heel veel parsers herkennen kolommen prima, en ik kan je niet vooraf vertellen welke er aan de andere kant van een upload zit. Het advies is dus niet "twee kolommen slopen je". Het is smaller en beter te verdedigen. Een opmaak in één kolom haalt de dubbelzinnigheid weg in plaats van erop te gokken dat die goed wordt opgelost. Je verliest niets wat een recruiter waardeert, want nog nooit is iemand aangenomen vanwege een zijkolom.

Platgeslagen tabellen, vaardighedenbrij en schade op tekenniveau

De tweede gemelde storing uit datzelfde draadje was een vaardighedenblok dat tot één brij was platgeslagen, en tabellen zijn daar meestal de oorzaak van. Een tabel geeft de lezer betekenis via het raster: deze cel hoort bij die cel. In een uitgelezen tekststroom zijn de celgrenzen weg, en wat overblijft is een rij woorden in de volgorde waarin de cellen zijn afgelopen.

Elke koppeling is nu een gok, en verderop wordt het erger. Het herkennen van vaardigheden werkt meestal door bekende termen in de tekst te zoeken. Een term die is versmolten met een langere reeks, of afgebroken waar de extractie denkt een regeleinde te zien, is dan gewoon niet te vinden. Je had de vaardigheid op papier staan. De zoekopdracht zag hem niet, en nergens wordt dat gemeld.

Dan is er het tekenniveau, het stuk waar bijna niemand over schrijft. Eigen opsommingstekens uit een pictogramlettertype komen er vaak uit als een niet-toegewezen teken of als niets. Ligaturen zijn het scherpste voorbeeld, en dit weet ik uit eerste hand omdat het me een week kostte in careerify's eigen pdf-extractie. Een ligatuur is één glyph die twee tekens tegelijk tekent, zoals veel lettertypen fi als één vorm tekenen. In een veelgebruikt Windows-lettertype gaf onze extractie die glyph terug als een nulteken, waardoor het woord met een gat in het midden binnenkwam. Op het scherm was het cv vlekkeloos. In de tekststroom was een woord kapot, en niets in het bestand meldde dat.

Bijna alles op deze pagina is vanaf jouw kant onzichtbaar. Het bestand ziet er goed uit omdat jij naar de tekening kijkt. De parser kijkt naar de instructies.

De delen van je cv die de parser misschien nooit ziet

Leesvolgorde en tabellen husselen wat er staat. Dit onderdeel gaat over inhoud die de tekststroom helemaal niet haalt, en dat is erger: een gehusseld veld kan een mens die snel doorleest nog terugvinden, een ontbrekend veld niet.

Data verdienen één extra regel, want ze zijn de stilste van de zes. Je loopbaan is een reeks periodes, en de parser moet uitzoeken waar elke periode begint, waar hij eindigt en bij welke werkgever hij hoort. Geef hem een maand en een jaartal van vier cijfers, gebruik hetzelfde formaat bij elke functie en overal hetzelfde scheidingsteken. Het klinkt pietluttig. Het is de goedkoopste ingreep op deze hele pagina.

Het spiegelbeeld van dit alles is tekst die wel in het bestand staat maar onzichtbaar is op de pagina, precies waar de truc met witte tekst op leunt. Dat is een slecht idee om redenen die niets met uitlezen te maken hebben, en die zette ik op een rij in het stuk over de onzichtbare prompt in een cv. Alles wat ik hier aanraad verandert de verpakking, nooit de beweringen.

Andere systemen, andere parsers, en wat de cijfers kunnen dragen

Workday, Greenhouse, Taleo en Lever zijn verschillende producten met verschillende parsers, en hier moet ik iedereen teleurstellen die kwam voor een tabel met gedrag per leverancier. Ik kan je niet vertellen wat een van hen intern doet. Ik heb ze niet getest, hun gedrag verandert tussen versies en tussen klantconfiguraties, en elke zelfverzekerde publieke bewering over de parser van een specifieke leverancier die ik heb nagetrokken, bleek geen methode achter zich te hebben. Wie je een regelboek per leverancier verkoopt, gokt. Wat je veilig kunt zeggen is wat ze tot hetzelfde soort product maakt: elk van hen moet een cv-bestand omzetten in een opgeslagen record, dus er tekst uit halen en die over velden verdelen. Hoe goed ze de lastige gevallen hierboven aankunnen, kan ik je niet vertellen.

Dat is ook het eerlijke antwoord op "welk formaat is het veiligst". Er is geen formaat, sjabloon of opmaak die ergens een schone uitlezing garandeert. Er zijn alleen keuzes die minder te raden overlaten. Dat geef ik je liever dan een regel die ik niet kan verdedigen.

Dan het getal 3.835, behandeld met de zorg die het verdient. Het is één persoon op Reddit die zijn of haar eigen opgegeven steekproef beschrijft, in een draadje waarin meerdere reageerders betwijfelden of het getal echt was. Ik ga het niet witwassen tot "onderzoek toont aan", en ik heb liever dat je het helemaal terzijde schuift dan dat je er meer op vertrouwt dan het kan dragen. Merk op dat niets in de mechanische onderdelen hierboven ervan afhangt. Leesvolgorde, platgeslagen tabellen, lege tekstlagen en niet-herkende koppen volgen uit hoe pdf en docx zijn opgebouwd, en zouden even waar zijn als dat draadje nooit was geplaatst. De steekproef vertelt je dat deze storingen vaak voorkomen. De bestandsformaten vertellen je waarom ze gebeuren.

Nog één ding dat het waard is om te zeggen in plaats van te verzwijgen, want het verklaart waarom de situatie voortduurt. Van de werkgeverskant wordt een selectie die een aantal goede kandidaten kwijtraakt vaak gezien als aanvaardbare prijs voor het verwerken van de volumes. Ik ga me er hier niet over opwinden; ik vertel het omdat het je verwachtingen goed zet. De oplossing komt niet op tijd van de leverancier om je volgende sollicitatie te helpen, en daarom moet ze voorlopig in jouw bestand gebeuren.

De productalinea, één keer, zodat je die kunt afwegen tegen al het bovenstaande. careerify heeft een gratis check via de link hieronder: geen account, geen kaart, drie checks per IP-adres per 24 uur. Hij verwerkt echt de pdf of docx die je uploadt, zoals elk ander systeem dat ook zou moeten doen, vergelijkt wat hij eruit haalde met de vacature die je erin plakt, en laat zien welke termen uit de vacature vanuit je bestand zijn doorgekomen en welke niet. Dat is een inspectie, geen reparatie. Komt een term waarvan je weet dat hij op pagina één staat terug als ontbrekend, dan heb je een van de storingen van deze pagina gevonden. De rest van wat careerify doet, een opgeslagen master-cv toespitsen op een specifieke vacature, blijft binnen de feiten die je zelf hebt ingevoerd en kan geen functie, werkgever of getal verzinnen dat je niet hebt gegeven.