Web Development Project: Jobsin.co

#Forskjellen mellom en tom installasjon og et fullt arkiv

De to dyreste feilene i en jobbportal har det til felles at de ikke vises før datamengden er stor nok. Begge ser helt riktige ut i uke én og begge krever omskriving i måned seks, og derfor begynner denne teksten med dem og ikke med funksjonslisten.

Den første er søket. Å filtrere på et dusin egenskaper samtidig over titusener av poster er i en relasjonsdatabase en spørring med mange koblinger. Den svarer umiddelbart på en fersk installasjon med et titalls testposter, og bruker sekunder mot et fullt arkiv. Derfor går søket her gjennom Elasticsearch, mens MySQL blir liggende som kilden til sannhet, for søkeindeksen er en avledet struktur og må kunne bygges opp igjen fra bunnen.

Den andre er varslene. En portal som sender e-post til alle relevante kandidater hver gang en annonse publiseres, havner i søppelpostmappen i løpet av en måned og når deretter ikke fram i det hele tatt, heller ikke til dem som selv bestilte varslene. Sendingen går derfor gjennom en kø, med frekvens valgt av kandidaten og gruppering etter relevans.

Fellesnevneren er at begge feilene bare lar seg avdekke mot ekte data. Lasttestene kjøres av den grunn mot en kopi av produksjonen, ikke mot en demoinstallasjon, og det er den enkeltbeslutningen som hindret flest overraskelser i dette prosjektet.

#Hva Jobsin.co er

Jobsin.co er en jobbportal for kvalifiserte tekniske spesialister innen bygg, maskinteknikk, ingeniørfag og beslektede industrisektorer, som kobler fagfolk til arbeidsgivere i flere nasjonale markeder. Prosjektet kom til oss i 2019 og leveransen tok rundt seks uker. Oppsettet og plasseringen av elementene kom fra kunden, så tiden som ellers går til designrunder, gikk her til de to delene som avgjør om en jobbportal holder: kompetansetaksonomien og flyten som flytter en søknad mellom tilstander.

De tekniske bransjene skiller seg fra resten av arbeidsmarkedet på måter som når helt inn i arkitekturen. Det er mangel på fagfolk globalt, så kandidaten har overtaket og fyller ikke ut et skjema med tjue felter. En stor andel av stillingene forutsetter flytting til utlandet, og da kommer visum, godkjenning av kvalifikasjoner og forskjeller i arbeidsrett inn i omfanget. Kravene er smale, og en betydelig del av oppdragene er tidsbegrenset eller på kontrakt, noe som endrer hele logikken bak varsler: en stilling som er åpen i tre uker, må nå riktig person de første dagene.

#Taksonomien er produktet

På en generell jobbportal holder det med søk på nøkkelord, fordi kandidat og arbeidsgiver bruker de samme ordene. I teknisk rekruttering svikter den mekanismen umiddelbart, for den samme kompetansen har et dusin navn: noen er et handelsnavn fra en produsent, noen en bransjeforkortelse, og noen avhenger av land og av hvem som skrev annonsen.

En sveiser med sertifikat for en bestemt metode, en operatør av en maskin fra en bestemt produsent og en ingeniør som arbeider etter en standard som gjelder i ett land, er tre tilfeller der tekstsøk gir enten null treff eller flere hundre uten sammenheng. Grunnlaget for denne plattformen er derfor ikke en søkemotor, men en ordnet kompetanseliste: et hierarki der en ferdighet har en overordnet kategori, koblinger til beslektede ferdigheter, angivelse av forutsetninger og et nivå fra grunnleggende til ekspert.

Å bygge en slik liste er fagarbeid og ikke programmering, og det er den delen som oftest undervurderes i prosjekter av dette slaget. Matchekode skrevet over et vokabular som fortsatt er i bevegelse, må skrives om hver gang en kategori får nytt navn. Rekkefølgen her ble derfor motsatt av den vanlige: først listen, så søk og varsler oppå den. Praktisk betyr det at en ny bransje etter lansering er et arbeid med data og ikke med kode.

#En annonse utløper på en dato

Nesten alt innhold på et nettsted eldes langsomt. En stillingsannonse gjør ikke det. Den utløper på en planlagt dag, og etter den dagen gjør den skade: den som søker på en stilling som ikke finnes, kaster bort tiden sin, og nettstedet mister troverdighet raskere enn ved noen teknisk feil.

Tre beslutninger følger av dette. Statusen på en annonse er et felt med lukket verdiliste og har sin egen livssyklus, uavhengig av teksten. Utløp sletter ikke posten, men endrer tilstanden, for søknadshistorikken må overleve annonsen den hører til. Og en utløpt annonse må slutte å være synlig for søkemotorer, noe som er eget arbeid og ikke en bivirkning: en side som først er indeksert, lever videre i resultatene i uker og sender trafikk til en stilling som ikke finnes.

Strukturerte data for stillingsannonser er i denne kategorien ikke pynt, men den viktigste distribusjonskanalen, fordi søkemotorene viser stillinger i en egen modul. Merkingen må derfor stemme med tilstanden til posten på dagen, og det er den eneste grunnen til at utløpsdatoen ligger i dataene og ikke i et avsnitt skrevet av en rekrutterer.

#Søk, matching og det matchingen ikke lover

Søket arbeider på listen beskrevet over og på lukkede egenskaper: sted fordelt på land, region og by, bransje, erfaringsnivå, kontraktstype, lønnsspenn og valuta, samt mulighet for fjernarbeid. Matchingen vekter overlapp i kompetanse, betydningen av stedspreferanse, erfaringsnivå og lønnsforventning.

Det er verdt å si rett ut hva en slik mekanisme ikke gjør. Den vurderer ikke kandidaten og forutsier ikke om vedkommende vil lykkes i stillingen. Den sorterer en liste etter samsvar mellom det begge parter har skrevet om seg selv, og ikke mer. Plattformer i denne klassen omtales ofte i et språk som antyder mer, og forskjellen betyr noe, for den avgjør om en rekrutterer behandler resultatet som et forslag eller som en dom. Prosenttallet ved siden av en stilling er lettlest for kandidaten og samtidig det mest risikable elementet i grensesnittet, for et tall ser ut som en måling og er en sum av vekter noen har satt for hånd.

#En søknad er en tilstand, ikke et innsendt skjema

På de fleste nettsteder slutter et skjema når meldingen er sendt, og det er hele livsløpet. På en jobbportal er en søknad et objekt som lever i uker og går gjennom tilstander: innsendt, gjennomgått, innkalt til intervju, avslått, lukket sammen med annonsen. Å behandle den som en e-post ser ut som en forenkling og gir to problemer samtidig.

Det første er stillheten hos kandidaten. Den som har sendt ti søknader og ikke vet hva som skjedde med noen av dem, slutter å bruke nettstedet raskere enn den som får avslag. En statusvisning og et varsel ved hver endring koster nesten ingenting og avgjør om kandidaten kommer tilbake. Det andre gjelder rekruttererens eget arbeid: uten tilstander er det umulig å si hvor mange søknader som venter, og umulig å lage en oversikt som ikke består i å telle meldinger i en innboks.

Tilstandene betyr også noe for lagring. En søknad inneholder personopplysninger og må slettes eller anonymiseres etter perioden kandidaten har samtykket til. Uten en uttrykkelig tilstand og dato lar ikke det seg automatisere, og gjøres det for hånd, gjør ingen det lenger etter et år.

#Kandidatens data og innstillingen som avgjør alt

En kandidatprofil i teknisk rekruttering er omfattende: kompetanse fra listen, sertifikater og godkjenninger med gyldighetsdatoer, arbeidshistorikk med prosjektbeskrivelser, språk, stedspreferanser inkludert flyttevillighet, og lønnsforventning i valgt valuta. Av dette genereres et søknadsdokument, flere versjoner kan lagres, og å søke fra en ferdig profil er én handling.

Det viktigste i denne delen er likevel ikke en funksjon, men en standardinnstilling. En kandidat som er i jobb og ser seg om, vil ikke at nåværende arbeidsgiver skal se profilen. Synligheten til profilen, muligheten for å søke anonymt og spørsmålet om hva et selskap faktisk ser før kontakt, ligger derfor hos brukeren, og standardverdiene er tilbakeholdne. Et nettsted som i utgangspunktet viser alt til alle, samler flere profiler ved lansering og mister nøyaktig de fagfolkene som er mest etterspurt, fordi de har mest å tape.

Personvern er derfor ikke bare etterlevelse forstått som en vilkårsside og en avkryssingsboks. Det er en del av produktet: samtykkehåndtering, dataportabilitet, sletting og lagring innenfor EU er kravene som avgjør om en kandidat i det hele tatt oppretter en konto.

#Arbeidsgiversiden og ærligheten i annonsene

Rekruttereren får en annonseredigering med strukturert kravliste, flere steder, lønnsspenn, frister og et malbibliotek, og på kandidatsiden oppfølging av søknader, sammenlikning av profiler, intervjuplanlegging og meldingsmaler. Tilgang for team betyr at flere personer arbeider på samme stilling, så en statusendring må knyttes til en person og ikke til firmakontoen.

Tillit er et eget tema. I internasjonale markeder er en falsk annonse en reell fare for kandidaten, fordi det dreier seg om arbeid i utlandet, flyttekostnader og noen ganger betaling krevd på forskudd. Verifisering av arbeidsgiver skjer derfor i flere trinn, annonser modereres, og meldinger fra brukere går til manuell gjennomgang. Automatisk gjenkjenning av mønstre er en hjelp og ikke en avgjørelse: siste steg tas av et menneske, for kostnaden ved en feil bæres den ene veien av kandidaten og den andre veien av en redelig arbeidsgiver som har fått annonsen holdt tilbake.

#Etterlevelse uten fiksjonen om ett regelverk

En plattform som opererer i flere land møter ulik arbeidsrett, ulike krav til data og ulike regler for publisering av lønnsspenn. Det dårligste mulige svaret er ett regelverk skrevet for den mest ettergivende jurisdiksjonen, fordi det ser ut som orden og i praksis flytter risikoen over på brukeren.

I stedet er etterlevelseslaget modulært: vilkår og klausuler henger på et land, data rutes til riktig lagringssted, og forskjellene er beskrevet som konfigurasjon og ikke som kode. Et nytt marked betyr da å fylle ut et sett regler og skaffe en juridisk gjennomgang for den jurisdiksjonen, ikke å gå gjennom hele applikasjonen.

#Valuta, språk og avstanden til stillingen

En stillingsannonse som gjelder arbeid i et annet land, bærer to opplysninger som er vanskeligere enn de ser ut: hva lønnen faktisk er, og hvor langt unna stedet ligger.

Lønn oppgitt i én valuta og lest i et annet land er nesten uten informasjonsverdi før den er omregnet, og en omregning som skjer på visningstidspunktet skaper et nytt problem, nemlig at tallet endrer seg mellom to besøk uten at arbeidsgiveren har rørt annonsen. Løsningen ble å lagre beløpet i valutaen arbeidsgiveren oppga, vise den som den opprinnelige verdien og oppgi en omregning som tydelig er en omregning. Et tall som later som det er avtalt lønn når det er dagens kurs, er den typen unøyaktighet som først dukker opp i en samtale om kontrakt.

Avstand er det samme problemet i en annen form. En stilling kan være aktuell for en som bor i nabolandet og uaktuell for en som bor to timer unna i samme land, avhengig av om arbeidsgiveren dekker reise og bolig. Derfor er stedet en egenskap med land, region og by, og ikke en fritekst, slik at filteret kan svare på spørsmålet kandidaten faktisk stiller.

Flerspråkligheten følger av det samme. En annonse skrevet på ett språk skal kunne finnes av en kandidat som søker på et annet, og det er nok en grunn til at kompetansene ligger i en liste med identifikatorer i stedet for i ord: identifikatoren er den samme uansett hvilket språk annonsen er skrevet på.

#Ytelse og teknologi

Plattformen står på WordPress med et eget jobbportaltema, en kraftig tilpasset annonsemotor, egne utvidelser og Advanced Custom Fields Pro. Datalaget er MySQL med replikering, Redis for økt- og objektmellomlager, Elasticsearch for søk og et eget lager for analysedata. Rundt dette ligger integrasjoner for distribusjon og strukturerte data, betalingsløsninger og e-postleverandører, med skyhosting, CDN, lastbalansering, køarbeidere og overvåking under.

Ytelsesarbeidet konsentrerer seg om listevisningene, fordi de bærer mesteparten av trafikken og er dyrest å beregne. Mellomlageret holder resultater for de vanligste filterkombinasjonene, statiske filer kommer fra CDN, og databasespørringene ble gjennomgått med tanke på dem som vokser lineært med antall annonser.

#Slik gikk gjennomføringen

Leveransen tok rundt seks uker fra gjennomgang av omfanget til lansering. Rekkefølgen på arbeidet er beskrevet over og fulgte av én observasjon: de to dyre feilene i denne kategorien viser seg først ved volum, og må derfor avgjøres før lansering og ikke etter den første måneden.

Etter lansering gikk prosjektet over i vedlikehold: sikkerhetskopier, sikkerhetsoppdateringer, jevnlig gjennomgang av ytelsen og lasttesting foran periodene der ansettelsesvolumet stiger. Vedlikeholdet omfatter også kvalitetskontroll av annonser og moderering, som på en jobbportal ikke er redaksjonelt arbeid, men direkte beskyttelse av nettstedets troverdighet.

#Konklusjon

Jobsin.co viser at en jobbportal i teknisk rekruttering ikke er en liste over stillinger med et søkefelt. Den er en kompetanseliste, en varslingsmekanisme, et etterlevelseslag for flere markeder og en prosess for verifisering av arbeidsgivere, og grensesnittet er det siste laget oppå alt dette. Alle de tekniske valgene over følger av den rekkefølgen: listen før matchingen, søkeindeksen atskilt fra kilden til sannhet, køen foran utsendingen, tilbakeholdne standardvalg for personvern, og et menneske i siste modereringssteg.

Det som overføres til neste leveranse, er arbeidsmåten. Listen og integrasjonene overføres ikke, for de ble bygget for ett marked og for én kundes data. Neste prosjekt begynner med en gjennomgang av omfanget, og prisen kommer etter den.