Din take-home case er sikkert for stor, for sløset og for nem at snyde

Fejlen jeg selv blev ved med at gentage

Første gang jeg selv lavede en take-home case til en udviklerrolle, lavede jeg et lille Frankenstein-monster.

Jeg tænkte: “De skal jo have noget at bide i”. Så casen endte som en mini-produktlansering: byg API, lille frontend, auth, tests, deploy og en README der lignede et halvt sprintlog. Estimeret tid: 3-4 timer. Realistisk tid: en halv weekend.

Resultatet var temmelig forudsigeligt:

• Nogle kandidater afleverede noget imponerende, men havde tydeligvis brugt 10+ timer.
• Andre skar alle hjørner og afleverede noget, der næsten ikke virkede.
• Og et par rigtig gode profiler droppede helt ud undervejs, fordi de ikke gad ofre en hel fridag på et job de ikke kendte endnu.

Det var ikke dem, der fejlede. Det var casen.

Herunder får du den tjekliste til take-home cases, jeg ville ønske, jeg havde haft fra start. Den gør din tekniske case mere fair, mere målbar og sværere at game med AI, uden at du skal opfinde raketforskning hver gang.

1. Afgør hvad din take-home case skal måle (og hvad den skal lade være)

En take-home case er god til nogle få ting. Den er dårlig til alt for meget andet.

Det du realistisk kan måle

• Om kandidaten kan læse en kravspec og vælge en simpel løsning.
• Om vedkommende kan strukturere kode nogenlunde fornuftigt.
• Om de kan skrive bare en smule tests, hvis du beder om det.
• Om de kan forklare deres valg og tradeoffs skriftligt.

Det du bør lade være med at presse ind

• Kreativ UI-design-evne (medmindre det er jobbet).
• Hastighed under pres som i et whiteboard-interview.
• Dybe arkitekturvalg til et system, der kun lever i 2 timer.
• Hvor meget fritid en kandidat er villig til at brænde af for dig.

En simpel tommelfingerregel: Hvis du ikke kan forklare præcis, hvordan du vil bedømme noget, så hører det nok ikke hjemme i casen.

2. Scope: sådan tidsbokser du til 2-4 timer uden at dræbe signalet

De fleste skriver “burde tage 2-3 timer” og mener i virkeligheden “det tog mig 2-3 timer første gang, efter jeg kendte facit”.

Jeg er begyndt at bruge den her metode i stedet.

Trin 1: Byg casen selv – ærligt

• Byg casen som om du selv er kandidat.
• Brug de samme rammer: ingen genbrug af gamle komponenter, ingen copy-paste af tidligere projekter.
• Tag tid på, hvor lang tid det faktisk tager fra tom mappe til “jeg kunne sende det her ind”.

Gange det tal med 1,5. Det er din kandidattid.

Trin 2: Skriv tidsrammen eksplicit

I caseteksten skriver du:

Vi forventer, at du bruger ca. 2-3 timer.
Vi ved godt, at man kan bruge længere tid, men det skal du ikke.
Prioritér kravene og skriv i README, hvad du bevidst har valgt fra.

Og så mener du det. Du belønner ikke dem, der har brugt 12 timer, med mindre de også har leveret noget helt exceptionelt og dokumenteret deres valg godt.

Trin 3: Split op i klart scope og bonus

Strukturér casen sådan her:

• Base scope (skal opfyldes) – det der skal kunne køre.
• Nice-to-have – valgfrit, kun hvis tid og energi.

Det gør det lettere at holde både tid og forventninger i ro.

3. Kravspec: sådan skriver du must-have vs nice-to-have skarpt

En god take-home case ligner lidt en lille user story-pakke, ikke en fri fantasiøvelse.

Must-have: de 4-6 ting du rent faktisk bedømmer på

Eksempel for en simpel mini-API + UI-case:

• Bruger skal kunne oprette en “opgave” med titel og status.
• Bruger skal kunne se en liste over opgaver.
• Data skal gemmes, så den overlever en page refresh.
• Projektet skal kunne køres lokalt med én kommando beskrevet i README.

Hvis du vil evaluere tests, så er det også et must-have og skal stå der:

• Der skal være mindst én automatiseret test, der kører med en enkelt kommando.

Nice-to-have: tydeligt markeret som valgfrit

Eksempel:

• Filter opgaver efter status.
• Enkel styling, så det er lidt pænere end plain HTML.
• Ekstra tests (unit eller integration).
• Docker-opsætning eller deploy til en gratis host.

Pointen er, at en kandidat med 2,5 time kan levere alle must-haves og måske én nice-to-have uden at gå i stykker.

Hvis du vil se flere eksempler på at skære scope skarpt, kan du kigge på strukturen i små projekter som i artiklen om at bygge et lille system i stedet for endnu en to-do app.

4. Evalueringsrubric: 5 dimensioner, 0-3 point hver

Her er den rubric, jeg er endt med at bruge igen og igen. Den er simpel nok til at huske, men præcis nok til at to reviewere lander nogenlunde samme sted.

Dimension 1: Funktionalitet (0-3)

• 0: Kan ikke køre, eller hovedflow virker ikke.
• 1: Kører, men centrale fejl og manglende edge cases.
• 2: Alle must-haves virker, mindre skønhedsfejl accepteres.
• 3: Must-haves + mindst én relevant nice-to-have, stabil oplevelse.

Dimension 2: Kodekvalitet og struktur (0-3)

• 0: Ingen struktur, lange filer, copy-paste overalt.
• 1: Nogenlunde ok, men tydeligt rodet og svært at følge.
• 2: Fornuftige funktioner/moduler, læselige navne, ingen åbenlys spaghetti.
• 3: Klar struktur, god opdeling, nem at udvide. Overraskende god for tiden.

Dimension 3: Tests (0-3)

• 0: Ingen tests, selvom casen bad om det.
• 1: En enkelt test smidt ind uden helt at dække noget.
• 2: Få, men meningsfulde tests der dækker centrale dele.
• 3: Gennemført, realistisk test-tilgang, tydelig tanke bag valget af hvad der testes.

Hvis du vil nørde mere i hvad der giver mening at teste, kan du hente inspiration i testpyramide-ideen a la det Martin Fowler beskriver i “Practical Test Pyramid”.

Dimension 4: Developer experience (DX) og README (0-3)

• 0: Ingen README, eller den hjælper ikke.
• 1: Meget kort README, mangler typisk kommandoer eller krav.
• 2: Klar beskrivelse af hvordan man kører projektet og hvad det gør.
• 3: README med korte noter om valg, begrænsninger og known issues.

Dimension 5: Tradeoffs og kommunikation (0-3)

Her kigger du både i README og i en kort opfølgende snak.

• 0: Ingen forklaring af valg, svært at se tanken bag.
• 1: Overfladisk forklaring (“manglede tid”, “valgte bare det”).
• 2: Kan forklare 1-2 tydelige valg og hvad der blev fravalgt.
• 3: Tydelige tradeoffs, kan forklare alternativer og hvorfor denne løsning passer til casens scope.

Summen giver dig 0-15 point. Det er ikke eksakt videnskab, men bedre end mavefornemmelse alene.

5. Anti-gaming: gør casen svær at AI-løse, uden at blive paranoid

Du kan ikke forhindre nogen i at åbne ChatGPT. Du kan til gengæld designe casen, så ren copy-paste bliver afsløret hurtigt.

Tre greb der hjælper

• Case med domain-twist: Brug et lidt mærkeligt domæne eller speciel regel. Noget der ikke findes i 1000 blogindlæg.
• Bed om korte skriftlige refleksioner: “Skriv 5-10 linjer om, hvad du ville ændre hvis du havde 4 timer mere.”
• Lav opfølgende interview-spørgsmål direkte til deres løsning (mere om det senere).

Hvad du ikke skal kræve

Nogle går for langt og kræver fx:

• Skærmoptagelse af hele kodningsprocessen.
• Live coding som eneste bevis på, at det er deres arbejde.
• Kæmpe mængder dokumentation for hvert lille skridt.

Det skræmmer først og fremmest de gode kandidater væk, især dem der har job, børn og et liv ved siden af. Bevar proportionerne.

6. Kandidat-oplevelse: sådan gør du casen fair

En fair case starter faktisk længe før de downloader zip-filen.

Vær tydelig om processen

Fortæl allerede i jobopslaget:

• At der er en take-home case.
• Hvor lang tid du forventer, de bruger.
• At de får feedback, også ved afslag.

Send en kort mail sammen med casen, hvor du gentager de punkter. Det dæmper stressen betydeligt.

Giv reel feedback

Du behøver ikke skrive en roman. Men lidt struktureret feedback ud fra din rubric gør en kæmpe forskel. For eksempel:

Funktionalitet: 2/3 - baseflow fungerer, men bug ved X.
Kodekvalitet: 1/3 - flere ting blandet sammen i samme fil.
Tests: 0/3 - ingen tests trods krav.
DX/README: 2/3 - let at køre lokalt, fin forklaring.
Tradeoffs: 2/3 - gode noter om hvad du prioriterede fra.

To linjer ekstra om hvad de kunne forbedre næste gang, og de fleste vil faktisk takke for afslaget. Næsten.

7. Eksempel-case: mini API + UI med klare acceptance criteria

Her er en case, du kan bruge som skabelon og tilpasse. Den er tænkt til 2-3 timer. Frontend eller full stack, alt efter hvad du leder efter.

Problem: enkel kø-system-tracker

Forestil dig en lille butik der vil holde styr på dagens kunder. De vil bare kunne:

• Tilføje en kunde i køen med navn og tidspunkt.
• Markere en kunde som “betjent”.
• Se en liste over kunder der stadig venter.

Must-have krav

1. Bruger kan tilføje en kunde med navn (tekst) og tidspunkt (automatisk nuværende tidspunkt er fint).
2. Bruger kan se en liste over alle kunder der ikke er betjent endnu.
3. Bruger kan markere en kunde som betjent, hvorefter de ikke længere vises i ventelisten.
4. Data skal gemmes så listen overlever en page refresh (simpel database, fil eller localStorage er ok, afhængig af stack).
5. README-fil der forklarer hvordan man kører projektet, og hvad du har valgt til og fra.

Nice-to-have krav

• Mulighed for at filtrere på ventende vs betjente kunder.
• Enkel visuel markering af hvem der kom først (sortering).
• Én eller flere automatiserede tests der dækker tilføjelse eller markering af kunder.

Tekniske rammer (eksempel)

Sådan kan du formulere stack-krav uden at låse alt:

Du må frit vælge teknologier inden for web-stacken.
Eksempel: React/Vue/Svelte til UI, Node/Express/FastAPI til backend.
Hvis du bygger ren frontend, så brug localStorage som lagring.

Og: skriv direkte at du ikke forventer perfekt UI-design. Det kan du vurdere i en egentlig frontend-case, hvis det er vigtigt. Her handler det om dataflow og struktur.

Hvis du vil have mere inspiration til at formulere en case som en lille historie, kan du snuppe idéer fra artiklen om at gøre en teknisk case til en god historie.

8. Interview-opfølgning: spørgsmål der afslører forståelse, ikke hukommelse

Den stærkeste anti-gaming-mekanisme er faktisk opfølgningen. Ikke fælder, bare nysgerrige spørgsmål ind i deres løsning.

Spørgsmål jeg selv bruger

• “Hvis du skulle starte forfra, hvad ville du gøre anderledes?”
  Afslører refleksion. AI kan ikke efterrationalisere dine faktiske fejl.
• “Hvad var den sværeste del at få til at virke?”
  Hvis de har kodet det selv, kan de beskrive rod og små bump på vejen.
• “Hvis butikken pludselig fik 100x flere kunder, hvad ville du være mest nervøs for i din nuværende løsning?”
  Tester om de kan tænke fremad, uden at du kræver enterprise-arkitektur.
• “Hvorfor valgte du netop [framework/teknologi]?”
  Afslører om det var vane, tilfældighed eller bevidst valg.

Her kigger jeg mindre på det rigtige svar og mere på, om de kan svare roligt og konkret. En god kandidat kan sagtens sige: “jeg valgte X fordi jeg kender det bedst, men til noget større ville jeg nok overveje Y”.

Hvis du vil have flere idéer til gode samtalespørgsmål, er der også gode vinkler i artiklen om at fortælle om et projekt, du er stolt af, hvor fokus er på netop valg og tradeoffs i stedet for superhelte-historier.

Det vigtigste råd

Sæt dig ned, byg din egen take-home case på 2-3 timer, og brug den oplevelse som sandhedskilde for alle krav, tidsangivelser og evalueringer du skriver til kandidaterne.