CV-en din trenger mer enn en liste med teknologier
Utviklere har ofte mye å si om systemet og svært lite plass å si det på. Det første utkastet blir en tett oversikt over språk, rammeverk, skytjenester, databaser og hvert eneste verktøy de har vært borti siden studietiden. Så forsvinner selve arbeidet.
Et ansettelsesteam trenger et klarere bilde. Hva bygde eller forbedret du? Hvor komplekst var miljøet? Hvilke beslutninger hadde du ansvaret for? Hvilke kolleger var avhengige av arbeidet ditt? Hva endret seg etter at du leverte?
De tekniske ferdighetene dine betyr fortsatt noe. De blir overbevisende når erfaringsseksjonen viser at du bruker dem med god dømmekraft.
Velg rolle før du redigerer
«Utvikler» dekker svært ulike jobber. En frontendutvikler i et produktteam, en backendutvikler i et plattformteam, en mobilutvikler, en SRE-ingeniør, en utvikler av innebygde systemer og en utviklingsleder trenger hver sin vektlegging.
Les annonsen nøye og finn ut hva som er kjernen i jobben. Se forbi den lengste teknologilisten. En backendrolle kan bry seg mest om pålitelige tjenester og datakonsistens. En rolle i produktutvikling kan verdsette eksperimentering og tett samarbeid med design. En plattformrolle kan handle om utvikleropplevelse, infrastruktur, observerbarhet og driftsbelastning.
Erfaringsnivået endrer også hva som må dokumenteres. En CV tidlig i karrieren kan lene seg på praksisplasser, studiearbeid, bidrag til åpen kildekode og godt forklarte egne prosjekter. En CV for en senior bør gjøre omfang, arkitekturvurderinger, eierskap, innflytelse og avveininger synlige.
Gi siden en tydelig teknisk struktur
For de fleste utviklere er en praktisk rekkefølge kontaktinformasjon, et valgfritt sammendrag, tekniske ferdigheter, arbeidserfaring, utvalgte prosjekter og utdanning. Sertifiseringer eller publikasjoner kan fortjene en egen seksjon når de betyr noe for rollen.
Legg GitHub, en portefølje, et personlig nettsted eller en teknisk blogg øverst på CV-en bare når lenken styrker kandidaturet ditt. Test hver lenke i et privat nettleservindu. En inaktiv profil full av uferdige repoer fra tutorials tilfører kanskje lite, mens ett godt dokumentert prosjekt kan gi reell dybde.
Sammendraget er valgfritt. Bruk det når det raskt forklarer retningen, domenet eller nivået ditt:
Backendutvikler med sju års erfaring med å bygge betalings- og faktureringstjenester i Java og Kotlin. Har den siste tiden jobbet med tjenestepålitelighet, hendelsesdrevet arkitektur og utviklerverktøy for team som drifter regulerte systemer.
Alt i det sammendraget bør underbygges andre steder på siden.
Lag en målrettet ferdighetsseksjon
Grupper teknologiene etter funksjon, så leseren kan skumme dem raskt. Kategoriene bør passe arbeidet ditt. En backendutvikler kan bruke språk, rammeverk, data, sky og infrastruktur, og testing. En frontendutvikler kan starte med språk, UI-rammeverk, tilstand og data, testing, universell utforming og byggverktøy.
En kortfattet seksjon kan se slik ut:
Språk: Java, Kotlin, SQL, Python; Data: PostgreSQL, Redis, Kafka; Infrastruktur: AWS, Docker, Kubernetes, Terraform; Testing og observerbarhet: JUnit, Testcontainers, Grafana, OpenTelemetry
Ta med teknologier du kan snakke trygt om. Hvis du brukte et rammeverk i én liten tutorial for flere år siden, hører det sannsynligvis hjemme i læringsnotatene dine og kan tas ut av hoved-CV-en. Skriv produktnavn riktig, også store og små bokstaver.
Nivåbetegnelser som «ekspert» og «avansert» betyr svært forskjellige ting. Kulepunkter fra erfaring, prosjekter, gyldige sertifiseringer og antall år med nylig bruk viser som regel dybde mer presist.
Skriv erfaring som en teknisk intervjuer kan grave i
Hvert sterkt kulepunkt gir intervjueren en nyttig tråd å trekke i. Det kan beskrive en funksjon, en tjeneste, en migrering, en hendelse, et utviklerverktøy, et eksperiment eller en arkitekturbeslutning. Ta med den relevante teknologien når den hjelper til å forklare metoden. Vis deretter omfang eller resultat med bevis du kan forsvare.
Du trenger ingen stiv skriveformel. En naturlig setning inneholder ofte fire elementer: problemet, bidraget ditt, den tekniske framgangsmåten og resultatet. To eller tre av dem kan være nok når konteksten er tydelig.
Her er en hypotetisk omskriving basert på konkrete kildenotater.
Kildenotater: Checkout-API-et hadde en p95-latens på 1,8 sekunder; profilerte databasekall; la til to indekser og endret én spørring; p95 nådde 620 millisekunder i neste versjon; kandidaten skrev og rullet ut endringene.
Reduserte p95-latensen for checkout-API-et fra 1,8 sekunder til 620 millisekunder ved å profilere databasekall, legge til to indekser og skrive om en kostbar spørring.
Tallet, metoden og eierskapet kommer alle fra notatene. Ingen ekstra påstand trengs.
Her er et annet hypotetisk eksempel, der verdien ligger i driften.
Kildenotater: Kandidaten vedlikeholdt et internt verktøy for utrulling som 14 utviklere brukte; la til validering av manglende miljøvariabler; relaterte feil ved utrulling falt fra 11 i mai til 3 i juni.
La til validering av miljøvariabler i et internt utrullingsverktøy som brukes av 14 utviklere, og reduserte relaterte utrullingsfeil fra 11 i mai til 3 i juni.
Den nøyaktige sammenligningen fra måned til måned hindrer at resultatet høres bredere ut enn bevisene tilsier.
Bruk tall du kan forklare
CV-er for utviklere er fulle av mistenkelig perfekte prosenttall. Du kan skrive en utmerket CV uten å gjøre hvert bidrag om til inntekter eller en dramatisk effektiviseringsgevinst.
Nyttige mål er blant annet latens, oppetid, feilrate, gjennomstrømning, byggetid, utrullingsfrekvens, antall hendelser, supporthenvendelser, testtid, skykostnader, bruksgrad, omfang av migreringer, datamengde, antall brukere og hvor mange team arbeidet nådde. Oppgi måleperioden når den påvirker tolkningen.
Når et presist resultat aldri ble målt, beskriv omfanget og betydningen. Du kan forklare at du migrerte tolv tjenester, var med i vaktordningen for en plattform kundene brukte, fjernet et manuelt steg i releaseprosessen eller skrev driftshåndboken som ble brukt ved overleveringer. Konkret omfang er verdifulle bevis.
Hold tilskrivingen rettferdig. En ytelsesforbedring som et team på seks leverte, bør høres ut som et teambidrag. Verb som «utviklet sammen med», «ledet», «hadde ansvaret for», «implementerte» og «bidro til» uttrykker ulike nivåer av ansvar. Velg det du ville brukt hvis tidligere kolleger satt i rommet.
Gi nok kontekst for folk utenfor selskapet
Interne prosjektnavn og egne forkortelser sier lite til en ny leser. Oversett dem til produktet, systemet, kunden eller driftskonteksten.
«Jobbet med Project Falcon» lar leseren gjette. «Utviklet arbeidsflyter for kontogjenoppretting på selskapets B2B-plattform for identitet» gir leseren noe å begynne med.
Du kan som regel vise systemtype, skala, metode og resultat uten å dele fortrolig arkitektur eller kundedata. Følg arbeidsavtaler, sikkerhetsregler og faglige forpliktelser. Rund av eller generaliser sensitive tall bare når det fortsatt er sannferdig, og forklar dem nøye i intervjuer.
Presenter prosjekter som utviklingsarbeid
Prosjekter er særlig nyttige for studenter, folk som bytter karriere, utviklere som vender tilbake etter en pause, og kandidater som går over i en ny spesialisering. Velg noen få som viser ferdighetene rollen du sikter mot, krever.
For hvert prosjekt: forklar hva det gjør, hva du bidro med, de viktigste teknologiene og én viktig teknisk beslutning. Legg til et repo eller en live demo når det er trygt, fungerer og er lett å forstå.
En prosjektbeskrivelse kan ta for seg en beslutning om universell utforming, en teststrategi, en utrullingsprosess, en datamodell, et ytelseskrav, et sikkerhetstiltak eller en avveining du gjorde. Slike valg forteller mer enn en lang liste med funksjoner.
Arbeid fra tutorials kan fortsatt vise læring, men det bør merkes ærlig. Bygg videre på det, dokumenter hva du endret, og forklar den delen du forstår godt nok til å diskutere.
Gjør GitHub innbydende for den som skal se på koden
En rekrutterer åpner kanskje aldri GitHub-profilen din. Det kan en teknisk intervjuer gjøre. Sørg for at førsteinntrykket er godt for den andre leseren.
Fest relevante repoer og skriv en README som forklarer formål, oppsett, arkitektur, nåværende begrensninger og viktige beslutninger. Ta med tester der det gir mening. Fjern eksponerte påloggingsdetaljer og gå gjennom commit-historikken for hemmeligheter før du deler lenken.
Bidragsgrafen er lite å bekymre seg over. Profesjonell kode er ofte privat, og sunne utviklerkarrierer gir rom for et liv borte fra laptopen. Kvaliteten og relevansen på arbeidet du velger å vise, betyr langt mer enn en sammenhengende vegg av grønne ruter.
Tilpass til ulike utviklerretninger
En frontend-CV bør vise det brukerrettede problemet, ikke bare rammeverket. Universell utforming, ytelse, arbeid med designsystemer, eksperimentering, nettleseratferd og samarbeid med design kan alle gi tyngde.
En backend-CV kan legge vekt på tjenestegrenser, datamodeller, pålitelighet, sikkerhet, ytelse, integrasjoner og driftsansvar. Nevn arkitekturmønstre når du faktisk har brukt dem og kan forklare avveiningene.
Roller innen plattform, sky, DevOps og SRE krever bevis på systemer andre utviklere var avhengige av. Vis automatisering, observerbarhet, hendelseshåndtering, kapasitet, styring av infrastruktur, kostnadsarbeid eller utvikleropplevelse gjennom konkrete endringer.
Roller innen data og maskinlæring bør skille mellom analyse, datateknikk, modellutvikling, evaluering, utrulling og overvåking. Få tydelig fram ditt eget bidrag når forskere, analytikere, plattformutviklere og produktteam delte på arbeidet.
For tekniske ledere kan kode ta mindre plass. Teamets omfang, ansettelser, coaching, leveransesystemer, arkitekturbeslutninger, arbeid med interessenter og resultater for organisasjonen blir viktigere. Behold nok teknisk kontekst til å vise miljøet du ledet.
Hjelp rekrutteringssystemene å lese dokumentet
Rekrutteringssystemer (ATS) varierer. Mange kan lese CV-er, lagre kandidatinformasjon og la rekrutterere søke i dataene. Ingenting av dette gir en universell score som garanterer et intervju.
Bruk kjente overskrifter som «Arbeidserfaring», «Tekniske ferdigheter», «Prosjekter» og «Utdanning». Gjør datoer og arbeidsgivernavn lette å finne. Unngå å legge viktig informasjon bare i bilder, ikoner eller dekorative diagrammer.
Bruk begreper fra annonsen der de beskriver bakgrunnen din korrekt. Hvis arbeidsgiveren ber om PostgreSQL og erfaringen din bare er med MySQL, hold de to databasene atskilt. Tilgrensende erfaring kan fortsatt være relevant, og ærlighet gjør intervjuet langt enklere.
Følg filformatet det bes om. En godt eksportert PDF bevarer ofte oppsettet, mens noen portaler ber spesifikt om DOCX eller samler inn opplysningene i skjemafelt. Åpne den ferdige filen og sjekk at teksten kan merkes, og at hver side vises riktig.
Les ATS-veiledningen for en grundigere forklaring av hvordan systemene leser CV-er, og hvordan rekrutterere søker i dem.
Tilpass uten å skrive om hele karrieren hver gang
Ha en fullstendig kilde-CV eller et dokument med alle prestasjonene dine. Velg for hver søknad ut erfaringene, kulepunktene, prosjektene og ferdighetene som passer best til rollen. Endre rekkefølgen der det er nyttig, og juster sammendraget hvis du bruker et.
Fem gjennomtenkte endringer kan virke bedre enn å skrive om hver linje. Løft fram den relevante spesialiseringen, speil korrekte begreper, velg de sterkeste bevisene, fjern eldre verktøy som tar oppmerksomheten, og sjekk filen én gang til.
Lagre den tilpassede versjonen sammen med annonsen og notatene dine. Da har du en pålitelig oversikt før intervjuet, særlig når flere søknader er i gang samtidig.
Bruk KI som redaktør, med kildemateriale
KI kan hjelpe deg med å sammenligne en stillingsannonse med CV-en din og stramme inn teknisk tekst. Den kan også finne på arkitektur, skala, tall, eierskap, verktøy og forretningsresultater med full selvsikkerhet.
Gi den en snever oppgave:
Sammenlign denne stillingsannonsen for utvikler med CV-en min. Finn den mest relevante erfaringen ved hjelp av ordrette sitater fra kilde-CV-en min. Skriv om opptil fem kulepunkter med bare fakta som er underbygd. Behold teknologier, tall, datoer, teamstørrelser og eierskap nøyaktig som de er. Sett eventuelle manglende detaljer i hakeparentes, så jeg kan fylle dem inn.
Gå gjennom den tekniske betydningen like nøye som grammatikken. «Forbedret påliteligheten», «designet arkitekturen» og «ledet migreringen» er store påstander. Hver av dem trenger belegg.
Med UseResume kan du laste opp eller lage en CV, legge til en stillingsannonse, lage en tilpasset versjon, redigere omskrevne kulepunkter, velge en mal og eksportere en PDF. Behold kontrollen over det endelige tekniske språket, og fjern alle tillegg som ikke er underbygd.
Den siste gjennomgangen
Før du sender, spør deg selv om en annen utvikler ville forstått systemene du har jobbet med, og hva du bidro med. Sjekk at viktige teknologier står i kontekst, at tallene har en kilde, at teamets prestasjoner er rettferdig tilskrevet, og at prosjektlenkene fungerer.
Les deretter for vanlig, menneskelig klarhet. En CV kan være teknisk imponerende og likevel slitsom å lese. Korte setninger, utvalgte detaljer og rolig selvtillit tar arbeidet ditt lenger.
Det beste materialet ditt finnes som regel allerede i karrieren din. Jobben er å grave det fram, sette presise ord på det og gi leseren en grunn til å stille neste spørsmål.
Opprett en UseResume-konto og lag en målrettet CV som utvikler.
Les videre i veiledningene om tekniske ferdigheter i CV-en og hvordan du legger til en portefølje.
