CV Go (Golang) Developera: jak opisać backend pod ofertę

Go wszedł do backendu pod jednym hasłem: prostota i wydajność. Ludzie wybierają go nie po to, żeby mieć trzydzieści warstw abstrakcji, tylko żeby napisać usługę, która trzyma tysiące zapytań na sekundę, startuje w milisekundach i nie zjada pół gigabajta RAM-u na bezczynności. Oferta na Go Developera to widzi i pod to rekrutuje. A potem otwiera twoje CV, w którym pod stanowiskiem stoi „Go Developer”, a niżej lista: Go, goroutines, gRPC, Docker, Kubernetes, PostgreSQL. Z tej listy nie wynika, czy ty te usługi kiedyś postawiłeś na produkcji, czy przeczytałeś o nich w „Tour of Go”.

Bo na roli backendowej w Go nie chodzi o to, ile wzorców na kanałach znasz na pamięć. Chodzi o to, czy potrafisz napisać serwis, który skaluje się na rdzenie, trzyma latencję p99 pod kontrolą i nie wycieka pamięcią pod obciążeniem. Lista technologii tego nie pokaże, bo każdy kandydat na Go ma niemal identyczną. Pokaże to dopiero opis, w którym widać skalę, efekt twoich decyzji i konkretną liczbę zamiast ogólnika „pisałem wydajne usługi”.

Poniżej masz, co wyeksponować nad fold, jak opisać projekt przez wpływ na przepustowość, latencję i zużycie zasobów, i jak pokazać przejście na Go z innego backendu, gdy idziesz z Javy, Pythona albo Node.

Co wyeksponować nad fold: Go, concurrency, baza, infra

„Nad fold” to ta część CV, którą rekruter widzi bez przewijania. Pod ofertę backendową w Go ma tam być widać cztery rzeczy: sam język i to, jak ogarniasz współbieżność, sposób budowania API, pracę z bazą i to, jak twoje usługi trafiają na produkcję. To rdzeń roli, reszta jest wsparciem.

Ułóż umiejętności w kolejności istotności dla oferty, nie alfabetycznie:

• Rdzeń: Go (z wersją, np. 1.22), współbieżność (goroutines, kanały, context, sync), REST i gRPC, SQL (PostgreSQL, ta baza z oferty na pierwszym miejscu).
• Realne wsparcie: mikrousługi i komunikacja (Protobuf, kolejki: Kafka, NATS, RabbitMQ), Docker, Kubernetes, testy (testing, testify, table-driven, benchmarki), cache (Redis), observability (Prometheus, OpenTelemetry).
• Reszta: narzędzia CI, chmura, linory i tooling, niżej i mniejszą wagą.

Jeśli oferta wymienia konkretną technologię, której realnie używasz na produkcji, na przykład gRPC albo Kafkę, ma być widoczna od razu, nie zakopana między dwudziestą a trzydziestą pozycją. Rekruter skanuje pod kątem zgodności z ogłoszeniem, nie kompletności twojej kariery. Wersja Go też coś mówi: świeże 1.2x z generykami to inny sygnał niż projekt zamrożony na starym module.

Jak opisać projekt Go efektem, nie zadaniem

To jest miejsce, gdzie większość CV Go Developera się wykłada. Ludzie wypisują, co robili („pisałem serwisy w Go”, „obsługiwałem gRPC”), a to są obowiązki, nie dokonania. Nie widać ani skali, ani tego, czy po twojej robocie cokolwiek działało szybciej albo taniej. Pokaż zmianę i jej efekt, mierzony tym, co w Go się liczy najbardziej: przepustowość, latencja, zużycie zasobów.

Słaby zapis, który czyta się jak zakres obowiązków:

Pisałem mikrousługi w Go z komunikacją przez gRPC i obsługą bazy PostgreSQL.

Ten sam fakt, ustawiony pod ofertę backendową:

Zaprojektowałem usługę w Go obsługującą 8000 RPS przy p99 poniżej 25 ms. Po zrównolegleniu przetwarzania na goroutines z ograniczeniem przez context i pulę workerów oraz wymianie warstwy serializacji na gRPC zbiłem zużycie pamięci z 600 MB do 180 MB na instancję i zszedłem z 6 podów do 2.

Druga wersja opisuje dokładnie to samo, co robiłeś, ale pokazuje punkt wyjścia, zmianę i efekt w liczbach. Widać skalę (8000 RPS), zmianę (równoległość pod kontrolą, gRPC) i wpływ (RAM z 600 do 180 MB, trzykrotnie mniej podów, czyli realna oszczędność na infrze). Tego rekruter szuka, bo to odróżnia kogoś, kto sklejał handlery z gotowych przykładów, od kogoś, kto rozumie, gdzie usługa traci czas, pamięć i pieniądze.

Mocne akcenty pod Go i ich konkrety: przepustowość (RPS, liczba zdarzeń na sekundę), latencja (p95, p99 w milisekundach), zużycie zasobów (RAM i CPU na instancję, liczba podów albo rdzeni), współbieżność (skala równoległości, eliminacja wyścigów po go test -race), niezawodność (uptime, spadek błędów po refaktorze). Jedna szczera liczba przy każdym z tych wymiarów robi więcej niż dziesięć logotypów.

Jak pokazać przejście na Go z Javy, Pythona albo Node

Większość ludzi w ofertach Go nie pisała w Go od pierwszego dnia kariery. Idą tu z Javy, bo chcą prostszego deploya i mniej ceremonii. Idą z Pythona, bo potrzebują wydajności, której interpreter nie da. Idą z Node, bo chcą prawdziwej współbieżności na rdzeniach zamiast jednej pętli zdarzeń. To nie jest słabość w CV, to twoja przewaga, o ile dobrze ją opiszesz.

Robota polega na przepisaniu, nie na udawaniu, że pisałeś w Go od zawsze. Twoje doświadczenie inżynierskie przenosi się niezależnie od języka: projektowanie usług, praca z bazą, kolejki, obserwowalność, myślenie o wydajności. Nowa jest składnia i model współbieżności, nie inżynieria. Pokaż projekt z poprzedniego stacku przez pryzmat tego, co przenosi się na Go, i bądź uczciwy co do tego, gdzie powstał. Jeśli komercyjnie nie dotknąłeś jeszcze Go, pet-projekt albo migracja jednej usługi jest twoim dowodem: „przepisałem serwis płatności z Pythona na Go, p99 spadło z 140 ms do 30 ms, RAM o połowę” to mocny, konkretny sygnał. Pełną mechanikę przeramowania projektu na nowy stack rozkładamy w zmiana stacku w IT, a jeśli idziesz akurat z backendu na JVM, porównanie podejść masz w CV Java/Spring Developera.

Nie chowaj starego stacku i nie dopisuj sobie lat w Go, których nie masz. Senior, który uczciwie mówi „mocny w Javie, rok komercyjnie w Go, reszta z migracji i side-projektów”, jest wiarygodniejszy niż ktoś z dekadą Go wpisaną na wyrost, która wyłoży się na pierwszym pytaniu o select na kanałach albo o to, czemu nie zamyka kanału po stronie odbiorcy.

Słowa kluczowe z ofert Go

Oferty backendowe w Go powtarzają konkretny zestaw zwrotów: go (z wersją), goroutines, channels, context, gRPC, protobuf, rest api, microservices, postgresql, redis, kafka albo nats, docker, kubernetes, prometheus, ci/cd, table-driven tests. To są twoje słowa kluczowe. Wyciągnij must-have z konkretnej oferty i sprawdź, które masz pokryte realnym przykładem z projektu, a których lepiej nie wpisywać, bo zweryfikują je na pierwszej rozmowie technicznej w pięć minut. Jak czytać ogłoszenie pod tym kątem, rozkładamy w jak wyciągnąć słowa kluczowe z oferty IT.

Uważaj na pułapkę: wpisanie do skills wszystkiego, co kiedyś przeszło ci przez terminal. Rekruter pod Go nie szuka najdłuższej listy, tylko zgodności z must-have i dowodu w projektach. Jeden serwis z prawdziwą skalą i metrykami waży więcej niż pełna kolumna logotypów bez kontekstu.

Częste błędy

• Ściana technologii bez kontekstu. Go, goroutines, gRPC, Kubernetes, Kafka wrzucone obok siebie nie mówią, czy stawiałeś na nich produkcję, czy przeszedłeś tutorial. Zostaw rdzeń, resztę podaj niżej i pokaż użycie w projektach z konkretnym efektem na przepustowość albo zasoby.
• Brak metryk wydajności i zasobów. „Pisałem wydajne usługi” bez liczb jest puste. Go sprzedaje się liczbami: RPS, p99 w ms, RAM i CPU na instancję, liczba podów. Bez nich to deklaracja, nie dokonanie.
• Współbieżność jako ozdoba. Wpisanie „zaawansowane goroutines i kanały” tam, gdzie odpalałeś trzy go func() bez kontroli, wychodzi na pierwszym pytaniu o wyścigi, context i zamykanie kanałów. Opisz, jak realnie panowałeś nad równoległością i co to dało.

Jak złożyć CV Go w ZłóżCV

Pod ofertę backendową w Go ZłóżCV bierze z twojej bazy projekty, w których realnie projektowałeś usługi, ogarniałeś współbieżność i optymalizowałeś zasoby, układa stack pod wymagania ogłoszenia i przepisuje opisy tak, żeby było widać skalę, efekt i decyzje, a nie samą listę bibliotek. Jeśli idziesz na Go z innego backendu, przeramuje projekty pod nową rolę bez zmyślania lat w Go. Wklejasz link do oferty, dostajesz dopasowane CV w PDF. Złóż CV pod ofertę Go, dwa pierwsze za darmo, bez karty.

Najczęstsze pytania

Mam głównie proste serwisy CRUD w Go, jak pokazać coś więcej? Wyciągnij z nich decyzje, które miały efekt: pula workerów, która ustabilizowała zużycie pamięci, context z timeoutem, który przestał wieszać requesty, indeks albo cache, który zbił czas zapytania. Nawet zwykły handler ma metrykę: ile RPS obsługuje, jaki ma p99, ile RAM-u trzyma instancja. To zamienia „pisałem serwisy” w konkretny wpływ.

Idę na Go z Javy lub Pythona, wpisywać stary stack? Tak, jako fundament i kontekst doświadczenia. Pokaż przenośne kompetencje (architektura, baza, kolejki, produkcja) i realny kontakt z Go, choćby z migracji jednej usługi albo side-projektu. Pod ofertę w Go to on jest na pierwszym planie, stary stack podpiera wiarygodność, nie chowaj go i nie dopisuj sobie lat w Go.

Oferta wymaga gRPC, a ja robiłem tylko REST, co wtedy? Nie dopisuj gRPC, bo pytanie o strumienie, deadline i Protobuf wyłoży to na rozmowie. Pokaż za to pokrewne kompetencje: projektowanie API, kontrakty, serializacja, komunikacja między usługami. Jeśli gRPC jest twardym must-have, a ty go nie dotykałeś, to po prostu nie jest oferta pod ciebie albo materiał na weekendowy pet-projekt przed aplikacją.

Jak pokazać wydajność, gdy nie mierzyłem dokładnych liczb? Podaj rzędy wielkości, które pamiętasz, zamiast zmyślać precyzję. „Ruch rzędu kilku tysięcy zapytań na sekundę”, „p99 w okolicach kilkudziesięciu milisekund”, „RAM zbity mniej więcej o połowę” jest wiarygodne i konkretniejsze niż „poprawiłem wydajność”. Lepszy uczciwy rząd wielkości niż ładnie brzmiąca liczba, której nie obronisz przy benchmarku na rozmowie.