Japonki i 10 lat rekrutowania

Ustawienia komentarzy tu na blogu spowodowały, że dopiero dziś przeczytałem komentarz pod jednym z wpisów z września 2015 roku. Ponieważ staram się odpowiadać na wszystkie (wymagające odpowiedzi) komentarze, chciałbym wynagrodzić anonimowemu Czytelnikowi ponadroczne oczekiwanie na odpowiedź osobnym wpisem poświęconym jego dwóm pytaniom. Tym bardziej, że nawet gdybym odpowiedział mu bezpośrednio (pod jego komentarzem), pewnie i tak (jako niezalogowany czytelnik) nie zostałby powiadomiony o odpowiedzi.

(Jednocześnie, by uniknąć podobnych sytuacji w przyszłości i mieć pewność, że każdy komentarz przeczytam szybko, zmieniłem ustawienia tak, by być powiadamianym o każdym komentarzu, a nie, jak dotychczas, tylko o wybranych. Zapraszam więc do komentowania i ew. pytań).

Zapomniany Czytelnik zadał pytania takie:

1. Czy jeśli jest gorąco, np. 30 stopni, zero wiatru, generalnie taka pogoda jak w sierpniu tego roku i zamiast przyjść w garniturze wybrałbym jednak krótkie spodenki i koszulę z krótkim rękawem, to co byś o tym pomyślał (mi osobiście zdarzyło się przyjść w taki upał do pewnej firmy w krótkich spodenkach, t-shirt i japonkach i panowie którzy mnie rekrutowali zrobili duże oczy widząc japonki i wymienili porozumiewawczy uśmiech, a po 2 dniach od rozmowy chcieli mi zaproponować stanowisko team leadera)?

2. Programistom, którzy pracują przez 10 lat w jednym projekcie (wiem wiem, to musiałby być skrajny przypadek, ale czytaj dalej) mówi się, że nie mają 10 lat doświadczenia, tylko rok powtórzony 10 razy. Jak odniesiesz się do swoich 10 lat doświadczenia w pracy rekrutera IT - czy nie uważasz, że masz rok doświadczenia powtórzony 10 razy?

Odpowiadam:

1. Zależy, gdzie się idzie na rozmowę i na jakie aplikuje się stanowisko. Inne są oczekiwania w stosunku do kandydata wybierającego się na rozmowę do banku albo renomowanej firmy konsultingowej, a inne do niewielkiego, kilkuosobowego start-upu. Podobnie, inny strój odpowiedni będzie przy aplikowaniu na stanowisko project managera, a inny przy ubieganiu się o pracę na stanowisku programisty. (Dla pewności: w obu przypadkach mniejsze oczekiwania co do biznesowości stroju będą dla drugich z wymienionych opcji:) 

Jeśli stojąc rano przed szafą ma się dylemat i waha się pomiędzy strojem (być może) zbyt formalnym, a z drugiej strony (potencjalnie) zbyt luźnym, lepiej wybrać to pierwsze. Mniejszą bowiem niestosownością będzie, jeśli jako kandydat ubrani będziemy "lepiej" (tj. bardziej biznesowo) niż nasi rozmówcy niż gdyby miało być odwrotnie.

Dobrze jest spytać wprost tego, kto zaprasza nas na rozmowę, jaki jest dress code w firmie. Podpowie to nam, jak się ubrać, a jednocześnie być może powie coś generalnie o kulturze firmy. W przypadku stanowisk programistycznych chyba już nigdzie nie oczekuje się garnituru. Koszula wystarczy pewnie wszędzie.

Czy jako rekruter wybaczyłbym t-shirt? Tak. A japonki? Jeśli w skarpetkach - też. A poważnie: jeśli planujemy przyjść w stroju, co do którego mamy podejrzenie, że może odbiegać od standardów rozmowy rekrutacyjnej czy kultury firmy, zdecydowanie warto uprzedzić rozmówców, że tak będzie i najlepiej usprawiedliwić to okolicznościami (np. upał, wracam prosto z imprezy itp;).

2. A co jeśli - jak się bawić w fantazjowanie i skrajności, to do końca - ten 10-letni projekt miał super technologie (przynajmniej na początku, a później co jakiś czas zastępowane), był świetnie prowadzony, obejmował najlepsze praktyki developerskie, z kapitalnym merytorycznie, zaangażowanym zespołem, z niesamowicie ciekawym sensem biznesowym i takąż logiką aplikacji? Czy wybrałbyś taki zamiast pięciu różnych, dwuletnich projektów, z których każdy był słaby? 

Ale fakt, jeśli zostawimy przypadki skrajne i wszystkie inne czynniki zrównamy, to pewnie każdy programista będzie wolał być w pięciu różnych, dwuletnich projektach niż w jednym, dziesięcioletnim.

W rekrutacji jest i trochę podobnie i trochę inaczej.

Podobnie, bo faktycznie lata rekrutowania na te same stanowiska, w ten sam sposób, na te same projekty i dla tych samych klientów mogą powodować znudzenie i spowolnić rozwój zawodowy. Ale podobnie też dlatego, że jeśli rekrutujesz do świetnej firmy, wśród fajnych ludzi i w dobrych standardach, to możesz mieć długo frajdę nawet za cenę większej powtarzalności.

A dlaczego inaczej? O ile technologie zmieniają się i wiele z tego, co programiści znają dziś, za 10 lat może być bezużyteczne, to ludzie - w swych podstawowych predyspozycjach psychicznych, społecznych, zawodowych; w swych aspiracjach, motywacjach, zachowaniach - są niezmienni. Rekruter z trzyletnim stażem i pięcioma setkami spotkanych na rozmowach rekrutacyjnych ludzi będzie dużo lepiej "czytał" kandydatów i dokonywał lepszych wyborów niż rekruter z rocznym doświadczeniem i niecałą dwusetką rozmów. W pracy, gdzie często bazować musisz na intuicji (osobny wpis nt. roli intuicji w rekrutacji tutaj), każdy dodatkowy rok doświadczenia udoskonala ją, ulepsza rekrutacyjny celownik.

Z jakich innych powodów 10 lat (teraz - po roku, odkąd pytałeś - już 11:) rekruterskiego doświadczenia w IT to nie to samo, co 1 rok razy 10?

1) Możesz rekrutować dla różnych firm. Rekrutacja w agencji rekrutacyjnej, rekrutacja w firmie kontraktorskiej i rekrutacja wewnętrzna to trochę inne bajki. Nawet sposób wynagradzania jest różny.

2) Możesz rekrutować na różne stanowiska. Rekrutacja project manager to zupełnie inne wyzwania - i to na każdym etapie rekrutacji - niż rekrutacja programisty.

3) Zmienia się świat i zmieniają się narzędzia rekrutacyjne. Gdy zaczynałem w 2005 roku, LinkedIn dopiero raczkował, o Facebooku (w kontekście rekrutacyjnym) nikt nie słyszał. Za 10 lat znów pewnie docierać do kandydatów będzie się zupełnie inaczej.

4) Podobnie jak w każdym innym zawodzie, także w rekrutacji wraz ze wzrostem kompetencji otrzymujesz szanse wpływania na swój obszar z wyższego poziomu, np. kształtując kulturę rekrutacyjną firmy czy pomagając młodszym rekruterom. 

Także nie, 10 lat w rekrutacji IT to nie musi być 1 rok razy 10, chociaż - muszę przyznać - w pierwszych sekundach dałeś mi, szanowny anonimowy Czytelniku, do myślenia:)

_______

foto: wonderopolis.org

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ć ;)

_______

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ę

_______

Programować do ostatnich dni czy iść w zarządzanie

Czytałem niedawno ciekawą dyskusję na forum Quora na temat karier programistów - konkretnie, na ile kariera programisty może być karierą na całe życie, a na ile wcześniej czy później zachodzi konieczność porzucenia pracy z kodem i zajęcia się innymi rzeczami, zwłaszcza zarządzaniem.

Na pewno nie padną w tym wpisie odpowiedzi definitywne, bo temat jest obszerny, a odpowiedź na główne pytanie (programować tak długo jak się da czy iść w zarządzanie) złożona i niejednoznaczna. Podzielę się jedynie paroma obserwacjami z perspektywy rekruterskiej, co jednak i tak może być jakąś wartością dla osób, dla których temat jest interesujący.

Pierwsza obserwacja jest następująca: zdecydowana większość programistów, z jakimi w swej karierze rozmawiałem, chciałaby programować możliwie długo, a jeśli rozważają zmiany, to nadal w obrębie tzw. ścieżki technicznej, awansując np. na stanowisko architekta. Wielu, nawet jeśli chciałoby być bliżej biznesu (zajmując się np. analizą biznesową) albo zarządzania (wskakując na stanowisko managerskie lub team leaderskie), nie chciałoby tracić kontaktu z kodem, najlepiej w jakiejś części swoich zadań czynnie programując.

Podejście takie uważam za w dużej mierze uzasadnione i rozsądne. Sądzę, że większość ludzi dość dobrze orientuje się w swoich predyspozycjach, fascynacjach, słabych i mocnych stronach. Większość programistów, wybierając taki zawód (a nawet wcześniej: wybierając taki profil studiów) wybrała świadomie, swej decyzji nie żałuje i chce być w niej konsekwentna. Wielu z zadowoleniem przyznaje, że lubi to co na codzień robi i chciałoby robić to dalej. Uzasadnione to tym bardziej, że programistom bardzo sprzyja sytuacja na rynku pracy. O ile nie mieli pecha, trafiając (rzadziej wybierając) w środowisko z nierynkowymi technologiami i zostając w nim na dłużej, na ogół nie muszą martwić się o pracę i poziom zarobków w niej. Nie sądzę, by szybko nastały czasy, w których ogłoszenie o pracę na stanowisko programisty zachęci kilkunastokrotnie więcej aplikantów niż ogłoszenie na stanowisko project managera. Dziś sytuacja jest odwrotna i to sporo mówi o popytowo-podażowej sytuacji obu zawodów.

Dlaczego jednak niektórzy myślą o czymś więcej, dlaczego niektórym samo programowanie z czasem przestaje wystarczać? Dla części czynnikiem mogą być finanse. Choć programiści zarabiają dobrze, kadra managerska (w tym project managerowie) nadal zarabia lepiej i tak chyba pozostanie. Zarobkowy szklany sufit ciąży zwłaszcza tym programistom, którzy związali się etatem i na długo z jednym pracodawcą. Jeszcze gorzej, jeśli zrobili to zaraz po (albo nawet na) studiach. W tych sytuacjach często jedyną szansą na znaczny awans finansowy (przy chęci pozostania w tej samej firmie) jest awans na stanowisko managerskie.

Nieczęsto wymienianym a, tak sądzę, istotnym motywem chęci pójścia "w management" jest brak poczucia wpływu na wiele aspektów swej pracy, z jakim mogą zmagać się programiści. Poczucie wpływu na to, co i jak robimy jest generalnie jedną z ważniejszych rzeczy decydujących o satysfakcji z pracy na jakimkolwiek stanowisku. Od szeregowego programisty - przy całej frajdzie, jaką może mieć z pracy; przy namacalnych, widocznych jej rezultatach; przy wysokim poczuciu własnej merytoryki - często niewiele zależy. Decyzje związane np. z zasobowaniem, finansowaniem, sposobem prowadzenia porojektu, czy w ogóle decyzje o rozpoczęciu bądź porzuceniu projektu - tu w grę wchodzi odstraszająca na ogół osoby techniczne "polityka". Często chyba niesłusznie demonizowana, ale to temat na inny, i to obszerny, wpis. 

Garść powyższych uwag pewnie nie rozstrzygnie dylematów tych, którzy być może rozważają przejście na ciemną (nietechniczną, managerską) stronę mocy. Dla tych, co chcą, dobrym pomysłem na bezpieczne "sprawdzenie się" w częściowo managerskiej roli i płynne przejście na ową stronę może być stanowisko łączące oba (techniczny i nietechniczny) aspekty. A ci, którzy za nic w świecie nie chcą? Sądzę, że mogą długie lata i z satysfakcją programować, przy czym tym dłużej i z tym większą satysfakcją (i wyższymi zarobkami) im dłużej będą na bieżąco ze współczesnymi, rynkowymi techńologiami.

Wszystkim natomiast, tradycyjnie, doradzić mogę systematyczne i pilne szlifowanie języka angielskiego.

_______

Programista pyta, rekruter odpowiada

Kilka tygodni temu, w internetowej korespondencji z potencjalnym kandydatem okazało się, że kandydat ów (programista) jest wiernym i pochlebnym czytelnikiem Rekrutacyjnego. Zainspirowany miłym tym zrządzeniem losu zaoferowałem, że mogę tu na łamach bloga poruszyć jakiś interesujący go temat, mogący być i dla mnie ciekawą inspiracją do wpisu. Zgodził się i napisał tak:

"Nurtuje mnie od dłuższego czasu temat związany z tzw. 'lojalnością' pracownika w świetle szybko zmieniającego się rynku IT. O co dokładnie chodzi? Otóż, korzystając z własnych doświadczeń jak również kolegów po fachu odnoszę wrażenie, że w Polsce przeważa duża liczba projektów typu Support&Maintenance. Ze strony programisty oznacza to mniej więcej tyle, że po kilku - kilkunastu miesiącach pracy w takim projekcie człowiek przestaje odczuwać jakikolwiek progres w kontekście poszerzania własnych umiejętności, struktura organizacyjna jest dosyć płaska więc w tym kontekście również nie ma na co liczyć.

Efektem tego (np. w moim przypadku) jest próba znalezienia nowego projektu (najlepiej takiego który startuje od zera).

Pytanie: jak w obecnych czasach patrzy się na takiego pracownika?"

Pierwsza rzecz to stwierdzenie, że w Polsce dominują projekty typu Support&Maintanance. Gdzieś już zetknąłem się taką opinią i niestety nie mogę - trudno znaleźć jakieś obiektywne dane na ten temat - powiedzieć, czy jest to prawdą. A jeśli jest to prawdą, to z kolei ciekawe, czy Polska jest pod tym względem wyjątkowa - czy np. na Zachodzie projektów tzw. greenfieldowych jest więcej. W Krzemowej Dolinie pewnie tak, natomiast patrząc na całość rynku, gdzie największymi pracodawcami są duże organizacje - które nie tworzą co roku nowych aplikacji, a raczej dodają nowe funkcjonalności w już istniejących - to projektów "od zera" jest chyba wszędzie stosunkowo niewiele. 

Z wielu rozmów z kandydującymi do nas programistami wiem, że typ projektu - rozwojowy vs. utrzymaniowy - to jedna z kluczowych rzeczy decydujących o jego atrakcyjności i ew. decyzji o dołączeniu. Zdecydowanie preferowane są te pierwsze, trudniej znaleźć ochotników do utrzymaniowych, co z pewnością potwierdzi cytowany wyżej czytelnik. Aczkolwiek, praca utrzymaniowa też różnie może wyglądać. Niekiedy inne atuty (i to nie finansowe) mogą zrekompendować programiście brak tworzenia czegoś. Mogą to być np.: nowe technologie, skala systemów, dobry team, od którego mozna się sporo nauczyć czy wreszcie ciekawe z biznesowego punktu widzenia środowisko. Częściej jednak, faktycznie, praca nad rzeczami powstającymi będzie dla developera (właśnie, sama nazwa developer implikuje przecież rozwój) atrakcyjniejsza niż praca nad rzeczami już istniejącymi, które trzeba jedynie (?) ulepszać.

Odpowiadając wreszcie na pytanie czytelnika, programista poszukujący projektów rozwojowych i tym motywujący chęć zmiany pracy, czy wreszcie tym wyjaśniający poprzednie zmiany pracy (czy projektów), będzie zrozumiany przez rekrutera w branży IT. O ile rekruter zna realia branży (w niej, by być dobrym, trzeba być na bieżąco), na pewno nie uzna takiej motywacji za fanaberię i nie zastosuje miary niektórych HR-owców, według której ktoś, kto zmienia pracę częściej niż co 3 lata, to tzw. skoczek. Zresztą, w dobie ogromnego popytu na kompetencje programistów, rekruterzy w stosunku do nich są chyba bardziej wyrozumiali niż w stosunku do przedstawicieli niektórych innych zawodów. Programiście pewnie wolno więcej. (Z czego niektórzy nadmiernie korzystają).

Wolno więcej, ale do pewnego stopnia. Jeśli ktoś poprowadzi swoją karierę programistyczną ekstremalnie "projektowo", efektem czego będzie CV z nie dłuższym uczestniczeniem w jednym projekcie niż parę miesięcy, wtedy może to wzbudzić w rekruterze podejrzenia. Poważne projekty IT trwają zwykle dłużej niż kilka miesięcy, zatem możliwe będzie w stosunku do takiego kandydata przypuszczenie, że - mówiąc obrazowo - nie kończy tego, co zaczął. (Nie powoduje get things done - jedna z dwóch rzeczy wyróżniających dobrych programistów, według pewnego programisty). 

Podsumowując, w programistycznym fachu - moim zdaniem - zrozumiałe (a czasem nawet wskazane) jest częstsze niż standardowe na rynku zmienianie miejsca pracy. Byle nie za częste i nie z błahych powodów. W końcu warto też czasem pochwalić się na rozmowie rekrutacyjnej, że ze względu na lojalność do firmy trwało się w niej mimo beznadziejnie nudnego projektu ;)

PS.

Pytanie czytelnika było interesujące i rzeczywiście dla nowego wpisu (też, mam nadzieję, ciekawego) inspirujące. Jeśli są inni czytelnicy, którzy chcieliby zadać pytanie albo po prostu poznać jakieś tajnie skrywane rekruterskie tajemnice - serdecznie zapraszam: pawel.zdziech@gmail.com

_______

obrazek dzięki: http://sd.keepcalm-o-matic.co.uk

Popularne stanowiska, o których 5 lat temu mało kto słyszał

Nowa liczba (2014) opisująca kolejny rok to zawsze moment sprzyjający spojrzeniu na upływ czasu, zmiany i trendy, także na rynku pracy - i to w wymiarze globalnym. O ciekawe spojrzenie tego typu postarał się niedawno LinkedIn. Serwis pogrzebał w swoich przepastnych danych o profilach jego użytkowników, by dowiedzieć się, jakie stanowiska - dość popularne dziś - nie istniały (lub ledwo istniały) jeszcze pięć lat temu, w 2008 roku . 

Sprawdzono 259 milionów profili, zatem było z czego liczyć. Oto lista 10-ciu najpopularniejszych dziś stanowisk, o których 5 lat temu jeszcze mało kto słyszał.

1) iOS Developer (89 profili w 2008 roku, 12 634 profili w 2013 roku; 142-krotny wzrost w ciągu 5 lat)

2) Android Developer (53 profile w 2008 i 10 554 w 2013; 199-krotny wzrost)

3) Zumba Instructor (16 - 6 331)

4) Social Media Intern (25 - 4 350)

5) Data Scientist (142 - 4 326)

6) UI/UX Designer (159 - 3 509)

7) Big Data Architect (0 - 3 440)

8) Beachbody Coach (0 - 3 360) [To dystrybutorzy produktów fitness firmy Beachbody LLC]

9) Cloud Services Specialist (195 - 3 314)

10) Digital Marketing Specialist (166 - 2 886)

Niesamowite i zmuszające do myślenia. Stanowiska, które dziś są oczywistością, na których pracują tysiące osób na całym świecie (liczby powyżej są zaniżone - nie wszyscy są i tym bardziej byli w 2008 roku na LinkedIn, a nawet tam mogą robić to samo pod innymi nazwami stanowisk i nie być uwzględnionymi w statystykach), niemal nie istniały w czasie wstecz równym czasowi trwania studiów (pięć lat)! Powiedzieć, że jedyną stałą rzeczą w dzisiejszych czasach jest zmiana to banał. Ale to zarazem fakt. Panta rei!

Kolejna oczywistość: zdecydowana większość nowych na rynku stanowisk to te związane z obszarem nowych technologii. Tu panuje największa dynamika pojawiania się nowych specjalizacji (czy wręcz zawodów), co z perspektywy osób pracujących w sektorze IT jest rzeczą dobrą, ale też - z drugiej strony - to w tym obszarze wiedza, kompetencje i specjalizacje relatywnie szybko dezaktualizują się. Choć czasem... ponownie aktualizują. Lider rankingu (iOS Developer) to stanowisko związane z programowaniem w języku Objective-C, powstałym dawno temu, początku lat 80-tych i dopiero po 2007 roku (rok wprowadzenia pierwszego iPhone'a) przeżywającym renesans.

W sytaucji tak szybkich zmian na rynku pracy trudno o tworzenie wieloletnich planów czy budowanie strategii rozwoju swojej kariery na wiele lat w przód. Z tego powodu rekrutacyjne pytanie "co będzie pan robił za 5 lat?" nie zawsze ma sens. Jak w takim razie sensownie kierować swoją karierą, na co postawić, by za 5 lat mieć większe, a nie mniejsze szanse na zatrudnienie? Bezpiecznie jest przyjąć, że nadal przyda się jezyk angielski, bycie miłym oraz punktualność i tę skromną, ostrożną poradę można przyjąć w ciemno.

_______

fot.: Instruktorka Zumby (źródło: www.zumba-danse.com)

Wyjazd integracyjny kontrolowany

Współczesne organizacje wkładają niemały wysiłek w to, by ich pracownicy mieli okazję poznawać się od strony nie tylko zawodowej, by pracujący codziennie ze sobą ludzie bardziej zbliżyli się do siebie, co przyczyniłoby się do lepszej atmosfery w zespole i być może bardziej efektywnej jego pracy. Jednym słowem, we współczesnych firmach sporo wysiłku wkłada się w integrację pracowników. Charakter i częstość imprez czy szerzej eventów integracyjnych zależy od polityki korporacyjnej i sytuacji finansowej firmy. Organizacje zasobne i kładące duży nacisk na integrowanie pracowników organizują takie wydarzenia częściej. Korporacyjne imprezy czy wyjazdy integracyjne stały się stałym elementem polskiej kultury pracowniczej. Tematem zainteresowała się kinematografia. Wystarczy przypomnieć niedawno goszczący w naszych kinach film "Wyjazd integracyjny".

Jak mają się imprezy integracyjne do rekrutacji i szerzej zarządzania karierą? Tak, że najogólniej mówiąc trzeba na takich imprezach uważać, by nie było później podczas rekrutacji zbyt ciężko i by w zarządzaniu karierą nie narobić sobie problemów. Trzeba pamiętać, że impreza firmowa to wciąż wydarzenie o charakterze zawodowym, jakkolwiek świetna byłaby na niej zabawa i jakkolwiek luźna atmosfera. Czasami zdarzyć się może tak, że to, co zrobimy i powiemy na takiej imprezie będzie mieć niepożądane dla nas z zawodowego punktu widzenia konsekwencje. Czasami nawet negatywne konsekwencje zawodowe może przynieść to, co zrobią na takiej imprezie inni - coś, z czym pozornie nie mamy nic wspólnego. Słyszałem kiedyś o kandydacie, którego podwładni (on i ona) na wyjeździe integracyjnym zbytnio... zbliżyli się do siebie, zintegrowali się za bardzo. Ich przełożony miał z tego powodu problemy i ostatecznie musiał rozstać się z firmą. Zalecane jest więc na eventach integracyjnych bawić się dobrze, ale w granicach rozsądku, by firmowa integracja nie stała się powodem... dezintegracji kariery.

_______

Co powiedział Steve Jobs o budowaniu kariery

Wydarzeniem nie tylko świata IT, ale wydarzeniem komentowanym w mediach wszelkich w zeszłym tygodniu było opuszczenie przez Steve'a Jobsa stanowiska Dyrektora Zarządzającego w firmie Apple. Mówiły i pisały o tym media na całym świecie, w tym te nie mające nic wspólnego z szeroko pojętymi nowymi technologiami. Jest bowiem Steve Jobs i to, czym się zajmuje, tematem istotnym z wielu punktów widzenia, wśród których technologiczny być może nawet nie jest najistotniejszy. Wśród opinii nt. twórcy i głównego autora sukcesu Apple znalazłem i tę, że jak nikt inny w ostatnich trzydziestu latach wpłynął na przemianę kulturową (!) na świecie. Przemiana kulturowa to dla socjologa duże słowo i jeśli pada, muszą być ku temu poważne przesłanki. I w przypadku Jobsa są. Jeśli jego Apple ze swoim Mac'iem, iPodem, iPhone'm czy iPadem zmieniło sposób w jaki miliony (miliardy?) ludzi na świecie słuchają muzyki, surfują po internecie, komunikują się i spędzają czas wolny, to wielkie słowa na temat pana Jobsa mają uzasadnienie.

Nie jestem wyznawcą Steve'a Jobsa ani oddanym wielbicielem produktów Apple'a. Aczkolwiek szanuję to, co zrobił, a iPhone'a uważam za świetne urządzenie. W całym zeszłotygodniowym szumie wokół postaci Jobsa zaciekawiły mnie momenty w jego karierze zawodowej, w których był na zakrętach albo na samym początku, kiedy jeszcze nie śnił o tym, co osiągnie w przyszłości. Zwróciłem uwagę na dwie rzeczy.

Pierwsza: kiedy był jeszcze w college'u (którego nigdy nie skończył!), jedynym przedmiotem, który naprawdę go zainteresował i któremu mocno się poświęcił, była kaligrafia. Autentycznie się tym fascynował i nigdy nie myślał, że kiedykolwiek mu się to przyda. A jednak, kiedy tworzył po latach pierwszy komputer Maca, dawne lekcje kaligrafii dostarczyły mu wiele inspiracji i konkretnych umiejętności w tworzeniu ładnie zaprojektowanych czcionek. Wniosek: nigdy nie wiemy, co nam się zawodowo przyda w przyszłości. Jeśli jednak interesujemy się czymś, poświęcenie temu czasu już teraz jest samo w sobie wartościowe.

Druga: stara jak świat i już nieco oklepana prawda, że tylko robiąc to, co naprawdę lubimy, mamy szansę stać się w tym świetni. I że czasem warto długo próbować różnych i nowych rzeczy, nawet za cenę obecnej kariery, by to coś znaleźć. Czasem nawet warto być zwolnionym - tak jak zwolnili Jobsa z Apple w 1986 Jobsa - by zacząć coś nowego. Wiadomo, że wszystko ładnie wygląda w ustach Steve'a Jobsa i generalnie success stories brzmią ładnie. Łatwo mówić o inspirującej roli porażek, gdy jest się na szczycie. Niemniej, postulat robienia w życiu tego, co się lubi i odnajdywania pozytywów w sytuacjach niekoniecznie pozytywnych (np. byciu wyrzuconym z pracy) wart jest rozważenia.

_______

Should I Stay Or Should I Go

Pomijając zadeklarowanych i wiecznych wolnych strzelców oraz osoby, które planują całą swoją karierę zawodową związać z jednym pracodawcą, oraz osoby, które nigdy w życiu nie będą nigdzie pracować, otóż pomijając ich wszystkich, każdego wcześniej czy później czeka zmiana pracy, oznaczająca też najczęściej zmianę pracodawcy. Nie jest to doświadczenie łatwe, psychologowie zaliczają je do jednych z najbardziej stresogennych doświadczeń życiowych. Stresujące jest rozpoczęcie nowej pracy - to zrozumiałe. Niedocenianym chyba jednak pod względem stresogenności jest odejście ze starej pracy. W końcu zostawiamy kawałek swojego zawodowego życia, zostawiamy ludzi, żegnamy się, odchodzimy. Ale zanim odejdziemy, bywa tak, że dotychczasowy pracodawca - najczęściej w osobie bezpośredniego przełożonego - próbuje zatrzymać nas. Im lepszym byliśmy pracownikiem, tym prawdopodobieństwo usłyszenia "Czy jest coś, co mogłoby cię zatrzymać?" jest większe. Co wtedy robić?

Nie ma dobrych, jednoznacznych odpowiedzi. Bardzo wiele zależy od motywacji, która kierowała pracownikiem, kiedy zdecydował się wziąć udział w rekrutacji, a więc z jakichś powodów założył odejście. Im więcej czynników skłaniało go do odejścia i im bardziej czynniki te były istotne z punktu widzenia satysfakcji zawodowej, tym dotychczasowy pracodawca będzie mieć trudniejsze zadanie w zatrzymaniu pracownika (jeśli oczywiście taką próbę podejmie). Jeśli, przykładowo, chodziło tylko o finanse, być może wystarczy tylko (lub aż) podwyżka. Dużo trudniej, gdy motywy skłaniające do odejścia były bardziej złożone i obejmowały np. brak - jakkolwiek pojętego - rozwoju.

Wśród rekruterów wydaje się dominować pogląd, że decyzja o jednak pozostaniu u dotychczasowego pracodawcy, pomimo wcześniejszego komunikatu o odejściu (czy nawet poinformowaniu o posiadanej konkurencyjnej ofercie pracy), nie jest najlepszym pomysłem. Rekruter z tego artykułu nazywa nawet taką decyzję zawodowym samobójstwem. Nie byłbym aż tak radykalny, aczkolwiek z kilkoma wnioskami się zgadzam. Przede wszystkim, informacja o (nawet tylko rozważanym) odejściu może nie najlepiej wpłynąć na naszą późniejszą pozycję w firmie, jeśli jednak zdecydujemy się zostać. Przykładowo, przełożeni, zanim powierzą nam jakąś odpowiedzialną i kluczową dla firmy rolę czy projekt, mogą mocno wahać się, czy powierzyć ją komuś, kto chciał (lub nawet tylko rozważał, by) odejść. Nawet jeśli, by skusić nas do zostania, obiecano nam wiele, warto rozważyć, dlaczego zaoferowano nam to dopiero teraz i na ile spełnienie tych obietnic będzie realne. Trudno oczekiwać, by doświadczane przez nas dotychczas braki w organizacji, jeśli są brakami istotnymi i mocno w nią wpisanymi (a przecież tylko takie najczęściej skłaniają do odejścia), otóż trudno oczekiwać, by braki te mogłyby być nagle i na trwałe wyeliminowane.

A jeśli dni rozważań nad "za" i "przeciw" zostaniu/odejściu nadal nie rozjaśniają nam sytuacji, proponuję piosenkę zespołu The Clash "Should I Stay Or Should I Go". W decyzji nie pomoże, ale przynajmniej umili czas spędzony na dylematach.


_______

Angielski - zrób to sam

Angielski jest ważny. Kompetencje komunikacyjne w języku Szekspira są jednymi z najczęściej powtarzających się wymagań wymienianych w ogłoszeniach rekrutacyjnych, niezależnie od branży. Być może nawet jest to wymaganie - oprócz wykształcenia - najczęściej powtarzające się w ogłoszeniach (inna sprawa, że czasem na wyrost). Fakt pozostaje faktem, że angielski często w pracy jest potrzebny (a podczas rekrutacji sprawdzany), gdyż nawet jeśli nie pracujemy w firmie międzynarodowej, to coraz częściej w miejscach, w których pracujemy, istnieje - przynajmniej od czasu do czasu - konieczność porozmawiania z kimś nie władającym językiem polskim.

Znany problem z nauką języka angielskiego w naszym kraju to ten, że w polskich szkołach w edukacji dużą wagę przywiązuje (przywiązywało?) się do nauki gramatyki, zaniedbując przy tym żywą komunikację. Takie jest odczucie moje i wielu osób z mojego pokolenia, które nie zaznały jeszcze dobrodziejstw (i przekleństw) prywatnej edukacji i multimediów. Zwykle angielski mówiony poprawia się znacznie u tych osób, które miały okazję wyjechać na dłużej za granicę lub zaraz po studiach rozpocząć pracę w firmie (faktycznie) międzynarodowej. A co z tymi, które nie miały i nie mają okazji rozmawiać na co dzień (lub chociaż od święta) po angielsku? Jak mogą poprawić swój angielski?

Istnieje kilka "domowych" sposobów, którymi chciałbym się podzielić. "Domowych", ponieważ nie każdy ma czas i pieniądze, by oddać się w ręce profesjonalisty (nauczyciela czy lektora).

1) Podcasty - czyli po prostu audycje publikowane w internecie i odtwarzalne na wszelkiego typu mp3-playerach. Wśród nich mnóstwo podcastów edukacyjnych, z słuchanym i polecanym przeze mnie podcastem ESL.

2) Koledzy z zagranicy - jedno z forów na Skype'ie umożliwia poznanie osób z całego świata, chcących doskonalić swój angielski. Wystarczy zostawić swój skype'owy nick, określić poziom angielskiego, zapoznać się z wybranymi osobami skądkolwiek i rozmawiać, rozmawiać, rozmawiać.

3) Audiobooki - jest ich coraz więcej i dla osób o różnym poziomie znajomości angielskiego. Wprawdzie słuchając audiobooka dużo bardziej rozwiniemy umiejętności słuchania angielskiego, a nie mówienia, ale przynajmniej na rozmowie o pracę po angielsku będziemy mogli potem chociaż zrozumieć pytanie, nawet jeśli nic nie będziemy w stanie powiedzieć :)

4) Kluby konwersacyjne - popularne głównie w większych miastach. To grupy ludzi (różnych narodowości), poznających się np. na forach językowych, którzy regularnie spotykają się, by konwersować po angielsku.

Te "domowe" sposoby pozwolą na przyzwoite opanowanie lub "odświeżenie" kompetencji konwersacyjnych.

A na koniec dzisiejszego wpisu, bardzo podobający mi się, dotyczący pracy, angielski cytat, który znalazłem w aplikacji "Quotations" na iPhone'a (właśnie, to kolejne możliwy sposób na ćwiczenie angielskiego):

"There are no menial jobs, only menial attitudes". (William Bennet)


_______

Konferencje jako źródło cierpień

Koleżanka podzieliła się dziś ze mną wrażeniami z pewnej konferencji (tematyka: HR), w której miała okazję niedawno uczestniczyć. Ponieważ oboje w tym roku byliśmy już na kilku konferencjach, o tematyce zarówno HR jak i IT, dobry to moment, by podzielić się paroma refleksjami, ze szczególnym uwzględnieniem perspektywy rekrutacyjnej.

Przede wszystkim, konferencje - o ile uczęszczamy na właściwe - są dobrą okazją, by poznać interesujące osoby w naszej branży. Interesujące z wielu punktów widzenia. Wiedząc, że w poszukiwaniu pracy często niebagatelną rolę odgrywają bezpośrednie kontakty (by nie użyć nieco pejoratywnych "znajomości"), te zdobyte na konferencjach mogą być w przyszłości przydatne, tym bardziej, jeśli są to konferencje ściśle związane z naszą branżą. Konferencje to także świetna okazja nawiązania relacji przydatnych na stanowisku aktualnie piastowanym, zwłaszcza w obszarach biznesowych, w których relacje mają szczególnie istotne znaczenie (np. sprzedaż, PR).

A co z konferencjami jako źródłem rozwoju zawodowego rozumianego jako pozyskiwanie nowej wiedzy i kompetencji merytorycznych? Tu już bywa bardzo różnie. Można uczestniczyć w konferencji interesującej i faktycznie pogłębiającej wiedzę, można też niestety stracić czas, słuchając osób przypadkowych, z takimi też tematami. Wspomnianej koleżance przydarzyło się to drugie. Choć tematyka konferencji była jak najbardziej związana z naszym obszarem, to poziom zarówno prelegentów, jak i ich wystąpień w wielu przypadkach rozczarował.

Duża część odpowiedzialności za sukces konferencji (mierzony przede wszystkim satysfakcją uczestników) leży po stronie instytucji ją organizującej. Dobrze, jeśli dobór i spójność tematów są dla niej priorytetowe; jeśli pierwszorzędną kwestią nie jest liczba osób, którą uda się przekonać do udziału w konferencji (przekładająca się na zyski z wpisowego). Tym, co mogą zrobić z kolei uczestnicy konferencji przed decyzją o ew. wzięciu udziału, to:
- wybierać tematy rzeczywiście dla siebie interesujące (starając się unikać motywacji "z ciekawości")
- dowiedzieć się cokolwiek o kompetencjach (a być może i - co nie mniej ważne - umiejętnościach prezentacyjnych) prelegenta
- uważać na efektownie brzmiące, a po bliższym pryzpatrzeniu się nie obiecujące nic ciekawego, tematy

_______