O różnych rozumieniach programistycznego seniority

Fascynujący rynek rekrutacji programistów nadal potrafi zaskoczyć. Kilka dni temu zaskoczył mnie tym, jak różnie może być rozumiane pojęcie programistycznego seniority. Czy raczej - w tym przypadku - juniority.

Wszystko zaczęło się od postu mojego kolegi z zespołu rekrutacji, który w jednej z programistycznych grup facebookowych zamieścił ogłoszenie, w którym moja firma (7N) poszukuje osoby na stanowisko Junior .NET Developera, a wymaganym minimalnym doświadczeniem są 3 lata w programowaniu.

Post – sądząc po komentarzach i reakcji na nie – wśród niemałej części osób wzbudził kontrowersje, a jej powodem było to, że osobie z min. 3-letnim doświadczeniem proponujemy stanowisko zaledwie juniora. Jak śmieliśmy?!

Dyskusję pozwoliłem sobie - jak się miało okazać - zamknąć takim komentarzem:

I właściwie byłoby po sprawie, gdyby nie to, że epizod ten jest jednak ciekawą ilustracją fenomenu programistycznego rynku pracy, kolejnym znakiem czasu.

Gdy kilka dni temu jedna z firm rekrutacyjnych zarekomendowała nam programistę, który – mając 1.5 roku doświadczenia programistycznego – pracował na stanowisku Senior Developera, nie zdziwiłem się już zbytnio. Na zwariowanym rynku dojdzie do jeszcze niejednej zwariowanej sytuacji. Czekam na dzień, w którym otrzymam CV osoby mającej w nazwie stanowiska „programista”, a dopiero wybierającej swój pierwszy w życiu język programowania. Czy może już istnieją takie CV?

Tak, wiem, że są super zdolni trzylatkowie, którzy w ciągu swoich trzech lat pracy nauczyli się więcej i znaczą rynkowo więcej niż niejeden dziesięciolatek. Patrząc jednak globalnie – i statystycznie – są oni wyjątkami. To po pierwsze.

A po drugie (i ważniejsze), doświadczony programista to – w moim i 7N rozumieniu – nie tylko koder. To również człowiek wnoszący wartość dodaną od strony dobrej znajomości dziedziny biznesowej, której dotyczy projekt. To ktoś mający świadomość różnych uwarunkowań sukcesu projektu czy różnych punktów widzenia jego uczestników i interesariuszy. W tym aspekcie nie można osiągnąć seniority inaczej niż przez zdobyte w różnych projektach, okupione umownymi bliznami, mierzone w latach - d o ś w i a d c z e n i e.

A i w obszarze wyłącznie technicznym programista nierówny programiście. Jeden będzie w stanie sprostać wyzwaniom wydajnościowym i integracyjnym w dużych systemach, inny nie. Jeden będzie w stanie (dobrze) wybrać technologie, narzędzia i metodykę, inny nie. Jeden będzie w stanie (mądrze) wyznaczyć standardy developerskie dla zespołu i w projekcie, inny nie. 

Ci pierwsi są w stanie robić to, czego nie są jeszcze w stanie robić ci drudzy dzięki m.in.  d o ś w i a d c z e n i u.

(Zainteresowanych rzetelnym, metodycznym podejściem do różnicowania poziomów zaawansowania zadań na stanowiskach IT zachęcam do zapoznania się z frameworkiem SFIA: LINK).

Sprawdziłem z ciekawości, kim był autor pierwszego, najbardziej popularnego komentarza pod wspomnianym na początku postem, oburzony tym, że stanowisko osoby z 3-letnim doświadczeniem można nazwać Junior.

Otóż jest programistą  i ma dziś trzy i pół miesiąca komercyjnego doświadczenia w programowaniu. W nazwie stanowiska... Junior. Jeszcze.

_______

Jakie jest najważniejsze pytanie, które rekruter powinien zadać ekspertowi IT, czyli za co wręczyliśmy elektryczną hulajnogę na infoShare

Dobrze jest od czasu do czasu zmienić codzienną, zawodową perspektywę, np. zobaczyć, jak to by było, gdyby rekruterami - nawet na czas jednego pytania rekrutacyjnego - zostali ludzie IT.

Byliśmy w zeszłym tygodniu z 7N na infoShare, jednym z głównych, a na pewno jednym z większych cyklicznych wydarzeń technologicznych w Polsce.

Duże konferencje w IT od zawsze służyły firmom poszukującym talentów do dotarcia do nich i ich – w pozytywnym scenariuszu – zrekrutowania. W czasach rosnącej, a czasem wręcz desperackiej konkurencji o specjalistów IT przybiera to często formę rozdawnictwa mało wartościowych gadżetów, o czym kiedyś już pisałem.

Też w 7N mamy gadżety, też mamy konkursy, też mamy nagrody, ale od zawsze chcieliśmy swoją rekrutacyjno-wizerunkową obecność na eventach budować bardziej na interakcjach niż na gadżetach (aczkolwiek grono fanów naszych krówek z Confitury, rosnące od 2008 roku, jest niemałe). Wierzymy, że nawet parominutowa rozmowa z doświadczonym rekruterem znającym rynek i trendy w IT da programiście większą wartość niż kolejny kubek czy piłka antystresowa.

Z takim też założeniem pojechaliśmy na tegoroczny infoShare. Chcieliśmy, by tym razem nasza obecność tam była okazją do wymiany wiedzy i opinii o tym, jak się rekrutuje i jak powinno się rekrutować specjalistów IT. Narzekają oni czasem, że ich rozmowy z rekruterami niewiele wnoszą, że najchętniej chcieliby od razu porozmawiać z „kimś technicznym”, że pytania, jakie rekruterzy im zadają, są bez sensu.

Zorganizowaliśmy więc konkurs, w którym daliśmy szansę uczestnikom konferencji – w zdecydowanej większości ludziom świata IT – na wymyślenie pytania rekrutacyjnego, które każdy rekruter na rozmowie rekrutacyjnej z ekspertem IT powinien zadać. Narzekacie na pytania? Wymyślcie je sobie sami. Taka mniej więcej była idea konkursu - z hulajnogą elektryczną jako główną nagrodą.

Zanim podzielimy się, jakie pytanie demokratycznie – głosował cały zespół rekrutacji 7N – uznaliśmy za zwycięskie, kilka obserwacji i wniosków. Myślę, że powinny być ciekawe i dla rekruterów IT, i dla specjalistów IT.

Przede wszystkim, uświadomiliśmy sobie, że prowadzenie rozmowy rekrutacyjnej to rzeczywisty know-how. Są pytania rekrutacyjne, które wnoszą do trafności oceny kandydata tak niewiele, że równie dobrze można by podjąć decyzję o zatrudnieniu na podstawie rzutu monetą. „Jakie są pana mocne strony?”, „Co by pan chciał robić za pięć lat?”, „Co pana motywuje?”. Można dowiedzieć się z nich, co kandydat sądzi na jakiś temat, ale już mniej o tym, czy sprawdzi się na danym stanowisku. 

Podobnie z pytaniem „Czy jesteś roszczeniowy?”, które zaproponował jeden z uczestników konkursu. Jest oczywistym, że żaden kandydat – jeśli jest choć minimalnie inteligentny i zmotywowany – nie odpowie na nie twierdząco.

Ciekawym pytaniem, które zaproponował jeden z uczestników (a może uczestniczek?) konkursu było: „Jak zareagujesz, gdy młodsza kobieta będzie dev leaderem w Twoim zespole?”. Domyślam się, że miałoby ono na celu zbadanie, czy kandydat nie ma problemu z pracą z kobietami w IT, zwłaszcza jeśli kobieta miałaby być jego szefem. Nie wiem, czy jest to na tyle powszechny problem, by pytać o to wszystkich kandydatów. W każdym razie, nawet jeśli kandydat miałby coś przeciwko kobiecie-szefowej, a nadal zależałoby mu na stanowisku, mógłby po prostu skłamać, że z kobietami wszystko u niego OK.

Wiele osób zaproponowało pytania starające się zbadać w kandydacie poziom pasji zawodowej. Było np. takie: „Co najbardziej ‘kręci’ Cię w tym co robisz? (Sprawdzamy, czy mamy do czynienia z pasjonatem czy rzemieślnikiem. Pasjonaci przenoszą góry. Lepiej się z nimi pracuje, zarażają.)”. Tu znów: możemy trafiać na kandydatów, którzy deklaratywnie będą pasjonatami, natomiast faktycznie już mniej. Ale ciekawszym problemem w tym pytaniu jest założenie, że praca w IT (zwłaszcza na przykład w programowaniu) musi albo przynajmniej powinna być pasją. Czy faktycznie? Czy dobry programista musi być pasjonatem czy też wystarczy, jeśli będzie dobrze wykonywał to co do niego należy? To pewnie temat z gatunku filozoficznych i znaleźliby się zwolennicy obu poglądów. Mi bliżej jest do poglądu, że jakkolwiek „miłość” do programowania pewnie czasem pomaga, to w zdecydowanej większości przypadków wystarczy, jeśli programista jest inteligentny, dowozi (smart and gets things done – klasyczna definicja dobrego programisty według Joela Spolsky’ego) i dogaduje się z ludźmi. I tego bardziej bym szukał na rozmowie i w pytaniach rekrutacyjnych.

Skoro już przy smart, jeden z uczestników konkursu, będąc najwyraźniej zdania, że kluczowa w IT jest spostrzegawczość, zaproponował, by zadawać kandydatom pytanie o to, jaki kolor włosów miała pani na recepcji. Nie jestem pewien, czy spostrzegawczość jest w IT aż tak ważna. Może na stanowiskach testerskich? Ale pytanie, czy umiejętność zwracania uwagi na rzeczy w otoczeniu (np. na kolor włosów pani na recepcji) będzie tym samym typem spostrzegawczości, którego wymagamy przy wykrywaniu błędów w aplikacjach.

Inny uczestnik infoShare w propozycji swojego pytania zwrócił uwagę na rolę etyki w IT: „Jesteś niewątpliwie dobry w tym co robisz. Czy uważasz, że jesteś również dobrym człowiekiem? Jakie, według Ciebie, ma to znaczenie w pracy w IT?”. Ponieważ uważam, że sama skuteczność to w biznesie za mało i fajnie jest jeszcze pracować z ludźmi, którzy są w porządku i dla takich samych firm, pytanie uważam za niezłe – może tylko sformułowałbym je inaczej, może mniej wprost.  

Były też pytania po prostu ciekawe:

„Jeśli miałbyś walczyć, to jako przeciwnika wolałbyś mieć: kaczkę wielkości niedźwiedzia czy stado niedźwiadków wielkości kaczek?” – o ile to nie był żart, to potrzeba tu komentarza, że pytanie rekrutacyjne, by było dobre, niekoniecznie musi być skomplikowane.

„Czy byłbyś w stanie zamieszkać w biurze tydzień dla sukcesu projektu?” – pytanie może i dobre, ale w specyficznych firmach, z niektórych odmiennych od naszego kulturowo regionów świata.

„Jakie wino pijesz na imprezach integracyjnych?” – to już pytanie zdecydowanie bliższe naszej kulturze, aczkolwiek mielibyśmy kłopot, jeśli kandydat odpowiedziałby nam po prostu „Duże”.

Do finału zakwalifikowaliśmy trzy pytania.

1) Właśnie to powyżej o bycie dobrym człowiekiem.

2) Czego się ostatnio nauczyłaś/eś? – ze względu na jego prostotę i uniwersalność. Bada przy tym to, co w IT jest chyba szczególnie ważne.

3) Gdybyśmy mieli machinę cofającą czas o godzinę, to czy chciałbyś coś zmienić w swoich odpowiedziach na nasze pytania? – podobała się nam jego oryginalność i to, że w jakiś sposób odnosi się do jednej z kompetencji interpersonalnych, które cenimy w 7N, „Insight into own strenghts and weaknesses” z zestawu „The 7N Secret Code”. Cenimy, jeśli kandydat, przy świadomości swoich wysokich kompetencji, ma też jednak trochę pokory.

W wewnętrznym, 7N-owym, rekrutacyjnym głosowaniu wygrało pytanie „Czego się ostatnio nauczyłaś/eś?”, nieznacznie wyprzedzając pytanie z maszyną cofającą czas. Co ciekawe, autorkami obu pytań okazały się być osoby nietechniczne...

Podsumowując, konkurs się udał, dziękujemy wszystkim uczestnikom. Z niektórymi mamy nadzieję jeszcze się zobaczyć.

_______

Jak nie zostałem certyfikowanym Tech Recruiterem - recenzja kursu DevSkillera

Kilka tygodni temu znajomy programista i współtwórca jednego z narzędzi do testowania programistów napisał do mnie z wiadomością, że stworzył kurs dla rekruterów IT. Zaproponował zerknięcie i konstruktywną krytykę. Oto ona.

Z Kubą Kubryńskim poznaliśmy się parę lat temu na rozmowie rekrutacyjnej. Przeszedł ją świetnie i choć nie została ona sfinalizowana współpracą (przynajmniej wówczas), sympatyczny kontakt pozostał. Jakiś czas potem Kuba stworzył narzędzie do sprawdzania wiedzy i umiejętności developerów o nazwie DevSkiller i to właśnie w ramach tej działalności niedawno powstał wspomniany kurs.

(Małe zastrzeżenie: nie chciałbym, by wpis traktowany był jako jakakolwiek - płatna czy po znajomości - reklama DevSkillera. Traktuję go tu jako jedno z wielu narzędzi testujących programistów i w ogóle nie pomyślałbym o nim jako bohaterze wpisu na Rekrutacyjnym, gdyby nie właśnie ów kurs. Zresztą, zobaczycie, że "konstruktywnej krytyki" kursu będzie dość.).

Przede wszystkim, miałbym zastrzeżenie do nazwania kursem czegoś, co w istocie jest dwoma - fakt, obszernymi, ale jednak tylko - dokumentami pdf. Jeden dotyczy optymalizacji procesu rekrutacji, drugi umiejętności wyszukiwania kandydatów. W pierwszym poruszono zagadnienia dotyczące m.in. screeningu i rozmowy rekrutacyjnej, składania ofert kandydatom, mierzenia skuteczności (czasowej i kosztowej) rekrutacji, dopasowywania kandydatów do kultury organizacji czy sytuacji kobiet w IT. Podobał mi się rozdział o wzajemnych (często niezrozumianych) oczekiwaniach działów HR i IT.

Ostatnim rozdziałem jest przystępny słownik zagadnień technicznych, przy czym licząc tylko 10 stron, musi on być potraktowany jako repozytorium jedynie podstawowej wiedzy, nawet dla rekrutera. Za oznakę wiedzy bardziej zaawansowanej uznałbym na przykład - i wiedzą to rekruterzy aplikujący do 7N - znajomość akronimu ORM :)

W części "Narzędzia do testowania technicznego" wymieniony i opisany jest... tylko DevSkiller. Jakoś to rozumiem, takie są reguły gry (czy jednak zawsze?) w content marketingu: dostarczamy wartość, ale jednak gdzieś koniec końców promujemy swój produkt. Czy jednak choćby wymienienie innych, konkurencyjnych narzędzi - albo przynajmniej wspomnienie, że są inne - byłoby z dużą marketingową szkodą?

Podobało mi się za to zwrócenie uwagi na kompetencje miękkie w rekrutacji programistów - również na kompetencje i zachowania samych przeprowadzających rozmowy techniczne ("don't be a jerk"). Generalna i pozytywna uwaga w odniesieniu do kursu: na dwustu stronach obu dokumentów jest sporo konkretnych, wartościowych treści, obfite podlinkowania do innych artykułów - prawdziwa kopalnia wiedzy i dobrych praktyk o tym, jak skutecznie i w dobrym stylu rekrutować programistów. Ktoś wykonał kawał roboty. Nawet jeśli nie jest to w sensie ścisłym kurs, a po prostu dwie książki, to całościowo chyba warte polecenia.  (A propos dobrego stylu: nie znalazłem - może przez nieuwagę - wzmianki o konieczności udzielania informacji zwrotnej kandydatowi po rozmowie. Dla mnie jakość rekrutacji zaczyna się właśnie tutaj).

Muszę powiedzieć, że ważnym bodźcem do przyjrzenia się kursowi była możliwość przeegzaminowania się.

Egzamin pewnie nieźle sprawdza wiedzę wyłożoną we wspomnianych dwóch publikacjach. Czy jednak sprawdza, czy ktoś jest dobrym rekruterem IT? Mam wątpliwości. Czytając treść niektórych pytań z egzaminu, przypominałem sobie wielu programistów narzekających na testy programistyczne, mówiących mi: "Panie Pawle, to nijak się ma do wykonywanej przez przeciętnego programistę pracy".

Bo co powiedzieć o pytaniach takich, jak np. te?

- W jakich przedziałach czasowych Glassdoor sugeruje zbieranie feedbacku od nowozatrudnionych?

- Jaki jest koszt fluktuacji pracowników według Leigh Branhama?

- Jak wiele operatorów AND, OR lub NOT możesz użyć w jednym zapytaniu (search query) na GitHubie?

- Czy możliwe jest bezpośrednie wysyłanie wiadomości do użytkowników na Stack Overflow Talent?

Teoria, teoria, teoria...

Trzecia (z w sumie trzech) część testu - badająca wiedzę IT rekrutera - jest już całkiem niezła, jest jakoś w stanie oszacować, na ile rekruter orientuje się w pracy programisty. Biorąc jednak pod uwagę cały test, nigdy tylko na jego podstawie nie odrzuciłbym kandydata na rekrutera. Inna sprawa, że nie wyobrażam sobie testu, którym mógłbym całościowo zmierzyć czyjąś rekruterską sprawność i jakość. Jeśli miałbym wskazać jakieś jedno kryterium, które byłoby w stanie przesądzić o zdecydowanym odrzuceniu kandydata z miejsca, to byłyby to na pewno niskie standardy etyczne (np. traktowanie kandydata wyłącznie jako towar, priorytet własnej prowizji we wszelkich okolicznościach rekrutacyjnych itp.). Ale jak to sprawdzić testem?

Podsumowując, kurs DevSkillera dla rekruterów IT uważam za wartościowe kompendium dla początkujących lub tych z jeszcze nieusystematyzowaną wiedzą rekruterów IT. Traktowałbym go przy tym zdecydowanie jako uzupełnienie (zawsze wartej uzupełniania) wiedzy niż pełne opracowanie tematu rekrutacji programistów. Momentami promocja DevSkillera jako narzędzia testującego programistów była moim zdaniem zbyt - że tak to nazwę - oczywista, jednak sama inicjatywa takiego kursu, dołożenie małej cegiełki do budowania świadomości wagi dobrych praktyk w rekrutacji uważam za rzecz bardzo cenną. Duża tu pochwała za widoczną i solidną pracę dla Kuby i zespołu.

PS.

Testu nie przeszedłem (wynik: 68%, zdawalne od 80%), zatem liczę tu na znajomości ;)

_______

Nieoczywisty kandydat - oczywiste wyzwanie rekrutacyjne

Czasami kandydat o niestandardowym profilu zawodowym, oprócz tego, że sam ma niełatwo, jest też wyzwaniem dla pracujących z nim rekruterów. Wyzwaniem jednak wartym podjęcia.

Wieloletnie pisanie o rekrutacji i idąca za tym rozpoznawalność (albo przynajmniej dobra wyszukiwalność w internecie) dają możliwość poznania różnych interesujących kandydatów. Czasem takich, którzy mogą zwrócić uwagę na rzeczy, o których nie wiedziałbyś, gdyby nie oni - nawet jeśli wydawało ci się, że o rekrutacji, a zwłaszcza o rekrutacji w IT, wiesz bardzo dużo.

Za pośrednictwem facebookowej strony Rekrutacyjnego napisał do mnie kilka tygodni temu pan Jacek z prośbą o poradę zawodową. Nie są to tygodnie, w których cieszę się nadmiarem wolnego czasu, ale poniewaź prośba była konkretna i sam proszący wydawał się wiedzieć, czego chce, zgodziłem się porozmawiać. Było warto, bowiem ciekawym okazał się i sam rozmówca i przedstawiony przez niego problem.

Wyzwanie zawodowe, przed jakim stoi pan Jacek, jest następujące. W swojej dotychczasowej karierze pracował jako analityk biznesowy, ale jakiś czas temu postanowił zostać... no właśnie. I tu problem pierwszy, bo nasza innowacyjna rzekomo branża chyba nie wymyśliła jeszcze nazwy dla stanowiska, w którym chciałby realizować się mój Czytelnik. O kogo chodzi? Mówiąc prosto, o kogoś, kto pomaga firmom wykorzystać innowacje technologiczne - na przykład te tworzone przez start-upy - do zarabiania pieniędzy.

Czym różni się takie stanowisko od analityka biznesowego? O ile rolą analityka biznesowego, uczestniczącego w projekcie budowy (załóżmy) stołu, jest to, by zebrać wymagania od użytkowników i przekazać je programistom (cieślom), to ktoś taki, jak pan Jacek jest bardziej od tego, by z klientem zastanowić się, czy dla komercjalizacji pomysłów firmy (dla spieniężenia jej modelu biznesowego) potrzebny w ogóle jest stół, czy też może jakiś inny mebel albo nawet nie mebel. "Mebel" ten może być stworzony we współpracy ze start-upem/ami. Przykłady dużych firm otwartych na taki model tworzenia innowacji technologicznych to PGE Ventures czy Alior Innovation Labs.

Niestandardowa jest rola. w jakiej chciałby się obsadzić wspomniany kandydat, niestandardowo zatem podszedł do poszukiwania pracy. Centralnym elementem promocyjnym swej kandydatury uczynił nie - jak czynią niemal wszyscy kandydaci - CV, a prezentację w pdf, która dopiero pod koniec odsyła do zawodowego życiorysu. Dwie niestandardowe rzeczy (rola i sposób zaprezentowania się) to, jak widać, za dużo nieszablonowości dla rekruterów, z którymi dotychczas rozmawiał pan Jacek. Nie bardzo wiedzieli, w jakiej "szufladzie" umieścić jego preferowany profil zawodowy, a podejrzewam, że niejeden był w stanie skreślić jego kandydaturę za "brak CV".

Z jednej strony rozumiem tych rekruterów. Niełatwy do całościowego pojęcia świat IT wymaga, jeśli chcieć go pojąć, jakiegoś porządkowania i kategoryzowania - tak w obszarze technologii, jak i stanowisk informatycznych. Z drugiej strony rodzi to niebezpieczeństwo nadmiernego szufladkowania kandydatów, zwłaszcza tych o niestandardowych profilach albo takich, którzy - jako reprezentanci jakiejś kategorii - nie mają w CV czegoś, co rzekomo powinni mieć. Myślę, że cierpią na tę dolegliwość zwłaszcza rekruterzy niedoświadczeni. I ich kandydaci.

Rekruterze! Jest wyzwanie i są pieniądze do wzięcia!

Pan Jacek proponuje dwukrotność swojego docelowego wynagrodzenia rekruterowi, który znajdzie mu pracę. W grę wchodzi kwota pięciocyfrowa i nie zaczynająca się od jedynki. Po mojej rozmowie z Panem Jackiem ręczę, że nie jest to niesprzedawalny desperat. Wysoko oceniam jego kompetencje komunikacyjne w mowie i w piśmie, a to - jak dla mnie - u kandydata zawsze dobrze wróży.

Do dzieła! Pokażmy, że nadajemy się do czegoś więcej niż forward oczywistego CV nadesłanego z ogłoszenia rekrutacyjnego klientowi, który i tak zatrudnia wszystkich. Chętnym przekażę CV. Tfu, prezentację plus CV.

_______

Pojedziemy na łów, czyli na konferencję IT

Mówi się czasem w rekrutacji o wojnie o talenty (war for talent). Oznacza to po prostu, że pracowników ciężko pozyskać i że należy aktywnie o nich z innymi firmami rywalizować, czasami wręcz - umownie - toczyć wojnę. Wojna już dawno przeniosła się z tradycyjnych portali rekrutacyjnych do zawodowych serwisów społecznościowych (zwłaszcza LinkedIn), które dziś są chyba głównym polem bitewnym.

                                               _______

Prawdziwa wielka wojna rzadko jednak toczy się na jednym polu. Tak też i wojna o najlepszych (a może już po prostu - o jakichkolwiek?) w branży IT przeniosła się z rzeczywistości wirtualnej z powrotem do tzw. reala, konkretnie: na targi pracy i konferencje informatyczne. Od kilku lat zauważam coraz bardziej intensywny ruch na tym polu. Coraz więcej firm i podmiotów niekomercyjnych (grup, stowarzyszeń itp.) proponuje mi i mojej firmie udział w różnego typu wydarzeniach. W zamian za uczestnictwo (i wydane pieniądze) oferuje się nam dostęp do dziesiątków, setek, a przy największych imprezach nawet tysięcy kandydatów. 

Zależnie od profilu konferencji/targów, możemy mieć dostęp do ludzi o różnych poziomach doświadczenia (od studentów do ekspertów), o różnych profilach zawodowych (programiści, administratorzy, testerzy itd.), wreszcie o różnych profilach technologicznych. Widać tu rozwój rynku i specjalizację. W zależności od potrzeb i zasobności portfela można wybrać: rozmiar stoiska na konferencji, poziom szczegółowości danych o jej uczestnikach, możliwość mailingu do nich, możliwość wystąpienia z prezentacją, możliwość organizacji konkursu, pełne portfolio interesujących gadżetów rozdawanych uczestnikom: od piłek antystresowych aż po lody i napoje (niekiedy też antystresowe).

Osobiście bardzo lubię konferencje. Z rekruterskiej perspektywy patrząc, są dla mnie ożywczą przerwą od wirtualnej rzeczywistości setek profili na LinkedIn i wyjściem do - prawdziwych - ludzi. Są szansą spotkania byłych kandydatów. Są szansą poodpowiadania na pytania, a nie tylko (jako rekruter) ich zadawania. Są wreszcie szansą poznania konkurencji, z którą o całe te setki znających się na komputerach (głównie) mężczyzn walczymy.

Właśnie: walczymy. Mam wrażenie, że konferencje i targi - widziane wyłącznie jako polowanie na kandydata - stają się jakimś konkursem piękności i rozdawnictwa gadżetów. Stosunkowo niewiele firm jest w stanie zaproponować coś oryginalnego, wykraczającego poza proste wręczenie uczestnikowi konferencji mało wartościowego czegokolwiek w zamian za zostawienie danych kontaktowych, a najlepiej CV.

Wyobrażam sobie, że gdybym był programistą i uczestnikiem takiej konferencji, to bardziej od gadżetu - w końcu co można zrobić z piątym kubkiem, dziesiątą koszulką i siódmym zeszytem - zależałoby mi na porozmawianiu z reprezentantem firmy rzeczywiście znającym jej projekty, najlepiej też potrafiącym powiedzieć o nich cokolwiek więcej poza wymienieniem stosu technologii. A jeśli powiedział(a)by mi jeszcze o trendach w zarobkach czy trendach w zapotrzebowaniu na specjalistów w danej technologii, jeśli profesjonalnie doradziłby mi, jak odpowiadać na kłopotliwe pytania HR-owców na rozmowach rekrutacyjnych, byłbym wniebowzięty, nawet jeśli opuściłbym stoisko firmy bez wymarzonej piłki antystresowej.

Rekruterzy, mniej rozdawajcie, więcej rozmawiajcie! Wojna o talenty IT może toczyć się i na konferencjach, ale nie musi przybierać formy "zostaw mi CV, a dostaniesz długopis".

_______

fot.: Manttas@Flickr

CV doświadczonego programisty, czyli jak poradzić sobie z nadmiarem bogactwa

Napisał Czytelnik: 

"Jestem starszym programistą, mam za sobą już kilka ładnych projektów i potrzebuję przygotować nowe CV. I teraz pojawia się z tym kilka problemów. Nie w stylu 'jak napisać CV', bo robiłem to już kilkukrotnie. Raczej 'jak napisać CV dla programisty w angielskim formacie'. Generalnie istnieje założenie, że CV nie powinno mieć więcej niż 2 strony i zwykle staram się 'na siłę' utrzymać je w takich ryzach. (Co ma sens bo jak kiedyś się rozpędziłem, doszedłem do 7 i to nie był dobry pomysł. Dlatego później robiłem drugi dodatkowy dokument wydzielający opis projektów, ale to też był słaby pomysł). Dlatego nie mam pojęcia, jak opisywać 'moje poprzednie prace'. Powinienem pisać coś w stylu obowiązków, ale to jest z grubsza bez sensu bo... Miałem te same obowiązki w każdej pracy (tworzenie oprogramowania, dokumentacji, testów, praca w zespole itd.) i nijak nie opisują mnie. Mało to wnosi rekruterowi, który ostatnio stwierdził, że 'za mało napisałem o moim ostatnim projekcie'. Kiedy dla każdego projektu samego opisywania technologii zwykle jest akapit, a co dopiero opisywania sensu samego projektu. Stąd moje pytanie koronne: Jak programista powinien opisywać swoje poprzednie prace?"

Zanim odpowiem na główne pytanie zadane w ostatnim zdaniu, kilka uwag do tego, co czytelnik napisał wcześniej.

Po pierwsze, nie wiem, skąd wzięła wśród kandydatów liczba dwóch stron jako maksymalna możliwa, jaką może mieć CV. Pewnie podpowiedział to jakiś nie lubiący czytać CV rekruter. Słyszałem też o limicie jednej strony - to już musiał podpowiedzieć naprawdę ktoś mający na CV alergię. Może to rada dobra dla rozpoczynającego karierę absolwenta, ale osoba już z paroma pracami za sobą (i to takimi, gdzie coś w nich robiła) będzie mieć ze zmieszczeniem się na jednej stronie spory problem. Czy sam mam jakąś zalecaną osobiście długość CV? Sądzę, że rozsądnie jest, jeśli autor CV mieści się pomiędzy dwiema a czterema stronami.

Po drugie, nie wiem dlaczego "słabym pomysłem" jest stworzenie oddzielnego dokumentu z dokładnie opisanymi projektami. Jeśli projektów rzeczywiście jest dużo, są na tyle urozmaicone, że opisanie każdego z nich osobno ma sens i autor nie chce niczego pominąć, to moim zdaniem stworzenie oddzielnego dokumentu jest pomysłem niezłym. Trzeba tylko pamiętać, by wspomnieć o dokumencie w głównym CV - najlepiej zrobić w nim jakiś odnośnik. Dokument z opisanymi projektami nie musi być wcale wysyłany jako plik, może być po prostu zamieszczony gdzieś, i łatwy do ściągnięcia/przeczytania, w sieci.

Jak programista powinien opisać poprzednie prace, jeśli nie chce w kolejnych pozycjach powtarzać de facto tych samych obowiązków, które wykonywał na kolejnych stanowiskach? Może to zrobić, opisując swoje doświadczenie i kompetencje w części "Profil zawodowy" - zwykle gdzieś na początku CV - a potem w dalszej części wymienić tylko poszczególnych pracodawców, projekty i daty zatrudnienia. No i technologie: nie wierzę, że jest programista, który w ciągu kilku lat pracy na kilku różnych projektach w każdym miejscu pracował w identycznym stosie technologii. To samo z sensem biznesowym tworzonej aplikacji. Jest sens pisać - oby zrozumiale - o takim sensie, bo dla osób nietechnicznych (w tym niektórych niekompetentnych rekruterów) może to być jedna z bardziej zrozumiałych części takiego programistycznego CV.  

Przykładami "Profili zawodowych", gdzie można powpisywać powtarzalne, "generyczne" elementy doświadczenia, mogą być niektóre "Summary" profili na LinkedIn (kliknij, by powiększyć):

Zachęcałbym jednak, mimo wszystko, do napisania przynajmniej paru zdań na temat każdego z miejsc, w których się pracowało. Jedno zdanie o samej firmie, jedno o projekcie (z biznesowej perspektywy) plus wymienienie technologii, z którymi miało się w danym miejscu do czynienia - wszystko to powinno dać czytającemu niezbędne minimum wiedzy przed rozmową rekrutacyjną.

Na koniec, kilka "lektur uzupełniających", które powinny pomóc temat programistycznego CV zgłębić na poziomie Senior (jeśli nie Ninja):

"10 resume do’s and don’ts for developers" (źródło: CIO Magazine) - zgadzam się ze zdecydowaną większością danych tu wytycznych

10 rzeczy niekoniecznie potrzebnych w CV - mój wpis z 2013 roku

Co możesz wyrzucić z CV - inny mój wpis z 2013 roku

Trzy typowe błędy w CV specjalisty IT - wpis z 2012 roku

Z wytycznymi ze swoich dawnych wpisów też nadal się zgadzam :)

Mam nadzieję, Drogi Czytelniku, że przygotowanie CV będzie teraz dla Ciebie dużo łatwiejsze.

_______

Czy warto znać Angulara? Wspomnienie z konferencji ng-Poland

Mówiłem niedawno na konferencji ng-Poland o tym, dlaczego być może warto znać zdobywający coraz większe uznanie w świecie programowania framework AngularJS. W prezentacji swej poruszyłem kilka wątków ogólniejszych, ciekawszych pewnie także dla nie-programistów albo nie-frontendowców, stąd pomyślałem, że może warto byłoby nimi podzielić się także tu, na blogu. A może i ci spośród 700 uczestników konferencji, którzy widzieli prezentację, ucieszą się z wpisu, gdyż podzielę się tu dokładniej danymi, które przytoczyłem.

Prezentacja miała być o najpopularniejszym dziś frameworku frontendowym (AngularJS). Wiedziałem, że jest to technologia w warstwie prezentacyjnej współczesnych aplikacji wiodąca - choćby po coraz częstszych rekrutacjach na specjalistów znających AJS, które w mojej firmie prowadzimy. Co innego jednak wyrywkowe spostrzeżenia z zawsze wąskiej perspektywy jednej firmy, a co dające pełniejszy obraz, o dużej skali dane. Choćby z Google'a, gdzie każdy dziś wyszukuje informacje; choćby z GitHub, z którego korzysta 14 milionów programistów, czy ze StackOverflow, z którego - przynajmniej od czasu do czasu - korzysta chyba każdy.

kliknij, by powiększyć

Widać z powyższego, że mówienie o przewadze Angulara nad innymi frameworkami czy bibliotekami frontendowymi to trochę niedopowiedzenie. Zwłaszcza w przypadku wyszukiwań w Google bardziej oddającym rzeczywistość słowem byłaby przepaść.

Czy taka dominacja Angulara przekłada się na zarobki ludzi go znających? Tu niespodzianka - niekoniecznie.

kliknij, by powiększyć

Zarówno w USA, jak i w UK - krajach o transparentnej co do zarobków kulturze - znający Angulara mogą liczyć na porównywalne zarobki do tych, którymi cieszyć się mogą znający pozostałe wymienione tu technologie. Na powyższej grafice pokazane są zarobki średnie, w UK mediany, ale wniosek ten sam. 

Statystyki dotyczące USA zaczerpnąłem z serwisu Indeed.com. Można pobawić się i posprawdzać zarobki w innych technologiach. Szkoda, że nie ma danych dla Polski, ale USA to w końcu kraj w technologiach wyznaczający trendy, a więc pewnie i w jakimś stopniu w zarobkach w technologiach.

Natomiast danych o zarobkach w Wielkiej Brytanii dostarczył mi serwis itjobswatch.co.uk. Pod względem różnorodności i kompletności danych jeszcze lepszy niż Indeed.com.

Nawiasem mówiąc, niespecjalnie dziwi mnie, że pracodawcy oferują często podobne pieniądze specjalistom od technologii dominujących (jak AngularJS) i tym od technologii niszowych czy wręcz schyłkowych. Jeśli nie mogą zaoferować programistom nowoczesnych technologii, czasem jedyną rzeczą, jaką mogą próbować im to zrekompensować, są pieniądze.

Angularowcy i reszta zarabiają więc podobnie. Czemu więc całe to halo wokół Angulara?

Temu.

kliknij, by powiększyć

To liczba ofert w USA pochodzących z portali pracy i zagregowanych przez Indeed.com. Widać, że w ostatnich latach AngularJS znokaoutował rywali (w tym nomen omen KnockoutJS) i dziś ofert pracy dla ludzi znających Angulara jest ok. 10 razy więcej niż ofert dla specjalistów pozostałych wymienionych tu technologii.

W Polsce przewaga Angulara nie jest aż tak duża, a po piętach dzielnie wydaje się mu deptać React. Dalej to jednak 2.5 raza więcej ofert dla ludzi od AJS (dane za Pracuj.pl).

kliknij, by powiększyć

Choć we frontendzie króluje dziś Angular, warto pamiętać, że relatywnie niewiele jest technologii, którym udaje się zachować panowanie w długiej, wieloletniej skali. Przykłady z przeszłości?

kliknij, by powiększyć

Może nie wszystkie z nich dominowały (GWT pewnie nie), ale były co najmniej bardzo obiecujące, a na pewno już nie są, przynajmniej z perspektywy szans zawodowych, czyli ofert pracy dla specjalistów znających te technologie.

(Poruszyłem też w prezentacji ciekawe zagadnienie cyklu życia technologii w aspekcie jej popularności, dojrzałości i "wykorzystywalności". Tu jedynie nadmieniam, a zainteresowanych szczegółami zapraszam tu (Gartner Hype Cycle na Wikipedii) oraz tu (info ze strony Gartnera).

Gdy zaczynałem przygodę z rekrutacją w 2005 roku, nowatorskimi rzeczami we frontendzie były rzeczy takie jak JSP czy Flash. Dawno już nie są. Trudno przewidzieć, jak będzie wyglądał - z perspektywy zapotrzebowania zawodowego i płac - świat frontendowy w, powiedzmy, 2020 roku. Czy dalej dominować będzie Angular? Czy znajdzie godnego rywala w React.js? A może pojawi się ktoś trzeci?

Jak by się to nie potoczyło, jedyną sensowną strategią programistów, by optymalnie wykorzystać i tak sprzyjającą im sytuację na rynku pracy, jest trzymanie ręki na pulsie tego, co dzieje się w technologiach. To niekoniecznie śledzenie wszystkich trendów i uczenie się każdego nowego frameworka, o którym ostatnio zrobiło się głośno. Bycie najzwyczajniej ciekawym, otwartym na nową wiedzę i w miarę możliwości aktywnym - to już sporo, by nie być "niewyedukowanym następnego dnia". 

_______

fot.: SP

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ę

_______

Rekruterzy IT w oczach specjalistów IT - wyniki ankiety

Na początku lipca ogłosiłem w bliskich mi rejonach internetu (w tym tu na blogu) ankietę adresowaną to specjalistów IT, w której mieliby wypowiedzieć się, co cenią (a co niekoniecznie) u rekruterów IT. Spędziwszy 11 lat po tej (rekruterskiej) stronie barykady chciałem nieco bardziej empirycznie przekonać się, jak odbierają nas, rekruterów, ci z drugiej jej strony, a więc programiści, administratorzy, testerzy, analitycy, architekci, project managerowie itd. - czyli ci, od których de facto jakoś zależy nasze zawodowe życie.

Wpadłem przy tym na pomysł, by to swoiste badanie opinii i preferencji wśród specjalistów IT mogło dać odpowiedź na pytanie: z jakim typem rekrutera wolą mieć do czynienia. Typy naturalnie nasunęły mi się dwa, a nazwałem je - roboczo i oczywiście bez uwzględniania tego w ankiecie - 1) rekruter-sprzedawca i 2) rekruter-nerd.

Dlaczego takie? 

Trochę upraszczając - rzeczywistość zawsze jest bogatsza niż klasyfikacje i typologie - w swojej dotychczasowej karierze zetknąłem się takimi dwoma wzorami rekruterów. Przykładowo, gdy zaczynałem przygodę w rekrutacji, trafiłem do środowiska, w którym od rekrutera oczekiwało się, że zanim rozpocznie rekrutację na stanowisko np. Programisty Embedded, to najpierw dobrze zrozumie, czym są systemy embedded. Słowem: oczekiwano, że będę rekruterem-nerdem. Z kolei w innym momencie swojej kariery znalazłem się w miejscu i pod kierownictwem osób, które mniejszą (jeśli nie żadną) wagę przywiązywali do tego, co będę wiedział, a interesowało ich wyłącznie, czy sprzedam kandydata klientowi - w skrócie: oczekiwano, że będę rekruterem-sprzedawcą.

Jeszcze raz: rekruter-nerd i rekruter-sprzedawca są ekstremami lokującymi się na przeciwległych końcach jakiegoś continuum. W rzeczywistości większość rekruterów jest w jakimś stopniu i tym i tym. Mimo to, dość często zdarza się, że przewaga jednego elementu (sprzedażowego czy nerdowskiego) idzie w parze z mniejszą ilością drugiego. Dla przykładu, kiedy poszukuję osób do swojego zespołu i rozmawiam z rekruterami pochodzącymi z firm rekrutacyjnych o wybitnie sprzedażowym charakterze (gdzie rekruterzy mają np. targety na wysłaną ilość CV), dość często zauważam pewną prawidłowość polegającą na dominacji u tych kandydatów pierwiastka sprzedażowego przy jednoczesnych niedostatkach (czasem sporych) w wiedzy IT. Obrazowo mówiąc, są wygadani, ale .NET uważają za język programowania.

W swoim eksperymencie badawczym chciałem sprawdzić, jak oba typy rekruterów traktowane są przez rekrutowanych, czyli specjalistów IT. Stworzyłem ankietę, w której zebrałem listę 19 cech (pozytywnych), chcąc, by respondenci oddzielnie odnieśli się do każdej z nich poprzez ocenienie jej ważności. Użyłem 5-stopniowej skali, gdzie najwyższy stopień pożądania danej cechy określony był jako konieczny, a najniższy jako obojętny (trzy środkowe to: bardzo istotny, raczej istotny i mało istotny).

Ankietę rozpropagowałem tu na blogu (w tym na jego profilu na Facebooku), na kilku programistycznych stronach na FB oraz na LinkedIn i GoldenLine (zwłaszcza wśród swoich kontaktów tam). Nie była to więc próba losowa, o czym jeszcze napiszę, komentując metodologię badania. (Jeden z wyżej wymienionych serwisów nie udźwignął wydajnościowo wiadomości wysłanych przeze mnie moim kontaktom, przez co otrzymali oni pustego maila w temacie i w treści. Dobrze, że wówczas to nie mi przyszło oceniać specjalistów IT z tego serwisu. Albo może tak: dobrze, że uczyniłem to tylko w samotności i pod nosem).

Pytanie, jakie zadałem specjalistom IT, było tylko jedno i brzmiało: Gdy kontaktuje się z Tobą rekruter IT, jak istotne są dla Ciebie jego następujące cechy?

I tak dalej, dla wszystkich 19 cech.

Zależało mi, by każda cecha oceniona została niezależnie, z na ile to możliwe małym odnoszeniem się do innych. Dlatego zamiast łatwego zaznaczania preferencji ptaszkami (co mogłoby skutkować pewną mechanicznością i bezrefleksyjnością w wyborach) użyłem list rozwijanych ("drop-down"). Dodatkowo, cechy pomieszałem tak, by cechy jednego typu nie grupowały się; by cechy rekrutera-nerda i rekrutera-sprzedawcy ułożone były naprzemiennie.

Rekrutera-sprzedawcę scharakteryzowałem następującymi cechami: sympatyczny, dający się lubić, ekspresyjny, energiczny, przekonujący, interesujący rozmówca, pewny siebie, z poczuciem humoru. Rekrutera-nerda zaś określiłem tak: znający branżę IT, słuchający, nienachalny, orientujący się w technologiach, znający stanowiska IT.

Pozostałe 6 cech (doświadczony, pracujący w rozpoznawalnej firmie, znający się na ludziach, wiarygodny, dotrzymujący słowa, szczery i otwarty w komunikacji) dodałem, by mieć jeszcze lepszy ogląd (na ogół pożądanych) cech rekruterskich i ich ocen przez specjalistów IT.

Ankiety wypełniło - stan na 25. sierpnia - 455 osób. Statystyczny respondent miał 34 lata, 11 lat doświadczenia zawodowego i w prawie 12% był kobietą.

Tyle jeśli chodzi o genezę, założenia i metodologię badania. Pora na wyniki.

kliknij, by powiększyć

Powyżej lista wszystkich uwzględnionych w badaniu cech - w takiej kolejności, w jakiej oceniali je respondenci.

A poniżej lista uwzględniająca cechy rekrutera-sprzedawcy i rekrutera-nerda.

kliknij, by powiększyć

Nie wiem, czy najszczęśliwiej wybrałem epitety "sprzedawca" i "nerd" dla określenia dwóch interesujących mnie typów rekruterów. Pewnie można byłoby lepiej. Jeśli jakiś czytelnik zwróci mi uwagę na mocną arbitralność tej typologii (sprzedawca vs nerd) albo na daleko posuniętą stereotypizację w charakterystyce rekrutera-sprzedawcy, też przyznam niemało racji. Tak samo z cechą "słuchający" - można by nie bez dozy racji spierać się, dlaczego przypisałem ją nerdom, a nie sprzedawcom.

To wszystko prawda, ale nawet jeśli tak zarysowane typy są arbitralne (a są), zaś przypisane im cechy dyskusyjne (niektóre są), to i tak całościowo i w ogólnym zarysie - moim zdaniem - trafnie ujmują one dwa dające się zauważyć w rzeczywistości podejścia do rekrutacji. Podejścia, których przykłady podałem w pierwszej części wpisu, gdzie opisałem swoje początki i to, czego oczekiwano ode mnie jako rekrutera w różnych środowiskach.

Przy tak dobranych cechach, specjaliści IT zdecydowanie silniej opowiedzieli się za tymi, które charakteryzują rekruterów-nerdów. Dlaczego bycie słuchającym i nienachalność uwzględniłem w cechach rekrutera-nerda, jeśli z wiedzą IT nie mają nic wspólnego? Dlatego, że bycie rekruterem-nerdem rozumiem tu trochę szerzej niż tylko jako znajomość IT. To także niebycie (zwłaszcza agresywnym) sprzedawcą. W relacji z kandydatem to bardziej słuchanie, a nie mówienie. W przedstawianiu mu swojej oferty to bardziej nienachalność niż przekonywanie. (A jeśli przekonywanie, to właśnie bardziej - może paradoksalnie - przez nienachalność.)

Czy nerdzi (specjaliści IT) aż tak wolą rekruterów-nerdów? Czy możliwe jest bycie sprzedawcą-nerdem? I jak stać się bogatym?

Odpowiedzi na te i inne pytania w następnym wpisie.

_______

grafika: talent.LinkedIn.com