poniedziałek, 17 października 2016

Jak sprawdzić, czy firma zapewnia rozwój zawodowy programiście (cz. 2)

Dobra, pofilozofowaliśmy już, co może oznaczać rozwój zawodowy. Teraz konkrety: jak w trakcie bycia rekrutowanym do jakiejś firmy (a nawet wcześniej) sprawdzić, czy można w niej liczyć na - jakkolwiek zdefiniowany - rozwój zawodowy.

Zacząłbym od oczywistej i najprostszej rzeczy: poszukania, co na temat firmy piszą jej pracownicy - obecni, byli i niedoszli. Jest w internecie kilka miejsc, gdzie opinie nt. pracodawców pojawiają się częściej niż gdzie indziej, wyskakując zwykle na górze listy wyników google'owego wyszukiwania. Byłbym ostrożny z przywiązywaniem nadmiernej wagi do opinii zamieszczanych na oficjalnych profilach firm - te mogą być moderowane i trudno będzie tam o szczerość. Od jednego z takich miejsc regularnie otrzymuję w 7N oferty z możliwością wykupienia "rozszerzonego profilu" umożliwiającego "samodzielne zarządzanie kontem pracodawcy" i "ochronę wizerunku".

Wymagającym trochę większej pracy, ale dającym chyba lepszy wgląd w to, jak mogło się pracować w danej firmie, jest prześledzenie profili obecnych i byłych pracowników tej firmy, np. na LinkedIn. Można zbadać w ten sposób choćby orientacyjny poziom rotacji w firmie (czyli to, jak często pracownicy z niej odchodzą) - im większa, tym na ogół gorzej rokuje to dla naszych szans na długą i satysfakcjonującą pracę tam.

Dla programisty zerknięcie na profile potencjalnych kolegów programistów z firmy, do której być może dołączy, to także dobry sposób na rozeznanie się na temat technologii, z jakimi może mieć do czynienia. Ale nie tylko to. Jeśli istotną w rozwoju zawodowym dla kogoś kwestią jest praca z dobrymi (albo przynajmniej niedużo gorszymi od siebie) programistami, wgląd w profile zawodowe osób z danej firmy może sporo powiedzieć nt. tego, czego może czekać po przekroczeniu progu firmy. W jakich firmach i środowiskach pracowali wcześniej, w czym programowali, jakie kończyli uczelnie, jakie mają doświadczenie - te rzeczy w jakimś stopniu da się wyczytać z profili zawodowych w sieci.

Najważniejszym jednak wskaźnikiem tego, na co programista może liczyć w firmie, będzie spotkanie rekrutacyjne i w ogóle sam proces rekrutacji. Znam przypadek, w którym w jednej firmie zaproszono kandydata na dwa, mające odbyć się jedno po drugim spotkania - w tym samym pokoju, najpierw z HR, później z kimś technicznym (a może w odwrotnej kolejności - nieistotne). Przy czym pierwszy rekrutujący, po odbytej rozmowie, zapomniał poinformować drugiego rekrutującego, że kandydat już czeka. Zapomniał też przypomnieć samemu kandydatowi, że będzie jeszcze druga rozmowa. Ten więc po chwili oczekiwania po prostu poszedł do domu.

Nie skreśliłbym firmy tylko z tego powodu. Wpadka, zdarza się. Są jednak przypadki, gdzie sama długość procesu rekrutacji, liczba zaangażowanych w nią osób i stopień zbiurokratyzowania (spotykam czasami rekruterów z dużych firm, którzy zlecają umawianie spotkań specjalnym asystentom) może dać dobry przedsmak kultury firmy i tego, jak tam będzie się pracować. (Ciekawi mnie, jaki byłby rekord oczekiwania programisty na pełną gotowość środowiska pracy od dnia startu w firmie).

Najważniejsze będzie samo spotkanie. Sądzę, że doświadczony programista na podstawie zadawanych mu technicznych pytań jest w stanie wyrobić sobie zdanie na temat kompetencji odpytujących go osób. Z moich obserwacji źle wśród developerów widziane jest "kodowanie" na kartce (albo tablicy), nie przystaje ono bowiem do realiów codziennego (a więc wspartego środowiskiem developerskim) programowania. Różnie też postrzegane są zagadki logiczne, choć te da się wybronić intencją chęci zbadania samego sposobu podejścia do problemu czy toku myślenia kandydata, bez względu na poprawność rozwiązania zagadki.

Jest coś ewidentnie nie tak, jeśli programistę pozbawia się szansy rozmowy ze swoim potencjalnym przełożonym albo team leaderem w projekcie, do którego miałby dołączyć. Idealnie - i to dla obu stron: rekrutowanego i rekrutujących - gdy jest szansa porozmawiania także z potencjalnymi kolegami z zespołu. W końcu dobrze jest móc zobaczyć, z kim być może przyjdzie spędzić biurko w biurko najbliższy kawałek zawodowego życia. Naprawdę sporo można wywnioskować z tego, jak bardzo transparentna jest firma w odniesieniu do tego, kogo i co pozwala zobaczyć rekrutowanemu podczas rekrutacji.

Zawsze wydawało mi się, że osoby techniczne (potencjalni bezpośredni współpracownicy kandydata) są względnie szczerym i obiektywnym źródłem wiedzy na temat tego, co może czekać programistę w pracy. Tymczasem od jednego z uczestników konferencji dowiedziałem się, że w firmie, do której był rekrutowany, techniczni managerowie mają swoje (uwaga!) targety rekrutacyjne. Jasne jest więc, że podczas spotkania rekrutacyjnego mogą chcieć przedstawić rzeczywistość w firmie bardziej kolorowo niż to wygląda faktycznie. Nie pomoże zadanie mu pytania "czy mówi pan prawdę?", ale pomóc mogą takie pytania jak: "co dla pana jako team leadera zespołu programistów jest wyzwaniem w pracy w tej firmie?" albo "jakie były główne powody, dla których w przeszłości developerzy odchodzili z tej firmy?".

O co jeszcze warto spytać? Choćby o warunki pracy, o standardy wytwarzania oprogramowania, czyli o praktyki developerskie, o używane technologie (czy faktycznie są tak nowe, jak wynikało z opisu stanowiska?), o stosowane metodyki, o proporcje rozwój vs utrzymanie - czyli typowe, interesujące programistę rzeczy. Warto na relację rekrutowany-rekrutujący spojrzeć jak relację symetryczną, partnerską. Jeśli firma chce sprawdzić referencje u mojego byłego pracodawcy, dlaczego nie mógłbym porozmawiać np. z kimś, na kogo miejsce w firmie jestem rekrutowany? Jeśli pytają mnie na rozmowie o moje porażki zawodowe (projektowe), dlaczego nie powiedzą mi o swoich?

Z nową firmą trochę jak z małżeństwem. Na samym początku pewności sukcesu nigdy nie ma, wszystko wychodzi w praniu. Można jednak, co chciał pokazać powyższy wpis, kilkoma sposobami zwiększyć prawdopodobieństwo udanej "współpracy". Z firmą (w porównaniu z małżeństwem) o tyle nawet lepiej, że przynajmniej jest szansa tych byłych pracowników obiektywnie prześledzić ;)


_______

piątek, 7 października 2016

Jak sprawdzić, czy firma zapewnia rozwój zawodowy programiście (cz. 1)

Miałem niedawno okazję wystąpić w roli jednego z prelegentów na jubileuszowym, setnym spotkaniu Warszawskiej Grupy .NET. Mówiłem o tym, jak programista podczas procesu rekrutacji może sprawdzić, czy dana firma dobrze rokuje jako miejsce do rozwoju zawodowego. Nie chcąc, by wnioski z  chyba dość owocnej dyskusji ulotniły się, postanowiłem podsumować je tu: być może przydadzą się komuś, kto nie był na spotkaniu a kto być może znajdzie się niedługo w sytuacji, gdzie wnioski te będą mogły się przydać.

Moja prezentacjo-dyskusja była chyba jedyną nietechniczną tego wieczoru, dlatego miłym zaskoczeniem było, że "w konkurencji" ze stricte technicznymi tematami udało jej się zebrać całkiem pokaźne grono zainteresowanych. Wspólnie spróbowaliśmy najpierw ustalić, co może kryć się pod tyleż efektownie co nieprecyzyjnie brzmiącym pojęciem rozwój zawodowy. (Zawsze, gdy słyszę od kandydata, że powodem rozważania przez niego zmiany pracy jest chęć rozwoju zawodowego, dopytuję, co konkretnie ten rozwój dla niego oznacza).

Zgodziliśmy się, że rozwój zawodowy może oznaczać w zasadzie każdą z poniżej wymienionych rzeczy:

1) poznawanie nowych technologii
2) awans (np. na stanowisko team leaderskie)
3) uczestniczenie w nowych projektach (w tym także poznawanie nowych sektorów biznesu)
4) praca z lepszym merytorycznie zespołem
5) awans finansowy
6) praca w projektach o coraz lepszych metodykach i z coraz lepszymi standardami wytwarzania oprogramowania
7) praca w projektach międzynarodowych (i coraz lepsze kompetencje w j. angielskim)

Następnie może nieco autorytatywnie, ale chyba zgodnie z rzeczywistością - sądząc przynajmniej po reakcji uczestników - stwierdziłem, że bardzo mało jest firm, które zaoferują programiście wszystkie z siedmiu elementów rozwoju. Nie należy się też łudzić, że każde kolejne miejsce, do którego w toku swojej kariery trafi programista, będzie lepsze od poprzedniego pod względem wszystkich siedmiu kryteriów. 

Istotną więc rzeczą przed przystąpieniem do prześwietlenia firmy, do której aplikujemy, jest to, by dobrze zdefiniować, czym osobiście jest dla nas rozwój zawodowy. Trzeba rozważyć, jak rozkładają się nasze zawodowe priorytety, by mieć przynajmniej z grubsza określone znaczenie kryteriów, które decydować będą o "potencjale rozwojowym" danej firmy w trakcie bycia do niej rekrutowanym.

W różnych momentach kariery rozkład znaczenia poszczególnych składowych rozwoju może się zmieniać. Jednym z klasycznych dylematów, przed jakimi stanąć może - zwłaszcza młody i jeszcze względnie niedużo zarabiający - programista, jest (w skrócie): stare technologie i duże pieniądze vs nowe technologie i małe pieniądze. 

Jak rozstrzygnąć taki dylemat? Ktoś nade wszystko ceniący rozwój (tu rozumiany jako nowe technologie) mógłby pójść na nawet znaczny finansowy kompromis. Warto jednak pamiętać - a przypomnijmy, że w omawianym przykładzie mamy do czynienia z młodym i jeszcze względnie mało zarabiającym programistą - że krzywa wzrostu dochodów wraz z latami doświadczenia spłaszcza się.

źródło: evojam.com
Oznacza to, realnie rzecz biorąc, że na największy relatywny wzrost naszego wynagrodzenia możemy liczyć w pierwszych latach kariery. Później - co pokazuje statystyka - trudno o spektakularny progres. Najczęściej zarobki, jakie osiągniemy przed trzydziestką, są mocnym wyznacznikiem tego, jak finansowo będzie nam się układać dalej. Nasz przykładowy młody programista powinien zatem i to wziąć pod uwagę, jeśli znajdzie się w sytuacji dylematu "mieć czy rozwijać się".

Mając już omówione, czym dla programisty może być rozwój zawodowy i jak odnajdywać się w przykładowej sytuacji dylematu związanego z rozwojem, możemy przejść do meritum, czyli tego, jak podczas rekrutacji sprawdzić, czy firma dobrze roku pod kątem wspomnianego rozwoju.

Widzimy się po chwili na reklamę



_______