Vurdering

Hvordan ved jeg, om en udvikler er god, når jeg ikke er teknisk?

Senest opdateret 10 oktober 2026

Du får tre råd: se på porteføljen, giv en kodeopgave, ring til referencerne. Forskningen bag to af dem blev revideret i 2022, og det tredje er aldrig blevet undersøgt. Her er hvad der faktisk er målt — og hvorfor den bedste metode er den, du ikke selv kan køre.

De tre råd, og hvad der er målt

Rekrutteringsforskningen har i 25 år hvilet på én tabel: Schmidt og Hunters opgørelse fra 1998 over, hvor godt forskellige udvælgelsesmetoder forudsiger jobpræstation. I 2022 blev den regnet om, og de fleste tal faldt.

Grunden er teknisk, men værd at forstå, for den afgør hvor meget man skal stole på tallene. De gamle estimater korrigerede for, at man kun måler på dem, der faktisk blev ansat. Men næsten alle de underliggende studier var samtidige — de målte folk, der allerede var i jobbet — og blev, som forfatterne skriver, “in effect, corrected as if they were predictive studies”. Korrektionen blev altså lagt på data, hvor den ikke hørte hjemme.

For arbejdsprøver var problemet et andet og værre: det gamle tal på .54 stammede fra en narrativ oversigtsartikel fra 1974 — ikke fra en metaanalyse. Den blev erstattet af et nyere studie, hvor 53 af 54 undersøgelser var samtidige.

Tabellen, efter revisionen

De to nederste linjer er vigtigere, end de ser ud. Referencetjek og uddannelseslængde blev ikke revideret ned — de blev taget ud af opgørelsen, fordi det underliggende materiale ikke indeholdt nok information til at regne om. Så det ærlige svar om referencer er ikke “de er dårligere, end vi troede”, men ingen kan for tiden sige det, og det eneste tal i omløb er netop det, der ikke kunne genberegnes.

Og forfatterne advarer selv mod rangliste-læsningen

De skriver, at opgørelsen ikke skal ses som et mandat til at foretrække én metode over en anden, og spredningen er stor: strukturerede interviews ligger på .42 med en standardafvigelse på .19. Forfatterne formulerer det selv som .42 plus/minus .24. Det er ikke et præcisionsinstrument, og enhver side der præsenterer tabellen som en facitliste — inklusive de engelske leverandørsider, der stadig citerer 1998-tallene — overfortolker den.

Tallet, der bør ændre dit første spørgsmål

“Hvor mange år har du arbejdet med React?” er typisk det eneste tekniske spørgsmål, en ikke-teknisk køber føler sig tryg ved at stille. Det er også det spørgsmål med den laveste forudsigelseskraft i hele tabellen — lavere end et ustruktureret interview, som i sig selv ligger på .19.

Det betyder ikke, at erfaring er irrelevant for arbejdet. Det betyder, at antallet af år ikke adskiller den gode fra den dårlige. Og det er antallet af år, der står på CV’et.

Den bedste metode er den, du ikke kan køre

Her bliver det ubehageligt, og jeg vil hellere være ærlig om det end sælge dig noget.

Et struktureret interview er ikke “et interview, hvor man har forberedt sig”. Det er et fast sæt jobrelevante spørgsmål, stillet til alle kandidater i samme rækkefølge, og scoret mod på forhånd definerede kriterier for hvad et godt, et middelmådigt og et dårligt svar er.

Strukturen kan du godt selv lave. Scoringen kan du ikke. For at score et teknisk svar skal du kunne skelne et rigtigt svar fra et velformuleret svar — og det er præcis den evne, der mangler, når man spørger, om udvikleren er god. Det er ikke en karakterbrist; det er definitionen af problemet.

Så valget står reelt mellem tre ting: at bruge metoderne med lav validitet, som du kan køre selv; at ansætte på mavefølelse og håbe på prøvetiden; eller at låne dømmekraften til den ene samtale, hvor den afgør noget. Hvad det koster at tage fejl, har jeg regnet på en anden side.

Whiteboard-studiet, uden overskriften

Du har måske mødt påstanden om, at tekniske interviews måler nervøsitet frem for evner. Der ligger et rigtigt studie bag, og det er værd at kende — både fordi det siger noget, og fordi det siger mindre end overskrifterne.

Forsøget satte deltagere til at løse den samme kodeopgave på 30 minutter, halvdelen ved en whiteboard med en observatør i rummet, halvdelen alene bag en lukket dør.

Forskellen i korrekthed var statistisk signifikant med en effektstørrelse på 0,57, og forfatternes egen formulering er, at præstationen mere end halveres “by simply being watched by an interviewer”.

Og så forbeholdene, som er store nok til at de hører med: 48 deltagere, alle studerende fra ét universitet, én opgave, én session. Forfatterne skriver selv, at deres opsætning formentlig skaber mindre stress end et rigtigt interview med noget på spil, og at de kun har undersøgt effekten på én kodeopgave fra deltagere fra ét universitet.

Hvad studiet viser: at blive set på forringer præstationen ved en whiteboard. Hvad det ikke viser: at tekniske interviews måler nervøsitet i stedet for evner. Den version stammer fra universitetets pressemeddelelse, ikke fra artiklen. Det er værd at vide, hvis nogen bruger studiet til at sælge dig et alternativ.

Og der findes ingen dansk vejledning

Jeg kiggede efter den hos PROSA, IDA, IT-Branchen, Dansk IT og DI. PROSA og IDA skriver til kandidaterne og laver arbejdsmarkedsanalyser; IT-Branchen og DI skriver om mangel på it-folk og om rekruttering i al almindelighed. Ingen dansk brancheorganisation udgiver vejledning til arbejdsgivere om at vurdere en udvikler, og der findes ikke nogen dansk standard for teknisk rekruttering.

Jeg har heller ikke kunnet finde nogen dansk lovregel, myndighedsvejledning eller fagforeningsholdning til, om en take-home-opgave skal betales. Det er en fraværende kilde, ikke et bekræftet fravær af regel — men hvis du leder efter noget at støtte dig til, er der ikke noget.

Den mest substantielle danske artikel om emnet, jeg kunne finde, er fra 2012. Den anbefaler kulturelt match frem for tekniske evner, fem samtaler, en hjemmeopgave der afviser omkring 80 procent — og at den endelige beslutning bør hvile på instinkt.

Hvad jeg så ville gøre

• Hold op med at spørge om antal år. Det tal er .07.
• Skriv spørgesættet ned på forhånd, stil det til alle, og skriv svarene ned. Strukturen alene er den største gratis forbedring, der findes.
• Hvis du giver en opgave: betal for den, hold den kort, og vid at der ikke findes bevis for, at den forudsiger noget.
• Lad udvikleren forklare noget, han har bygget, i stedet for at løse noget nyt foran dig — og få nogen, der kan vurdere svaret, til at lytte med.
• Og vigtigst: gør beslutningen billig at tage fejl i, i stedet for at prøve at gøre den rigtig første gang.

Kilder. Revisionen: Sackett, Zhang, Berry & Lievens, “Revisiting meta-analytic estimates of validity in personnel selection: Addressing systematic overcorrection for restriction of range”, Journal of Applied Psychology 107(11), 2022, s. 2040-2068, doi 10.1037/apl0000994, læst i forfatternes eget accepterede manuskript; tabellen gengivet efter opfølgningen i Industrial and Organizational Psychology 16, 2023, s. 283-300, doi 10.1017/iop.2023.24. Tallene er korrelationer, ikke procenter, og gengives her uden spredningsmål bortset fra de steder, det fremgår. Whiteboard-forsøget: Behroozi, Shirolkar, Barik & Parnin, “Does Stress Impact Technical Interview Performance?”, ESEC/FSE 2020, doi 10.1145/3368089.3409712. Den danske artikel fra 2012: Version2, “Sådan ansætter du den rigtige udvikler”, 5. oktober 2012. Gennemgangen af PROSA, IDA, IT-Branchen, Dansk IT og DI er mit eget opslag, oktober 2026 — et fravær af fundne kilder, ikke et bevis for at intet findes. Alt hentet 9.-10. oktober 2026.