Jeg tror, mange gør jobsøgning sværere, end den behøver at være.
Ikke fordi det er nemt. Det er det ikke. Jobsøgning er en mærkelig blanding af research, salg, selvindsigt, timing, tilfældigheder og små formularer, der alle sammen gerne vil have ens CV på en lidt ny måde.
Men fordi man hurtigt kommer til at behandle det som en følelsesbaseret aktivitet:
- Har jeg lyst i dag?
- Føles den her rolle rigtig?
- Er mit CV godt nok?
- Hvorfor har ingen svaret?
- Skal jeg ændre hele min profil klokken 23:41?
Det er forståeligt.
Det er bare ikke en særlig god driftsmodel.
Så jeg begyndte at behandle min jobsøgning mere som et lille delivery-system.
Ikke koldt. Ikke kynisk. Bare mere struktureret.
Første problem: for mange åbne loops
En jobsøgning skaber hurtigt flere åbne loops, end man tror.
Der er roller, der skal vurderes. CV’er, der skal tilpasses. Ansøgninger, der skal sendes. Recruiters, der skal kontaktes. LinkedIn-profiler, der skal opdateres. Samtaler, der skal forberedes. Opfølgninger, der ikke må glemmes. Afslag, der skal håndteres uden at lave personlighedsreform hver gang.
Hvis det hele ligger i hovedet, bliver det hurtigt støj.
Og støj føles som dårlig selvtillid, selv når problemet egentlig er manglende system.
Det kender jeg fra softwarearbejde:
Når ingen ved, hvad der er deployed, hvad der fejler, hvem der ejer hvad, og hvilken ændring der kommer næste gang, føles systemet kaotisk.
Jobsøgning er ikke så anderledes.
Jeg lavede en backlog
Det første nyttige skridt var at gøre rollerne konkrete.
Ikke bare:
Jeg leder efter noget inden for DevOps.
Men:
- Hvilke roller er stærkest?
- Hvilke er platform/DevOps?
- Hvilke er senior backend med platformansvar?
- Hvilke er backup-volume?
- Hvad er status?
- Hvad er næste handling?
- Hvornår skal der følges op?
Det lyder banalt.
Det er også pointen.
En god jobsøgning behøver ikke begynde med personlig branding i højglans. Den kan begynde med en tabel.
Jeg endte med at dele rollerne op i spor:
- platform og DevOps
- senior backend med drift og reliability
- SRE og observability
- AI/platform-adjacent roller
- lavere prioriterede backup-roller
Det gjorde det nemmere at sige nej til roller, der kun var interessante, fordi de eksisterede.
Det gjorde også CV-arbejdet mere ærligt. Jeg skulle ikke opfinde en ny person til hver ansøgning. Jeg skulle bare fremhæve den del af min profil, der faktisk passede.
Positionering er ikke pynt
Jeg har en senior software engineering-baggrund og har senest arbejdet tættere på DevOps, infrastruktur, CI/CD, testmiljøer, monitoring, fejlsøgning og dokumentation.
Den kombination kan forklares på mange måder.
Dårlig version:
Jeg kan lidt af det hele.
Bedre version:
Jeg kan bygge software, men jeg tænker også på deployment, drift, observability, dokumentation og developer experience.
Det er forskellen på en kompetenceliste og en retning.
For mig blev den offentlige version cirka:
Senior software engineer med praktisk DevOps- og platformerfaring, der gerne vil arbejde med systemer, teams faktisk kan drive.
Det er ikke en perfekt slogan-sætning. Gudskelov.
Men den er brugbar, fordi den hjælper med at sortere:
- Roller med platformansvar passer.
- Senior backend-roller med reliability passer.
- Rent frontendprodukt uden drift passer dårligere.
- Ren management uden hands-on teknik passer dårligere.
Positionering er ikke pynt. Det er et filter.
Hver rolle fik en lille playbook
Det næste skridt var at stoppe med at starte forfra hver gang.
For de mest relevante roller lavede jeg en kort note med:
- hvorfor rollen passer
- hvilken del af CV’et der skal fremhæves
- hvilken ansøgningstekst der kan bruges
- hvilke interviewspørgsmål der sandsynligvis kommer
- hvilke spørgsmål jeg selv bør stille
- hvornår der skal følges op
Det er meget tæt på det, jeg ville gøre for et teknisk system:
- Hvad er konteksten?
- Hvad er afhængighederne?
- Hvad er den næste sikre handling?
- Hvad skal vi kunne forklare bagefter?
Det fjerner ikke usikkerheden.
Men det gør usikkerheden mindre tåget.
Interview stories skal være genbrugelige
En af de vigtigste ting var at lave et lille story bank.
Ikke en roman.
Bare korte, brugbare historier:
- en om production troubleshooting og observability
- en om testmiljøer og deployment workflows
- en om senior review og sikkerhedstænkning
- en om AI-assisteret dokumentation og knowledge management
- en om en fejl og hvad jeg lærte af den
Det hjælper, fordi interviews sjældent belønner den person, der har flest erfaringer i hovedet.
De belønner den person, der kan finde den rigtige erfaring hurtigt og forklare den klart.
Det er også en DevOps-ting:
Hvis runbooken først skal skrives under incidenten, er den for sent ude.
Hvis interviewhistorien først skal findes, mens nogen spørger “kan du give et eksempel?”, bliver svaret ofte længere, mere nervøst og mindre præcist.
Follow-up er en del af systemet
Jeg bryder mig ikke særligt meget om opfølgninger.
De kan hurtigt føles som at banke på en dør, hvor man ikke ved, om nogen er hjemme, eller om huset overhovedet findes.
Men uden opfølgning bliver jobsøgning mærkeligt passiv.
Så jeg satte en simpel regel:
Efter cirka fem arbejdsdage uden svar er en kort, høflig opfølgning rimelig, medmindre processen tydeligt siger noget andet.
Ikke en roman.
Ikke:
Jeg skriver for tredje gang for at genbekræfte min dybe passion for jeres transformative rejse.
Bare:
Jeg vil bare følge kort op på min ansøgning. Rollen passer godt med min erfaring inden for senior softwareudvikling, DevOps, CI/CD, observability og platformarbejde. Jeg tager gerne en kort samtale, hvis profilen er relevant.
Det er nok.
AI hjalp, men den måtte ikke overtage
Jeg brugte AI meget i processen.
Ikke til at opfinde mig selv.
Til at strukturere.
AI var god til:
- at sammenligne jobopslag med min profil
- at lave første udkast til CV-varianter
- at gøre ansøgningstekster kortere
- at finde huller i positioneringen
- at bygge interviewspørgsmål
- at omsætte løse noter til STAR-historier
- at holde styr på opfølgninger
Men der er en vigtig grænse.
AI må gerne hjælpe med formen. Den må ikke fjerne ejerskabet.
Hvis jeg ikke kan forsvare en sætning i en samtale, skal den ikke stå i mit CV.
Hvis jeg ikke har lyst til at forklare en teknologi under interview, skal den ikke fremhæves som en kernekompetence.
Hvis AI får teksten til at lyde som en person, der har været “passionate about scalable solutions” siden børnehaven, skal teksten ned på jorden igen.
Det er måske den vigtigste regel:
Brug AI til at blive tydeligere.
Ikke til at blive glattere.
Bloggen blev en del af beviset
Noget af det mest nyttige var at forbinde jobsøgningen med min blog.
Ikke som et stort “personal brand”-projekt.
Mere som praktisk dokumentation:
- Her er hvordan jeg tænker om DevOps.
- Her er hvordan jeg tænker om AI i produktion.
- Her er hvordan jeg tænker om observability, governance og platformarbejde.
- Her er konkrete eksempler på, at jeg kan skrive klart om tekniske systemer.
Det giver en anden type bevis end et CV.
Et CV siger:
Jeg har arbejdet med det her.
En god teknisk blog siger:
Sådan tænker jeg, når jeg arbejder med det her.
Begge dele er nyttige.
Men i seniorroller er den anden ofte lige så vigtig.
Det mest nyttige var ro
Den største effekt af systemet var ikke, at alt blev perfekt.
Det blev det ikke.
Der var stadig ventetid. Stadig usikkerhed. Stadig roller, der passede bedre på papiret end i virkeligheden. Stadig dage, hvor det hele føltes lidt som at sende små flaskeposter ind i et ATS-system med dårlig belysning.
Men systemet gjorde arbejdet roligere.
Når noget gik i stå, kunne jeg spørge:
- Hvad er næste konkrete handling?
- Hvilken rolle er vigtigst lige nu?
- Er det CV, outreach, interview prep eller opfølgning?
- Har jeg en god historie klar?
- Skal jeg justere strategien, eller bare fortsætte?
Det er meget bedre end:
Hvad er der galt med mig?
Nogle gange er svaret ikke dyb eksistentiel analyse.
Nogle gange mangler man bare en tracker.
Min lille tjekliste
Hvis jeg skulle give mit eget jobsøgningssystem videre til en anden udvikler, ville det være det her:
- Lav en prioriteret liste over roller.
- Del dem op i spor, så du ikke ændrer identitet for hver ansøgning.
- Skriv én klar positioneringssætning.
- Lav en lille playbook for hver stærk rolle.
- Gem hver CV-version, du sender.
- Forbered 4-5 korte interview stories.
- Følg op efter nogle arbejdsdage, hvis processen er stille.
- Brug AI til struktur, ikke til pynt.
- Brug portfolio, blog eller projekter som bevis.
- Evaluer ugentligt, ikke efter hvert enkelt afslag.
Jobsøgning bliver aldrig helt rationelt.
Det handler om mennesker, timing, behov, kemi, budgetter og en del ting, man ikke kan se udefra.
Men man kan godt gøre sin egen del mere driftbar.
Og for mig har det været den mest nyttige måde at tænke på:
Jobsøgning er ikke kun en serie ansøgninger.
Det er et lille system.
Og små systemer bliver bedre, når man giver dem struktur, feedback og lidt observability.
Læs også
- DevOps er ikke en pipeline
- AI-agenter skal bruge hukommelse
- Fra prompt til prototype: AI hjalp mig ikke bare med at bygge. Den hjalp mig med at slette.
- Portfolio: DevOps, Platform Engineering og .NET
Note
Dette indlæg bygger på mine egne jobsøgningsnoter, CV-iterationer, interviewforberedelse og workflow-eksperimenter fra 2026. Jeg har udeladt konkrete virksomhedsdetaljer, live processer og private kontaktoplysninger.