niedziela, 5 lutego 2017

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

Co możesz wyrzucić z CV - inny mój wpis z 2013 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.

_______

sobota, 21 stycznia 2017

Gdy kandydat to towar a jego sprzedaż to spam

Kandydat to nie towar. Z jego CV - a już na pewno z danymi osobowymi - nie powinno się robić, co się komuś podoba. Warto, by pamiętały o tym niektóre firmy rekrutacyjne. Można lepiej przysłużyć się i klientom i kandydatom, niż spamując skrzynki tych pierwszych aplikacjami tych drugich.

_______

Obserwuję od jakiegoś czasu nasilenie pewnej praktyki stosowanej przez niektóre firmy rekrutacyjne; praktyki, która jest pewnie tak stara, jak stara jest sama branża, ale która mimo to nigdy nie zdobyła mojej sympatii. Chodzi o przesyłanie przez rekruterów CV kandydatów do firm bez wcześniejszego nawiązania kontaktu z daną firmą i upewnienia się, czy firma chce w ogóle otrzymać takie - anonimowe - CV. Zwiększony napływ tego typu "propozycji współpracy" otrzymuję zwykle po opublikowaniu ogłoszenia rekrutacyjnego na którymś z portali. Firma rekrutacyjna (czy reprezentujący ją rekruter) dzięki ogłoszeniu wie, że poszukuję kogoś o danym profilu, spodziewa się więc, że otrzymane CV jednego lub więcej kandydatów zachęci mnie do podjęcia rozmów i "kupienia kandydata". Ale bywa i tak, że otrzymuję propozycje aplikacji zupełnie nietrafionych, w żaden sposób nie pasujących do tego, kogo dziś i dawniej poszukiwała moja firma.

Mam z taką praktyką kilka problemów.

Po pierwsze, nie podoba mi się sama filozofia - niestety częsta w branży rekrutacyjnej - traktowania CV jako towaru, który można sprzedać komukolwiek. Firmy rekrutacyjne często deklarują, że dbają o interes kandydata. "Z nami twoja kariera nabierze rozpędu" (sam wymyśliłem ten kiepski slogan - proszę nie przypisywać go do żadnej firmy :) i tym podobne. Jak to się ma do wysyłania CV kandydata de facto byle gdzie, tylko dlatego, że ten byle ktoś akurat kogoś poszukuje? I jak to się ma do "najlepszego dopasowania kandydatów do kultury klienta", jeśli tego "klienta" zna się tylko z adresu mailowego?

Po drugie, CV kandydatów, które otrzymują, tylko w teorii są anonimowe. Nawet jeśli usunięte zostały w nich dane osobowe i kontaktowe, wystarczy oparty o pozostałe zawarte w CV dane Google lub LinkedIn search, by łatwo odgadnąć tożsamość właściciela CV. Gdybym był takim prowizorycznie zanonimizowanym kandydatem, nie chciałbym, by moje - łatwe do zidentyfikowania - CV wysyłane było gdzie bądź. Inna rzecz, że znam przypadki wysyłania  p e ł n y c h  CV bez wiedzy i zgody kandydatów...

(Ciekawym etycznym problemem jest możliwość łatwego dotarcia przez otrzymującą CV firmę do właściwego kandydata i zaproszenie go do rekrutacji z zupełnym - i formalnie zgodnym z prawem - pominięciem firmy rekrutacyjnej. Ciekawe dyskusje na ten temat tutaj: Can you hire a candidate that a recruitment agency provided a CV (unsolicited) of without going through the agency?  i tutaj: Going around a recruiter who submits unsolicited candidates )

A po trzecie, jako rekrutujący w branży IT - a więc takiej, gdzie to raczej pracodawcy usilnie poszukują specjalistów niż odwrotnie - mam dużo wątpliwości co do rekomendowanego mi specjalisty, który by znaleźć pracę, musiał udać się do firmy rekrutacyjnej i teraz przez tę firmę wysyłany jest w ciemno do pewnie tuzina firm.

Nie oznacza to, że praktykę tę totalnie potępiam. Jeśli przeprowadzona w sposób cywilizowany, taka sprzedaż kandydata może pewnie czasem zaowocować trójstronnym (firma rekrutacyjna - klient - kandydat) zadowoleniem. A jak ucywilizowałbym ją? Proponuję na początek:

1) Uzyskiwać od kandydata przez firmę rekrutacyjną wyraźną zgodę na to, by jego CV było rekomendowane różnym klientom. Idealnie byłoby, gdyby kandydat wiedział, ilu i jakim konkretnie klientom i z jakim efektem jego kandydatura została zarekomendowana, ale postaram się nie być naiwny.

2) Przed zarekomendowaniem kandydata klientowi zrobić przyzwoity research nt. tego klienta. Dowiedzieć się: jakich kompetencji potrzebuje, czy współpracuje z firmami rekrutacyjnymi i czy jest otwarty na otrzymywanie niezapowiedzianych rekomendacji obcych kandydatów. 

Bo jakoś jednak przykro mi, gdy otrzymując maile od nieznanych mi rekruterów z niepotrzebnymi mi kandydatami, muszę potraktować je jako spam, załatwiając całą sprawę naciśnięciem klawisza "delete".


_______

wtorek, 3 stycznia 2017

Klasa społeczna w rekrutacji, czyli kiedy "dobre pochodzenie" ułatwia zatrudnienie

Aplikując do niektórych firm, trzeba uważać, co wpisuje się w CV w sekcji hobby. Czasem - jeśli posiada się hobby nasuwające skojarzenia z taką a nie inną klasą społeczną - lepiej  już nie wpisywać nic.






Pisałem ponad rok temu o powodach tych odrzuceń kandydatów przez rekruterów, które wynikają z postrzeganej przynależności kandydata do tej czy innej klasy społecznej, przynależności dostrzegalnej np. w sposobie wypowiadania się czy ubiorze. Tamten wpis dotyczył Wielkiej Brytanii, konkretnie londyńskiego City, gdzie rekruterzy z elitarnych firm są w stanie odrzucić kandydata tylko dlatego, że ma on np. sugerujący robotnicze pochodzenie akcent. 

Zetknąłem się niedawno z ciekawym badaniem socjologicznym - jego szczegóły opisane w tym artykule - którego autorzy postanowili sprawdzić, jak na różne wskaźniki klasowego backgroundu aplikujących kandydatów reagować będą rekruterzy z tym razem amerykańskim firm prawniczych. Socjologowie stworzyli fikcyjne CV absolwenta prawa dobrej uczelni i rozesłali je do 316 biur reprezentujących 147 najlepsze firmy prawnicze w 14 miastach USA. CV stworzone zostało w kilku wersjach, różniących się tylko i wyłącznie co do wspomnianych wyznaczników klasy społecznej oraz płci. Wszystkie "merytoryczne" zmienne - dotyczące doświadczenia czy osiągnięć edukacyjnych kandydatów - były we wszystkich wysłanych CV identyczne.

Klasowymi wyróżnikami w hipotezach badawczych autorów miały być: nazwisko kandydata, typ dodatkowej działalności studenckiej (w tym też typ uprawianego sportu) oraz jego zainteresowania.

źródło: American Sociological Review za: HBR.org
CV zostały wysłane, a badacze uzbroili się w cierpliwość, czekając na telefony od rekruterów ze wspomnianych firm. 

Co się okazało? Zgadliście. Subtelne znaki wskazujące społeczne "dobre pochodzenie" znacząco zwiększały szansę odebrania telefonu od rekrutera oraz bycia zaproszonym na rozmowę. Istotne przy tym, że decydującą rolę odegrała także płeć kandydata/tki. Wśród kandydatów wyglądających na pochodzących z klasy wyższej zdecydowanie faworyzowano mężczyzn, wśród tych zdradzających pochodzenie z klasy niższej - kobiety. (Zainteresowanych interpretacjami zapraszam do oryginalnego artykułu.)

Jak to się może mieć do Polski? Jako kraj bardzo różnimy się od i USA i od Wielkiej Brytanii pod względem kształtu i stabilności naszej struktury klasowej. W skrócie: jesteśmy społeczeństwem dość jednorodnym - w porównaniu z tamtymi - jeśli chodzi o pochodzenie i względnie egalitarnym jeśli chodzi o style życia. U nas pewnie dużo trudniej byłoby stworzyć modelowe CV zdradzające na podstawie aktywności studenckich czy hobby, jaką jego posiadacz reprezentuje klasę społeczną. Sposób spędzania czasu wolnego coraz bardziej demokratyzuje się i jeśli chcieć by tworzyć fikcyjnych polskich kandydatów należących do różnych klas, trzeba byłoby pewnie odwołać się do bardziej twardych wskaźników, jak miejsce zamieszania czy ukończona uczelnia.

Wtedy, być może, polscy rekruterzy pracujący w lub dla renomowanych firm prawniczych czy konsultingowych, dokonując wstępnej selekcji kandydatów, chętniej sięgaliby np. po tych pochodzących z dużych miast i kończących dobre (albo przynajmniej znane) uczelnie. Sądzę jednak, że aktywności studenckie albo hobby nie sprawdziłyby się w naszych realiach jako przybliżony choćby wskaźnik klasy społecznej. (I nie piszę tego tylko dlatego, że piłka nożna w moim CV lokowałaby mnie pewnie wśród kandydatów o niezbyt wyrafinowanych gustach i przynoszącym mały splendor pochodzeniu).

Są branże mniej i bardziej podatne na czynnik klasy społecznej w rekrutacji. Bliski mi sektor IT jest mało podatny. Umiesz programować - możesz mieć w hobby co chcesz, mówić jak chcesz, wyglądać jak chcesz i pochodzić, skąd chcesz, a i tak wiele firm będzie cię chciało. Inaczej np. w sektorze dóbr luksusowych czy usług/produktów premium. Przeglądając (co właśnie zrobiłem) ogłoszenia o pracę ich dotyczące, w wymaganiach dla kandydatów bardzo często spotkać można "wysoką kulturę osobistą", "profesjonalną aparycję" itp. To bardzo subtelna wskazówka, że tu pochodzenie kandydata - manifestowane przecież przez prezencję - może mieć znaczenie.


_______
fot.: bbc.co.uk


niedziela, 11 grudnia 2016

Jack Arnold zdradza sekret zadowolenia z obranej drogi zawodowej

Stare powiedzenie mówi, że jak się nie ma tego, co się lubi, trzeba lubić to, co się ma. A że w sferze zawodowej rzadko jest tak, że ma się wszystko, czego się chce, zaczęcie lubić tego co się ma wydaje się bardzo rozsądną opcją.

Wróciłem ostatnio do czasów późnego dzieciństwa za sprawą przypomnienia sobie serialu "Cudowne lata". Czasy te w moim przypadku to początek lat 90-tych, a jednym z popularniejszych seriali emitowanych wówczas były właśnie "Cudowne lata". Opowiadały one o w zasadzie zwyczajnym, codziennym świecie nastolatka z Ameryki przełomu lat 60-70-tych, Kevina Arnolda, ale opowiadały w wyjątkowo ciepły i mądry sposób - przynajmniej tak to z tamtych czasów zapamiętałem. Kilka tygodni temu postanowiłem sprawdzić, jak serial podobać mi się będzie dziś.

Jeden z pierwszych odcinków, do których dotarłem, miał tytuł "Biuro mojego ojca" i przyniósł kilka ciekawych spostrzeżeń na temat pracy, kariery i satysfakcji zawodowej - temat w sam raz na wpis na Rekrutacyjnym.

W odcinku tym Kevin przygląda się pracy swego ojca - Jacka Arnolda, managera średniego szczebla w dziale logistyki firmy Norcom. Zauważa, że surowość ojca w domu - i tak spora - rośnie wprost proporcjonalnie do poziomu stresu, z jakim zetknął się danego dnia w pracy. Przede wszystkim jednak uświadamia sobie, że tak naprawdę kompletnie nie wie, czym ojciec się zajmuje. Czym zajmuje się manager średniego szczebla w dziale logistyki?


Ojciec postanawia zabrać Kevina do biura, by pokazać mu, co robi i jak pracuje. Następnego dnia obaj wystrojeni w garnitury przekraczają progi mitycznego Norcomu. Tam Kevin powierzchownie wprawdzie, ale poznaje specyfikę pracy managerskiej; imponuje mu sposób, w jaki ojciec załatwia sprawy (często kilka na raz), w jaki wydaje polecenia; jest pod wrażeniem autorytetu, jakim się cieszy.

Podczas przerwy na kawę w kuchni Kevin - sam na sam z ojcem - próbuje dowiedzieć się (trochę jak rekruter) na temat zawodowej historii ojca.

- Tato, kiedy zdecydowałeś, że zostaniesz managerem dystrybucji i usług serwisowych?
- (śmiejąc się) Przepraszam. To zabawna myśl: chcieć zostać managerem dystrybucji i usług serwisowych. To znaczy... To dobra praca, ale nie jest to coś, o czym myślałem, że będę robił w życiu.
- A co chciałeś robić?
- Chciałem być zawodowym graczem bejsbola.
- Naprawdę?
- Tak. Miałem jeszcze opcję zapasową. Nigdy nikomu tego nie mówiłem, nawet twojej mamie. Gdy byłem dzieckiem, chciałem być kapitanem statku. Wiesz, któregoś z tych wielkich frachtowców czy nawet tankowca. Cudownie byłoby stać na mostku w środku nocy i nawigować, kierując się gwiazdami. Oczywiście, dziś są od tego urządzenia, ale wtedy o tym nie wiedziałem. Tak, myślałem wtedy, że to byłaby najcudowniejsza rzecz na świecie.
- To czemu tego nie zrobiłeś?
- Hmm, wiesz, jedna rzecz prowadzi do drugiej. Poszedłem na studia, spotkałem twoją mamę. Następnego lata znalazłem pracę w doku rozładunkowym tu w Norcomie. Reszta jest historią.
- Byłbyś świetnym kapitanem statku, tato.
- Nie, pewnie nie. Pewnie miałbym chorobę morską. Wiesz, Kevin... Nie możesz zrobić każdej głupiej rzeczy, na jaką masz ochotę w życiu. Musisz dokonywać wyborów. Musisz próbować i starać się być szczęśliwy z tych wyborów. Myślę, że ułożyło nam się całkiem dobrze, co?
- Myślę, że ułożyło nam super.

Uważam postawę pana Jacka Arnolda za dojrzałą i mądrą. W 99% przypadków nie robimy tego, o czym marzyliśmy. Większość współcześnie istniejących zawodów nie jest ekscytujących jak bycie graczem bejsbola czy kapitanem statku. Zawodowe realia to raczej praca w biurze, np. w dziale X, w firmie Y. Raporty, maile, spotkania, telefony... "Musisz dokonywać [z dostępnej ci puli] wyborów i próbować być szczęśliwy z tych wyborów".

A na koniec, by już ostatecznie przesądzić, że pan Jack Arnold jest osobą mądrą, on sam powie o najważniejszym momencie w dniu pracy:




_______
fot.: TimeLife.com

poniedziałek, 28 listopada 2016

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

wtorek, 1 listopada 2016

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

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


_______