Så skapar du ett kodningstest

What you'll need

• En SkillCort-arbetsyta (eller en demo)
• Ett verkligt exempel på den kod ditt team skriver — en bugg, en liten funktion, en refaktorering
• En senior utvecklare som definierar uppgiften och bedömningsmatrisen
• Ett beslut om vilka språk du kommer att acceptera

Step 1: Välj en realistisk uppgift framför ett algoritmpussel

Titta på den senaste månadens pull requests och välj en uppgift som liknar de som återkommer: fixa en bugg utifrån ett felaktigt beteende, utöka en liten funktion så att den hanterar ett nytt fall, refaktorera ett rörigt block eller skriv en datatransformation. Sådant förutsäger prestation i vardagen mycket bättre än att invertera ett binärt träd.

Anpassa storleken till 30–45 minuters fokuserat arbete för en kompetent rekrytering. Ett pussel belönar den som har övat på det; en realistisk liten uppgift belönar den som kan läsa befintlig avsikt, göra en sund ändring och hålla koden begriplig — vilket är det du rekryterar för.

Skala bort ramverksspecifik och företagsspecifik kunskap om inte rollen verkligen kräver den, och ge det sammanhang uppgiften behöver inne i briefen själv. En stark utvecklare som aldrig har rört din stack ska ändå kunna visa dig sunt omdöme. Testa färdigheten, inte förtrogenheten med detaljerna i din kodbas.

• Återkommer i din verkliga kodbas, inte i böcker om intervjuförberedelser
• Har mer än en rimlig lösning
• Ryms på 30–45 minuter utan hjältedåd
• Går att läsa för en bedömare på under tio minuter

Step 2: Skapa kodfrågan i frågebanken

Skapa en mapp för rollen — Backend Engineer, till exempel — med taggar för färdighetsområde och svårighetsgrad, och skapa sedan en fråga med frågetypen för kod. Kandidaterna skriver och redigerar kod direkt i svarsytan, och bedömarna granskar den sedan på plats.

Ge frågan startkod i stället för en tom editor. En kort funktion med en beskriven bugg, eller en stubbe med ett tydligt kontrakt, förankrar varje kandidat i samma utgångspunkt och gör deras ändringar direkt jämförbara. Verkligt arbete börjar nästan aldrig från en tom fil, och det ska inte testet heller göra.

Step 3: Skriv briefen bredvid editorn

Använd layouten där stimulus ligger sida vid sida: briefen, kraven och exempel på indata och utdata på ena sidan, kodeditorn bredvid. Kandidaten behöver aldrig scrolla bort från specifikationen för att skriva lösningen — samma form som att arbeta utifrån ett ärende i en IDE.

Skriv briefen som ett bra ärende läses: nuvarande beteende, förväntat beteende, begränsningar och två eller tre konkreta exempel. Säg uttryckligen vad du bryr dig om — ”fungerande kod först; vi läser också för tydlighet” — så att kandidaterna optimerar för det du faktiskt kommer att poängsätta. Otydlighet i briefen blir brus i resultaten.

Step 4: Bygg en bedömningsmatris som poängsätter mer än korrekthet

Korrekt utdata är nödvändigt, inte tillräckligt. Bygg en nivåbaserad bedömningsmatris av matristyp med tre eller fyra kriterier — vanligtvis korrekthet, läsbarhet och angreppssätt, eventuellt hantering av gränsfall — vart och ett med förankrade beskrivningar av hur stark, godtagbar och svag kod ser ut. ”Namnen avslöjar avsikten, ingen död kod” går att poängsätta; ”ren kod” gör det inte.

Vikta korrekthet tyngst, men håll de övriga kriterierna på riktigt: en nätt och jämnt fungerande lösning som ingen kan underhålla är ingen stark signal för en rekrytering. När du kopplar på bedömningsmatrisen fryses den till en ögonblicksbild, så att varje kandidat i körningen granskas mot exakt samma standard även om versionen i banken utvecklas senare.

Step 5: Sätt ihop och tidsätt i buildern

Skapa assessmentet som sektioner, sidor och block och importera kodfrågan via väljaren. Många team lägger till en kort första sektion med snabba omdömesfrågor — läsa en diff, hitta buggen i ett kodavsnitt, snabbinklistrade som flervalsfrågor — och placerar kodningsuppgiften i en egen sektion.

Sätt den totala tidsgränsen med marginal för läsning och eftertanke, och använd en gräns per sida på kodningssidan så att uppgiften inte kan sluka hela försöket. Vikta kodningssektionen tyngst (till exempel ×3) så att rollpassningen på Decision Board speglar arbetet och inte uppvärmningen. Skriv instruktioner som namnger de tillåtna språken och vad som händer om tiden tar slut.

Step 6: Förhandsgranska, beta av checklistan och publicera

Använd Preview as candidate och gör uppgiften själv, eller ännu hellre: låt en utvecklare som inte skrev den göra den utan förkunskap. Blir de klara på tio minuter är den för lätt; kan de inte bli klara inom gränsen får du lätta på omfattningen eller på klockan. Justera briefen överallt där de tvekade.

Uppfyll sedan publiceringschecklistan — den blockerar Publish tills poängsättning, tider och instruktioner är klara. Ett kodningstest med en saknad bedömningsmatris eller en otestad tidsgräns ska aldrig nå en kandidat, och checklistan ser till att det inte kan hända.

Step 7: Sätt integritetskontroller i proportion till vad som står på spel

Skapa genomförandet med namn och tidsfönster och välj sedan säkerhetsinställningarna medvetet. För en vanlig rekryteringsgallring räcker det oftast med blockering av kopiera/klistra in och lockdown i helskärm med en rimlig överträdelsegräns. Webbkamerainspelning, skärminspelning, upptäckt av andra skärm och ID-kontroller finns för körningar där insatserna verkligen är höga — certifiering, slutomgångar — inte som standard.

Allt du aktiverar redovisas vid samtyckes- och preflight-kontrollen innan kandidaten startar. Integritetssignaler är flaggor för en människa att granska i sitt sammanhang, aldrig grund för automatiskt avslag — att lämna helskärm kan vara en avisering, inte fusk. Proportionalitet gör att starka kandidater inte vänder i dörren inför ett övervakningsnät.

Step 8: Granska koden med bedömningsmatrisen, med AI som stöd

Bedömarna granskar varje inlämning mot den gemensamma bedömningsmatrisen och klickar på det nivåkort som stämmer med koden för varje kriterium — korrekthet, läsbarhet, angreppssätt. Att sätta två granskare på gränsfall eller fall med höga insatser håller ribban ärlig, och eftersom alla poängsätter mot samma frysta ögonblicksbild av bedömningsmatrisen visar sig oenigheter som konkreta skillnader på ett kriterium i stället för som vaga magkänsloskillnader.

AI kan skriva ett utkast till sammanfattning av inlämningen och föreslå poäng på kriterienivå — en genuint användbar första genomläsning av kod, med modell och version loggade för protokollet. Men en namngiven utvecklare bekräftar eller ändrar varje poäng. AI är beslutsstöd här, aldrig den som fattar beslutet: den ansvariga bedömningen av en kandidats kod är alltid mänsklig.