Hva en ATS-parser faktisk gjør med CV-filen din

"Vi kunne ikke lese filen din", og hva den setningen faktisk rapporterer

Du bruker en kveld på CV-en. Den er ryddig, den får plass på to sider, luften sitter riktig, og for én gangs skyld er du litt stolt av den. Du laster den opp, og enten skjer det ingenting på tre uker, eller så kommer det en linje tilbake om at filen ikke kunne leses. Ingen diagnose, ingen markert del, ingen antydning om hva som falt. Den stillheten er hele problemet, for det som gikk galt er fullt mulig å vite, og ingen forteller deg det.

En parser leser ikke CV-en din slik du ser den. Den henter ut en lineær tekststrøm fra filen og prøver å plassere den i databasefelt, så alt som får mening av oppsettet i stedet for av rekkefølgen på teksten, kan bli stokket om, slått sammen med nabofeltet eller falle bort.

Selve feilmeldingen er smalere enn folk tror. Den dekker en kort liste årsaker, alle i selve filen: en skannet eller bildebasert PDF med tomt tekstlag, et dokument som er passordbeskyttet eller sperret for kopiering, en fil der filendelsen ikke stemmer med innholdet, eller noe opplastingsskjemaet rett og slett ikke tar imot. Det er en lesefeil på bytenivå. Den har ikke sett på erfaringen din og funnet den for tynn.

En grenseoppgang før vi går videre, for to ulike spørsmål blandes sammen hele tiden. Denne siden handler om hvordan selve filen ryker på veien inn. Om et automatisk system deretter siler deg bort på innholdet, er en annen diskusjon, og den tok jeg i teksten om hvorvidt et ATS avviser CV-er automatisk. Jeg gjentar den ikke her.

Og innrømmelsen, med en gang i stedet for gravd ned til slutt, for det er den sterkeste innvendingen mot hele siden. Du burde ikke måtte designe CV-en din rundt programvare som ikke takler to spalter. Det er en teknisk svikt hos leverandøren, ikke hos kandidaten. Den som mistet et intervju til en feil i leserekkefølgen, gjorde ingenting galt, og ingen burde måtte lære seg dokumentformatenes innmat for å søke jobb. Jeg skriver siden likevel, av én smal grunn: å vite koster deg ingenting, og avslagsmailen kommer aldri til å si det.

CV-en din er et bilde. Parseren vil ha en databaserad.

En PDF lagrer tegn på koordinater, ikke struktur. Den ene setningen forklarer det meste av det som følger, så her er hva den betyr i klartekst. En PDF-side er et sett tegneinstruksjoner: sett dette tegnet, i denne skriften, på denne x- og y-posisjonen. Den sier ikke "dette er en overskrift", "dette er en tabellcelle", "denne blokka er sidespalten". Med mindre filen bærer et tilgjengelighetstre, noe de fleste CV-er eksportert fra et designverktøy ikke gjør, finnes den informasjonen bare i øynene dine.

Altså må uttrekkeren rekonstruere den ved gjetning. Den grupperer tegn til ord ved å se på mellomrommene, ord til linjer ved deres felles grunnlinje, og linjer til blokker ved nærhet. Hvert av trinnene er en gjetning som stemmer for det meste. Hver feil lenger ned på denne siden er en av de gjetningene som sporer av på et oppsett som gjorde gjetningen vanskelig.

En DOCX er et annet dyr. Under overflaten er den en zip med XML der et avsnitt er et avsnittselement, en tabell er et tabellelement og en overskrift bærer et navngitt format. Strukturen står skrevet i stedet for å bli gjettet fram. Det betyr ikke at du alltid skal sende Word. Mange parsere takler PDF helt fint, en PDF ser lik ut på hver eneste maskin, og en god del arbeidsgivere tar bare imot det ene formatet. Følg alltid instruksjonen i utlysningen først. Det som er sant, er smalere: en DOCX rekker over struktur parseren ellers måtte gjette seg til.

Den andre halvparten av jobben er kartleggingen. Når det finnes en tekststrøm, prøver systemet å fylle ut felt. Det er disse som teller, og hver feil under er en feil i ett av dem.

• Navn
• Kontaktopplysninger: e-post, telefon, sted
• Arbeidsgiver, per rolle
• Tittel, per rolle
• Startdato og sluttdato, per rolle
• Ferdigheter
• Utdanning

Du har allerede sett resultatet av denne kartleggingen uten at noen sa at det var det du så. Når et søknadsskjema tvinger deg til å laste opp filen og deretter skrive inn de samme tre jobbene i felt, er feltene som kom ferdig utfylt kartleggingen som viser arbeidet sitt, og de som kom feil er den som svikter rett foran deg. Om det trinnet betyr at et menneske kontrollerer noe, er et annet spørsmål, og det svarte jeg på i teksten om å laste opp CV-en og likevel fylle ut skjemaet.

"Sidespalten leses inn midt i arbeidserfaringen din"

Den linjen kommer fra en person på r/resumes som oppga at hen tolker CV-er profesjonelt og beskrev hva som røk i et utvalg på 3 835 filer hen hadde kjørt gjennom. Jeg kommer tilbake til hvor mye det tallet orker å bære. Selve setningen trenger ikke noe utvalg for å stå, for den følger direkte av hvordan leserekkefølgen rekonstrueres, og den er den dyreste feilen på hele siden.

Se for deg oppsettet nesten hver moderne mal leverer: en smal venstrespalte med ferdigheter og språk, en bred høyrespalte med arbeidserfaringen din. På skjermen er de to spaltene åpenbart atskilt. I filen er de bare tegn på koordinater, og tegnene i venstrespalten ligger på de samme vannrette grunnlinjene som tegnene i høyrespalten. En uttrekker som grupperer linjevis, i stedet for å finne spaltegrensen først, sender dem ut sammen.

Les den andre blokka slik en maskin ville gjort. Linjen som skulle bære tittelen din, lyder nå "Python Business Controller". Et feltsystem som leter etter en tittel på den linjen, får en tittel med et programmeringsspråk sveiset fast foran. Ferdighetene dine er ikke lenger en liste, de er første ord på fire urelaterte linjer. Og hvis uttrekkeren i stedet grupperer blokkvis og slipper sidespalten inn der nærheten antyder, kan ferdighetsspalten havne mellom to jobber, slik at datoene etter den fester seg til feil rolle. Det er mekanikken bak en CV som viser de riktige ti årene på skjermen og de gale ti i databasen.

Det ærlige forbeholdet: mange parsere finner spaltene helt riktig, og jeg kan ikke si på forhånd hvilken som sitter i den andre enden av en gitt opplasting. Rådet er altså ikke "to spalter ødelegger deg". Det er smalere og lettere å forsvare. Et enspaltet oppsett fjerner tvetydigheten i stedet for å satse på at den løses pent. Du mister ingenting en rekrutterer setter pris på, for ingen har noen gang blitt ansatt for en sidespalte.

Flatklemte tabeller, ferdighetsklumper og skade på tegnnivå

Den andre rapporterte feilen fra samme tråd var en ferdighetsseksjon klemt flat til én klump, og tabeller er som regel årsaken. En tabell gir leseren mening gjennom rutenettet: denne cellen hører sammen med den der. I en uttrukket tekststrøm er cellegrensene borte, og igjen står en rekke ord i den rekkefølgen cellene tilfeldigvis ble gått gjennom.

Hver parkobling er nå en gjetning, og det blir verre lenger fram. Ferdighetsmatching virker som regel ved å lete etter kjente termer i teksten. En term som er smeltet inn i en lengre streng, eller delt ved det uttrekkeren tror er et linjeskift, kan rett og slett ikke finnes. Du hadde ferdigheten på papiret. Oppslaget så den ikke, og ingen steder rapporteres det.

Så er det tegnnivået, den delen nesten ingen skriver om. Egne punkttegn fra en ikonskrift kommer ofte ut som et ukjent tegn eller som ingenting. Ligaturer er det skarpeste eksempelet, og dette vet jeg på egen hånd fordi det kostet meg en uke i careerifys egen PDF-uttrekker. En ligatur er én glyf som tegner to tegn samtidig, slik mange skrifter tegner fi som én form. I én vanlig Windows-skrift leverte uttrekkeren vår den glyfen tilbake som et nulltegn, så ordet kom inn med et hull midt i. På skjermen var CV-en feilfri. I tekststrømmen var et ord ødelagt, og ingenting i filen sa fra.

Nesten alt på denne siden er usynlig fra din side. Filen ser riktig ut fordi du ser på tegningen. Parseren ser på instruksjonene.

Delene av CV-en din som parseren kanskje aldri ser

Leserekkefølge og tabeller roter til det som er der. Dette avsnittet handler om innhold som aldri når tekststrømmen i det hele tatt, noe som er verre, for et omstokket felt kan fortsatt finnes av et menneske som skummer, og et manglende kan det ikke.

Datoer fortjener én ekstra linje, for de er de stilleste av de seks. Yrkeshistorien din er en rekke intervaller, og parseren må finne ut hvor hvert intervall begynner, hvor det slutter og hvilken arbeidsgiver det hører til. Gi den en måned og et firesifret årstall, bruk samme format for hver rolle og samme skilletegn hele veien. Det høres pirkete ut. Det er det billigste grepet på hele siden.

Speilbildet av alt dette er tekst som finnes i filen, men er usynlig på siden, som er nøyaktig det trikset med hvit tekst bygger på. Det er en dårlig idé av grunner som ikke har med tolkning å gjøre, og dem gikk jeg gjennom i teksten om den usynlige prompten i CV-en. Alt jeg anbefaler her, endrer beholderen, aldri påstandene.

Ulike systemer, ulike parsere, og hvor mye tallene orker å bære

Workday, Greenhouse, Taleo og Lever er ulike produkter med ulike parsere, og her må jeg skuffe alle som kom hit for en tabell over leverandøratferd. Jeg kan ikke si hva noen av dem gjør internt. Jeg har ikke testet dem, atferden deres endres mellom versjoner og mellom kunders oppsett, og hver selvsikre offentlige påstand om en bestemt leverandørs parser jeg har fulgt opp, viste seg å mangle metode. Den som selger deg en regelbok per leverandør, gjetter. Det som trygt kan sies, er hva som gjør dem til samme slags produkt: hver av dem må gjøre en CV-fil om til en lagret post, altså hente ut tekst og plassere den i felt. Hvor godt noen av dem takler de vanskelige tilfellene over, kan jeg ikke si.

Det er også det ærlige svaret på "hvilket format er tryggest". Det finnes ikke noe format, ingen mal og intet oppsett som garanterer en ren tolkning noe sted. Det finnes bare valg som lar mindre stå igjen å gjette på. Det gir jeg deg heller enn en regel jeg ikke kan forsvare.

Så til tallet 3 835, håndtert med den varsomheten det krever. Det er én person på Reddit som beskriver sitt eget oppgitte utvalg, i en tråd der flere kommentatorer tvilte på at tallet var ekte. Jeg vasker det ikke til "forskning viser", og jeg vil heller at du avviser det helt enn at du stoler mer på det enn det tåler. Legg merke til at ingenting i mekanikkavsnittene over henger på det. Leserekkefølge, flatklemte tabeller, tomme tekstlag og ukjente overskrifter følger av hvordan PDF og DOCX er bygget, og de ville vært like sanne om tråden aldri var postet. Utvalget forteller deg at feilene er vanlige. Filformatene forteller deg hvorfor de oppstår.

Én ting til som er verdt å si i stedet for å skjule, for den forklarer hvorfor situasjonen består. Fra arbeidsgiversiden behandles en utvelgelse som mister noen gode kandidater ofte som en akseptabel kostnad for å håndtere volumet. Jeg skal ikke bli forarget over det her; jeg sier det fordi det stiller inn forventningene dine riktig. Løsningen kommer ikke fra leverandøren i tide til å hjelpe neste søknad, og derfor må den skje i filen din inntil videre.

Produktavsnittet, én gang, så du kan veie det mot alt over. careerify har en gratis sjekk på lenken under: ingen konto, intet kort, tre sjekker per IP-adresse per døgn. Den tolker den faktiske opplastede PDF-en eller DOCX-en din slik ethvert annet system måtte gjort, sammenligner så det den fikk mot utlysningen du limer inn, og viser hvilke av utlysningens termer som kom gjennom fra filen din og hvilke som ikke gjorde det. Det er en besiktigelse, ikke en reparasjon. Hvis en term du vet står på side én kommer tilbake som manglende, har du funnet en av feilene på denne siden. Resten av det careerify gjør, å tilpasse en lagret hoved-CV til en bestemt utlysning, er begrenset av fakta du selv har lagt inn og kan ikke finne på en rolle, en arbeidsgiver eller et tall du ikke har gitt det.