Sådan opretter du en kodetest

What you'll need

• Et SkillCort-workspace (eller en demo)
• Et virkeligt eksempel på den kode, jeres team skriver — en fejl, en lille funktion, en oprydning
• En erfaren udvikler, der kan definere opgaven og bedømmelsesmatricen
• En beslutning om, hvilke sprog I accepterer

Step 1: Vælg en realistisk opgave frem for en algoritmenød

Se på den seneste måneds pull requests, og vælg en opgave, der har samme form som dem, der går igen: ret en fejl ud fra en beskrevet forkert adfærd, udvid en lille funktion til at klare et nyt tilfælde, ryd op i en rodet blok, eller skriv en datatransformation. Den slags tillader slutninger om den daglige præstation langt bedre end at vende et binært træ på hovedet.

Dimensionér den til 30–45 minutters fokuseret arbejde for en kompetent ansat. En nød belønner den, der har øvet sig på den; en realistisk lille opgave belønner den, der kan læse en eksisterende hensigt, lave en fornuftig ændring og holde koden forståelig — og det er det, I ansætter efter.

Skær viden om bestemte frameworks og om jeres egen virksomhed væk, medmindre rollen reelt kræver den, og læg den kontekst, opgaven har brug for, ind i selve briefen. En stærk udvikler, der aldrig har rørt jeres stack, skal stadig kunne vise jer sund dømmekraft. Test kompetencen, ikke kendskabet til petitesser i jeres kodebase.

• Går igen i jeres virkelige kodebase, ikke i bøger om interviewforberedelse
• Har mere end én rimelig løsning
• Kan være der på 30–45 minutter uden heltemod
• Kan læses af en bedømmer på under ti minutter

Step 2: Opret kodeopgaven i opgavebanken

Lav en mappe til rollen — for eksempel Backend Engineer — med tags for kompetenceområde og sværhedsgrad, og opret så en opgave af kodeopgavetypen. Kandidaterne skriver og redigerer kode direkte i svarfeltet, og bedømmerne gennemgår den bagefter samme sted.

Læg startkode i opgaven i stedet for en tom editor. En kort funktion med en beskrevet fejl, eller en stub med en tydelig kontrakt, forankrer hver kandidat i det samme udgangspunkt og gør deres ændringer direkte sammenlignelige. Virkeligt arbejde begynder næsten aldrig fra en tom fil, og det bør testen heller ikke.

Step 3: Skriv briefen ved siden af editoren

Brug side-om-side-layoutet: briefen, kravene og eksempler på input og output i den ene side, kodeeditoren ved siden af. Kandidaten scroller aldrig væk fra specifikationen for at skrive løsningen — den samme form som at arbejde ud fra en ticket i en IDE.

Skriv briefen, som en god ticket læses: nuværende adfærd, forventet adfærd, begrænsninger og to-tre konkrete eksempler. Sig udtrykkeligt, hvad I går op i — «kode, der virker, først; vi læser også efter klarhed» — så kandidaterne optimerer efter det, I faktisk scorer. Flertydighed i briefen bliver til støj i resultaterne.

Step 4: Byg en bedømmelsesmatrix, der scorer mere end korrekthed

Korrekt output er nødvendigt, ikke tilstrækkeligt. Byg en niveaubaseret bedømmelsesmatrix med tre-fire kriterier — typisk korrekthed, læsbarhed og fremgangsmåde, eventuelt håndtering af grænsetilfælde — hver med forankrede beskrivelser af, hvordan stærk, acceptabel og svag kode ser ud. «Navnene viser hensigten, ingen død kode» kan scores; «ren kode» kan ikke.

Vægt korrekthed tungest, men lad de andre kriterier være virkelige: en løsning, der lige akkurat virker, og som ingen kan vedligeholde, er ikke et stærkt ansættelsessignal. Når du sætter bedømmelsesmatricen på, fryses den til et snapshot, så hver eneste kandidat i kørslen gennemgås efter den samme målestok, også selv om versionen i banken udvikler sig senere.

Step 5: Sæt sammen, og sæt tidsrammen i builderen

Opret assessmentet som sektioner, sider og blokke, og importér kodeopgaven gennem vælgeren. Mange teams lægger en kort første sektion med hurtige dømmekraftsspørgsmål ind — læs en diff, find fejlen i et kodestykke, hurtigt indsat som multiple choice — og lader kodeopgaven få sin egen sektion.

Sæt den samlede tidsgrænse med luft til at læse og tænke, og brug en grænse pr. side på kodesiden, så opgaven ikke kan sluge hele forsøget. Vægt kodesektionen tungest (for eksempel ×3), så rollematch på Decision Board afspejler arbejdet og ikke opvarmningen. Skriv instruktioner, der nævner de tilladte sprog, og hvad der sker, hvis tiden løber ud.

Step 6: Forhåndsvis, ryd tjeklisten, og publicér

Brug Preview as candidate, og forsøg selv opgaven — eller endnu bedre: lad en udvikler, der ikke har skrevet den, forsøge den koldt. Bliver vedkommende færdig på ti minutter, er den for let; kan vedkommende ikke nå det inden for grænsen, så løsn omfanget eller uret. Ret briefen alle de steder, hvor de tøvede.

Opfyld derefter publiceringstjeklisten — den spærrer for Publish, indtil scoring, tider og instruktioner er på plads. En kodetest med en manglende bedømmelsesmatrix eller en utestet tidsgrænse bør aldrig nå frem til en kandidat, og tjeklisten sørger for, at den ikke kan.

Step 7: Sæt integritetskontroller i forhold til indsatsen

Opret leveringen med navn og tidsvindue, og vælg så sikkerhedsindstillingerne bevidst. Til en almindelig screening i en ansættelse er blokering af kopiér/indsæt og Lockdown i fuld skærm med en fornuftig grænse for overtrædelser som regel nok. Webcamoptagelse, skærmoptagelse, registrering af ekstra skærm og ID-kontrol findes til kørsler med reelt høje indsatser — certificering, sidste runder — ikke som standardindstillinger.

Alt, hvad I slår til, oplyses ved samtykke- og preflight-porten, før kandidaten går i gang. Integritetssignaler er markeringer, som et menneske skal gennemgå i sammenhæng, aldrig grundlag for et automatisk afslag — at nogen forlader fuld skærm kan være en notifikation og ikke snyd. Rimeligt omfang holder stærke kandidater fra at gå deres vej fra et overvågningsnet.

Step 8: Gennemgå kode med bedømmelsesmatricen, med AI som støtte

Bedømmerne gennemgår hver aflevering op imod den fælles bedømmelsesmatrix og klikker på det niveaukort, der passer til koden på hvert kriterium — korrekthed, læsbarhed, fremgangsmåde. At sætte to bedømmere på grænsetilfælde eller sager med høje indsatser holder målestokken ærlig, og fordi alle scorer efter det samme frosne snapshot af matricen, viser uenigheder sig som konkrete huller på et kriterium frem for som vage forskelle i mavefornemmelse.

AI kan lave et udkast til et resumé af afleveringen og foreslå scorer på kriterieniveau — en reelt nyttig første gennemgang af kode, med model og version logget til optegnelsen. Men en navngiven udvikler bekræfter eller tilsidesætter hver eneste score. AI er beslutningsstøtte her, aldrig den, der træffer beslutningen: den ansvarlige vurdering af en kandidats kode er altid menneskelig.