Vad en ATS-parser faktiskt gör med din CV-fil

"Vi kunde inte läsa din fil", och vad den meningen faktiskt rapporterar

Du lägger en kväll på ditt CV. Det är rent, det får plats på två sidor, luften sitter rätt, och för en gångs skull är du lite stolt över det. Du laddar upp det och antingen händer ingenting på tre veckor eller så kommer det tillbaka en rad om att filen inte gick att läsa. Ingen diagnos, inget markerat avsnitt, ingen antydan om vilken del som föll. Den tystnaden är hela problemet, för det som gick fel är fullt möjligt att veta och ingen berättar det.

En parser läser inte ditt CV som du ser det. Den drar ut en linjär textström ur filen och försöker mappa den mot databasfält, så allt vars betydelse ligger i layouten i stället för i textens ordning kan kastas om, slås ihop med grannfältet eller falla bort.

Själva felmeddelandet är smalare än folk tror. Det täcker en kort lista orsaker, alla i själva filen: en inskannad eller bildbaserad PDF med tomt textlager, ett dokument som är lösenordsskyddat eller spärrat för kopiering, en fil vars filändelse inte stämmer med innehållet, eller något uppladdningsformuläret helt enkelt inte tar emot. Det är ett läsfel på bytenivå. Det har inte tittat på din erfarenhet och funnit den otillräcklig.

En gränsdragning innan vi går vidare, för två olika frågor blandas ihop hela tiden. Den här sidan handlar om hur själva filen går sönder på vägen in. Om ett automatiskt system sedan sållar bort dig på innehållet är en annan diskussion, och den tog jag i texten om huruvida ett ATS nekar CV automatiskt. Jag tänker inte upprepa den här.

Och medgivandet, direkt i stället för nedgrävt i slutet, för det är den starkaste invändningen mot hela sidan. Du borde inte behöva designa ditt CV runt programvara som inte klarar av två spalter. Det är ett tekniskt misslyckande hos leverantören, inte hos kandidaten. Den som förlorade en intervju till en bugg i läsordningen gjorde ingenting fel, och ingen borde behöva lära sig dokumentformatens innanmäte för att söka jobb. Jag skriver ändå sidan, av ett enda smalt skäl: att veta kostar dig ingenting, och avslagsmejlet kommer aldrig att berätta det.

Ditt CV är en bild. Parsern vill ha en databasrad.

En PDF lagrar tecken på koordinater, inte struktur. Den enda meningen förklarar det mesta av det som följer, så här är vad den betyder i klartext. En PDF-sida är en uppsättning ritinstruktioner: sätt det här tecknet, i det här typsnittet, på den här x- och y-positionen. Den säger inte "det här är en rubrik", "det här är en tabellcell", "det här blocket är sidospalten". Om filen inte bär ett tillgänglighetsträd, vilket de flesta CV exporterade ur ett designverktyg inte gör, finns den informationen bara i dina ögon.

Alltså måste uttolkaren rekonstruera den genom gissningar. Den grupperar tecken till ord genom att titta på mellanrummen, ord till rader genom deras gemensamma baslinje, och rader till block genom närhet. Varje steg är en gissning som stämmer för det mesta. Varje fel längre ner på den här sidan är en av de gissningarna som spårar ur på en layout som gjorde gissningen svår.

En DOCX är ett annat djur. Under ytan är den en zip med XML där ett stycke är ett styckeelement, en tabell är ett tabellelement och en rubrik bär ett namngivet format. Strukturen står utskriven i stället för att gissas fram. Det betyder inte att du alltid ska skicka Word. Många parsers klarar PDF alldeles utmärkt, en PDF ser likadan ut på varje dator, och en hel del arbetsgivare tar bara emot det ena formatet. Följ alltid annonsens instruktion först. Det som är sant är smalare: en DOCX räcker över struktur som parsern annars måste gissa sig till.

Den andra halvan av jobbet är mappningen. När det finns en textström försöker systemet fylla i fält. Det är de här som räknas, och varje fel nedan är ett fel i något av dem.

• Namn
• Kontaktuppgifter: mejl, telefon, ort
• Arbetsgivare, per roll
• Titel, per roll
• Startdatum och slutdatum, per roll
• Kompetenser
• Utbildning

Du har redan sett resultatet av den här mappningen utan att någon sa att det var det du såg. När ett ansökningsformulär tvingar dig att ladda upp filen och sedan skriva in samma tre jobb i rutor, är de rutor som kom förifyllda mappningen som visar sitt arbete, och de som kom fel är den som misslyckas framför ögonen på dig. Om det steget betyder att en människa kontrollerar något är en annan fråga, och den svarade jag på i texten om att ladda upp CV:t och ändå fylla i formuläret.

"Sidospalten läses in mitt i din arbetslivserfarenhet"

Den raden kommer från en person på r/resumes som uppgav att hen tolkar CV yrkesmässigt och beskrev vad som gick sönder i ett urval på 3 835 filer som hen kört igenom. Jag återkommer till hur mycket den siffran orkar bära. Själva meningen behöver inget urval för att hålla, för den följer direkt av hur läsordningen rekonstrueras, och den är det dyraste felet på hela sidan.

Tänk dig layouten som nästan varje modern mall levererar: en smal vänsterspalt med kompetenser och språk, en bred högerspalt med din arbetslivserfarenhet. På skärmen är de två spalterna uppenbart åtskilda. I filen är de bara tecken på koordinater, och tecknen i vänsterspalten ligger på samma horisontella baslinjer som tecknen i högerspalten. En uttolkare som grupperar radvis, i stället för att först hitta spaltgränsen, skickar ut dem tillsammans.

Läs det andra blocket som en maskin skulle göra. Raden som borde bära din titel lyder nu "Python Business Controller". Ett fältsystem som letar efter en titel på den raden får en titel med ett programmeringsspråk fastsvetsat i början. Dina kompetenser är inte längre en lista, de är första ordet på fyra orelaterade rader. Och om uttolkaren i stället grupperar blockvis och släpper in sidospalten där närheten antyder, kan kompetensspalten hamna mellan två jobb, så att datumen efter den fäster vid fel roll. Det är mekaniken bakom ett CV som visar rätt tio år på skärmen och fel tio år i databasen.

Den ärliga reservationen: många parsers hittar spalterna alldeles rätt, och jag kan inte säga i förväg vilken som sitter i andra änden av en viss uppladdning. Rådet är alltså inte "två spalter förstör dig". Det är smalare och mer försvarbart. En enspaltig layout tar bort tvetydigheten i stället för att satsa på att den löses snyggt. Du förlorar ingenting som en rekryterare värderar, för ingen har någonsin blivit anställd för en sidospalt.

Utplattade tabeller, kompetensklumpar och skador på teckennivå

Det andra rapporterade felet från samma tråd var en kompetenssektion som plattats till en enda klump, och tabeller är oftast orsaken. En tabell ger läsaren mening genom rutnätet: den här cellen hör ihop med den där. I en uttolkad textström är cellgränserna borta, och kvar är en rad ord i den ordning cellerna råkade gås igenom.

Varje parbildning är nu en gissning, och det blir värre längre fram. Kompetensmatchning fungerar i regel genom att leta efter kända termer i texten. En term som smälts in i en längre sträng, eller delats vid det uttolkaren tror är ett radbrott, kan helt enkelt inte hittas. Du hade kompetensen på pappret. Uppslagningen såg den inte, och ingenstans rapporteras det.

Sedan finns teckennivån, den del nästan ingen skriver om. Egna punktglyfer från ett ikontypsnitt kommer ofta ut som ett omappat tecken eller som ingenting alls. Ligaturer är det skarpaste exemplet, och det här vet jag på egen hand eftersom det kostade mig en vecka i careerifys egen PDF-uttolkare. En ligatur är en enda glyf som ritar två tecken samtidigt, så som många typsnitt ritar fi som en enda form. I ett vanligt Windows-typsnitt lämnade vår uttolkare tillbaka den glyfen som ett nolltecken, så ordet kom in med ett hål mitt i. På skärmen var CV:t felfritt. I textströmmen var ett ord trasigt, och ingenting i filen berättade det.

Nästan allt på den här sidan är osynligt från din sida. Filen ser rätt ut för att du tittar på teckningen. Parsern tittar på instruktionerna.

De delar av ditt CV som parsern kanske aldrig ser

Läsordning och tabeller rör om i det som finns. Det här avsnittet handlar om innehåll som aldrig når textströmmen alls, vilket är värre, för ett omkastat fält kan fortfarande hittas av en människa som skummar och ett saknat kan det inte.

Datum förtjänar en extra rad för de är de tystaste av de sex. Din yrkeshistoria är en följd av intervall, och parsern måste lista ut var varje intervall börjar, var det slutar och vilken arbetsgivare det hör till. Ge den en månad och ett fyrsiffrigt årtal, använd samma format för varje roll och samma skiljetecken hela vägen. Det låter petigt. Det är den billigaste åtgärden på hela sidan.

Spegelbilden av allt det här är text som finns i filen men är osynlig på sidan, vilket är precis vad tricket med vit text bygger på. Det är en dålig idé av skäl som inte har med tolkning att göra, och dem gick jag igenom i texten om den osynliga prompten i CV:t. Allt jag rekommenderar här ändrar behållaren, aldrig påståendena.

Olika system, olika parsers, och hur mycket siffrorna orkar bära

Workday, Greenhouse, Taleo och Lever är skilda produkter med skilda parsers, och här måste jag göra alla som kom hit för en tabell över leverantörsbeteenden besvikna. Jag kan inte säga vad någon av dem gör internt. Jag har inte testat dem, deras beteende ändras mellan versioner och mellan kunders inställningar, och varje självsäkert offentligt påstående om en viss leverantörs parser som jag har följt upp visade sig sakna metod. Den som säljer dig en regelbok per leverantör gissar. Det som går att säga tryggt är vad som gör dem till samma sorts produkt: var och en måste förvandla en CV-fil till en lagrad post, alltså dra ut text och mappa den mot fält. Hur väl någon av dem klarar de svåra fallen ovan kan jag inte säga.

Det är också det ärliga svaret på "vilket format är säkrast". Det finns inget format, ingen mall och ingen layout som garanterar en ren tolkning någonstans. Det finns bara val som lämnar mindre att gissa. Det ger jag hellre än en regel jag inte kan försvara.

Nu till siffran 3 835, hanterad med den omsorg den kräver. Det är en person på Reddit som beskriver sitt eget uppgivna urval, i en tråd där flera kommentatorer tvivlade på att siffran var äkta. Jag tänker inte tvätta den till "forskning visar", och jag vill hellre att du avfärdar den helt än litar mer på den än den orkar. Lägg märke till att ingenting i mekanikavsnitten ovan hänger på den. Läsordning, utplattade tabeller, tomma textlager och okända rubriker följer av hur PDF och DOCX är byggda, och de vore precis lika sanna om tråden aldrig hade postats. Urvalet säger dig att felen är vanliga. Filformaten säger dig varför de uppstår.

En sak till som är värd att säga i stället för att dölja, för den förklarar varför läget består. Från arbetsgivarsidan behandlas ett urvalsflöde som tappar en del bra kandidater ofta som en acceptabel kostnad för att klara volymen. Jag tänker inte bli upprörd över det här; jag säger det för att det ställer in dina förväntningar rätt. Fixen kommer inte från leverantören i tid för att hjälpa din nästa ansökan, och därför måste den ske i din fil så länge.

Produktstycket, en gång, så att du kan väga det mot allt ovan. careerify har en gratis kontroll på länken nedan: inget konto, inget kort, tre kontroller per IP-adress per dygn. Den tolkar din faktiska uppladdade PDF eller DOCX på samma sätt som vilket annat system som helst skulle behöva göra, jämför sedan det den fick mot annonsen du klistrar in, och visar vilka av annonsens termer som kom igenom från din fil och vilka som inte gjorde det. Det är en besiktning, inte en reparation. Om en term du vet står på sida ett kommer tillbaka som saknad har du hittat ett av felen på den här sidan. Resten av det careerify gör, att anpassa ett sparat master-CV till en specifik annons, är begränsat av fakta du själv har lagt in och kan inte hitta på en roll, en arbetsgivare eller en siffra du inte har gett det.