Gør din tekniske case til en god historie, ikke en kode-dump

“Kan du fortælle om et projekt du er stolt af?”

Skærmen fryser, hænderne bliver lidt for varme, og du hører dig selv sige: “Øhm, jeg lavede sådan en todo-app i React…”.

Jeg har selv siddet der. Masser af kode i GitHub, men nul plan for, hvordan jeg forklarer, hvad jeg faktisk har tænkt. Og det er lige præcis det, der skiller “jeg kan kode lidt” fra “jeg tænker som udvikler” til en teknisk case jobsamtale som udvikler.

Det gode er: du kan øve det. Ret systematisk endda.

Forstå hvad interviewere leder efter

De fleste interviewere ved godt, at du ikke er senior-arkitekt. De leder sjældent efter den perfekte løsning. De leder efter din måde at tænke på.

Typisk scanner de efter tre ting:

• Kan du forklare problemet med dine egne ord?
• Kan du begrunde tekniske valg og tradeoffs, ikke bare nævne frameworks?
• Ser du selv forbedringer og “det ville jeg gøre anderledes næste gang”?

Hvis du kan ramme de tre, virker du markant mere erfaren, selv med få års eller ingen professionel erfaring.

Brug STAR som skelet til din case

STAR er en job-interview-klassiker: Situation, Task, Action, Result. Den lyder lidt HR-agtig, men den fungerer overraskende godt til tekniske cases.

Tricket er at oversætte den til udvikler-sprog i stedet for floskler.

Situation: konteksten, ikke hele din livshistorie

Her forklarer du kort, hvad projektet er, og hvorfor det overhovedet findes.

“Jeg byggede en lille bookingside til min venindes yogahold, 
fordi hun var træt af at holde styr på tilmeldinger i Messenger.”

Keep it tight. 1-2 sætninger. Ingen lange arkitektur-diagrammer endnu.

Task: hvad var dit konkrete ansvar?

Selv hvis det er et solo-projekt, så afgræns din opgave.

“Mit mål var at lave en simpel webapp, 
hvor deltagere kunne booke en plads, og hun kunne se dagens hold.”

Hvis du har været i et team: nævn hvad du specifikt tog ansvar for. Det viser, at du forstår roller.

Action: nu må du endelig snakke teknik

Det her er stedet hvor du forklarer, hvad du faktisk byggede. Men pas på ikke at lave en “jeg nævner bare alt tech-stack jeg kan komme i tanke om”.

Fokuser på 2-3 hovedbeslutninger:

• Valg af stack (fx React vs vanilla JS, Django vs Node)
• Hvordan du strukturerede data (fx simpel JSON-fil, lille database)
• Et konkret problem du løste (fx login, formularvalidering, API-kald)

“Jeg valgte React med Vite, fordi jeg kendte det fra tidligere projekter, 
og en lille Supabase-database til at gemme bookinger. 
Jeg byggede en enkel admin-side, hvor hun kunne se tilmeldinger per dag.”

Result: hvad blev bedre for nogen i virkeligheden?

Her taber mange juniorer tråden. Resultat er ikke “koden virkede”.

Resultat handler om impact. Små metrics er også fine:

• Sparede tid: “Hun brugte før 20 minutter per hold, nu bruger hun 5.”
• Færre fejl: “Deltagere glemmer sjældnere tilmelding.”
• Brug: “10 faste brugere om ugen, deployet og brugt i 3 måneder.”

Og ja, du må gerne sige “mit bedste bud er” hvis du ikke har perfekte tal. Det er bedre end ingenting.

Tilføj tradeoffs: 5 spørgsmål du skal kunne svare på

STAR giver struktur, men det er tradeoffs, der får dig til at lyde som en udvikler, ikke bare en tutorial-følger.

Jeg bruger en lille fast liste, når jeg forbereder mig:

1. Hvad kunne du have valgt i stedet?

Nævn 1-2 realistiske alternativer og hvorfor du ikke valgte dem.

“Jeg kunne have brugt Next.js for server-side rendering, 
men jeg vurderede at det var overkill til en lille, simpel app 
med få sider.”

2. Hvad var din største begrænsning?

Tid, viden, hosting, data, performance. Vælg noget konkret.

“Jeg var ny til databaser, så jeg valgte Supabase, 
fordi det gav mig auth og database uden for meget opsætning. 
Til gengæld er jeg låst lidt til deres måde at gøre ting på.”

3. Hvad ville du gøre anderledes i version 2?

Det her spørgsmål er guld. Det viser, at du kan se dine egne kompromisser.

“Hvis jeg skulle bygge det igen, ville jeg lægge mere energi 
i tests og lave en bedre struktur for komponenter. 
Lige nu er nogle af dem blevet for store.”

4. Hvad var din største tekniske fejltagelse?

En ærlig fejl med læring er stærkere end en perfekt historie. Vælg noget teknisk, ikke “jeg var for doven”.

“Jeg startede med at gemme bookinger i localStorage, 
hvilket hurtigt blev en begrænsning da hun skulle bruge data 
fra flere devices. Det tvang mig til at lære en rigtig database.”

5. Hvordan ville du teste eller måle løsningen bedre?

Selv en basal tanke om tests eller metrics viser modenhed.

“Jeg har manuelt testet de vigtigste flows, 
men hvis jeg havde mere tid, ville jeg skrive et par 
end-to-end tests for booking-flowet.”

Brug en 1-side skabelon til din tekniske case

Jeg er stor fan af at have alt på én side, når jeg skal til samtale. Så her er en lille skabelon, du kan kopiere til din næste case.

1-side case skabelon

Forestiller du dig et simpelt dokument, fx i Notion eller Google Docs:

• Projekt-navn: Yogabooking til små hold
• Stack: React (Vite), Supabase, Tailwind, Vercel
• Situation: Kort kontekst, 1-2 sætninger
• Task: Dit ansvar og mål
• Action: 3 punktopstillinger med vigtige beslutninger
• Result: 2-3 punktopstillinger med impact
• Tradeoffs & læring: 3-5 korte bullets
• Link: Live-demo + GitHub-repo

Eksempel på “Tradeoffs & læring” sektion:

- Valgte Supabase for hurtig start, men det låser mig til deres platform
- Ingen automatiske tests endnu, manuelt testet de vigtigste flows
- UI er simpelt, men kunne bruge bedre mobil-optimering
- Ville vælge en mere modulær komponentstruktur næste gang

Den her side er din memory cheat. Du skal ikke læse op, men den hjælper dig med at huske pointerne.

Gør din GitHub og README til støtteværktøjer

En stærk teknisk case hænger tit sammen med et pænt repo. Ikke perfekt, bare pænt nok til at en anden udvikler ikke får stress.

Skriv en README, der hjælper samtalen

Tænk din README som en mini-version af din case:

• Kort beskrivelse af projektet og formålet
• Tech stack
• Hvordan man kører projektet lokalt
• Eventuelle kendte begrænsninger

Det ligner meget strukturen i en god projektbeskrivelse, som vi også bruger i andre artikler på Coding Class.

Brug issues og commits som bonus-point

Hvis du vil gå et skridt videre:

• Lav et par GitHub issues, der viser bugs eller forbedringer du har tænkt over
• Skriv meningsfulde commit-beskeder i stedet for “fix” og “update”

I en samtale kan du så sige: “Jeg har dokumenteret et par ting i issues, fx performance på X, som jeg ville kigge på i næste iteration.” Det får dig til at ligne en, der arbejder som et team, selv når du er alene.

Undgå den klassiske fælde: for meget implementation

Hvis du kan høre dig selv sige “så lavede jeg en komponent… og så en ny komponent… og så endnu en…”, så er du faldet i implementation-fælden.

Intervieweren kan sjældent bruge en detaljeret gennemgang af hver fil. De vil høre dine beslutninger og mønstre.

Skift fra “hvad jeg skrev” til “hvad jeg besluttede”

Prøv at omskrive dine sætninger.

• Ikke: “Så lavede jeg en useEffect til at hente data.”
• Hellere: “Jeg valgte at hente data client-side, fordi…”

Det første handler om kode-linjer. Det andet handler om arkitektur og tradeoffs.

Hvis du har lyst til at træne den her måde at tænke på, er der en del gode systemdesign-ressourcer (fx roadmap.sh), selvom du er junior.

Træn derhjemme: 3 små prompts

Det føles super akavet første gang man sidder og “fortæller om et projekt” højt til sig selv. Men det virker. Her er tre øvelser, jeg selv har brugt.

Øvelse 1: 2 minutters STAR på et simpelt projekt

Vælg et lille projekt, fx en portfolio-side eller en todo-app.

• Sæt en timer på 2 minutter
• Forklar projektet højt efter STAR
• Optag dig selv på lyd, og lyt efter: roder du rundt i implementation?

Gentag, indtil du kan sige det nogenlunde flydende uden at nævne hver eneste komponent.

Øvelse 2: Svar på de 5 tradeoff-spørgsmål skriftligt

Tag samme projekt og skriv korte svar til de 5 spørgsmål om tradeoffs. Maks 2-3 linjer per spørgsmål.

Det her er guld til din 1-side case og din README. Og det hjælper dig med at opdage, hvor du ikke helt forstår dine egne valg endnu.

Øvelse 3: Forklar projektet til en ikke-udvikler

Find en ven, kæreste, forælder. Forklar:

• Hvad problemet var
• Hvad du byggede
• Hvordan det gjorde noget lettere for en rigtig person

Hvis de kan gentage “nå, så det er sådan en ting, der hjælper X med Y”, er du på rette spor. Hvis de ser helt tomme ud i blikket, er du for dybt nede i teknikken.

Rund af som en udvikler, ikke som en superhelt

En af de bedste slutninger på en teknisk case er ikke “og så var alt perfekt”, men noget i stil med:

“Projektet løser det vigtigste for nu, 
men hvis jeg havde en uge mere, ville jeg forbedre A og B. 
Det her har især lært mig C.”

Det lyder måske småt, men det viser, at du forstår, at software altid er i version 0.x. Det matcher ret godt den måde mange teams faktisk arbejder på, især hvis de bruger retro- og post-mortem formater som dem du kan se hos fx Atlassian.

Og bare for at lukke cirklen: Jeg troede engang jeg havde ødelagt en hel side lige før en demo, fordi alt pludselig var blankt. Det viste sig at være en lille, dum env-variabel. Den case lød meget bedre, da jeg turde fortælle om fejlen, valget der førte til den, og hvad jeg ændrede bagefter, end nogen perfekt “alt virkede første gang” historie nogensinde ville have gjort.