Hvordan du bygger en udvikler-portfolio der kan bestå en 60 sekunders test

Det føles lidt som at købe brugt Game Boy på DBA: du har tre billeder, en vag beskrivelse og skal på 30 sekunder gætte, om den faktisk virker. Sådan har mange hiring managers det, når de åbner en udvikler-portfolio.

Jeg har efterhånden kigget på en del junior-portfolios for venner, studerende og kollegaer. Mønsteret går igen: spændende idéer, flotte screenshots, men svært at se, om personen også kan bygge noget, der holder til hverdag.

I den her tekst bygger vi en anden type udvikler portfolio: få, små projekter, men med klare beviser. Ikke kæmpe “SaaS”-drømme, men tre stykker software, der viser, at du kan tænke som en udvikler, ikke bare som en tutorial-bruger.

Hvad en hiring manager faktisk prøver at finde ud af på 60 sekunder

Forestil dig, at nogen åbner din ansøgning på en skærm, mens deres kat går hen over tastaturet (det sker mere, end man tror). De har måske 60 sekunder, før næste møde.

De kigger typisk efter nogle meget konkrete ting:

• Kan du få ting deployet et sted, hvor andre kan prøve dem?
• Har du styr på grundlæggende webudvikling: formularer, data, fejl, tilstand?
• Har du nogen som helst vaner omkring kvalitet: tests, logging, struktur?
• Forstår du, hvad du selv har bygget, eller har du bare fulgt en video?

De spørgsmål stiller de ikke højt. De klikker bare rundt og mærker efter. Din opgave er at gøre det nemt for dem at svare “ja” til de rigtige ting uden at skulle gætte.

Det gør du ved at bygge få, fokuserede projekter og beskrive dem på samme måde hver gang.

Projekt 1: frontend-app der tager formularer og fejl alvorligt

Det første projekt er ren frontend. Ingen backend, ingen database, ingen auth. Bare browseren og din evne til at håndtere brugerinput pænt.

Tænk noget i stil med:

• Registrering til et lille event
• Bookingskema til klatretider
• En “lav din egen kaffeprofil” formular

Pointen er ikke idéen, men at det er formular-tungt. Mange felter, forskellige typer input, validering og tydelige fejl.

Krav til dit frontend-projekt

Hvis jeg skulle sætte en lille tjekliste på det her projekt, ville det være:

• Mindst 5-8 felter, inkl. tekst, e-mail, tal, dropdown og checkbox
• Validering både mens man skriver og når man indsender
• Fejlbeskeder, der forklarer hvad der er galt (ikke bare rød kant)
• Korrekt brug af HTML-formularfelter og labels
• Focus-states og keyboard-navigation, der faktisk virker
• Et simpelt “pseudo-backend”-lag, fx localStorage eller en mock-funktion

Eksempel på simpelt valideringsmønster i JavaScript:

const form = document.querySelector("form");
const emailInput = document.querySelector("#email");
const emailError = document.querySelector("#email-error");

form.addEventListener("submit", (event) => {
  event.preventDefault();

  const email = emailInput.value.trim();
  let hasError = false;

  if (!email) {
    emailError.textContent = "Email er påkrævet";
    hasError = true;
  } else if (!email.includes("@")) {
    emailError.textContent = "Email ser ikke gyldig ud";
    hasError = true;
  } else {
    emailError.textContent = "";
  }

  if (!hasError) {
    // gem i localStorage eller vis en "tak"-besked
  }
});

Det behøver ikke være fancy. Men det skal være tydeligt, at du har tænkt på, hvad der sker, når ting går galt.

Tilgængelighed og fejltilstande

Hvis du vil hæve niveauet en tand (anbefalet), så:

• Brug <label for="..."> på alle felter
• Marker fejl med både farve og tekst
• Brug aria-live eller lignende til fejlområder, så skærmlæsere får besked

Du behøver ikke være ekspert i a11y. Men lige så snart du viser, at du har tænkt på det, skiller du dig ud fra 80 % af de andre portfolios.

Projekt 2: lille backend-API med rigtig database

Det andet projekt flytter fokus fra knapper og farver til data, struktur og kvalitet. Her vil du gerne vise, at du kan bygge og passe på et lille API.

Eksempelidéer:

• API til en bogsamling eller spilbibliotek
• API til simple to-dos med kategorier
• API til at logge dine klatretræninger

Vælg noget med 2-3 tabeller, relationer og nogle få endpoints. Brug en rigtig database som Postgres. Det gør dig også klar til emner under data og databaser senere.

Krav til backend-projektet

Jeg ville personligt sigte efter:

• Mindst 3 endpoints, fx GET /items, POST /items, DELETE /items/:id
• Postgres database med migrations, ikke manuel klik-opsætning
• En simpel test-suite, selv hvis det bare er 3-5 tests
• En CI-workflowfil, der kører tests ved hver push
• Rate limiting “light” eller anden beskyttelse mod misbrug

Eksempel på migrations-tankegang (pseudo-SQL):

-- 001_create_tables.sql
CREATE TABLE users (
  id serial PRIMARY KEY,
  email text UNIQUE NOT NULL
);

CREATE TABLE workouts (
  id serial PRIMARY KEY,
  user_id integer REFERENCES users(id),
  date date NOT NULL,
  difficulty integer NOT NULL
);

Og så et simpelt script til at køre migrations, fx i Node:

"scripts": {
  "migrate": "node scripts/migrate.js",
  "test": "NODE_ENV=test npm run migrate && vitest"
}

CI og en lille test som bevis

Hvis jeg kun måtte se én ting i din GitHub for at vurdere et backend-projekt, ville det være:

• En testfil, der rammer API’et
• En grøn checkmark fra CI

Eksempel på en minimalt brugbar test (supertest eller lignende):

import request from "supertest";
import { app } from "../src/app";

test("POST /workouts opretter en træning", async () => {
  const response = await request(app)
    .post("/workouts")
    .send({ date: "2024-01-01", difficulty: 3 });

  expect(response.status).toBe(201);
  expect(response.body.id).toBeDefined();
});

Du behøver ikke 100 % coverage. Bare vis, at du ved, hvad tests er, og at de kører automatisk. Så er du allerede ovre i feltet test og kvalitet, ikke bare “jeg kan lave en route”.

Rate limiting light

Du skal ikke implementere Cloudflare. Men en lille “beskyt mod spam”-mekanisme er fin signalværdi.

Eksempel: blokér mere end X requests per minut per IP i memory. Ja, det er ikke perfekt i produktion, men til et portfolio-API viser det, at du har tænkt over trafik.

Projekt 3: lille full stack system med auth og drift-vaner

Det tredje projekt binder det sammen. Ikke et kæmpe system, bare noget der har:

• Login eller anden form for auth
• Frontend og backend, der taler sammen
• Logging, simple metrics eller monitoring
• En idé om backup/restore af data

Tænk fx en mini-app, hvor brugere kan logge ind og gemme en lille liste over noget personligt. Ikke en social platform, mere et privat værktøj.

Auth uden at opfinde sikkerhed på ny

Du behøver ikke implementere alt omkring tokens selv. Brug gerne et framework eller bibliotek, men forstå, hvad der sker.

Et typisk niveau kunne være:

• Registrer og log ind med e-mail + password
• Passwords hashes med et bibliotek (ikke plain text)
• Session i cookie eller JWT som bearer token

Hvis du er gået ned i JWT og sessions i forvejen, så brug det her. Men dokumentér det tydeligt i write-up’en.

Logging og simple metrics

Vis at du tænker: “Hvordan finder jeg ud af, hvad der sker, når noget går galt?”

• Log fejl til konsollen på backend med timestamp og endpoint
• Lav evt. en simpel route, der viser antal oprettede brugere, seneste login osv.
• Tag et screenshot af et lille dashboard eller log-udskrift og smid det i README

Det tager dig måske en aften at sætte op, men det positionerer dig som én, der har forstået, hvorfor deployment og drift også er en del af jobbet.

Backup/restore-plan på minimumsniveau

Ingen forventer, at du har hot standbys og snapshots i tre regioner. Men de fleste virksomheder vil elske at se:

• En kort beskrivelse i README: “Sådan tager jeg backup af databasen”
• En kommando til backup og en til restore

Eksempel, igen i pseudo:

"scripts": {
  "db:backup": "pg_dump $DATABASE_URL > backup.sql",
  "db:restore": "psql $DATABASE_URL < backup.sql"
}

Det er mere signal end løsning. Signalet er: “Jeg ved, at data kan forsvinde, og jeg har tænkt over det.”

Write-up skabelon til hver case: samme format, hver gang

Nu mangler du én vigtig ting: gøre projekterne læsbare. Ikke som roman, men som teknisk mini-historie.

Jeg bruger selv ofte en fast skabelon, både i arbejde og sideprojekter. Du kan genbruge den til alle dine portfolio cases.

Strukturen: Problem → løsning → tradeoffs → læring → næste skridt

For hver case, fx i README eller på din portfolio-side, skriv:

1. Problem – 2-4 linjer
   • Hvad skulle det her projekt løse?
   • For hvem, og hvorfor var det interessant?
2. Løsning – 5-8 linjer
   • Hvilken tech stack valgte du, og hvorfor?
   • Hvad kan systemet konkret?
3. Tradeoffs – 3-5 linjer
   • Hvilke valg tog du bevidst, som ikke er “perfekte”?
   • Hvad droppede du for at blive færdig?
4. Læring – 3-5 linjer
   • Hvad var det vigtigste, du lærte af netop det her projekt?
5. Næste skridt – 2-4 linjer
   • Hvis du fik en uge mere, hvad ville du bygge på?

Eksempelbid (kortet ned) til et backend-API:

Problem
Jeg ville have et lille API til at gemme og hente mine klatre-workouts,
med fokus på at lære Postgres og migrations.

Løsning
Node + Express backend med Postgres. Tre endpoints: GET/POST/DELETE /workouts.
Migrations køres via npm script, tests via Vitest og Supertest i CI.

Hvis du vil nørde mere i den retning, så er artiklen skriv en README der faktisk bliver læst rigtig god træning.

“Beviser” der løfter projekterne en klasse op

Nu kommer den del, mange glemmer. Ikke flere features, men mere synlighed omkring det, du allerede har bygget.

Jeg ville målrette hvert projekt mod at have følgende på plads:

1. Demo-link der virker på 30 sekunder

• Et klart link i toppen af README: “Live demo: https://…”
• Helst uden loginskærm til at starte med (eller demo-login øverst)
• Ingen “npm install” for at se noget, bare klik og oplev

Hvis du har auth, så tilføj fx:

Demo-bruger
email: demo@example.com
password: demo1234

2. Seed-data og “first run” kommando

Hvis nogen vil køre projektet lokalt, skal de kunne gøre det uden at gætte.

Eksempel i README:

npm install
npm run migrate
npm run seed
npm run dev

Og en kort note om, hvad seed-dataen gør: “Opretter 3 demo-brugere og 10 workouts”.

3. Test-kommando og output

Vis præcist, hvad man skal køre for at teste:

npm test

# eller

pytest

Og gerne et screenshot af grønne tests eller klip ind i README:

$ npm test

PASS  tests/workouts.test.js
  POST /workouts
    ✓ opretter en træning (45 ms)

4. CI og evt. monitoring-screenshot

Hvis du har sat GitHub Actions eller lignende op:

• Vis den lille “build status”-badge øverst i README
• Nævn kort, hvad workflowet gør: install, test, lint osv.

Har du nået at lege med logs eller metrics, så smid et lille screenshot ind. Ikke som pynt, men som: “Sådan holder jeg øje med, om min app lever”.

Typiske portfolio-fejl (og hvad du kan rette på en aften)

Her er nogle ting, jeg ser igen og igen, og forslag til hurtige fixes.

Fejl 1: Ingen kontekst

Problem: Repo hedder “awesome-app”, README siger “A cool app built with React”. Ingen ved, hvorfor den findes eller hvad der er interessant ved den.

Fix i aften:

• Tilføj sektionen “Problem” og “Løsning” øverst i README
• 3-5 linjer er nok til at ændre hele indtrykket

Fejl 2: Kun screenshots, ingen demo

Problem: Der er flotte billeder, men ingen måde at prøve tingene på.

Fix i aften:

• Deploy frontend-projekter gratis på fx Netlify eller Vercel
• Smid demo-linket tidligt i README og på din portfolio-side

Fejl 3: README, der ikke fortæller, hvordan man kører projektet

Problem: “To run: clone repo.” Og så stopper det.

Fix i aften:

• Tilføj sektionen “Sådan kører du projektet lokalt”
• Angiv konkrete commands i rækkefølge: install, env, migrate, start

Fejl 4: Ingen omtale af fejl, tests eller begrænsninger

Problem: Det ser ud som et “perfekt” projekt. Ingen ved, om det er realistisk.

Fix i aften:

• Tilføj “Tradeoffs” og “Kendte begrænsninger” til hver case
• Skriv 2-3 ting, du bevidst har valgt eller ikke nåede

Det virker måske sårbart, men som hiring manager er det guld at se, at du kan være ærlig om dine valg.

Sådan får du portfolioen til at arbejde for dig i CV og ansøgning

Det sidste skridt er at koble alt det her til dine papirer. Ikke bare én lang liste over GitHub-links.

På CV’et: 2-3 stærke projekter, ikke 10 svage

Lav en sektion der hedder fx “Udvalgte projekter”. For hvert projekt:

• Navn + type: “Workout API – backend-projekt med Postgres”
• 1 linje problem: “Løser X for Y”
• 1 linje tech: “Node, Express, Postgres, Vitest, GitHub Actions”
• 1 linje fokus: “Fokus på migrations, tests og simpelt rate limiting”
• Link: GitHub + demo

Det gør det lynhurtigt at matche projektet til den rolle, du søger.

I ansøgningen: brug projektet som eksempel på dine vaner

I stedet for at skrive “Jeg går op i kvalitet”, så bind det til et konkret projekt. For eksempel:

• “I mit mini full stack-projekt har jeg bygget simpel logging og backup-flow ind fra starten, fordi jeg gerne vil tænke drift med, selv i små apps.”
• “I mit formular-tunge frontend-projekt har jeg fokuseret på fejltilstande og tilgængelighed, så brugere får ordentlige beskeder frem for bare en rød kant.”
• “Mit API-projekt bruger migrations, tests og CI, så jeg kan ændre schema og kode, uden at være i tvivl om, om noget er gået i stykker.”

Når du skriver sådan, får arbejdsgiveren øje på dine vaner, ikke bare dine værktøjer. Det er noget af det samme, jeg prøver at trække frem i artiklerne om portfolio og ansøgning generelt.

Hvis din nuværende udvikler portfolio føles kaotisk

Hvis du læser det her og tænker “min GitHub er bare 40 halvfærdige ting”, så er du i godt selskab. Det er næsten standardtilstanden.

Mit forslag som “oprydning i porteføljen”-plan:

1. Vælg tre projekter, der matcher de tre typer her (eller næsten)
2. Arkivér eller skjul resten for nu, hvis de forvirrer billedet
3. Giv de tre valgte projekter en ordentlig README og case-write-up
4. Få mindst én ven/mentor til at teste demo-links og følge README

Hvis du har energi bagefter, så kan du altid bygge videre. Måske med nye projekter, måske ved at refaktorere de gamle. Men få de tre første til at ligne noget, du faktisk ville sende til nogen uden at undskylde.

Og hvis du en dag fanger dig selv i at finpudse farver i 3 timer uden tests, så kan du altid sige, at du øver dig på at være frontend-perfektionist. Jeg siger det i hvert fald til mig selv, når jeg for tredje gang justerer padding på en knap i stedet for at skrive en ekstra test.