Jobsamtale
Hvad skal jeg spørge om til en teknisk jobsamtale?
Du kan ikke bedømme et svar om arkitektur, hvis du ikke kan faget. Men du kan bygge rammen — og det er rammen, der gør arbejdet. Her er de syv spørgsmål jeg ville stille, hvad jeg ville lytte efter, og de tre jeg ville holde op med at stille.
Strukturen er den gratis halvdel
I den reviderede opgørelse over, hvor godt udvælgelsesmetoder forudsiger jobpræstation, er forskellen mellem de to interviewformer den største i hele tabellen:
| Metode | Validitet |
|---|---|
| Strukturerede interviews | .42 — højest i opgørelsen |
| Ustrukturerede interviews | .19 |
Det er den samme samtale, med den samme person, i det samme lokale. Forskellen er udelukkende, om du har skrevet spørgsmålene og kriterierne ned på forhånd.
Og et struktureret interview er ikke “et interview, hvor man har forberedt sig”. Det er tre ting: samme spørgsmål, samme rækkefølge, og kriterier du har formuleret før du mødte nogen. Ændrer du kriterierne undervejs, fordi du kom til at synes godt om nummer to, er du tilbage på .19.
Forfatterne bag tallene advarer selv mod at læse opgørelsen som en facitliste — spredningen er stor, og de formulerer det som .42 plus/minus .24. Men rangordenen mellem struktureret og ustruktureret er ikke til diskussion, og den koster ingenting at udnytte.
De tre spørgsmål, du skal holde op med at stille
| Spørgsmål | Hvorfor ikke |
|---|---|
| “Hvor mange år har du arbejdet med X?” | År med erfaring har en revideret validitet på .07, med en nedre troværdighedsværdi på minus .07. Det laveste tal i opgørelsen |
| “Kan du sende nogle referencer?” | Referencetjek blev udeladt af re-analysen i 2022, fordi datagrundlaget var for tyndt til at regne om. Det eneste tal i omløb er fra 1998 — og det er netop det, der ikke kunne genberegnes |
| “Må jeg se din portefølje?” | Portefølje er slet ikke en undersøgt udvælgelsesmetode. Du kan ikke se, hvad personen selv lavede, hvor lang tid det tog, eller hvem der rettede det |
Det betyder ikke, at du ikke må kigge på en portefølje. Det betyder, at den ikke må bære beslutningen, og at du ikke skal tro, du har målt noget.
De syv spørgsmål
Spørgsmålene her er mine egne, ikke forskning. De er valgt efter ét kriterium: at en ikke-teknisk køber kan score svaret, fordi de handler om proces, dømmekraft og selvindsigt frem for om syntaks.
| Spørgsmål | Stærkt svar | Svagt svar |
|---|---|---|
| 1. Fortæl om noget du har bygget, som du i dag ville have bygget anderledes | Konkret, nævner en følge det fik, og hvad han lærte | “Det hele kørte fint”, eller skylden ligger hos andre |
| 2. Hvad gjorde du sidste gang du var i tvivl om, hvad kunden egentlig ville have? | Spurgte, skrev det ned, fik det bekræftet | Gættede og byggede videre |
| 3. Hvordan opdagede du den sidste fejl, der nåede ud til brugerne? | Overvågning, en alarm, en test der fangede det | En bruger ringede. Eller: det er aldrig sket |
| 4. Hvad ville du gøre i din første uge hos os? | Læse, spørge, få noget lille i produktion | Skrive det hele om. Vælge ny teknologi |
| 5. Hvad er du ikke god til? | Konkret og afgrænset, med hvad han gør ved det | “Jeg er lidt for perfektionistisk” |
| 6. Hvis vi kun havde halvdelen af tiden, hvad ville du så skære væk? | Skærer i omfang og kan begrunde hvorfor det stadig virker | Skærer i test. Eller: det kan man ikke |
| 7. Hvem overtager, hvis du er syg i to uger? | Har skrevet ned hvordan man udruller, og hvor adgangene er | Har ikke tænkt over det |
Spørgsmål 6 er det, jeg selv ville vægte højest, og det er ikke tilfældigt. I det bedste danske datasæt over it-projekter kom medianprojektet hjem en smule under budget og næsten 15 procent for sent — og forklaringen er, at omfanget giver sig, når tiden ikke gør. En udvikler, der ikke kan svare på, hvad der skæres væk, kommer til at skære i det forkerte.
Sådan scorer du det
- Skriv de syv spørgsmål ned, og skriv for hvert af dem hvad et stærkt, et middel og et svagt svar er. Før den første samtale.
- Giv 0, 1 eller 2 point per spørgsmål, mens du sidder der. Ikke bagefter.
- Stil dem i samme rækkefølge til alle. Rækkefølgen flytter svarene.
- Skriv svaret ned, ikke din vurdering. Vurderingen kan du lave bagefter; svaret kan du ikke huske.
- Og lav ikke kriterierne om undervejs. Det er hele forskellen mellem .42 og .19.
Den del, du ikke kan tage selv
De syv spørgsmål dækker proces og dømmekraft. De dækker ikke, om personen faktisk kan skrive ordentlig kode, om arkitekturvalget holder, eller om svaret om databasen var rigtigt eller bare velformuleret.
Det er ikke en mangel ved spørgsmålene. Det er definitionen af problemet: hvis du kunne score de tekniske svar, ville du ikke have brug for at spørge, om udvikleren er god. Så enten får du nogen med, der kan faget, eller du accepterer, at du har målt halvdelen og gør beslutningen billig at lave om. Hvad den anden mulighed koster, har jeg regnet på en anden side.
Hvis du insisterer på en kodeopgave
Så vid, hvad du køber. Der findes ingen offentliggjort undersøgelse, der viser, at en take-home-kodeopgave forudsiger, hvordan en udvikler klarer sig på jobbet. Det nærmeste er arbejdsprøver som metodekategori, og det tal blev revideret ned fra .54 til .33 — målt næsten udelukkende på folk, der allerede var ansat.
Og live-varianten har sit eget problem. I et kontrolleret forsøg løste 61,5 procent ikke opgaven, når der sad en observatør i rummet, mod 36,3 procent når de sad alene. Forbeholdene er store — 48 studerende, én opgave — men retningen er klar nok: du måler delvis, hvordan folk har det med at blive set på.
Så hvis du giver en opgave: gør den kort, betal for den, og brug den som noget at tale om frem for som en prøve. Og bed hellere udvikleren forklare noget, han selv har bygget, end at løse noget nyt foran dig. Det er den samtale, en teknisk person kan score for dig på tyve minutter.
Kilder. Validitetstallene: Sackett, Zhang, Berry & Lievens, “Revisiting meta-analytic estimates of validity in personnel selection”, Journal of Applied Psychology 107(11), 2022, doi 10.1037/apl0000994, læst i forfatternes eget accepterede manuskript; tabellen gengivet efter opfølgningen i Industrial and Organizational Psychology 16, 2023, doi 10.1017/iop.2023.24. Tallene er korrelationer, ikke procenter. Observatøreffekten: Behroozi, Shirolkar, Barik & Parnin, “Does Stress Impact Technical Interview Performance?”, ESEC/FSE 2020, doi 10.1145/3368089.3409712 — 48 analyserede deltagere, alle studerende fra ét universitet, én opgave. At omfanget giver sig: Alami, Madsen & Krancher, 54 afsluttede danske statslige it-projekter 2011-2020, ISD2021. De syv spørgsmål og scoringsanvisningerne er mine egne og er ikke forskningsbaserede — kun kravet om struktur, rækkefølge og forudskrevne kriterier er det. Alt hentet 9.-10. oktober 2026.
Skal jeg tage den tekniske halvdel?
Du kører rammen, jeg scorer de svar du ikke kan bedømme. En time på en samtale er billigere end tre måneder med den forkerte.
Skriv til mig →