Teknisk intervju, tre skräckhistorier
“Zlatan doesn’t do auditions” var något jag hade överst på min LinkedIn-profil. Inte (bara) på grund av arrogans! Grunden var hellre påstridiga rekryterare (ofta sittandes i England) och egentligen ännu mer ett tyst men syrligt försöka att påverka de dåliga rekryteringsprocesser som blivit standard i utvecklingsbranschen: vill du rekrytera mig behöver du göra något bättre än att utsätta mig för tester du kan få svaret på av mitt tidigare arbete.
Att tekniska intervjuer, eller tester, i utvecklingsbranschen gjorts dåligt har länge varit ett känt faktum. O`Reilly publicerade redan 2013 två artiklar av Trisha Gee på temat Technical tests you are doing it wrong som beskrev många av de fel och brister som är vanligt förekommande vid tekniska intervjuer. Dessa tester har ofta en hög kostnad i form av tidsåtgång och liten lärdom för den intervjuade. De testar fel saker såsom möjligheten att arbeta extra övertid, när det förväntas att man arbetar flera timmar på fritiden för att lösa uppgifterna, förmåga att arbeta under övervakning eller att kandidaten i förväg övat in hypotetiska och sällan realistiska testscenarier. Trisha kom också med konkreta förslag på hur dessa kan genomföras på ett bättre och mer effektivt sätt. Ändå har utformningen av tekniska intervjuer fortsatt att i samman form helt till dags dato. Många utvecklare ser fortsatt detta som ett reellt problem något som exempelvis tagits upp på NordicJS 2022 där Carly Litchfield berättade om Interviews by developers, for developers.
Så vad har jag under min karriär fått utstå för att få arbete? Jag tänkte dela de mest speciella tekniska intervjuer jag varit med om (hittills) och hoppas innerligt att det kan bidra till att påverka de dåliga rekryteringsprocesserna som fortfarande finns eller kanske ge dig som ännu inte behövt uppleva detta ett perspektiv på hur dåliga dess processer kan vara.
Tre skräckhistorier
Gruppintervju
Tidigt i min karriär sökte jag ett jobb på ett då nyuppstartat medtechbolag. Idag är detta företag väldigt stort och har en stor marknadsandel i Norden. Här bjöd man in lite under 20 nyutexaminerade kandidater till intervju på samma dag. Efter välkomstfraser och information från företaget blev vi uppdelade i tillfälliga mindre grupper. Vi skulle tillsammans, i gruppen, på bästa sätt bygga en lastbil av en hög med Legobrickor. Denna övning hade varierande succé mellan grupperna och medan några byggde en Legobil stod andra kvar med en hög brickor och några hjul när tiden gått ut.
Jag har alltid älskat Lego! … Men här hade man nästan lyckats förstöra min kärlek till Lego.
Jag har alltid älskat Lego! Jag fick inget jobb och heller ingen annan i min grupp. Jag stod igen med en dålig känsla av att på ett slumpmässigt och irrelevant sätt blivit bedömd på något hel oväsentligt kriterium för det jobb jag sökt. De ville testa förmåga att jobba i grupp, men satte samman grupper på ett för arbetslivet onaturligt sätt och testade på en hypotetisk men orealistisk arbetsuppgift. Men här hade man nästan lyckats förstöra min kärlek till Lego.
Gratis arbetskraft
Ett stort världskänt, och på den tiden marknadsledande, telecombolag bjöd in en handfull kandidater till sitt kontor för en heldag med intervjuer och tester. Efter en kortare inledande intervju och den vanliga presentationen av bolaget visade det sig att alla kandidater var där på samma dag. Resten av dagen var planerad som en gratis arbetsdag — här fanns en backlog bestående av buggar man inte själv lyckats lösa och som nu den riktiga kandidaten kunde visa att hen utfyllde teamets bristande kunskap med sina. Flest squashed bugs vid dagens slut får jobbet… 🐛
Den nedvärderande känslan av att stå med mössan i hand som en annan daglönare gjorde att jag avstod från det tekniska testet, tackade nej och åkte hem.
Övertidsscreening
…se det som test skapat för att diskvalificera eller diskriminera småbarnsföräldrar…
Den sista historian handlar om ett väldigt vanligt förekommande, så vanligt att nästan enbart undantagsfallen inte är utformade så, i anställningsprocesser för utvecklare. Här pratar vi om att man ska genomföra tester eller uppgifter hemma som sedan ska diskuteras på intervju. Dessa uppgifter som alltid beskrivs som både “små” och “enkla” och som bara tar “någon timme” — i alla fall om man redan är insatt i kontexten eller är den som konstruerat testet (eller för dennes chef som inte har kompetens att värdera detta). Men faktum är att dessa nästan alltid tar mycket längre tid och blir en slags tävling mot andra sökare om vem som lägger ner mest tid. Tid som kan jämställas med att gräva ett hål och fylla det igen eftersom värdet för den som gör testet är lika med noll. Kan du bygga ett Black Jack, hämta data här och visa där, sätta upp all boiler plate för att visa att du kan bygga en sida? Ja, det kan jag och jag har redan 1000 verkliga referenser på det! Det blir då ett test för att se vem som har mycket fritid och kan jobba övertid snarare än ett relevant arbetstest. Jag kan dessutom precis som du (Big Corp) köpa utvecklingstimmar från Indien för att lösa grävande av hål åt mig, vilket ytterligare minskar värdet av filtreringen via hemtester. Kanske kunde man vända på det och se det som test skapat för att diskvalificera eller diskriminera småbarnsföräldrar eller de med riktiga liv vid sidan av arbetet?
Hos en välkänd offentligt arbetsgivare som satsade stort på att bygga en moder intern miljö för digitalisering hade man tagit detta med att göra hemtester till nya höjder. Här skulle man hemma genomföra uppgifter på flera timmar redan före första intervjun, och så också mellan alla kommande steg i processen. Totalt tre tester på 2–4 timmar styck, för alla kandidater bara för att kvalificera till att prata med en människa. Den förminskade och nedvärderade synen på den sökande var uppenbar. Vilken typ av anställda appellerade de egentligen med denna process? Antagligen samma som sin persona — vit man utan fritid eller med jämställdhet i hemmet liknandes 1950-tal. Lika barn leka bäst.
En bättre rekryteringsprocess
Ingen av dessa arbetsgivare skulle jag söka mig till igen.
Ingen av dessa arbetsgivare skulle jag villigt söka mig till igen. Även om säkert både rekryterare och process förändrats så har dessa upplevelser byggt varande känslor för dem som arbetsgivare. Ord sprider sig dessutom från en utvecklare till en annan och snart är det flera kandidater som inte längre aktivt söker sig till din arbetsplats. Det kan vara värt att beakta när man väljer hur en anställningsprocess ska se på de sökande, dessa sökare kan vara de som inte når fram idag men som du kanske önskar dig om några år.
Själv har jag under några år med framgång använt mig av code reviews som en metod för diskussionsunderlag vid tekniska intervjuer. Då får den som söker jobb se en del av den kod hen kan komma att jobba med, och därmed bättre förstå situationen hen kommer till, för att så komma med konstruktiv feedback som visar på förståelse för både kodmönster och teknologi. Jag upplever att det har en låg kostnad för båda parter och hög träffsäkerhet. Om man dessutom begränsar tiden som förväntas användas av den sökande kan den individuella kostnaden eller tidsåtgången minskas ytterligare.
Ett annat alternativt tillvägagångssätt för ungefär samma metod är att den sökande får visa fram och diskutera igenom kod hen skrivit, gärna ett bra exempel och ett exempel med förbättringspotential. Detta ger möjlighet att se på både kod, kritiskt tänkande och förmåga att visa fram och förmedla eget arbete.
Variant
Hos Variant genomförs tekniska tester genom att man utför en uppgift i samarbete. Den sökande och de som intervjuar löser tillsammans ett problem, lite så som det är ute i det verkliga arbetslivet. Trygghet skapas mellan parterna genom transparens i intervjuprocessen, och att alla i intervjun ska ha liknande utgångspunkt och tillsammans hjälps åt att lösa ett gemensam problem istället för hamna i en förhörsliknande situation.
Läs mer om intervjuprocessen hos Variant i bloggen och sök gärna på lediga jobb 🥰
Lycka till. Jag vet att du kan bidra till att göra tekniska intervjuer i branschen bättre! 🤝
