Teknisk screening utan kodtest: så går du tillväga

Kort svar: teknisk screening utan kodtest går ut på att bedöma arbete som redan finns. Läs kandidatens publika kod, särskilt ändringar som andra har godkänt, och be sedan kandidaten förklara en av dem i ett strukturerat samtal. En ingenjör går på djupet i ett andra samtal, och för de sista kandidaterna kan du lägga till en kort betald uppgift.

Kodtest fungerar bra i vissa lägen, och de är ingen dålig metod. Men många erfarna utvecklare tackar nej till flera timmars obetalt arbete, och hemmatest kan i dag lösas med hjälp av AI-verktyg. Därför vill många team ha ett första steg som inte kräver något av kandidaten.

Varför teamen letar efter alternativ

• Kandidater hoppar av. Erfarna utvecklare har ofta flera erbjudanden och väljer bort processer som tar mycket tid.
• Pussel liknar sällan jobbet. Algoritmuppgifter ligger långt från det dagliga arbetet.
• AI. Karats medgrundare har sagt att ungefär 80 procent av kandidaterna använder språkmodeller i tester, enligt SoftwareSeni. Det är ett påstående från branschen, inte ett uppmätt faktum, men riktningen är tydlig.
• Kostnad. Testplattformar säljer ofta årspaket. HackerRanks startpaket listades till exempel för 990 dollar per år för 60 försök, vilket är mycket om ni ska anställa två personer.

Det betyder inte att kodtest är dåliga. De är ett verktyg bland flera. Se jämförelsen i take-home, live coding och GitHub-granskning (på engelska).

Teknisk screening utan kodtest i fyra steg

Steg 1: Läs arbete som redan finns (10 minuter)

Ett arbetsprov är något riktigt som du kan bedöma. Utvecklare med publik kod har redan gjort många.

• Öppna kandidatens GitHub-profil. Hoppa över stjärnor och gröna rutor, de mäter aktivitet och inte kvalitet.
• Titta på godkända ändringar, så kallade merged pull requests, i projekt som kandidaten inte äger. Där har någon annan sagt ja.
• Titta på kodgranskningar som kandidaten har gjort åt andra. De visar omdöme.
• Kontrollera att arbetet pågått över månader och inte bara i en kort period.

Hela metoden beskrivs i hur du utvärderar en utvecklares GitHub-profil (på engelska).

DevEval gör det här steget automatiskt. Verktyget läser bara kod som kandidaten själv har skrivit, säger vad det inte kunde se och föreslår intervjufrågor om kandidatens egna ändringar.

Finns ingen publik kod går du vidare till steg 2 och ber kandidaten beskriva ett tidigare projekt. Privat arbete är vanligt och säger ingenting negativt om kandidaten.

Steg 2: Ett screeningsamtal på 30 minuter

Fråga om kandidatens arbete, inte om facit-frågor.

• "Berätta om den här ändringen du gjorde i projekt X. Vad var problemet?"
• "Vad bad granskaren dig ändra, och höll du med?"
• "Vad skulle du göra annorlunda i dag?"
• "Vilken del gjorde någon annan?"

Du kontrollerar om kandidaten förstår det hen har levererat. De som skrivit koden svarar med detaljer och avvägningar. Hur du bedömer svaren utan att kunna koda beskrivs i rekrytera utvecklare utan teknisk bakgrund.

Steg 3: Tekniskt samtal med en ingenjör (45 till 60 minuter)

En ingenjör läser samma arbete och går djupare: designval, vad som händer när något går fel och hur kandidaten skulle angripa ett problem från er produkt. Det är ett samtal om riktig kod, inte ett förhör. Har ni ingen ingenjör kan ni hyra in en för en timme.

Steg 4: Valfri betald uppgift (bara finalister)

För de två eller tre sista kandidaterna kan du erbjuda en kort, betald uppgift: granska en pull request från er kodbas, rätta en liten bugg eller skriv en kort designnotering. Håll den till två eller tre timmar, betala för tiden och kom överens om omfattningen i förväg. Betalning gör utbytet rättvist och visar respekt för kandidatens tid.

Vad du ska leta efter: gröna och röda flaggor

Gröna flaggor	Röda flaggor
Godkända ändringar i andras projekt	Bara kopior av handledningsprojekt utan egna ändringar
Tydliga beskrivningar av vad och varför	Kan inte förklara sitt eget listade projekt
Svarar på feedback med ändringar eller motiverat motstånd	Säger "vi" om allt och kan inte säga vad hen gjorde
Arbete utspritt över månader eller år	All aktivitet strax före ansökan
Ärlig om vad hen inte byggde själv	Påståenden som inte stämmer med koden eller med senare svar

Behandla flaggorna som anledningar att fråga mer. En enda röd flagga räcker sällan för att avfärda någon.

När ett kodtest fortfarande är rätt val

Ett test eller en uppgift slår profilgranskning i dessa lägen:

• Volymrekrytering, där du behöver ett enhetligt filter för hundratals sökande.
• Junior- och nyexamen-roller, där kandidaterna har lite verkligt arbete att visa.
• Roller där publik kod är osannolik, till exempel inom säkerhet eller finans med strikt privat kod.
• Reglerade eller högriskroller, där du behöver en dokumenterad och repeterbar bedömning.

I de lägena ger en bra testplattform en struktur som profilgranskning inte kan ge. De bästa processerna blandar metoder: en snabb granskning av arbetsprov, sedan ett samtal och sist en riktad uppgift.

Begränsningar med screening utan kodtest

• Privat arbete syns inte. En utvecklare som jobbar i slutna repon ser tom ut på GitHub. Det betyder inte att hen är svag.
• Teamkod är svår att tillskriva. Commits visar vem som skrev, inte vem som bestämde designen.
• Publik kod gynnar dem med fritid. Småbarnsföräldrar och personer med krävande jobb har ofta mindre publik kod. Gör inte en publik profil till ett krav.
• Bevis blir gammalt. Kontrollera hur nytt arbetet är.

Så behandlar du kandidaten rättvist

• Berätta att du tittar på publik kod och vad du letar efter.
• Erbjud ett alternativ till personer utan publikt arbete.
• Använd samma process för alla.
• Låt rapporten eller dina anteckningar vara ett underlag till ett mänskligt beslut. Avvisa aldrig någon automatiskt på en poäng.
• Du behandlar personuppgifter, så informera kandidaten enligt GDPR.

Du kan börja gratis: DevEval har en enkel rapport utan betalning, och metodsidan förklarar vad den läser.

Checklista

• Läste 2 eller 3 godkända ändringar, eller en beskrivning av ett tidigare projekt
• Skrev frågor om konkreta ändringar
• Berättade för kandidaten hur du screenar
• Höll ett samtal på 30 minuter om kandidatens eget arbete
• Lät en ingenjör hålla ett tekniskt samtal om riktig kod
• Använde betald uppgift bara för finalister
• Dokumenterade skälen till varje beslut

Vanliga frågor

Är det okej att anställa utan kodtest? Ja. Många företag använder arbetsprov, samtal och betalda provuppgifter. Ett test är ett verktyg, inte ett krav.

Kan inte kandidater låtsas att andras kod är deras? Vissa gör det. Därför är samtalet viktigt: frågor om avvägningar och misstag i kandidatens egna ändringar visar snabbt vem som skrev vad.

Vad gör jag med en tom GitHub-profil? Fråga om privat arbete, erbjud en kort betald uppgift och låt inte den tomma profilen räknas mot kandidaten.