CV-guide för developer advocates: Att bevisa att du kan koda och kommunicera

Developer advocacy är en av de mest intressanta rollerna inom tech — och en av de svåraste att skriva CV för. Utmaningen är strukturell. Du är en teknisk yrkesverksam vars jobb involverar offentlig kommunikation, community-byggande och skapande av innehåll, och du ansöker till roller där rekryteringskommittén kan inkludera en ingenjörschef, en marknadschef och en community-ledare, var och en av vilka läser ditt CV genom en helt annorlunda lins.

Ingenjörschefen letar efter bevis på att du kan koda. Marknadschefen letar efter innehållsräckvidd och publikpåverkan. Community-ledaren letar efter bevis på att du förstår utvecklare som en gemenskap. Ditt CV måste tillfredsställa alla tre läsarna utan att framstå som inkohärent eller urvattnat.

Den här guiden ger dig de specifika ramverken för att göra det.

Vad developer advocacy faktiskt innefattar

Innan du strukturerar ditt CV är det värt att vara precis om vad DevRel-roller faktiskt innebär, för omfånget varierar avsevärt beroende på företag och kan avgöra vilka aspekter av din bakgrund du ska lyfta fram.

På ett litet startup eller API-företag är developer advocacy ofta mycket teknisk: du skriver produktionskvalitativa exempelkoder, bygger integrationer, underhåller SDK:er och ger detaljerad teknisk feedback till produktteamet baserat på utvecklarsamtal. Community- och innehållsarbetet är verkligt, men den tekniska trovärdigheten är grundläggande.

På ett större plattformsföretag kan rollen vara mer stratifierad. Du kanske specialiserar dig på innehåll (tekniska blogginlägg, konferensföredrag, YouTube-handledningar) eller community (Discord, forum, utvecklarevenemang), med lägre förväntning att du skriver produktionskod dagligen. Ingenjörsgolvet är lägre, men kommunikations- och räckviddförväntningarna är högre.

På ett enterprise SaaS-företag fungerar developer advocacy ofta närmre en teknisk säljingenjörs- eller lösningsarkitektroll, med community och innehåll som sekundära kanaler. Betoningen ligger på att göra det möjligt för enterprise-utvecklare att lyckas med produkten.

Att veta vilken typ av roll du ansöker till formar allt om hur du skriver ditt CV.

Strukturen som fungerar

Developer advocacy-CV:n fungerar bäst med en struktur som lyfter fram båda dimensionerna explicit snarare än att försöka blanda ihop dem. Här är layouten som konsekvent presterar:

Professionell sammanfattning — 3-4 meningar. Etablera tydligt att du är en teknisk yrkesverksam som specialiserar sig på utvecklarutbildning och community. Något som: "Developer advocate med bakgrund inom full-stack-ingenjörskap och fyra år av erfarenhet av att bygga utvecklargemenskaper, skapa tekniskt innehåll och möjliggöra för utvecklare via SDK-bidrag och exempelapplikationer." Notera ordningen: teknisk trovärdighet först, kommunikationsfärdigheter andra. Det här är inte oavsiktligt — i de flesta DevRel-rekryteringsbeslut är den tekniska ribban den svårare att klara.

Tekniska färdigheter — lista språk, ramverk, plattformar och verktyg. Var ärlig om djupet. "Kunnig i Python och JavaScript" betyder något annorlunda än "casual kännedom om flera språk." Rekryteringschefer inom DevRel är utvecklare själva och kommer att sondera under den tekniska skärmen.

Innehålls- och community-räckvidd — det här är ett avsnitt som många kandidater utelämnar, och det utelämnandet är ett misstag. Developer advocacy är delvis ett distributionsjobb. Om du har en utvecklarblogg med meningsfull trafik, en YouTube-kanal, konferensföredragsupptagningar, öppen källkod-bidrag med stjärnor eller forks, eller en gemenskap du har hjälpt att växa — lista det. Kvantifiera det.

Arbetslivserfarenhet — detaljeras nedan.

Föredrag och publikationer — ett separat avsnitt för signifikanta föredrag, artiklar, handledningar, podcastuppträdanden eller workshops. Det behöver inte vara uttömmande; tre till fem signal-starka objekt slår en lång lista med mindre omnämnanden.

Att skriva arbetslivserfarenhet för DevRel-roller

Arbetslivserfarenhetsavsnittet i ett developer advocacy-CV kräver en annan rytm än ett rent ingenjörs-CV. Du skriver inte en lista med tekniska prestationer. Du skriver en historia om teknisk trovärdighet plus utvecklarpåverkan. Varje roll bör ha punkter över båda dimensionerna.

Några exempel på hur det ser ut i praktiken:

Svagt: "Skapade tekniskt blogginnehåll för utvecklarpublik"

Starkare: "Wrote 24 technical articles in 12 months on [Platform] best practices, averaging 8,000 views per post and cited in the documentation of three third-party integrations"

Svagt: "Bidrog till SDK och exempelkod"

Starkare: "Ägde Python SDK — triagerade problem, mergade 60+ community-PR:er och minskade genomsnittlig problemlösningstid från 11 dagar till 3 — vilket resulterade i 40 % ökning av SDK:ns GitHub-stjärnor under sex månader"

Svagt: "Talade på utvecklarevenemang"

Starkare: "Höll 12 föredrag vid evenemang inklusive DevRelCon, PyCon och interna utvecklartoppmöten; genomsnittlig workshop-registreringsfrekvens efter föredrag på 34 %"

Svagt: "Stödde utvecklarcommunity på Discord"

Starkare: "Ökade Discord-community från 800 till 4 200 aktiva medlemmar under 18 månader; implementerade onboarding-flöde och community-hälsomätvärden som minskade 90-dagars churn med 28 %"

Mönstret är konsekvent: påstående plus mekanism plus mätbart utfall. Inom DevRel specifikt involverar mekanismen ofta både ett tekniskt element (du byggde något, förbättrade något, skrev något med kod) och ett community- eller distributionselement (folk hittade det, använde det, delade det, återvände till det).

Att demonstrera teknisk trovärdighet: Det icke-förhandlingsbara

För en developer advocacy-roll på ett företag med en meningsfull utvecklarprodukt — ett API, en plattform, ett infrastrukturverktyg — är teknisk trovärdighet inte valfritt. Här är vad bevisen behöver se ut som.

Kodexempel som är offentliga och sökbara. Din GitHub-profil kommer att kontrolleras. Den måste ha repositories med faktisk kod, meningsfull commit-historik och helst bidrag till andra projekt. En GitHub-profil som innehåller fem tomma repositories och en fork från 2019 är aktivt skadlig. Om du har bidragit till öppna källkodsprojekt, även blygsamt, lista de specifika repositories och vad du bidrog med.

Exempelapplikationer som är genuint instruktiva. De bästa developer advocates bygger saker som andra utvecklare lär sig av. Om du har byggt handledningsappar, startmallar eller integrationsguider som är live och används, länka till dem. Även en välkonstruerad exempelapplikation demonstrerar mer än en sida med självbeskrivning.

Tekniskt skrivande som kräver kodkunskap. Blogginlägg eller dokumentation du har skrivit som involverar kodutdrag, arkitekturförklaringar eller felsökningsgenomgångar är starka bevis. Artiklar som pratar om teknik i allmänna termer utan kod är svagare signaler.

Återkopplingsslingor med produktteam. Developer advocacy har en intern funktion: att lyfta fram utvecklarsmärtpunkter till produktteamet på ett sätt som påverkar vägkartan. Om du kan demonstrera att din feedback ledde till specifika produktförbättringar är det ytterst övertygande bevis på att du opererade som en strategisk tillgång snarare än bara en innehållsskapare.

Att bygga din portfölj innan du ansöker

Om du övergår till developer advocacy från en ren ingenjörsroll, eller om du är tidigt i din DevRel-karriär, spelar det portföljarbete du gör innan du ansöker en enorm roll. Här är de investeringarna med högst hävstång.

Börja skriva offentligt. En personlig blogg eller en serie artiklar på en plattform som Hashnode, dev.to eller Substack som lär ut något tekniskt bygger ditt rykte och ditt arkiv simultant. Efter sex månader av konsekvent publicering har du bevis på uthållig produktion som inget CV-punkt kan replikera.

Tala på ett lokalt meetup. Utvecklarkonferenser är konkurrenskraftiga, men lokala utvecklarmeetups är nästan alltid öppna för nya talare. En eller två föredrag ger dig en riktig punkt och en inspelning om du arrangerar att få det inspelat.

Bidra till ett öppet källkodsprojekt du använder. Även dokumentationsförbättringar, buggfixar eller reproduktioner av rapporterade problem räknas. Välj något du genuint använder och bryr dig om. Dina bidrag kommer att vara mer sammanhängande och din kunskap djupare när du tillfrågas om dem i en intervju.

Bygg en genuint användbar exempelapplikation. Inte en handledning du följde — något du byggde för att lösa ett verkligt problem eller för att demonstrera något du önskade var bättre dokumenterat. Det enskilda projektet, om det är bra, kan förankra hela din portföljberättelse.

Innehålls- och community-mätvärden: Vad man ska spåra

Developer advocacy-rekryterare vill se bevis på att ditt arbete driver utvecklaradoption och engagemang. De mätvärden som spelar störst roll är inte alltid uppenbara.

Utvecklarspecifika engagemangsmätvärden spelar större roll än vanity metrics. 500 utvecklare som deltar i ett föredrag spelar mer roll än 10 000 videovisningar. 200 utvecklare som slutför en workshop spelar mer roll än 2 000 bloggvisningar. Räckvidd hos en icke-utvecklarpublik överförs inte.

Konverterings- och aktiveringsmätvärden är ytterst övertygande. Om du kan demonstrera att en handledning du skrev konverterade läsare till gratisregistreringar, eller att ett workshop du höll ledde till mätbara ökningar i API-användning, demonstrerar du exakt vad developer advocacy är tänkt att åstadkomma.

Community-hälsomätvärden — aktiv tillväxt av medlemmar, retentionsfrekvenser, svarstider, sentimentindikatorer — är alltmer viktiga allteftersom företag investerar mer i utvecklargemenskaper som en retentions- och lojalitetskanal.

Om du inte har formell tillgång till dessa siffror från din nuvarande eller tidigare roll, gör ditt bästa för att rekonstruera rimliga uppskattningar baserat på vad du vet och var transparent om uppskattningsmetodologin när du tillfrågas.

Att positionera dig mot rena ingenjörer och rena marknadsförare

Developer advocacy-anställningsprocessen involverar ofta en teknisk skärm och en kommunikationsbedömning, ibland med en take-home-övning som involverar båda. De kandidater som vanligtvis förlorar är de som är utmärkta i en dimension men ej övertygande i den andra.

Rena ingenjörer som kommer in i DevRel misslyckas ibland med kommunikationsbedömningen — de kan bygga imponerande saker men kämpar med att artikulera varför en utvecklare borde bry sig om dem, eller producerar innehåll som är tekniskt korrekt men pedagogiskt ogenomträngligt.

Marknadsförare med ytlig teknisk kunskap misslyckas ibland med den tekniska skärmen — de kan inte skriva meningsfull kod eller svara på frågor om produkten på implementeringsnivå, och utvecklare i communityn känner till sist att de stöds av någon som faktiskt inte kan hjälpa.

Den sweet spot ditt CV behöver kommunicera är genuin teknisk kompetens som kanaliseras genom ett undervisnings- och community-tänkesätt. Du bygger saker för att du förstår hur de fungerar; du förklarar saker för att du vill att andra utvecklare ska förstå dem också. Båda halvorna är verkliga. Båda halvorna är djupa.

Att anpassa ditt CV för den specifika rollen

Developer advocacy-jobbeskrivningar varierar enormt. Vissa betonar konferensföredrag. Andra betonar SDK-underhåll. Andra är nästan helt community-hantering med en teknisk förutsättning. Att läsa jobbeskrivningen noggrant och anpassa ditt CV för att matcha den specifika betoningen är särskilt viktigt inom detta område.

Ett verktyg som NextCV gör det praktiskt att generera en version av ditt CV som lyfter fram den mest relevanta erfarenheten för varje specifik roll. Givet att samma underliggande bakgrund kan stödja flera olika inramningar är den här typen av anpassning skillnaden mellan ett CV som resonerar omedelbart och ett som läses som generiskt.

Intervjun: Vad man förbereder sig för

Developer advocacy-intervjuer inkluderar vanligtvis minst en av följande komponenter: en live-kodningsövning eller kodgranskning, en presentation eller mock-föredrag om ett tekniskt ämne, och en diskussion om din innehållsstrategi och community-filosofi. Att vara utmärkt på alla tre kräver uthållig förberedelse — inte halvhjärtat plottande.

De kandidater som landar DevRel-roller är de som har gjort arbetet innan intervjun: publicerat innehåll, talat på evenemang, bidragit till communities. Intervjun är en möjlighet att lyfta fram ett redan existerande körk av arbete, inte att tillverka ett under press. Börja bygga det nu och låt CV:t vara dokumentet som pekar mot det.