Slik lager du en kodetest

What you'll need

• Et SkillCort-arbeidsområde (eller en demo)
• Et ekte eksempel på koden teamet ditt skriver — en feil, en liten funksjon, en opprydding
• En erfaren utvikler som kan definere oppgaven og vurderingsmatrisen
• En avgjørelse om hvilke språk dere godtar

Step 1: Velg en realistisk oppgave framfor en algoritmenøtt

Se på den siste måneden med pull requests og plukk en oppgave formet som dem som går igjen: rett en feil ut fra en beskrevet oppførsel, utvid en liten funksjon til å håndtere et nytt tilfelle, rydd opp i en rotete blokk, eller skriv en datatransformasjon. Slikt forutsier daglig prestasjon langt bedre enn å invertere et binærtre.

Dimensjonér den til 30–45 minutters fokusert arbeid for en kompetent ansatt. En nøtt belønner den som har øvd på den; en realistisk liten oppgave belønner den som kan lese eksisterende intensjon, gjøre en fornuftig endring og holde koden forståelig — som er det du ansetter for.

Fjern rammeverkspesifikk og selskapsspesifikk kunnskap med mindre rollen genuint krever det, og gi all konteksten oppgaven trenger, inne i selve oppgaveteksten. En dyktig utvikler som aldri har rørt teknologistabelen deres, bør likevel kunne vise deg god dømmekraft. Test ferdigheten, ikke kjennskapen til trivialiteter i kodebasen deres.

• Går igjen i den ekte kodebasen deres, ikke i intervjuforberedelsesbøker
• Har mer enn én rimelig løsning
• Får plass på 30–45 minutter uten heltedåder
• Kan leses av en bedømmer på under ti minutter

Step 2: Opprett kodeoppgaven i oppgavebiblioteket

Lag en mappe for rollen — Backend Engineer, for eksempel — med tagger for ferdighetsområde og vanskelighetsgrad, og lag så en oppgave med kodeoppgavetypen. Kandidatene skriver og redigerer kode direkte i svarfeltet, og bedømmerne går senere gjennom den der den står.

Så oppgaven med startkode framfor en blank editor. En kort funksjon med en beskrevet feil, eller en stubbe med en tydelig kontrakt, forankrer hver kandidat i samme utgangspunkt og gjør endringene deres direkte sammenlignbare. Ekte arbeid starter nesten aldri fra en tom fil, og det bør ikke testen heller.

Step 3: Skriv oppgaveteksten ved siden av editoren

Bruk stimulusoppsettet side om side: oppgavetekst, krav og eksempler på inn- og utdata på den ene siden, kodeeditoren ved siden av. Kandidaten blar aldri vekk fra spesifikasjonen for å skrive løsningen — samme form som å jobbe ut fra en sak i en IDE.

Skriv oppgaveteksten slik en god sak leses: dagens oppførsel, forventet oppførsel, begrensninger, og to eller tre konkrete eksempler. Si uttrykkelig hva du bryr deg om — «kode som virker først; vi leser også for tydelighet» — slik at kandidatene optimaliserer for det du faktisk poengsetter. Tvetydighet i oppgaveteksten blir til støy i resultatene.

Step 4: Bygg en vurderingsmatrise som måler mer enn riktig svar

Riktig utdata er nødvendig, ikke tilstrekkelig. Bygg en nivåbasert vurderingsmatrise med tre eller fire kriterier — vanligvis riktighet, lesbarhet og framgangsmåte, eventuelt håndtering av grensetilfeller — hvert med forankrede beskrivelser av hvordan sterk, akseptabel og svak kode ser ut. «Navn røper intensjon, ingen død kode» kan poengsettes; «ren kode» kan det ikke.

Vekt riktighet tyngst, men hold de andre kriteriene ekte: en løsning som så vidt virker og ingen kan vedlikeholde, er ikke et sterkt ansettelsessignal. Når du kobler på vurderingsmatrisen, fryses den til et øyeblikksbilde, slik at hver kandidat i runden gjennomgås mot den identiske standarden selv om bankversjonen utvikler seg senere.

Step 5: Sett sammen og tidsavgrens i byggeren

Opprett vurderingen som deler, sider og blokker, og importer kodeoppgaven gjennom velgeren. Mange team legger på en kort første del med raske dømmekraftspørsmål — lese en diff, finne feilen i et utdrag, raskt limt inn som flervalg — og legger kodeoppgaven i sin egen del.

Sett den samlede tidsgrensen med slingringsmonn for lesing og tenking, og bruk en grense per side på kodesiden, slik at oppgaven ikke kan sluke hele forsøket. Vekt kodedelen tyngst (for eksempel ×3), slik at rollematch på Decision Board gjenspeiler arbeidet, ikke oppvarmingen. Skriv instruksjoner som navngir de tillatte språkene og hva som skjer når tiden går ut.

Step 6: Forhåndsvis, gå gjennom sjekklisten og publiser

Bruk «Preview as candidate» og gjennomfør oppgaven selv, eller enda bedre: la en utvikler som ikke skrev den, forsøke den kaldt. Blir de ferdige på ti minutter, er den for lett; klarer de den ikke innenfor grensen, løsner du på omfanget eller klokken. Rett oppgaveteksten overalt der de nølte.

Oppfyll deretter publiseringssjekklisten — den sperrer «Publish» til poengsetting, tidsstyring og instruksjoner er komplette. En kodetest med manglende vurderingsmatrise eller en utestet tidsgrense bør aldri nå en kandidat, og sjekklisten sørger for at den ikke kan.

Step 7: Sett integritetstiltak som står i forhold til innsatsen

Opprett leveringen med navn og tidsvindu, og velg deretter sikkerhetsbryterne bevisst. For en vanlig rekrutteringssiling holder som regel blokkering av kopiering og liming pluss fullskjerms Lockdown med en fornuftig bruddgrense. Webkameraopptak, skjermopptak, deteksjon av ekstra skjerm og ID-kontroll finnes for kjøringer med genuint høy innsats — sertifisering, siste runder — ikke som standardvalg.

Alt du slår på, opplyses ved samtykke- og forhåndssjekkporten før kandidaten starter. Integritetssignaler er flagg som et menneske skal vurdere i kontekst, aldri grunnlag for automatisk avvisning — et utsteg fra fullskjerm kan være et varsel, ikke juks. Proporsjonalitet hindrer at sterke kandidater går sin vei fra et overvåkingsnett.

Step 8: Gå gjennom koden med vurderingsmatrisen, med AI som støtte

Bedømmerne går gjennom hver besvarelse mot den felles vurderingsmatrisen og klikker nivåkortet som passer koden på hvert kriterium — riktighet, lesbarhet, framgangsmåte. Å sette to bedømmere på grensetilfeller eller saker med høy innsats holder standarden ærlig, og fordi alle poengsetter mot det samme frosne øyeblikksbildet av matrisen, dukker uenighet opp som konkrete kriteriegap framfor vage magefølelsesforskjeller.

AI kan skrive et utkast til sammendrag av besvarelsen og foreslå poeng på kriterienivå — en genuint nyttig første gjennomgang av kode, med modell og versjon logget for ettertiden. Men en navngitt utvikler bekrefter eller overstyrer hvert eneste poeng. AI er beslutningsstøtte her, aldri den som avgjør: den ansvarlige vurderingen av en kandidats kode gjøres alltid av et menneske.