[Ksiega_dusz]

🐶 Nowy artykuł dla programistów i nie tylko 🐶

👉 „Presja w Sprintach” – czyli jak programista może wyczuć toksyczną kulturę pracy już na etapie rekrutacji

Wielu programistów Java wybierając nową firmę kieruje się głównie stawką. Widełki robią wrażenie, a dodatkowy bonus za podpisanie umowy tylko przyspiesza decyzję. Jednak po kilku latach w branży coraz więcej osób zaczyna mówić: „Wolę zarobić mniej i pracować normalnie niż znowu zmieniać firmę po roku z powodu psychicznego dojechania.” Bo co z tego, że zarobisz 20 czy 30 procent więcej, skoro po kilku sprintach jesteś już wypalony, a w planowaniu kolejnego bierzesz udział z nerwowym tikiem? Wartości takie jak stabilność, kultura techniczna i szacunek do czasu dewelopera zaczynają przeważać nad cyferkami w ofercie.

Dlatego ten poradnik kierujemy do Java developerów, którzy chcą podejść do rozmów rekrutacyjnych świadomie – i potrafić odróżnić zdrowy zespół od miejsca, gdzie sprinty oznaczają wieczny pośpiech, wrzutki i presję na dowożenie za wszelką cenę. Oto, na co zwracać uwagę i jakich pytań użyć, by nie skończyć w kolejnej firmie z permanentnym poniedziałkiem.

1. Zapytaj o typowy dzień pracy. Dobra firma będzie potrafiła opowiedzieć konkretnie: jak wygląda stand-up, kiedy są spotkania, jak planują czas na głęboką pracę. Jeśli odpowiedź brzmi: „No wiesz, jak to w IT – trochę spotkań, trochę kodu” albo „Jest dynamicznie” – to często oznacza chaos i brak struktury. Szukaj zespołów, które mają jasno określony rytm dnia.

2. Zapytaj wprost, czy zakres sprintu się zmienia po jego rozpoczęciu. Jeśli słyszysz „czasem coś dorzucimy, jak klient bardzo chce” albo „trzeba być elastycznym”, to prawdopodobnie scope creep jest na porządku dziennym. Dobrze zorganizowany zespół potrafi bronić sprintu przed wrzutkami i planuje zmiany na kolejne iteracje.

3. Zapytaj, jak wygląda współpraca z Product Ownerem i Scrum Masterem. Jeśli PO jest decyzyjny, słucha zespołu i nie wrzuca zadań bez dyskusji, to dobry znak. Jeśli Scrum Master pomaga zespołowi rozwiązywać problemy, a nie tylko pilnuje Jiry – jeszcze lepiej. Gorzej, gdy słyszysz: „PO mocno ciśnie, ale wie czego chce” albo „Scrum Master pilnuje, żebyśmy mieli velocity”.

4. Zapytaj o podejście do błędów i jakości. Powiedz: „Co się dzieje, jeśli feature nie działa? Czy techniczne długi są spłacane?” Jeśli odpowiedź to: „Zawsze dowozimy, jakoś się spina” lub „Refaktory robimy, jak jest luz” – to znak, że jakość nie jest priorytetem, a Ty będziesz łatał prowizorkę po godzinach.

5. Zapytaj o dyżury on-call i support. Jeśli firma pracuje z systemami produkcyjnymi, warto wiedzieć, czy wsparcie jest rotacyjne, czy płatne i czy naprawdę „zdarza się rzadko”. Niedopowiedziane obowiązki po godzinach mogą szybko zamienić się w stały, niepłatny obowiązek.

6. Przejrzyj ogłoszenie i stronę firmy pod kątem kultury technicznej. Czy opisują, jak wygląda ich proces developmentu? Czy są wzmianki o zespołach, współpracy, mentoringu? Czy tylko stack technologiczny i wymagania? Brak opisu kultury to często brak kultury w praktyce.

7. Sprawdź opinie pracowników. Zajrzyj na GoWork, Glassdoor, JustJoinIT. Nie chodzi o to, by wierzyć każdej opinii, ale jeśli widzisz powtarzające się uwagi o chaosie, presji, pożarach – to coś znaczy. Możesz też napisać bezpośrednio do kogoś z zespołu na LinkedIn i zapytać, jak naprawdę wygląda praca. Większość osób chętnie odpowiada.

8. Jeśli jesteś Java developerem, szczególnie zwróć uwagę na typ firmy. Duże enterprise’y często oznaczają procesy, Excela, „dowiezienie wymagania biznesowego”, a nie jakość kodu. Jeśli zależy Ci na dobrym warsztacie i spokojnym flow, celuj w firmy produktowe, fintechy z Europy Północnej lub software house’y prowadzone przez programistów, a nie przez ex-konsultantów.

9. Obserwuj język, jakim posługują się rekruterzy i managerowie. Jeśli słyszysz: „u nas się dowozi”, „potrafimy przycisnąć jak trzeba”, „szukamy kogoś twardego” – potraktuj to jak ostrzeżenie. Może być tak, że firma nie szuka programisty, tylko mięsa armatniego do kodowania pod presją.

10. Nie bój się zapytać o fluktuację zespołu. Możesz to ubrać w delikatne pytanie: „Czy zespół jest stabilny, czy ostatnio były zmiany?” Jeśli ktoś mówi: „mieliśmy ostatnio sporo rotacji, ale już jest lepiej” – to też coś mówi.

11. Zadaj pytanie o feedback i rozwój. W zdrowym zespole będzie miejsce na code review, czas na szlifowanie warsztatu, mentoring i przeglądy techniczne. W firmach nastawionych wyłącznie na dowiezienie – jedynym feedbackiem będzie commit „fix prod hotfix urgent”.

I najważniejsze: słuchaj swojego ciała. Jeśli po rozmowie czujesz dyskomfort, zmęczenie, lekkie „coś tu nie gra” – nie ignoruj tego. Intuicja programisty to też narzędzie.

#pracait #programowanie #programista15k #programista25k #java #korposwiat #agh #studbaza #politechnikapoznanska #politechnikalodzka #politechnikakrakowska #pracbaza

[Enso_]

@Ksiega_dusz coś w tym jest niestety albo stety.

[Ksiega_dusz]

@Enso_:
gdyby nie było w tym "coś" to ten mem by nie powstał, ja to czuję że tak jest, stąd zrobiłem ten mem. pracuję w IT już 8 lat

[ByczekRozplodowy]

@Ksiega_dusz: Jaki bonus za podpisanie, o czym ty człowieku p--------z w 2025 roku? Poza tym był tu już ostatnio senior Java Developer. W poście na Linkedin napisał, że lubi pracować w nocy i tyrać po nockach plus łapać ślinę zębami jak jest. Najważniejsze godnie zarobić, a nie godnie pracować. Co do reszty to sama prawda, aż przyjemnie się czyta.

[Ksiega_dusz]

@ByczekRozplodowy: dzieki