“Zlatan doesn’t do auditions” var noe jeg hadde øverst på min LinkedIn-profil. Ikke (bare) på grunn av arroganse!
Grunnen var heller pågående rekrutterere (ofte sittende i England), og egentlig enda mer et stille, men syrlig forsøk på å påvirke de dårlige rekrutteringsprosessene som har blitt standard i utviklingsbransjen:
Vil du rekruttere meg, trenger du å gjøre noe bedre enn å utsette meg for tester du kan få svaret på fra mitt tidligere arbeid.
Tekniske intervjuer
Tekniske intervjuer, eller tester, i utviklingsbransjen har lenge blitt gjort dårlig.
O`Reilly publiserte allerede i 2013 to artikler av Trisha Gee om temaet, "Technical tests, you are doing it wrong", som beskrev mange av feilene og manglene ved tekniske intervjuer.
Disse testene har ofte en høy kostnad i form av tidsbruk og liten lærdom for den intervjuede. De tester feil ting, som evnen til å arbeide overtid når det forventes at oppgavene løses over mange timer på fritiden, evnen til å arbeide under overvåkning, eller om kandidaten på forhånd har øvd inn hypotetiske og sjeldent realistiske testscenarier.
Trisha kom også med konkrete forslag til hvordan disse kan gjennomføres på en bedre og mer effektiv måte. Likevel har utformingen av tekniske intervjuer fortsatt i samme form til dags dato.
Mange utviklere ser fortsatt dette som et reelt problem, noe som eksempelvis ble tatt opp på NordicJS 2022 hvor Carly Litchfield snakket om "Interviews by developers, for developers".
Så hva har jeg måttet gjennomgå i min karriere for å få arbeid? Jeg tenkte å dele de mest spesielle tekniske intervjuene jeg har vært med på (hittil), og håper inderlig at det kan bidra til å påvirke de dårlige rekrutteringsprosessene som fortsatt finnes, eller kanskje gi deg som ennå ikke har opplevd dette et perspektiv på hvor dårlige disse prosessene kan være.
Skrekkhistorie #1: Gruppeintervju med Lego
Tidlig i min karriere søkte jeg en jobb hos et da nyoppstartet medtech-selskap. I dag er dette selskapet veldig stort og har en stor markedsandel i Norden.
Her inviterte de litt under 20 nyutdannede kandidater til intervju samme dag. Etter velkomstfraser og informasjon fra selskapet ble vi delt opp i midlertidige mindre grupper. Vi skulle sammen, i gruppen, bygge en lastebil av en haug med Lego-klosser.
Denne øvelsen hadde varierende suksess mellom gruppene, og mens noen bygde en Lego-bil, sto andre igjen med en haug klosser og noen hjul når tiden var ute. Jeg har alltid elsket Lego! Men jeg fikk ingen jobb, og det gjorde heller ingen i min gruppe.
Jeg satt igjen med en dårlig følelse av å ha blitt bedømt på en tilfeldig og irrelevant måte, basert på noe helt uviktig for jobben jeg søkte. De ønsket å teste evnen til å jobbe i gruppe, men satte sammen grupper på en unaturlig måte og testet på en hypotetisk, men urealistisk arbeidsoppgave. Her hadde de nesten klart å ødelegge min kjærlighet til Lego.
«Jeg har alltid elsket Lego! Men jeg fikk ingen jobb.»
Skrekkhistorie #2: Gratis arbeidskraft
Et stort, verdenskjent og markedsledende telekomselskap inviterte en håndfull kandidater til sitt kontor for en hel dag med intervjuer og tester.
Etter et kort innledende intervju og den vanlige presentasjonen av selskapet, viste det seg at alle kandidatene var der samme dag.
Resten av dagen var planlagt som en gratis arbeidsdag — her var det en backlog bestående av feil man ikke selv hadde klart å løse, og som nå kandidatene kunne vise at de kunne fylle teamets manglende kunnskap med sine. Flest squashed bugs ved dagens slutt får jobben… 🐛
Den nedverdigende følelsen av å stå med lua i hånden som en annen dagarbeider gjorde at jeg avsto fra det tekniske testen, takket nei og dro hjem.
«Resten av dagen var planlagt som en gratis arbeidsdag.»
Skrekkhistorie #3: Overtids-screening
Den siste historien handler om noe som er veldig vanlig, så vanlig at nesten bare unntakene ikke er slik, i ansettelsesprosesser for utviklere. Her snakker vi om å gjennomføre tester eller oppgaver hjemme som deretter skal diskuteres på intervju.
Disse oppgavene beskrives alltid som både “små” og “enkle”, som bare tar “noen timer” — i alle fall hvis man allerede er kjent med konteksten eller har konstruert testen (eller for sjefen som ikke har kompetanse til å vurdere dette).
Men faktum er at disse nesten alltid tar mye lengre tid, og blir en slags konkurranse mot andre søkere om hvem som bruker mest tid. Tid som kan sammenlignes med å grave et hull og fylle det igjen, siden verdien for den som gjør testen er lik null.
Sånn takler du et teknisk jobbintervju - inkludert FizzBuzz
Kan du bygge en Black Jack, hente data her og vise der, sette opp all boilerplate for å vise at du kan bygge en side? Ja, det kan jeg, og jeg har allerede 1000 virkelige referanser på det! Det blir da en test for å se hvem som har mye fritid og kan jobbe overtid snarere enn et relevant arbeidstest.
Jeg kan dessuten, akkurat som du (Big Corp), kjøpe utviklingstimer fra India for å løse graving av hull for meg, noe som ytterligere reduserer verdien av filtreringen via hjemmetester. Kanskje kunne man snu det og se det som en test skapt for å diskvalifisere eller diskriminere småbarnsforeldre, eller de med ekte liv ved siden av arbeidet?
Hos en velkjent offentlig arbeidsgiver som satset stort på å bygge et moderne internt miljø for digitalisering hadde man tatt dette med å gjøre hjemmetester til nye høyder. Her skulle man hjemme gjennomføre oppgaver på flere timer allerede før første intervju, og så gjennom alle kommende steg i prosessen. Totalt tre tester på 2 til 4 timer hver, for alle kandidater, bare for å kvalifisere til å snakke med et menneske. Den reduserte og nedverdigende synet på den søkende var åpenbar.
Hvilken type ansatte appellerte de egentlig til med denne prosessen? Antagelig de samme som sin persona — hvit mann uten fritid eller med likestilling i hjemmet liknende 1950-tallet. Like barn leker best.
«Tid som kan sammenlignes med å grave et hull og fylle det igjen, siden verdien for den som gjør testen er lik null.»
En bedre rekrutteringsprosess
Ingen av disse arbeidsgiverne ville jeg frivillig søkt meg til igjen. Selv om både rekrutterere og prosesser sikkert har endret seg, har disse opplevelsene gitt varige følelser for dem som arbeidsgivere.
Ord sprer seg også fra en utvikler til en annen, og snart er det flere kandidater som ikke lenger aktivt søker seg til din arbeidsplass. Dette kan være verdt å vurdere når man velger hvordan en ansettelsesprosess skal se ut for søkerne; disse søkerne kan være de som ikke når frem i dag, men som du kanskje ønsker deg om noen år.
Selv har jeg i noen år med suksess brukt kodegjennomganger som en metode for diskusjonsunderlag ved tekniske intervjuer. Da får den som søker jobb se en del av koden hen kan komme til å jobbe med, og dermed bedre forstå situasjonen hen kommer til, for så å komme med konstruktiv tilbakemelding som viser forståelse for både kodemønstre og teknologi.
Nå skjer det, igjen: Søker utviklere til høsten 2025, nå
Jeg opplever at det har en lav kostnad for begge parter og høy treffsikkerhet. Hvis man i tillegg begrenser tiden som forventes brukt av den søkende, kan den individuelle kostnaden eller tidsbruken reduseres ytterligere.
En annen alternativ tilnærming for omtrent samme metode er at den søkende får vise frem og diskutere gjennom kode hen har skrevet, gjerne et godt eksempel og et eksempel med forbedringspotensial. Dette gir mulighet til å se både på kode, kritisk tenkning og evne til å vise frem og formidle eget arbeid.
Hos oss i Variant gjennomføres tekniske tester ved at man utfører en oppgave i samarbeid. Den søkende og de som intervjuer løser sammen et problem, litt slik det er ute i det virkelige arbeidslivet. Trygghet skapes mellom partene gjennom transparens i intervjuprosessen, og at alle i intervjuet skal ha lignende utgangspunkt og sammen hjelpe til med å løse et felles problem i stedet for å havne i en forhørslignende situasjon.
Lykke til. Jeg vet at du kan bidra til å gjøre tekniske intervjuer i bransjen bedre! 🤝
(kode24 har oversatt teksten fra svensk med ChatGPT 4o, og kvalitetssikra den med ekte mennesker, som ikke er så flinke i svensk.)
