Przykłady CV i szablony dla Technical Writera na rok 2025

Biuro Statystyki Pracy (Bureau of Labor Statistics) podaje, że w Stanach Zjednoczonych zatrudnionych jest około 56 400 technical writerów, a ich mediana rocznych zarobków wynosi 91 670 dolarów według danych z maja 2024 r. (BLS, Occupational Employment and Wage Statistics, 27-3042). Przy prognozowanych około 4 500 wakatach rocznie do roku 2034 konkurencja o najlepsze stanowiska w czołowych firmach SaaS, u producentów sprzętu i w firmach zajmujących się narzędziami dla programistów pozostaje intensywna. CV, które wykazuje mierzalny wpływ dokumentacji — ograniczenie zgłoszeń do działu wsparcia, przyspieszenie wdrożenia, zwiększenie adopcji wśród programistów — oddziela kandydatów zapraszanych na rozmowy kwalifikacyjne od tych, których dokumenty są odrzucane przez systemy ATS, zanim menedżer rekrutujący w ogóle przeczyta choćby jedno słowo.

Spis treści

1. Dlaczego ta rola jest ważna
2. Przykład CV dla juniorskiego Technical Writera
3. Przykład CV dla Technical Writera na średnim poziomie
4. Przykład CV dla starszego / wiodącego Technical Writera
5. Kluczowe umiejętności i słowa kluczowe ATS
6. Przykłady podsumowania zawodowego
7. Częste błędy w CV Technical Writera
8. Wskazówki dotyczące optymalizacji pod ATS
9. Najczęściej zadawane pytania
10. Źródła

Dlaczego ta rola jest ważna

Technical writerzy działają na styku inżynierii produktu i doświadczenia użytkownika końcowego. Każda referencja API, instrukcja instalacji, nota do wydania i artykuł dotyczący rozwiązywania problemów, który tworzy technical writer, decyduje o tym, czy klienci mogą samodzielnie wdrożyć produkt, czy też zasypią kolejkę wsparcia technicznego zapobiegalnymi zgłoszeniami. Kiedy dokumentacja jest jasna, firmy odnotowują bezpośrednie oszczędności: mniej eskalacji, szybszy czas do uzyskania wartości i wyższe wskaźniki Net Promoter Score. Kiedy dokumentacja jest nieobecna lub niejasna, konsekwencje widać w metrykach odejść klientów, negatywnych opiniach w sklepach z aplikacjami i czasie inżynierów marnowanym na odpowiadanie na powtarzające się pytania. Ruch docs-as-code fundamentalnie zmienił oczekiwania pracodawców wobec technical writerów w 2025 roku. Biegłość w Git, Markdown, generatorach stron statycznych takich jak Hugo czy Docusaurus, pipeline'ach CI/CD do budowania dokumentacji oraz specyfikacjach OpenAPI/Swagger to teraz wymaganie bazowe — nie wyróżnik. Firmy takie jak Stripe, Twilio, Datadog i Cloudflare publicznie uznały swoją dokumentację deweloperską za przewagę konkurencyjną, co podniosło strategiczne znaczenie zespołów technical writingu w całej branży oprogramowania (Write the Docs, „Docs as Code"). Dla osób poszukujących pracy oznacza to, że CV technical writera musi jednocześnie udowadniać dwie rzeczy: umiejętność pisania z precyzją i klarownością oraz biegłość techniczną pozwalającą pracować w ramach procesów inżynieryjnych. Poniższe przykłady CV pokazują, jak prezentować obie te kompetencje za pomocą mierzalnych osiągnięć, które przechodzą skanowanie słów kluczowych ATS i przekonują menedżerów rekrutujących do umówienia rozmowy kwalifikacyjnej.

Przykład CV dla juniorskiego Technical Writera

**Odpowiednie dla:** 0–2 lata doświadczenia, osoby zmieniające branżę z obszaru inżynierii lub anglojęzycznej komunikacji, świeżo upieczeni absolwenci ze stażem lub freelance'ową pracą dokumentacyjną.

SARAH CHEN

Portland, OR 97201 | [email protected] | (503) 555-0147 | linkedin.com/in/sarahchen-techwriter | portfolio: sarahchen-docs.com

PODSUMOWANIE ZAWODOWE

Technical writer z 1,5-rocznym doświadczeniem dokumentacyjnym w produktach SaaS, łączący licencjat z informatyki z certyfikacją STC Foundation. Autorka ponad 45 podręczników użytkownika, tutoriali szybkiego startu API i artykułów bazy wiedzy w startupie Series B, przyczyniając się do 22% redukcji zgłoszeń wsparcia Tier 1 w ciągu sześciu miesięcy. Biegła w Markdown, Git, Confluence i przepływach pracy docs-as-code z wykorzystaniem Hugo i GitHub Actions.

DOŚWIADCZENIE

**Technical Writer** Samsara | Portland, OR | czerwiec 2024 – obecnie

• Stworzyła 38 artykułów bazy wiedzy obejmujących konfigurację sprzętu do zarządzania flotą, kalibrację czujników i konfigurację dashboardu, redukując zgłoszenia wsparcia Tier 1 o 22% (z 1840/miesiąc do 1435/miesiąc) w ciągu pierwszych dwóch kwartałów
• Napisała 12-rozdziałowy przewodnik szybkiego startu API dla Samsara Developer Platform, generujący 14 200 unikalnych wyświetleń w pierwszych 90 dniach i uzyskujący średnią ocenę przydatności 4,6/5,0 w ankietach opinii programistów
• Przeniosła 94 starsze podręczniki PDF do repozytorium ze strukturalnym Markdown zarządzanego przez Git, umożliwiając wersjonowaną dokumentację z przepływami pracy opartymi na pull requestach dla 7-osobowego zespołu inżynierskiego
• Współpracowała z 4 menedżerami produktu i 11 inżynierami oprogramowania w 3 zespołach sprintowych nad dwutygodniowymi notami do wydań, obejmującymi średnio 8 funkcji i 15 poprawek na cykl
• Skróciła średni czas przeglądu artykułu z 5 dni roboczych do 2,5 dnia roboczego, wdrażając przepływ redakcyjny w Confluence ze znormalizowanymi szablonami i listą kontrolną stylu **Stażystka ds. Technical Writingu** Puppet (Perforce) | Portland, OR | styczeń 2024 – maj 2024
• Napisała 7 przewodników instalacji i konfiguracji dla modułów Puppet Enterprise, każdy średnio o objętości 2800 słów z osadzonymi przykładami CLI i drzewami decyzyjnymi dotyczącymi rozwiązywania problemów
• Zaktualizowała 23 istniejące strony dokumentacji zgodnie ze zmianami w wydaniu Puppet Enterprise 2024.1, zapewniając dokładność na platformach Linux, Windows i macOS
• Stworzyła glosariusz terminologiczny obejmujący 180 terminów specyficznych dla produktu, używany przez zespół dokumentacyjny do zapewnienia spójności na ponad 400 opublikowanych stronach

WYKSZTAŁCENIE

**Licencjat z informatyki** Portland State University | Portland, OR | Ukończenie: maj 2023

• Specjalizacja uzupełniająca: Komunikacja techniczna
• Praca dyplomowa: Przeprojektowanie dokumentacji projektu open source Apache Airflow; 3 scalone pull requesty do oficjalnego repozytorium dokumentacji

CERTYFIKATY

• **Certified Professional Technical Communicator (CPTC) — Foundation Level**, Society for Technical Communication (STC), 2024
• **Google Technical Writing Course** (Technical Writing One & Two), Google Developers, 2023

UMIEJĘTNOŚCI TECHNICZNE

• **Tworzenie treści:** Markdown, reStructuredText, AsciiDoc, HTML/CSS
• **Narzędzia:** Confluence, Jira, MadCap Flare, Oxygen XML, Snagit, Lucidchart
• **Docs-as-Code:** Git, GitHub, Hugo, Docusaurus, GitHub Actions CI/CD
• **Dokumentacja API:** Swagger/OpenAPI 3.0, Postman, cURL
• **Współpraca:** Slack, Figma (adnotacje zrzutów ekranu), Miro

Przykład CV dla Technical Writera na średnim poziomie

**Odpowiednie dla:** 3–6 lat doświadczenia, kandydaci ze specjalizacją w dokumentacji API i pracy z odbiorcami deweloperskimi, osoby przechodzące na stanowiska starszych specjalistów.

MARCUS JOHNSON

Austin, TX 78701 | [email protected] | (512) 555-0293 | linkedin.com/in/marcusjohnson-docs | github.com/marcusjdocs

PODSUMOWANIE ZAWODOWE

Specjalista ds. dokumentacji API z 5-letnim doświadczeniem w tworzeniu treści skierowanych do programistów dla interfejsów RESTful i GraphQL API w firmach typu enterprise SaaS. Kierował pracami dokumentacyjnymi przy premierze produktu Observability Pipelines firmy Datadog, tworząc 74 strony referencyjne, 12 przewodników integracji i 8 interaktywnych tutoriali, które przyczyniły się do 31% wzrostu adopcji wśród programistów w pierwszym kwartale. Posiada certyfikat CPTC Practitioner i aktywnie udziela się w społeczności Write the Docs.

DOŚWIADCZENIE

**Senior Technical Writer, dokumentacja API** Datadog | Austin, TX (praca zdalna) | marzec 2023 – obecnie

• Odpowiedzialny za pełną dokumentację linii produktowej Observability Pipelines, tworząc 74 strony referencyjne API, 12 przewodników integracji i 8 interaktywnych tutoriali z próbkami kodu, co przyczyniło się do 31% wzrostu adopcji wśród programistów (mierzonego liczbą unikalnych aktywacji kluczy API) w I kwartale 2024
• Wdrożył pipeline docs-as-code z wykorzystaniem Hugo, GitHub Actions i lintera Vale, redukując błędy w buildach dokumentacji o 67% i skracając średni czas publikacji z 45 minut do 12 minut na merge
• Opracował szablon specyfikacji OpenAPI 3.1 przyjęty przez 6 zespołów inżynierskich (42 inżynierów), standaryzując dokumentację referencyjną API dla 11 mikroserwisów i eliminując 85% niespójności specyfikacji wykrytych w audytach kwartalnych
• Pisał noty do wydań dla 26 wydań produktów, średnio po 1200 słów na wydanie z przewodnikami migracji, ostrzeżeniami o zmianach powodujących niezgodności i przykładami różnic w kodzie; strony z notami wydań uzyskiwały średnio 8400 wyświetleń na publikację
• Przeprowadził 14 testów użyteczności dokumentacji z zewnętrznymi programistami, identyfikując 23 problemy z nawigacją i terminologią; wdrożone poprawki podniosły NPS dokumentacji z +34 do +52 w ciągu dwóch kwartałów
• Mentorował 2 juniorskich technical writerów podczas onboardingu, sesji wspólnego pisania i cotygodniowych spotkań feedbackowych — oboje uzyskali ocenę „przewyższa oczekiwania" w pierwszym cyklu ewaluacji wyników **Technical Writer** HashiCorp | Austin, TX | sierpień 2020 – luty 2023
• Tworzył i utrzymywał dokumentację dla Terraform Cloud i Terraform Enterprise, obejmującą 48 integracji z providerami, zarządzanie workspace'ami i przepływy pracy policy-as-code (Sentinel) na ponad 210 opublikowanych stronach
• Stworzył framework do ponownego wykorzystania treści z użyciem skrótów Hugo i szablonów cząstkowych, redukując zduplikowane treści o 38% na stronie dokumentacji Terraform i oszczędzając szacunkowo 12 godzin miesięcznie nakładu pracy konserwacyjnej
• Napisał 6 obszernych tutoriali (średnio 4500 słów każdy) dla portalu HashiCorp Developer; tutorial „Getting Started with Terraform on AWS" zgromadził 287 000 wyświetleń w ciągu 18 miesięcy
• Współpracował z zespołem lokalizacyjnym przy przygotowaniu 34 stron o wysokim ruchu do tłumaczenia na japoński, niemiecki i francuski, opracowując przewodnik stylu przyjazny tłumaczom, który ograniczył zapytania tłumaczy o 45%
• Zarządzał dokumentacją dla 3 głównych wydań produktu rocznie, koordynując prace z zespołami zarządzania produktem, inżynierii i developer advocacy w celu zapewnienia kompletności dokumentacji w dniu premiery — referencje API, przewodniki CLI i ścieżki migracji **Junior Technical Writer** Rackspace Technology | San Antonio, TX | czerwiec 2019 – lipiec 2020
• Dokumentował interfejsy API Rackspace Managed Kubernetes i OpenStack Private Cloud, tworząc 32 strony referencyjne endpointów z przykładami zapytań/odpowiedzi, przepływami uwierzytelniania i tabelami kodów błędów
• Skrócił średni czas do pierwszego udanego wywołania API dla nowych klientów z 47 minut do 19 minut, restrukturyzując sekwencję przewodnika szybkiego startu i dodając kolekcję Postman ze wstępnie skonfigurowanymi zmiennymi środowiskowymi
• Napisał 18 artykułów dotyczących rozwiązywania problemów do bazy wiedzy wsparcia Rackspace; 5 najczęściej odwiedzanych artykułów łącznie odciążyło szacunkowo 340 zgłoszeń wsparcia miesięcznie (na podstawie danych z ankiety wyjściowej Zendesk)

WYKSZTAŁCENIE

**Licencjat z filologii angielskiej — specjalizacja: pisanie profesjonalne** University of Texas at Austin | Austin, TX | Ukończenie: maj 2019

CERTYFIKATY

• **Certified Professional Technical Communicator (CPTC) — Practitioner Level**, Society for Technical Communication (STC), 2022
• **ITCQF Certified Technical Communication Professional — Foundation Level**, International Technical Communication Qualifications Foundation, 2021
• **Google Technical Writing Course** (Technical Writing One & Two), Google Developers, 2020

UMIEJĘTNOŚCI TECHNICZNE

• **Dokumentacja API:** OpenAPI/Swagger 3.0 i 3.1, dokumentacja schematów GraphQL, kolekcje Postman, Redoc, Stoplight Studio
• **Tworzenie treści:** Markdown, MDX, reStructuredText, AsciiDoc, DITA XML
• **Docs-as-Code:** Git, GitHub/GitLab, Hugo, Docusaurus, MkDocs, linter Vale, GitHub Actions, CircleCI
• **Narzędzia deweloperskie:** VS Code, terminal/CLI (Bash), Python (skryptowanie), cURL, jq
• **Zarządzanie treścią:** Confluence, Notion, ReadMe.io, Paligo
• **Diagramy:** Mermaid.js, Lucidchart, draw.io, PlantUML

DZIAŁALNOŚĆ SPOŁECZNA I WYSTĄPIENIA

• Prelegent, Write the Docs Portland 2024: „Mierzenie wpływu dokumentacji poza wyświetleniami stron"
• Kontrybutor, Good Docs Project: Współautor szablonu dokumentacji referencyjnej API
• Autor bloga, 6 opublikowanych artykułów o praktykach docs-as-code (publikacje gościnne na passo.uno)

Przykład CV dla starszego / wiodącego Technical Writera

**Odpowiednie dla:** 7+ lat doświadczenia, kandydaci z kompetencjami w zakresie strategii treści, zarządzania zespołem i przywództwa międzyfunkcyjnego.

DR EMILY NAKAMURA

San Francisco, CA 94105 | [email protected] | (415) 555-0381 | linkedin.com/in/emilynakamura | emilynakamura.dev

PODSUMOWANIE ZAWODOWE

Wiodąca Technical Writer i strateg dokumentacji z 10-letnim doświadczeniem w budowaniu i skalowaniu programów dokumentacyjnych w szybko rosnących firmach SaaS. Zbudowała praktykę dokumentacji deweloperskiej Stripe dla platform Payments i Connect od 2-osobowego zespołu do 8-osobowej organizacji, zarządzając portfolio dokumentacyjnym obejmującym ponad 1400 opublikowanych stron obsługujących 3,4 miliona unikalnych odwiedzających miesięcznie. Kierowała strategią odciążenia wsparcia opartą na dokumentacji, która zmniejszyła kontakty ze wsparciem dotyczące integracji płatności o 41%, oszczędzając szacunkowo 2,8 miliona dolarów rocznie kosztów wsparcia. Posiada doktorat z retoryki i komunikacji profesjonalnej oraz certyfikat CPTC Expert.

DOŚWIADCZENIE

**Wiodąca Technical Writer, dokumentacja deweloperska** Stripe | San Francisco, CA | styczeń 2020 – obecnie

• Zbudowała i zarządzała zespołem dokumentacji deweloperskiej, rozwijając go z 2 do 8 osób, ustanawiając kryteria rekrutacji, programy wdrożeniowe i ścieżkę kariery od poziomu Associate do Staff Technical Writer
• Odpowiedzialna za portfolio dokumentacyjne Stripe Payments i Stripe Connect, obejmujące ponad 1400 opublikowanych stron, 230 repozytoriów z próbkami kodu (Ruby, Python, Node.js, Go, Java, PHP) i 48 interaktywnych tutoriali obsługujących 3,4 miliona unikalnych odwiedzających miesięcznie
• Zaprojektowała i wdrożyła strategię odciążenia wsparcia opartą na dokumentacji, która zmniejszyła kontakty ze wsparciem dotyczące integracji płatności o 41% (z 18 200/miesiąc do 10 738/miesiąc), oszczędzając szacunkowo 2,8 miliona dolarów rocznie przy średnim koszcie 13,50 dolara za kontakt
• Ustanowiła architekturę treści strukturalnej opartą na typach tematów DITA (koncepcja, zadanie, referencja) zaadaptowanych do Markdown, zwiększając wskaźnik ponownego wykorzystania treści z 12% do 47% na stronie dokumentacji i skracając czas propagacji aktualizacji o 63%
• Kierowała migracją ze starego CMS do systemu docs-as-code zbudowanego na Next.js i MDX, z kontrolą wersji opartą na Git, automatycznym sprawdzaniem linków i publikacją CI/CD przez GitHub Actions; skróciła średni czas publikacji z 3 dni roboczych do 4 godzin
• Stworzyła kartę oceny jakości dokumentacji obejmującą 8 wymiarów (dokładność, kompletność, wyszukiwalność, czytelność, poprawność próbek kodu, klarowność wizualna, dostępność, aktualność), osiągając średni wynik zespołowy 92/100 w kwartalnych audytach
• Współpracowała z zespołem Stripe Developer Advocacy przy tworzeniu 14 materiałów do warsztatów konferencyjnych i 6 scenariuszy do wideo-tutoriali, łącznie generujących 890 000 wyświetleń na YouTube i kanale Stripe Developer
• Zarządzała rocznym budżetem na narzędzia dokumentacyjne w wysokości 420 000 dolarów, obejmującym platformy autorskie, usługi tłumaczeniowe, automatyzację zrzutów ekranu i infrastrukturę analityczną **Senior Technical Writer** Twilio | San Francisco, CA | kwiecień 2017 – grudzień 2019
• Kierowała dokumentacją interfejsów API Twilio Programmable Voice i Programmable Video, utrzymując 380 opublikowanych stron z 99,2% dokładnością weryfikowaną za pomocą automatycznego testowania próbek kodu (uruchamianie na żywo wywołań API w środowiskach sandbox co noc)
• Opracowała przewodnik stylu dokumentacji Twilio przyjęty przez 22 technical writerów w 4 zespołach produktowych, ustanawiając standardy głosu, tonu, formatowania kodu i inkluzywnego języka, co ograniczyło cykle poprawek redakcyjnych o 35%
• Koordynowała lokalizację dokumentacji na 8 języków (hiszpański, portugalski, francuski, niemiecki, japoński, koreański, chiński uproszczony, chiński tradycyjny), zarządzając rocznym budżetem tłumaczeniowym w wysokości 180 000 dolarów i osiągając 96% terminowość realizacji dla 2400 przetłumaczonych stron
• Zbudowała dashboard analityczny integrujący Google Analytics, mapy ciepła Hotjar i widgety opinii na stronach, aby śledzić efektywność dokumentacji; zidentyfikowała, że 68% porzuceń przez programistów następowało na etapie konfiguracji uwierzytelniania, po czym przepisała tę sekcję, zmniejszając porzucenia o 29%
• Autorka 15 000-słowowego wewnętrznego przewodnika „Writing for Developers at Twilio", wykorzystywanego do wdrożenia 9 nowych technical writerów i 14 developer advocates w ciągu 2 lat **Technical Writer** Cisco Systems | San Jose, CA | lipiec 2015 – marzec 2017
• Dokumentowała produkty sieciowe Cisco Meraki zarządzane w chmurze, tworząc 64 przewodniki administracyjne, 28 dokumentów referencyjnych API i 12 białych ksiąg z najlepszymi praktykami wdrożeniowymi dla platformy Meraki Dashboard
• Przeniosła 420 starszych dokumentów z FrameMakera do repozytorium DITA XML ze strukturą, tworząc taksonomię 1200 wielokrotnie używanych komponentów treści i skracając średni czas aktualizacji dokumentu z 6 godzin do 1,5 godziny
• Przeprowadzała kwartalne audyty dokumentacji obejmujące 840 opublikowanych stron, identyfikując i rozwiązując średnio 47 problemów z dokładnością na cykl audytowy we współpracy z zespołami QA i inżynierii **Technical Writer** IBM | Research Triangle Park, NC | sierpień 2013 – czerwiec 2015
• Tworzyła przewodniki instalacji, konfiguracji i administracji dla IBM WebSphere Application Server, utrzymując 180 stron dokumentacji dla 4 równoległych wersji produktu
• Napisała 22 podręczniki rozwiązywania problemów wykorzystywane przez zespół wsparcia IBM, przyczyniając się do 16% redukcji średniego czasu rozwiązania przypadku w zgłoszeniach wsparcia związanych z WebSphere

WYKSZTAŁCENIE

**Doktorat, retoryka i komunikacja profesjonalna** Iowa State University | Ames, IA | Uzyskany 2013

• Rozprawa: „Autorstwo strukturalne i architektura informacji w korporacyjnej dokumentacji technicznej" **Licencjat z filologii angielskiej, summa cum laude** University of California, Berkeley | Berkeley, CA | Uzyskany 2008

CERTYFIKATY

• **Certified Professional Technical Communicator (CPTC) — Expert Level**, Society for Technical Communication (STC), 2021
• **ITCQF Certified Technical Communication Professional — Advanced Level**, International Technical Communication Qualifications Foundation, 2020
• **Certified ScrumMaster (CSM)**, Scrum Alliance, 2018

UMIEJĘTNOŚCI TECHNICZNE

• **Strategia treści:** Architektura informacji, modelowanie ponownego wykorzystania treści, projektowanie taksonomii, specjalizacja DITA, autorstwo strukturalne
• **Dokumentacja API:** OpenAPI/Swagger, GraphQL, gRPC/Protocol Buffers, AsyncAPI, Redoc, Stoplight, ReadMe.io
• **Tworzenie i publikacja:** Markdown, MDX, DITA XML, reStructuredText, MadCap Flare, Oxygen XML Author, Paligo
• **Docs-as-Code:** Git, GitHub/GitLab CI/CD, Hugo, Docusaurus, Next.js, Vale, textlint, markdownlint
• **Narzędzia inżynierskie:** Python, skrypty Bash, Docker, Postman, cURL, Jupyter Notebooks, VS Code
• **Analityka:** Google Analytics 4, Hotjar, FullStory, niestandardowe dashboardy Looker, testy A/B
• **Lokalizacja:** Systemy zarządzania tłumaczeniami (Crowdin, Smartling), XLIFF, przepływy pracy internacjonalizacji
• **Zarządzanie:** Rekrutacja, mentoring, przeglądy wyników, zarządzanie budżetem, negocjacje z dostawcami

PUBLIKACJE I WYSTĄPIENIA

• Prelegentka główna, Write the Docs Portland 2023: „Dokumentacja jako produkt: budowanie zespołów, które dostarczają treści"
• Panelista, STC Summit 2022: „Przyszłość DITA w świecie Docs-as-Code"
• Autorka opublikowanego artykułu, Technical Communication Quarterly: „Pomiar zwrotu z inwestycji w dokumentację deweloperską" (2021)
• Kontrybutor open source, OASIS DITA Technical Committee

Kluczowe umiejętności i słowa kluczowe ATS

Poniższe 30 umiejętności i słów kluczowych pojawia się najczęściej w ogłoszeniach o pracę dla technical writerów na LinkedIn, Indeed i Glassdoor. Włącz terminy odpowiednie do Twojego doświadczenia do sekcji umiejętności, podsumowania zawodowego i punktorów osiągnięć.

Przykłady podsumowania zawodowego

Poziom juniorski (0–2 lata)

„Technical writer z certyfikatem STC Foundation i 1,5-rocznym doświadczeniem w tworzeniu podręczników użytkownika, tutoriali szybkiego startu API i artykułów bazy wiedzy dla produktów SaaS. Zredukował zgłoszenia wsparcia Tier 1 o 22% w Samsara dzięki 38-artykułowej bazie wiedzy napisanej w Markdown z przepływami pracy przeglądu opartymi na Git. Posiada licencjat z informatyki z Portland State University ze specjalizacją uzupełniającą w komunikacji technicznej."

Poziom średni (3–6 lat)

„Specjalista ds. dokumentacji API z 5-letnim doświadczeniem w pisaniu treści skierowanych do programistów dla interfejsów RESTful i GraphQL API w HashiCorp i Datadog. Zbudował pipeline docs-as-code z wykorzystaniem Hugo, GitHub Actions i Vale, redukujący błędy w buildach dokumentacji o 67%. Stworzył szablony specyfikacji OpenAPI przyjęte przez 6 zespołów inżynierskich dla 11 mikroserwisów. Certyfikat CPTC Practitioner z aktywnym udziałem w społecznościach Write the Docs i Good Docs Project."

Poziom seniorski/wiodący (7+ lat)

„Lider dokumentacji z 10-letnim doświadczeniem w budowaniu zespołów technical writingu i programów treściowych w Stripe, Twilio i Cisco. Rozwinął zespół dokumentacji deweloperskiej Stripe z 2 do 8 osób, zarządzając portfolio 1400 stron obsługującym 3,4 miliona unikalnych odwiedzających miesięcznie. Zaprojektował strategię odciążenia wsparcia opartą na dokumentacji, która ograniczyła kontakty ze wsparciem dotyczące integracji płatności o 41%, oszczędzając 2,8 miliona dolarów rocznie. Certyfikat CPTC Expert. Doktorat z retoryki i komunikacji profesjonalnej."

Częste błędy w CV Technical Writera

1. Wymienianie narzędzi bez kontekstu

Napisanie „Biegły w MadCap Flare, Confluence i Oxygen XML" nie mówi menedżerowi rekrutującemu nic o wpływie. Zamiast tego podaj, co zbudowałeś: „Stworzyła 12-rozdziałowy przewodnik szybkiego startu API w Confluence, generujący 14 200 unikalnych wyświetleń stron w pierwszych 90 dniach." Każda wzmianka o narzędziu powinna być powiązana z wynikiem.

2. Używanie „Odpowiedzialny za" zamiast czasowników osiągnięć

„Odpowiedzialny za utrzymanie dokumentacji produktowej" to opis stanowiska, nie punkt w CV. Zastąp to mierzalnym działaniem: „Utrzymywała 380 opublikowanych stron referencyjnych API z 99,2% dokładnością weryfikowaną za pomocą automatycznego nocnego testowania próbek kodu w środowiskach sandbox." Różnica między oddzwonieniem a odrzuceniem często tkwi właśnie w tym rozróżnieniu.

3. Całkowite pomijanie metryk

Technical writing daje mierzalne wyniki, których wielu kandydatów nie śledzi ani nie raportuje. Wskaźniki odciążenia zgłoszeń wsparcia, wyświetlenia stron, wyniki NPS dokumentacji, czas do pierwszego udanego wywołania API, procenty ponownego wykorzystania treści i redukcje czasu przeglądu — to wszystko metryki, które menedżerowie rekrutujący rozpoznają. Jeśli nie pamiętasz dokładnych liczb, oszacuj je konserwatywnie i podaj podstawę (np. „szacowane na podstawie danych z ankiety wyjściowej Zendesk").

4. Ignorowanie wymogu portfolio

Analiza 1000 ogłoszeń o pracę dla technical writerów wykazała, że 60% wyraźnie wymagało próbki pisarskiej lub linku do portfolio (CV Compiler, 2024). Kandydaci, którzy pomijają adres URL portfolio w nagłówku CV, pomijają wymaganie bazowe. Dołącz link do osobistej strony z dokumentacją, portfolio na GitHub Pages lub wyselekcjonowanego zestawu opublikowanych próbek pisarskich.

5. Traktowanie wszystkich rodzajów technical writingu jako identycznych

Kandydat dokumentujący konsumenckie aplikacje mobilne ma inne umiejętności niż ktoś, kto pisze referencje API dla platformy deweloperskiej. Dostosuj swoje CV do konkretnego rodzaju technical writingu, którego wymaga docelowe stanowisko. Jeśli ogłoszenie wymienia „dokumentację deweloperską" lub „dokumenty API", zacznij od tych doświadczeń. Jeśli kładzie nacisk na „dokumentację dla użytkownika końcowego" lub „podręczniki produktowe", dostosuj się odpowiednio.

6. Ukrywanie biegłości technicznej

Niektórzy technical writerzy z wykształceniem inżynierskim ukrywają umiejętności programistyczne na dole CV. Jeśli stanowisko wymaga biegłości w docs-as-code, doświadczenia z Git lub umiejętności czytania i pisania próbek kodu, uwypuklij te kompetencje w podsumowaniu zawodowym i najważniejszych punktach doświadczenia — nie w sekcji umiejętności na końcu.

7. Przesyłanie wizualnie przeładowanego CV

Od technical writerów oczekuje się, że informacje będą jasne i łatwe do przeskanowania. CV z niespójnym formatowaniem, gęstymi akapitami lub elementami dekoracyjnymi podważa tę fundamentalną obietnicę profesjonalną. Stosuj czyste nagłówki sekcji, spójne formatowanie punktorów i wystarczającą ilość białej przestrzeni. Samo CV jest próbką pisarską.

Wskazówki dotyczące optymalizacji pod ATS

1. Odwzorowuj dokładną terminologię z ogłoszenia o pracę

Jeśli ogłoszenie mówi „API documentation", użyj dokładnie tego wyrażenia, a nie synonimów jak „developer docs" czy „technical references". Systemy ATS dopasowują słowa kluczowe, a parafrazowanie obniża wynik dopasowania. Umieść dokładne terminy zarówno w sekcji umiejętności, jak i w punktach doświadczenia.

2. Rozwijaj akronimy przy pierwszym użyciu, a następnie stosuj obie formy

Napisz „Darwin Information Typing Architecture (DITA)" za pierwszym razem, a potem stosuj „DITA" w kolejnych wzmiankach. Dzięki temu dopasujesz się niezależnie od tego, czy ATS indeksuje pełny termin, akronim czy obie formy. Zastosuj ten sam wzorzec do „OpenAPI/Swagger", „Certified Professional Technical Communicator (CPTC)" i „Docs-as-Code".

3. Stosuj standardowy format CV bez grafik i tabel

Parsery ATS mają problemy z polami tekstowymi, układami wielokolumnowymi, osadzonymi obrazami i złożonymi strukturami tabelarycznymi. Użyj jednokolumnowego układu z wyraźnie oznaczonymi nagłówkami sekcji (Podsumowanie zawodowe, Doświadczenie, Wykształcenie, Certyfikaty, Umiejętności). Kreatywność formatowania zachowaj do portfolio — CV musi być poprawnie parsowane.

4. Podawaj nazwy certyfikatów dokładnie tak, jak zostały wydane

Napisz „Certified Professional Technical Communicator (CPTC) — Practitioner Level, Society for Technical Communication" zamiast skracać do „STC CPTC". Podaj pełną nazwę organizacji wydającej, poziom certyfikatu i rok uzyskania. Zarówno systemy ATS, jak i rekruterzy wyszukują te dokładne ciągi znaków.

5. Umieszczaj słowa kluczowe w kontekście, nie tylko w liście umiejętności

Lista umiejętności na dole CV pomaga z gęstością słów kluczowych, ale systemy ATS i rekruterzy coraz bardziej cenią słowa kluczowe pojawiające się w punktach osiągnięć w sekcji doświadczenia. „Wdrożył pipeline docs-as-code z wykorzystaniem Hugo, GitHub Actions i lintera Vale" ma większą wagę niż samodzielna linijka „Hugo, GitHub Actions, Vale" w bloku umiejętności.

6. Przesyłaj w formacie .docx, chyba że wyraźnie proszono o PDF

Wiele platform ATS parsuje pliki .docx bardziej niezawodnie niż pliki PDF. Jeśli instrukcje aplikacyjne nie mówią wyraźnie „prześlij jako PDF", domyślnie wybierz .docx. Jeśli przesyłasz PDF, upewnij się, że zawiera zaznaczalny tekst (nie zeskanowany obraz) i przetestuj go, kopiując tekst z pliku, aby zweryfikować wierność parsowania.

7. Nadawaj plikom profesjonalne i opisowe nazwy

Nazwij swój plik „Marcus-Johnson-Technical-Writer-CV.docx" zamiast „cv-ostateczne-v3.docx" lub „dokument1.docx". Niektóre platformy ATS wyświetlają nazwę pliku rekruterom, a profesjonalna konwencja nazewnictwa potwierdza dbałość o szczegóły — kluczową kompetencję technical writera.

Najczęściej zadawane pytania

Czy technical writerzy muszą umieć programować?

Nie musisz być inżynierem oprogramowania, ale umiejętność czytania kodu, pisania podstawowych skryptów i poruszania się po narzędziach deweloperskich jest coraz bardziej oczekiwana. Podręcznik perspektyw zawodowych BLS zaznacza, że technical writerzy muszą rozumieć technologię (BLS, OOH, 27-3042). Na stanowiskach związanych z dokumentacją API praktyczna znajomość co najmniej jednego języka programowania, narzędzi wiersza poleceń, kontroli wersji Git oraz formatów JSON/YAML jest wymaganiem funkcjonalnym. Juniorzy mogą to wykazać poprzez ukończone kursy (Google Technical Writing, freeCodeCamp), kontrybucje w dokumentacji open source lub portfolio zawierające próbki kodu.

Które certyfikaty mają największą wagę w CV technical writera?

Certified Professional Technical Communicator (CPTC) od Society for Technical Communication jest najbardziej uznawanym certyfikatem w branży, oferowanym na trzech poziomach: Foundation (260 dolarów dla członków STC), Practitioner (410 dolarów dla członków STC) i Expert (STC, 2025). Certyfikat ITCQF (International Technical Communication Qualifications Foundation) zyskuje na znaczeniu na arenie międzynarodowej, szczególnie na rynkach europejskich. Bezpłatne kursy Google Technical Writing są cenione jako uzupełniające referencje. Certyfikaty w pokrewnych dziedzinach — Certified ScrumMaster dla środowisk Agile, AWS Cloud Practitioner dla dokumentacji chmurowej — mogą również wyróżnić kandydatów.

Jak długie powinno być CV technical writera?

Jedna strona dla kandydatów z mniej niż 5-letnim doświadczeniem; dwie strony dla kandydatów z 5+ latami doświadczenia, szczególnie tych z obowiązkami w zakresie przywództwa, strategii treści lub koordynacji międzyfunkcyjnej. Kluczowym czynnikiem jest gęstość istotnych treści, nie liczba stron. Dwustronicowe CV wypełnione mierzalnymi osiągnięciami i konkretnymi umiejętnościami technicznymi zawsze pokona jednostronicowe CV wypchane ogólnikowymi opisami. Nigdy nie przekraczaj dwóch stron, chyba że posiadasz doktorat i uwzględniasz istotne publikacje akademickie.

Czy powinienem zamieścić link do portfolio w CV?

Bezwzględnie. Ponieważ 60% ogłoszeń o pracę dla technical writerów wymaga próbek pisarskich lub portfolio (analiza CV Compiler, 2024), pominięcie tego linku stawia Cię w gorszej pozycji jeszcze przed rozpoczęciem procesu rekrutacyjnego. Hostuj swoje portfolio na własnej domenie, GitHub Pages lub platformie dokumentacyjnej takiej jak ReadMe.io. Zamieść 3–5 wyselekcjonowanych próbek demonstrujących różne typy dokumentacji: referencję API, podręcznik użytkownika, tutorial i artykuł dotyczący rozwiązywania problemów. Jeśli Twoje najlepsze prace są objęte klauzulą NDA, stwórz oryginalne próbki dla fikcyjnego produktu lub wnies wkład w dokumentację projektów open source.

Co to jest docs-as-code i dlaczego ma znaczenie dla mojego CV?

Docs-as-code to podejście do dokumentacji, które stosuje praktyki tworzenia oprogramowania — kontrolę wersji z Git, autorstwo w formacie tekstowym w Markdown lub reStructuredText, automatyczne testowanie i budowanie za pomocą CI/CD oraz przepływy pracy przeglądu kodu — do produkcji dokumentacji (Write the Docs, przewodnik „Docs as Code"). To podejście stało się standardem w firmach technologicznych, ponieważ integruje dokumentację z tymi samymi repozytoriami i przepływami pracy, których inżynierowie używają do kodu. Dla Twojego CV wymienienie narzędzi docs-as-code (Git, GitHub/GitLab, Hugo, Docusaurus, MkDocs, linter Vale) i opisanie przepływów pracy dokumentacyjnych, które zbudowałeś lub do których się przyczyniłeś, sygnalizuje, że możesz działać w nowoczesnych zespołach inżynierskich bez potrzeby osobnego, odizolowanego CMS-a.

Źródła

1. **Bureau of Labor Statistics.** „Technical Writers." Occupational Outlook Handbook, U.S. Department of Labor. Aktualizacja: wrzesień 2024. https://www.bls.gov/ooh/media-and-communication/technical-writers.htm
2. **Bureau of Labor Statistics.** „27-3042 Technical Writers." Occupational Employment and Wage Statistics, maj 2024. https://www.bls.gov/oes/2023/may/oes273042.htm
3. **O*NET OnLine.** „27-3042.00 — Technical Writers." National Center for O*NET Development. https://www.onetonline.org/link/summary/27-3042.00
4. **Society for Technical Communication.** „Certified Professional Technical Communicator (CPTC)." STC Certification Program, 2025. https://www.stc.org/certification/
5. **Write the Docs.** „Docs as Code." Write the Docs Community Guide. https://www.writethedocs.org/guide/docs-as-code/
6. **CV Compiler.** „16 Technical Writer Resume Examples for 2025." CV Compiler Blog. https://cvcompiler.com/technical-writer-resume-examples
7. **Tom Johnson.** „Documenting APIs: A Guide for Technical Writers and Engineers." I'd Rather Be Writing. https://idratherbewriting.com/learnapidoc/
8. **Fluid Topics.** „5 Technical Documentation Trends to Shape Your 2025 Strategy." Fluid Topics Blog, 2025. https://www.fluidtopics.com/blog/industry-insights/technical-documentation-trends-2025/
9. **Fabrizio Ferri-Benedetti.** „My Technical Writing Predictions for 2025." passo.uno, 2025. https://passo.uno/tech-writing-predictions-2025/
10. **Heretto.** „7 Best Technical Writing Certifications for 2026." Heretto Blog. https://heretto.com/technical-writing-certification-2022/