Ditt CV behöver mer än en lista med tekniker
Utvecklare har ofta mycket att säga om systemet och väldigt lite utrymme att säga det på. Det första utkastet blir en kompakt förteckning över språk, ramverk, molntjänster, databaser och varje verktyg du har rört sedan universitetet. Sedan försvinner själva arbetet.
Ett rekryteringsteam behöver en tydligare bild. Vad byggde eller förbättrade du? Hur komplex var miljön? Vilka beslut var dina? Vilka kollegor var beroende av ditt arbete? Vad förändrades efter att du hade levererat?
Dina tekniska kompetenser spelar fortfarande roll. De blir övertygande när erfarenhetsavsnittet visar hur du använder dem med gott omdöme.
Välj roll innan du redigerar
”Utvecklare” täcker väldigt olika jobb. En frontendutvecklare inom produkt, en backendutvecklare inom plattform, en mobilutvecklare, en SRE (site reliability engineer), en utvecklare av inbyggda system och en utvecklingschef behöver var och en sin egen tyngdpunkt.
Läs annonsen noga och ta reda på vad som är kärnan i jobbet. Titta förbi den längsta tekniklistan. En backendroll kan bry sig mest om pålitliga tjänster och datakonsistens. En roll inom produktutveckling kan värdera experiment och nära samarbete med design. En plattformsroll kan fokusera på utvecklarupplevelse, infrastruktur, observerbarhet och driftbörda.
Senioriteten påverkar också vilka belägg som behövs. Ett CV tidigt i karriären kan luta sig mot praktik, studier, bidrag till öppen källkod och väl förklarade egna projekt. Ett seniort CV bör göra omfattning, arkitektoniskt omdöme, ansvar, inflytande och avvägningar synliga.
Ge CV:t en tydlig teknisk struktur
För de flesta utvecklare är en praktisk ordning kontaktuppgifter, en profil om du vill ha en, tekniska kompetenser, arbetslivserfarenhet, utvalda projekt och utbildning. Certifieringar eller publikationer kan förtjäna ett eget avsnitt när de är viktiga för tjänsten.
Lägg GitHub, en portfolio, en personlig webbplats eller en teknisk blogg överst i CV:t bara när länken stärker din kandidatur. Testa varje länk i ett privat webbläsarfönster. En vilande profil full av halvfärdiga övningsprojekt från tutorials tillför kanske inte mycket, medan ett enda väldokumenterat projekt kan ge verkligt djup.
Profilen är valfri. Använd den när den snabbt förklarar din inriktning, din bransch eller din nivå:
Backendutvecklare med sju års erfarenhet av att bygga betal- och faktureringstjänster i Java och Kotlin. Det senaste arbetet har handlat om tjänsternas tillförlitlighet, händelsedriven arkitektur och utvecklarverktyg för team som driver reglerade system.
Allt i den profilen ska ha stöd någon annanstans i CV:t.
Gör ett urval i kompetensavsnittet
Gruppera tekniker efter funktion så att läsaren snabbt kan skumma dem. Kategorierna ska passa ditt arbete. En backendutvecklare kan använda språk, ramverk, data, moln och infrastruktur samt testning. En frontendutvecklare kan börja med språk, UI-ramverk, tillstånd och data, testning, tillgänglighet och byggverktyg.
Ett kortfattat avsnitt kan se ut så här:
Språk: Java, Kotlin, SQL, Python; Data: PostgreSQL, Redis, Kafka; Infrastruktur: AWS, Docker, Kubernetes, Terraform; Testning och observerbarhet: JUnit, Testcontainers, Grafana, OpenTelemetry
Ta med tekniker som du kan prata om med säkerhet. Om du använde ett ramverk i en liten tutorial för flera år sedan hör det förmodligen hemma i dina studieanteckningar och kan lämna huvud-CV:t. Skriv produktnamn med rätt stavning och rätt versaler.
Nivåbeteckningar som ”expert” och ”avancerad” betyder väldigt olika saker för olika personer. Punkter under erfarenhet, projekt, aktuella certifieringar och antal år av färsk användning visar oftast djupet mer exakt.
Skriv erfarenhet som en teknisk intervjuare kan gräva i
Varje stark punkt ger intervjuaren en tråd att dra i. Den kan beskriva en funktion, en tjänst, en migrering, en incident, ett utvecklarverktyg, ett experiment eller ett arkitekturbeslut. Ta med den relevanta tekniken när den hjälper till att förklara metoden. Visa sedan omfattning eller resultat med belägg som du kan försvara.
Någon fast skrivformel behövs inte. En naturlig mening innehåller ofta fyra delar: problemet, ditt bidrag, det tekniska angreppssättet och resultatet. Två eller tre av dem kan räcka när sammanhanget är tydligt.
Här är en hypotetisk omskrivning utifrån tydliga anteckningar.
Underlag: API:et för kassan hade en p95-latens på 1,8 sekunder; profilerade databasanrop; lade till två index och ändrade en fråga; p95 nådde 620 millisekunder i nästa version; kandidaten skrev och driftsatte ändringarna.
Minskade p95-latensen för kassans API från 1,8 sekunder till 620 millisekunder genom att profilera databasanrop, lägga till två index och skriva om en kostsam fråga.
Siffran, metoden och ansvaret kommer alla från anteckningarna. Inga extra påståenden behövs.
Här är ett andra hypotetiskt exempel där värdet ligger i driften.
Underlag: Kandidaten förvaltade ett internt driftsättningsverktyg som användes av 14 utvecklare; lade till validering av saknade miljövariabler; relaterade driftsättningsfel minskade från 11 i maj till 3 i juni.
Lade till validering av miljövariabler i ett internt driftsättningsverktyg som används av 14 utvecklare, vilket minskade relaterade driftsättningsfel från 11 i maj till 3 i juni.
Den exakta jämförelsen mellan två månader hindrar resultatet från att låta större än beläggen.
Använd siffror som du kan förklara
Utvecklares CV:n är fulla av misstänkt perfekta procentsatser. Du kan skriva ett utmärkt CV utan att omvandla varje bidrag till intäkter eller en dramatisk effektivitetsvinst.
Användbara mått är bland annat latens, tillgänglighet, felfrekvens, genomströmning, byggtid, driftsättningsfrekvens, antal incidenter, supportärenden, testtid, molnkostnad, användningsgrad, migreringens omfattning, datavolym, antal användare och hur många team som berörs. Ange mätperioden när den påverkar tolkningen.
När ett exakt resultat aldrig mättes kan du beskriva omfattning och betydelse. Du kan förklara att du migrerade tolv tjänster, ingick i jourschemat för en plattform som kunderna använder, tog bort ett manuellt steg i releaseprocessen eller skrev driftinstruktionen som användes vid överlämningar. Konkret omfattning är värdefulla belägg.
Var rättvis när du fördelar äran. En prestandaförbättring som ett team på sex personer levererade ska låta som ett teambidrag. Verb som ”utvecklade tillsammans med”, ”ledde”, ”ansvarade för”, ”implementerade” och ”bidrog till” signalerar olika nivåer av ansvar. Välj det verb du skulle använda om dina tidigare kollegor satt i rummet.
Ge sammanhang för läsare utanför företaget
Interna projektnamn och egna förkortningar säger lite för en ny läsare. Översätt dem till produkten, systemet, kunden eller driftsammanhanget.
”Arbetade med Project Falcon” lämnar läsaren att gissa. ”Utvecklade flöden för kontoåterställning i företagets B2B-plattform för identitetshantering” ger henne något att utgå från.
Du kan oftast avslöja typ av system, skala, metod och resultat utan att dela konfidentiell arkitektur eller kunddata. Följ anställningsavtal, säkerhetsregler och yrkesmässiga skyldigheter. Avrunda eller generalisera känsliga siffror bara när de fortfarande är sanna, och förklara dem noga på intervjun.
Presentera projekt som utvecklingsarbete
Projekt är särskilt användbara för studenter, den som byter karriär, utvecklare som kommer tillbaka efter ett uppehåll och kandidater som går över till en ny specialitet. Välj några som visar de kompetenser som rollen kräver.
För varje projekt förklarar du vad det gör, ditt bidrag, de viktigaste teknikerna och ett tekniskt beslut som betydde något. Lägg till ett repo eller en live-demo när det är säkert, fungerar och är lätt att förstå.
En projektbeskrivning kan handla om ett beslut kring tillgänglighet, en teststrategi, en driftsättningsprocess, en datamodell, en prestandabegränsning, en säkerhetsåtgärd eller en avvägning du gjorde. De valen säger mer än en lång lista med funktioner.
Arbete från tutorials kan fortfarande visa vad du har lärt dig, men det ska märkas ärligt. Bygg vidare på det, dokumentera vad du ändrade och förklara den del som du förstår tillräckligt väl för att diskutera.
Gör GitHub inbjudande för den som granskar
En rekryterare kanske aldrig öppnar din GitHub-profil. En teknisk intervjuare kan göra det. Forma det första intrycket för den andra läsaren.
Fäst relevanta repon och skriv en README som förklarar syfte, installation, arkitektur, nuvarande begränsningar och viktiga beslut. Ta med tester där det är rimligt. Ta bort exponerade inloggningsuppgifter och gå igenom commit-historiken efter hemligheter innan du delar länken.
Bidragsgrafen är inget att oroa sig mycket över. Kod på jobbet är ofta privat, och en sund karriär som utvecklare lämnar utrymme för ett liv utanför datorn. Kvaliteten och relevansen i det arbete du väljer att visa betyder mycket mer än en obruten vägg av gröna rutor.
Anpassa efter olika utvecklarroller
Ett CV för frontend ska visa det användarnära problemet och inte bara ramverket. Tillgänglighet, prestanda, arbete med designsystem, experiment, webbläsarbeteende och samarbete med design kan alla ge tyngd.
Ett CV för backend kan betona tjänstegränser, datamodeller, tillförlitlighet, säkerhet, prestanda, integrationer och driftansvar. Nämn arkitekturmönster när du verkligen har använt dem och kan förklara avvägningarna.
Roller inom plattform, moln, DevOps och SRE kräver belägg för de system som andra utvecklare förlitade sig på. Visa automatisering, observerbarhet, incidenthantering, kapacitet, styrning av infrastruktur, kostnadsarbete eller utvecklarupplevelse genom konkreta förändringar.
Roller inom data och maskininlärning bör skilja på analys, datateknik, modellutveckling, utvärdering, driftsättning och övervakning. Ange tydligt ditt eget bidrag när forskare, analytiker, plattformsutvecklare och produktteam delade på arbetet.
För tekniska chefsroller kan koden ta mindre plats. Teamets storlek, rekrytering, coachning, leveransprocesser, arkitekturbeslut, arbete med intressenter och resultat för organisationen blir viktigare. Behåll tillräckligt med tekniskt sammanhang för att visa miljön du ledde.
Hjälp rekryteringssystemen att läsa CV:t
Rekryteringssystem (ATS) varierar. Många kan tolka CV:n, lagra uppgifter om kandidater och stödja rekryterares sökningar. Inget av detta skapar en universell poäng som garanterar en intervju.
Använd välkända rubriker som ”Arbetslivserfarenhet”, ”Tekniska kompetenser”, ”Projekt” och ”Utbildning”. Gör datum och arbetsgivarnamn lätta att hitta. Undvik att lägga viktig information enbart i bilder, ikoner eller dekorativa diagram.
Använd termer från annonsen där de korrekt beskriver din bakgrund. Om arbetsgivaren efterfrågar PostgreSQL och din erfarenhet enbart gäller MySQL ska du hålla isär databaserna. Närliggande erfarenhet kan ändå vara relevant, och ärlighet gör intervjun mycket enklare.
Följ det filformat som efterfrågas. En välexporterad PDF bevarar ofta layouten, medan vissa portaler uttryckligen ber om DOCX eller samlar in uppgifter via formulärfält. Öppna den slutliga filen och se till att texten går att markera och att varje sida visas korrekt.
Läs guiden om ATS för en djupare förklaring av hur CV:n tolkas och hur rekryterare söker.
Anpassa utan att skriva om karriären varje gång
Ha ett heltäckande grund-CV eller ett dokument med alla dina prestationer. Välj för varje ansökan de erfarenheter, punkter, projekt och kompetenser som passar rollen bäst. Ändra ordningen där det hjälper och justera profilen om du har en.
Fem genomtänkta ändringar kan ge mer än att skriva om varje rad. Flytta fram den relevanta specialiteten, använd annonsens termer där de stämmer, välj de starkaste beläggen, ta bort äldre verktyg som stjäl uppmärksamhet och kontrollera filen en gång till.
Spara den anpassade versionen tillsammans med annonsen och dina anteckningar. Då har du ett pålitligt underlag inför intervjun, särskilt när flera ansökningar pågår samtidigt.
Använd AI som redaktör, med underlag
AI kan hjälpa till att jämföra en jobbannons med ditt CV och strama upp tekniska texter. Den kan också hitta på arkitektur, skala, siffror, ansvar, verktyg och affärsresultat, och låta helt säker på sin sak.
Ge en avgränsad uppgift:
Jämför den här jobbannonsen för en utvecklartjänst med mitt CV. Peka ut den mest relevanta erfarenheten med exakta citat ur mitt grund-CV. Skriv om upp till fem punkter med bara fakta som har stöd. Bevara tekniker, siffror, datum, teamstorlekar och ansvar exakt. Sätt eventuella saknade detaljer inom hakparentes så att jag kan fylla i dem.
Granska den tekniska innebörden lika noga som grammatiken. ”Förbättrade tillförlitligheten”, ”designade arkitekturen” och ”ledde migreringen” är stora påståenden. Vart och ett behöver belägg.
Med UseResume kan du ladda upp eller skapa ett CV, lägga till en jobbannons, generera en anpassad version, redigera omskrivna punkter, välja en mall och exportera en PDF. Behåll kontrollen över det slutliga tekniska språket och ta bort varje tillägg som saknar stöd.
Den sista genomgången
Fråga dig innan du skickar in om en annan utvecklare skulle förstå systemen du arbetade med och ditt bidrag till dem. Kontrollera att viktiga tekniker förekommer i sitt sammanhang, att siffror har en källa, att teamets prestationer tillskrivs rättvist och att projektlänkarna fungerar.
Läs sedan igenom texten som en vanlig läsare. Ett CV kan vara tekniskt imponerande och ändå kännas utmattande. Korta meningar, utvalda detaljer och lugnt självförtroende tar ditt arbete längre.
Ditt bästa material finns oftast redan i din karriär. Uppgiften är att hitta det, benämna det exakt och ge läsaren en anledning att ställa nästa fråga.
Skapa ditt konto på UseResume och bygg ett fokuserat CV som utvecklare.
Läs vidare i guiderna om tekniska kompetenser i CV:t och hur du lägger till en portfolio.
