Zmiana stacku w IT (PHP→Node, .NET→Go): jak przepisać CV i projekty
Zmiana stacku to nie restart kariery. Co przenosi się między technologiami i jak przeramować projekty pod nową rolę, bez udawania doświadczenia.

Większość poradników o przebranżowieniu mówi o wejściu do IT spoza branży. To inny temat. Tu chodzi o zmianę w środku: jesteś senior developerem PHP i chcesz robić w Node. Piszesz w .NET, a ciągnie cię Go. Masz lata doświadczenia, tylko w innym stacku niż ten z oferty.
Dobra wiadomość: nie zaczynasz od zera. Twoje projekty już zawierają to, czego nowa rola szuka, tylko opowiedziane językiem starego stacku. Robota polega na przepisaniu, nie na udawaniu, że jesteś juniorem w nowej technologii. Poniżej jak to zrobić.
Co przenosi się między stackami 1:1
Składnia się zmienia, inżynieria nie. Większość tego, co czyni cię seniorem, jest niezależna od języka:
- Architektura: projektowanie systemów, podział na usługi, wzorce, kompromisy. To samo w PHP i w Go.
- Praca z danymi: bazy, zapytania, modelowanie, wydajność. SQL nie pyta o twój główny język.
- Testy i jakość: myślenie o testach, CI/CD, code review.
- Debugowanie i produkcja: czytanie logów, profilowanie, ogarnianie incydentów.
- Domena: jeśli znasz e-commerce albo fintech, ta wiedza zostaje, gdy zmieniasz stack.
To są rzeczy, które wpisze się w CV na pierwszym planie przy zmianie stacku. Nowy język jest do douczenia, doświadczenie inżynierskie nie.

Jak przeramować projekt z jednego stacku na drugi
Weźmy senior developera PHP, który celuje w Node i TypeScript. Ten sam projekt, dwa opisy:
Wersja PHP (oryginalna): Zbudował API zamówień w Laravel z kolejką na Redis i integracją płatności.Wersja pod Node (przeramowana): Zaprojektował i wdrożył API zamówień z asynchroniczną kolejką i integracją płatności, architektura przeniesiona później na Node. Wzorce (kolejki, idempotencja, obsługa błędów płatności) niezależne od języka.
Druga wersja nie udaje, że projekt był w Node. Eksponuje wzorce i decyzje, które przenoszą się na nowy stack, i jest uczciwa co do tego, gdzie powstał. Tę samą mechanikę przesuwania akcentu rozkładamy szerzej w jeden projekt, cztery role.

Czego nie robić
- Nie udawaj komercyjnego doświadczenia w nowym stacku, którego nie masz. Jeśli twój Node to dwa pet-projekty, tak to pokaż. Rozmowa techniczna szybko zweryfikuje resztę.
- Nie chowaj starego stacku. Twoje lata w PHP to atut (znasz produkcję), nie wstyd. Pokazujesz je jako fundament, na którym uczysz się nowego.
- Nie pisz, że „znasz wszystko". Senior, który uczciwie mówi, gdzie jest mocny, a gdzie się douczą, jest wiarygodniejszy niż ktoś z dwudziestoma technologiami na liście.
Jak pokazać pet-projekt w nowym stacku
Jeśli komercyjnie nie robiłeś jeszcze w nowym stacku, pet-projekt jest twoim dowodem. Opisz go jak pracę: problem, co zbudowałeś, czego się nauczyłeś. „Przepisał własny serwis na Node i TypeScript, żeby poznać ekosystem, z testami i CI" to uczciwy, mocny sygnał. Pokazuje inicjatywę i realny kontakt z technologią.
Jak złożyć takie CV pod ofertę
ZłóżCV trzyma twoje projekty jako stałą bazę i przepisuje ich opisy pod personę docelowej roli. Przy zmianie stacku to oznacza, że ten sam projekt pokażesz w języku oferty, na którą aplikujesz, eksponując przenośne wzorce zamiast starej składni. Wklejasz ofertę z nowym stackiem, dostajesz CV ustawione pod nią. Złóż CV pod nową rolę, dwa pierwsze za darmo bez karty. Punkt wyjścia, jak czytać ofertę, masz w jak dopasować CV do oferty.
Najczęstsze pytania
Czy przyznawać wprost, że to dla mnie nowy stack? Tak. Uczciwość buduje wiarygodność, a rozmowa techniczna i tak to ujawni. Pokaż przenośne doświadczenie i realny, choćby własny, kontakt z nowym stackiem.
Ile pet-projektów wystarczy? Jeden albo dwa skończone i dobrze opisane wystarczą jako dowód kontaktu z technologią. Lepiej dwa mocne niż pięć porzuconych po README.
Czy zmiana stacku obniża moją senioralność? Nie powinna, jeśli dobrze pokażesz przenośne doświadczenie. Jesteś seniorem w inżynierii, który uczy się nowego narzędzia, nie juniorem od zera. CV ma to komunikować od pierwszego akapitu.
Czy wpisywać stary stack na równi z nowym? Stary stack pokaż jako fundament i kontekst doświadczenia, nowy jako kierunek. Pod ofertę w nowym stacku to on jest na pierwszym planie, stary podpiera wiarygodność.