STX Next: 5 pytań do Senior Developera

15 min read

HR
None

Mając za sobą 5, 6, a niekiedy i 10 lat doświadczenia wraz z długą-długą listą języków programowania, technologii, frameworków i tooli, kwestia dalszego rozwoju i przyszłych awansów nabiera zupełnie innego znaczenia. Wraz z doświadczeniem zmieniają się wymagania dotyczące projektów, pracodawcy oraz dodatkowych obowiązków w zespole. Nadchodzi taki moment, kiedy samo programowanie już nie wystarcza i chce się robić coś poza tym. 

W tworzeniu dzisiejszego wpisu wzięli udział nasi doświadczeni programiści, którzy przedstawili swoją perspektywę i definicję ‘Senior Developera’. Serdecznie zapraszamy do lektury i bardzo dziękujemy Pawłowi, Sebastianowi, Patrykowi, Krystianowi, Piotrowi oraz Mikołajowi za podzielenie się opinią, swoją historią oraz doświadczeniem. 


arif-riyanto-1DRq1ZsE2N0-unsplash.jpg

Oleksandra Chernyak: Nikt nie staje się Senior Developerem w dwa dni - idzie za tym długa droga pełna warsztatów programistycznych, nauki, niezliczonych code review i popełnionych błędów. Jak wyglądała Twoja droga do bycia starszym programistą? Kiedy przychodzi ten moment, kiedy jest się Seniorem?

Osobiście uważam, że miałem bardzo dużo szczęścia wybierając swoją pierwszą pracę z dostępnych ofert - trafiłem do małej firmy, w której zagęszczenie pasjonatów na metr kwadratowy było dość spore. Niewiele wtedy wiedziałem o programowaniu, a co dopiero o projektowaniu systemów IT i pamiętam, że wracając do domu głowa mi zawsze pulsowała od nadmiaru wiedzy.

Trwało to prawie rok i w tym czasie dowiedziałem się kilka istotnych prawd o IT, które pozostały ze mną do dzisiaj, np. „nie chodzi o to, aby dogonić króliczka, tylko o to, aby go gonić” z dopowiedzeniem że „zawsze będziesz do tyłu, dziennie pojawia się tego więcej niż jesteś w stanie ogarnąć” lub takie powiedzenie, które często jest mylnie przypisywane Charlesowi Bukowskiemu - „Pokochaj coś i daj się temu zabić”, co tak naprawdę obrazuje, że jest to bardziej sposób na życie, a nie na zarobek.

A kiedy przychodzi ten moment? Możliwe, że to jest ten moment w którym bierzesz odpowiedzialność za coś więcej niż kawałek kodu i ciągle myślisz o tym jak można coś ulepszyć, jakie problemy może wygenerować dane rozwiązanie, a które jest lepsze pod kątem konkretnych wymagań (czas/jakość/niezawodność).


Do tematu zostania Seniorem w środowisku IT istnieje sporo różnych podejść. Osobiście za bardzo trafne uważam to stosowane w STX-ie. Ta definicja mówi, że Senior Developer to osoba, która jest w stanie samodzielnie projektować systemy, "rozkręcać projekty" i być liderem technologicznym dla całego zespołu. 

Żeby zostać Seniorem potrzebne są zarówno szerokie umiejętności techniczne, znajomość wykorzystywanej technologii, jak i kompetencje miękkie. Niezbędne jest również praktyczne doświadczenie, które można zdobyć jedynie biorąc udział w różnego rodzaju projektach i pracując w różnych zespołach. 

Sądzę, że bardzo ważne jest, aby do każdego doświadczenia podchodzić świadomie i analizować co w danej sytuacji poszło dobrze, a co można by było poprawić. Moja droga wyglądała właśnie w ten sposób. Poznawałem nowe technologie i walczyłem z błędami. Starałem się zrozumieć jak działa dane rozwiązanie oraz dlaczego w ten właśnie sposób. Brałem udział w wielu projektach, współpracowałem z różnymi zespołami i klientami, coraz pewniej podejmowałem kolejne decyzje. Mnóstwo z nich było błędnych albo co najwyżej umiarkowanie poprawnych, jednak widząc efekty poprzednich mogłem wyciągnąć wnioski na przyszłość.


Do mojego rozwoju i wejścia w rolę seniora przyczynił się projekt i jego dynamika. Choć nie miałem jeszcze wtedy ogromnego doświadczenia, przypadło mi zadanie opanowania większej części realizowanego projektu (oczywiście ze wsparciem) wraz z dodatkowymi zagadnieniami tj. deployment na produkcję czy analiza występujących tam błędów. 

Dziś uważam, że seniority opiera się na trzech filarach: wiedzy technicznej, mentorowaniu innych oraz doświadczeniu produkcyjnym i wynikającą z tego odpowiedzialnością. 

W przypadku wiedzy technicznej, mówimy o różnych językach, wzorcach, paradygmatach programowania czy architekturze. Drugi filar, czyli mentorowanie, nierozerwalnie łączy się ze wspieraniem innych i pomaganiem im w rozwoju. Z kolei doświadczenie produkcyjne zamyka całą pętlę zwrotną w uczeniu się, czy nasze rozwiązania w ogóle działają "w prawdziwym świecie", a może tylko dobrze wyglądają na tablicy. Senior, tak samo jak Junior i Regular, cały czas rozwija swoją wiedzę i nie musi umieć wszystkiego od samego początku - do STX-a dołączyłem bez większego doświadczenia w mentorowaniu i dopiero tutaj doskonaliłem tę umiejętność, m.in. odpowiadając za zespół.


Seniorem jesteś, kiedy rozumiesz kontekst i zdajesz sobie sprawę, że odpowiedź “to zależy” jest często jedyną słuszną. Rozumiesz nie tylko swoje poletko (kawałek kodu, nad którym aktualnie pracujesz), ale również szerszy obraz i masz dość wiedzy, by proponować, argumentować i wdrażać rozwiązania architektoniczne i procesowe. Jednocześnie zdajesz sobie sprawę, że jest wiele rzeczy, których nie wiesz i ciągle zdobywasz nową wiedzę. 

Do głębszego zainteresowania tematami takimi jak agile, architektura, programowanie funkcyjne czy DevOps napędzały (i nadal napędzają) mnie przede wszystkim napotykane problemy. Nie lubię się stresować i wiedziałem, że - jakby to ujął Raymond Hettinger - there must be a better way! Cały czas szukam coraz lepszych sposobów, żeby przesuwać stosunek radości do stresu w tę lepszą stronę i wydaje mi się, że to całkiem niezły sposób na zostanie Seniorem i dalszy rozwój.


emile-perron-xrVDYZRGdw4-unsplash.jpg

O.C.: Mając za sobą 5, 6, a niekiedy i 10 lat doświadczenia wraz z długą-długą listą języków, technologii, frameworków i tooli, kwestia dalszego rozwoju i przyszłych awansów nabiera zupełnie innego znaczenia. W jaki sposób podtrzymujesz obraną przez Ciebie ścieżkę rozwoju?

Powiedzmy sobie szczerze - w IT dzieje się tak dużo, że nie da się nadążać za wszystkim. Języki programowania i frameworki dynamicznie się zmieniają i jedynie pracując z nimi na co dzień można dotrzymać im kroku. Na pewno warto poznawać rzeczy ponadczasowe tj. inżynieria oprogramowania. Wiedzę można czerpać z książek, rozpraw naukowych, podcastów czy kursów wideo. Czasami najwydajniejszym sposobem nadrobienia konkretnej wiedzy jest udanie się na szkolenie specjalistyczne. W STX-ie takie decyzje ułatwia roczny budżet szkoleniowy, którym dysponują wszyscy współpracownicy. Osobiście miałem okazję uczestniczyć w szkoleniach z AWS i Elasticsearch.


Od kiedy zacząłem pracę w STX-ie staram się wykorzystywać możliwości, jakie oferuje mi budżet szkoleniowy. Przykładowo, w ciągu roku mogę zrobić kilka kursów online z interesujących mnie tematów (np. Udemy), wziąć udział w konferencjach tematycznych lub otrzymać zwrot kosztów certyfikatu, oprogramowania/usługi wykorzystanej do nauki czy pracy. Osobiście bardzo cenię ludzi starających się cały czas podnosić swoje kompetencje i, odpowiednio, staram się być jedną z nich. 


Kierunków rozwoju jest mnóstwo i wybór konkretnej ścieżki, bez wątpienia, jest związany z naszymi indywidualnymi predyspozycjami. Można wybrać ścieżkę ekspercką i zostać tzw. ninja w danej technologii. Można poznać dość dużo rozwiązań i działać uniwersalnie. Można też doskonalić się w projektowaniu systemów, efektywnej współpracy w zespole, mentorowaniu innych i komunikacji z biznesem. Moje podejście wygląda mniej więcej tak: obmyślam długofalową wizję, dzielę ją na krótkoterminowe cele, które następnie dzielę na jeszcze mniejsze kroki. Kiedy zaczynam je zrealizować, nie zapominam o analizie i ewentualnie „poprawiam kierunek” (cele zawsze mogą się zmienić :)).

Swój rozwój staram się budować na dobrej jakości wiedzy teoretycznej połączonej z doświadczeniem praktycznym i głębokim zrozumieniem tematu. W zdobyciu tej pierwszej z pewnością pomaga mi dostępny budżet szkoleniowy, a doświadczenie praktyczne to praca w konkretnym projekcie. Dzięki dużej różnorodności klientów oraz często bardzo szerokiej swobodzie technologicznej zespołu jest to jak najbardziej możliwe.

W głębokim zrozumieniu tematu pomaga mi zazwyczaj wyjaśnienie go innym. STX organizuje bardzo dużo wydarzeń (np. serie Has Powerów, wewnętrzne warsztaty, Craftowe Czwartki, comiesięczne Lightning Talki czy Agile Community of Practice) pozwalających nie tylko dowiedzieć się czegoś od innych, ale i samemu podzielić się wiedzą z kolegami i koleżankami.


Jednym z większych problemów jaki napotkałem przez lata jest… klęska urodzaju. Książek, blogów i prezentacji o programowaniu jest bardzo dużo, a przeczytanie wszystkiego co pojawia się w Internecie oraz na półkach w księgarniach jest raczej niemożliwe i jeszcze bardziej utrudnia wybór konkretnych pozycji.

Osobiście korzystam z poleceń znajomych oraz sprawdzonych i znanych już nazwisk, które są dla mnie znakiem jakości. Kevlin Henney, Jez Humble, Greg Young, Raymond Hettinger - jeśli nazwisko któregoś z nich pojawia się na agendzie konferencji lub na okładce książki to wiem, że warto się tym zainteresować. 

Przy okazji tego pytania, chcę również wspomnieć o jednym z powodów, dla których dołączyłem do STX-a - wiedziałem, że niezależnie od poziomu moich kompetencji będę miał od kogo się uczyć.


Nie skupiam się na jednej ścieżce rozwoju. Nakreślam przed sobą konkretne cele na następny rok i staram się je realizować. Zdaję sobie też sprawę z tego, że każdy etap rozwoju oraz każda wykorzystana okazja zmienia nasze doświadczenie i wewnętrzne pojęcie na temat naszych możliwości. Staram się być proaktywnym, z uśmiechem przyjmować każdą nadarzającą się okazję i próbować wszystkiego: miałem okazję pracować na back-endzie, front-endzie, być Scrum Masterem, Product Ownerem, liderem zespołów oraz brać udział w rekrutacjach, rozmowach sprzedażowych i wycenach nowych projektów. Ostatecznie dopiero po 5 latach nabrałem pewności i zrozumiałem, gdzie jest meta mojej ścieżki (jednak nieobiecuje, że i ona nie ulegnie zmianie ;))


annie-spratt-QckxruozjRg-unsplash.jpg

O.C.: Rynek IT rozwija się, a właściwie pędzi i się zmienia w błyskawicznym tempie. Lokalne meetupy, specjalistyczne warsztaty, światowe konferencje - na brak branżowych eventów nie ma co narzekać. Jaki jest, według Ciebie, idealny przepis na dzielenie się wiedzą i jak rozwinąć w sobie umiejętności przekazywania wiedzy innym?

Przede wszystkim warto próbować. Prowadzenie warsztatów i występowanie publiczne to umiejętność, której możemy się nauczyć. Doskonałą okazją do sprawdzenia się może być udział w jednej z wewnętrznych STX-owych inicjatyw (np. Lightning Talki, wewnętrzny Has Power) lub zorganizowanie próby generalnej w gronie zespołu. W STX-ie możemy skorzystać z pomocy w przygotowaniu prezentacji na konferencję czy też lokalne wydarzenie oraz wystąpić w roli firmowego prelegenta. W październiku, w takiej właśnie roli, można mnie spotkać na konferencji PyCode. :)

Dzieląc się wiedzą z innymi tworzymy relację win-win. Przekazujemy nasze doświadczenia dalej, pozwalamy innym szybciej rozwiązać pewne problemy, nie popełnić tych samych błędów i bardziej świadomie iść swoją drogą. Z drugiej strony ucząc innych sami pogłębiamy i utrwalamy naszą wiedzę. Dla mnie każde wystąpienie to niesamowity zastrzyk energii i motywacji do dalszej pracy i bardzo się cieszę, że mogę się w tym obszarze realizować.


  • Paweł Kunat, Senior Full-Stack Developer we wrocławskim STX Next: 

Do wystąpień publicznych zwykle potrzebuję powera i lubię robić to z kimś w parze, aby wspólnie posiedzieć i pogłówkować nad agendą i planem warsztatów czy prelekcji. Swoją wiedzę najczęściej przekazuję za pośrednictwem code review, ale zdarzało mi się też usiąść z kimś i wyjaśnić kilka kwestii technicznych osobiście zamiast pisania 30 komentarzy. Wszystko zależy od zespołu oraz poziomu osób z jakimi współpracuję.


Jest fajny cytat z Richarda Feynmana, który staram się zawsze pamiętać: "Pierwsza zasada brzmi, że nie wolno wam oszukiwać siebie samych - a osoba, którą najłatwiej wam będzie oszukać, jesteście właśnie wy sami." Chodzi o to, aby stale wystawiać swoją wiedzę na próbę. Dobrym sposobem na to jest zarówno uczestnictwo w warsztatach czy prelekcjach, jak i prowadzenie ich.

Uczestnicząc w warsztatach mamy szansę nie tylko nauczyć się czegoś nowego, ale też skonfrontować swoje myślenie z cudzym mózgiem, który może mieć na dany temat drastycznie inne zdanie. Wynikający z tego dysonans poznawczy powinien motywować nas do zadawania pytań, a później zgłębiania tematu we własnym zakresie.


austin-distel-wD1LRb9OeEo-unsplash.jpg

O.C.: Lata doświadczenia w programowaniu i spory bagaż dowiezionych projektów daje w pewnym momencie możliwość użycia tej (już mocno eksperckiej i specjalistycznej) wiedzy przy projektowaniu nowych rozwiązań, rozmowach z potencjalnymi klientami oraz przygotowaniu estymacji związanych z nowym projektem. Na czym dokładnie polega udział w tego typu procesach?

Rozmowy z potencjalnymi klientami mają na celu odpowiedzenie na jedno, zasadnicze pytanie - czy możemy razem robić interesy? Zasadniczą częścią całego procesu jest zdobycie wiedzy na temat tego, co klient chce zbudować. W tym celu przeprowadzamy przeróżne warsztaty i budujemy wstępną roadmapę czy listę historyjek użytkownika. Z punktu widzenia przygotowania wyceny, zastanawiamy się nad poszczególnymi punktami wymagań i szacujemy, jak czasochłonne będzie wykonanie danego projektu. 

W tego typu rozmowach klient szuka przede wszystkim ekspertyzy technicznej i doradztwa, a naszą rolą jest pokazanie klientowi, że możemy mu w czymś pomóc.


Udział w tego typu procesach można podzielić na kilka obszarów. Najwcześniejszym z nich jest zaangażowanie w początkowe rozmowy z potencjalnym klientem i działanie w roli konsultanta technicznego. Wykorzystując swoje doświadczenie z reguły możemy szybko rozwiać wątpliwości i zasugerować optymalny kierunek dalszych rozważań. 

Kolejnym etapem jest udział w tzw. discovery workshop - warsztatach, podczas których wspólnie z klientem analizujemy wymagania biznesowe, projektujemy podstawy rozwiązania technicznego, poznajemy cele, ograniczenia i główne „drivery” architektoniczne. Na tej podstawie proponujemy i omawiamy różne rozwiązania postawionych problemów. 

Mamy również wpływ na ogólny stack technologiczny i koncept infrastruktury. W takim procesie udział biorą nie tylko doświadczeni programiści, ale również osoby z działu sprzedaży, PO, managerowie, Product Design oraz DevOps. Nadając ogólny kierunek projektowi mamy wpływ na wiele decyzji i występujemy w roli partnera technicznego, co daje nam zarówno swobodę wyboru, jak i dużą odpowiedzialność związaną z oczekiwaniem zbudowania jak najlepszego rozwiązania.


Kluczowym zadaniem tego procesu jest zrozumienie problemu z jakim przychodzi do nas klient oraz zebranie jak największej ilości danych wejściowych, na podstawie których będziemy w stanie zaproponować konkretne rozwiązanie. Wymyślenie całości i wybór technologii do realizacji projektu jest bardzo pasjonującą dla mnie sprawą! Bez wątpienia, odpowiedzialność jest ogromna, ale satysfakcja wynikająca z procesu, kiedy wyobraźnia staje się rzeczywistością, jest równie wielka.


Każdy nowy projekt to zupełnie inna przygoda. Aby móc uczestniczyć w rozmowach sprzedażowych musimy wyrazić chęć i gotowość na udział w takich inicjatywach. Najprościej można to zrobić zgłaszając się do przełożonego.

Cały proces zaczyna się od wdrożenia oraz zapoznania się z dokumentacją projektu lub problemu, jaki musimy rozwiązać. Czasem jest to briefing liczący kilka stron i wyjaśniający biznes/potrzeby klienta, a czasem mamy do czynienia z pełną dokumentacją techniczną. Wszystko zależy od skali projektu i poziomu zaawansowania rozmów. Po zapoznaniu się z dostarczonymi materiałami organizujemy spotkanie z klientem, którego celem jest uzyskanie odpowiedzi na wszystkie dodatkowe pytania. Jest to bardzo ważny etap procesu, kiedy to po raz pierwszy przedstawiamy naszą wizję produktu. Poza tym tego typu spotkania pomagają szybko zweryfikować czy nasze wstępne założenia były poprawne.

Kiedy ustalimy finalne rozwiązanie oraz zasoby zabieramy się do rozpisywania poszczególnych zadań (rozbijamy większe zadania na mniejsze). Na tym etapie bardzo cenne jest doświadczenie zdobyte w poprzednich projektach, ponieważ pomaga nam przygotować realną estymatę przyszłych zadań i konkretnych sprintów.


Trafiłem do tego tematu dość organicznie. W poprzedniej firmie zahaczyłem o stanowisko Tech Lead i pewnego dnia dostałem propozycję spróbowania swoich sił w estymacji projektu pod okiem doświadczonego Product Ownera. Trudno było nie skorzystać z takiej okazji. 

To jest jedna z fajniejszych rzeczy w STX-ie - nieograniczone możliwości i obszary, w które można się zaangażować. Wyzwania zawsze motywowały mnie do dalszego rozwoju. A jak to wygląda? Różnie. Niektóre estymacje ograniczają się do zapoznania z dokumentami dostarczonymi przez klienta. Innym razem temat potrafi ciągnąć się dłużej z powodu złożoności problemu.

Jednym z fajniejszych doświadczeń dla mnie była konfrontacja naszego sposobu działania (czysta architektura, TDD, nastawienie na zwinność) z negatywnymi doświadczeniami potencjalnego klienta wynikających z wcześniejszych projektów. Takie sytuacje wymagają bardzo dobrego rozumienia praktyk i stwarzają wyzwania na warstwie technicznej (dodatkowo dają możliwość sprawdzenia swoich soft skills i znajomości języka angielskiego).


helloquence-5fNmWej4tAA-unsplash.jpg

O.C.: Jesteś częścią zespołu Tech Recruitment w STX Next - przeprowadzasz weryfikacje techniczne, przygotowujesz szczegółowy feedback, wystawiasz finalną ocenę techniczną i w wyniku decydujesz o zatrudnieniu kandydatów. Jak wyglądał Twój proces zostania rekruterem technicznym w STX-ie? 

  • Paweł Kunat, Senior Full-Stack Developer we wrocławskim STX Next: 

Doświadczenie rekruterskie zdobyłem jeszcze w poprzedniej firmie, a w STX-ie sam zgłosiłem się do roli rekrutera technicznego. Po krótkim wprowadzeniu i kilku rozmowach zostałem samodzielnym rekruterem. Najtrudniejszą częścią procesu rekrutacji jest dla mnie pisanie notatki i rekomendacji. Mimo to sam proces sprawia mi przyjemność i planuję rozwijać się w tym kierunku dalej.


Pewnego dnia otrzymałem propozycję dołączenia do zespołu rekruterów technicznych. Zanim podjąłem decyzję miałem okazję spotkać się z dziewczynami z Rekrutacji, które wprowadziły mnie w cały proces i odpowiedziały na wszystkie nurtujące mnie pytania.

Następnym krokiem był udział w kilku rekrutacjach technicznych najpierw w roli słuchacza, a później w roli osoby współprowadzącej rozmowę. Każda rozmowa odbywała się z innym rekruterem, co dało mi możliwość obserwacji różnych stylów. Po każdym spotkaniu wspólnie omawialiśmy zarówno pytania prowadzącego, jak i odpowiedzi oraz zachowanie kandydata. Gdy uznałem, że jestem gotów do prowadzenia rekrutacji, poprowadziłem pierwsze trzy spotkania pod okiem bardziej doświadczonych rekruterów i finalnie zostałem członkiem załogi technicznych rekruterów STX Next. 

Nasz zespół rekrutacyjny budują świetni i doświadczeni ludzie, z którymi współpraca to sama przyjemność, dlatego kiedy w naszym oddziale pojawiła się informacja o budowaniu zespołu rekruterów technicznych od razu się do niego zgłosiłem :) Dzięki wcześniejszym doświadczeniom związanym z budowaniem zespołów wiedziałem jak ważny, rozwijający i dający mnóstwo satysfakcji jest to proces. Zanim zacząłem samodzielnie prowadzić rozmowy techniczne przeszedłem wewnętrzne szkolenie i brałem udział w rekrutacji jako osoba wspomagająca.

W weryfikacji technicznej kluczowe jest zadanie odpowiednich pytań tak, abyśmy byli w stanie ocenić kompetencje techniczne kandydatki lub kandydata oraz przygotować szczegółowy feedback. Bardzo ważne jest również to, aby informacja ta była wartościowa dla osoby rekrutowanej, niezależnie od wyniku rozmowy. W dokonaniu samej oceny mocno pomaga nam STX-owa macierz kompetencji i podejście polegające na wyznaczaniu dwóch parametrów – poziomu Seniority oraz Versatility. Możliwość przedyskutowania różnych podejść i sytuacji w ramach zespołu technicznego pozwala nam stale się rozwijać i prowadzić rozmowy w profesjonalny sposób.

Praca rekrutera technicznego wiążę się nierozerwalnie z trudnymi dylematami, jednak radość i satysfakcja z jakże widocznych jej efektów jest, według mnie, bezcenna :)

 

Author

Oleksandra Chernyak

Recruitment & Employer Branding Specialist

More articles about HR