Przepis na udany proces rekrutacji IT.

Dosyć spontanicznie powstał ten artykuł, a to za sprawą ankiety, którą wypełniałem dla No Fluff Jobs (https://nofluffjobs.com/). Na samym końcu spotkałem się z propozycją konkursu:

Początkowo zacząłem coś tam pisać w małym okienku, ale uznałem, że jest to bardzo dobry temat na artykuł!

Gdy jestem na etapie zmiany pracy, zazwyczaj w ofercie nie znajduję żadnych przydatnych informacji (poza widełkami). Głównie znajdują się w niej informacje o bibliotekach, które są używane (średnio ważne detale) lub o tym że jest wykorzystywany SCRUM ale po pierwszej rozmowie okazuje się, że to jest „SCRUM” ale taki własny bez daily i bez Product Ownera. Dlatego zawsze mam mnóstwo pytań.

Jestem z tych osób, które zawsze szukają pracy aktywnie tzn. planuję odejście z pracy z min. półrocznym wyprzedzeniem – wtedy dopiero zaczynam odpowiadać na oferty. Dlatego też forma ogłoszenia nie jest dla mnie aż tak bardzo istotna, ponieważ i tak przeprowadzam własne śledztwo. W artykule opiszę jak chciałbym aby wyglądała każda rekrutacja począwszy od oferty aż do przyjęcia na stanowisko, taki sposób powinien wyeliminować niedomówienia, które mogą być powodem niezadowolenia z pracy.

Udany proces rekrutacji

Rekrutacje są jak gra, w której 2 strony chcą jak najwięcej przed sobą ukryć. Pracodawca chce ukryć, że ma słabo utrzymany projekt i nikt nie chce nad nim pracować a kandydat swoje braki kompetencji udając specjalistę z najwyższej półki. Aby tak karykaturalnie nie wyglądał cały proces rekrutacji obie strony muszą być wobec siebie szczere.

Pracodawca szybko straci nowego pracownika, któremu obiecał czysty kod pokryty testami w 100% jeśli ten po przyjściu do pracy zobaczy klasy mające 10k linii oraz dodaną bibliotekę volkswagen https://github.com/auchenberg/volkswagen. Strata pracownika to jedno, ale strata dobrego imienia na rynku może utrudnić późniejsze rekrutacje. Szczerość pozwoli na znalezienie programistów, którzy będą chcieli pracować nawet w słabo zarządzanym projekcie – będzie to stanowiło dla nich wyzwanie aby doprowadzić taki projekt do używalności.

Udana rekrutacja to przede wszystkim zadowolone obie strony, które uzyskały wspólne porozumienie oraz wiedzą o swoich wadach i zaletach.

Pierwszy kontakt czyli ogłoszenie o pracę

Pierwszy kontakt zachodzi prawie zawsze ze strony pracodawcy (przez ogłoszenie albo przez rekrutera). To od ogłoszenia zależy czy oferta trafi do odpowiedniego kandydata i czy kandydat się nią wystarczająco zainteresuje, żeby przesłać swoje CV (owocowe czwartki i piłkarzyki nie przyciągną profesjonalistów, a jedynie benefit hunterów). Oferta o pracę nie powinna wyglądać jak reklama Mango!

Powitanie

Miło jeśli poza zwykłym powitaniem jest nawiązanie do doświadczenia, elementów będących na profilu LinkedIn lub publikacji. Wtedy wiadomo, że osoba rekrutująca zapoznała się z profilem kandydata i jego oferta spełnia prawdopodobnie kryteria kandydata jak i kandydat spełnia kryteria oferty. To nie może być długa litania na obszarach lizusostwa ale jednozdaniowa szczypta kurtuazji.

Niektórzy pisząc wiadomość nie zauważają istotnej różnicy pomiędzy oryginalnością a infantylnością co w przypadku ofert dla bardziej doświadczonych programistów może przynieść skutek odwrotny niż zamierzony – żal, żenada, brak słów.

Oferujemy

„Oferujemy” to sekcja, która jako pierwsza przyciąga wzrok kandydata szukającego widełek. Niestety, w tej sekcji umieszczane są zwykle benefity oraz informacja o „konkurencyjnych zarobkach”, która znaczy tyle co „napisz priv”. Jeśli w branży IT nie ma podanych widełek to oferta będzie ignorowana przez duże grono programistów – taki mamy klimat, sorry.

Ogólniki w ofercie są niewidoczne dla kandydata, oferta powinna zwierać tylko konkrety. Kandydat nie powinien tracić czasu na zastanawianie się i przygotowywanie podstawowych pytań dla rekrutera. Mało precyzyjne ogłoszenie od razu zniechęca osoby, które nie poszukują aktywnie pracy i nie chcą marnować swojego czasu. Ogłoszenie powinno zawierać jasne i konkretne dane np.:

Budżet szkoleniowy od 3000zł ~~możliwości rozwoju~~
4 osobowy zespół mobilny (7 lat, 5lata, 5lata, 2lata doświadczenia w aplikacjach mobilnych) ~~młody i dynamicznie rozwijający się zespół~~
2 testerów automatycznych (Appium) i jeden manualny ~~testerzy w zespole~~
Praca na najnowszych modelach telefonów (Samsung S10, OnePlus 7t Pro), zakup najnowszych modeli po premierze, Android Home, Android TV, wykorzystanie Dialogflow, możliwość wyboru sprzętu komputerowego raz na 2 lata (budżet 15k) ~~dostęp do najnowszych technologii~~
Praca w godzinach 7-18 ~~elastyczne godziny pracy~~ (elastyczne godziny oznaczają, że mogę pracować w dowolnych godzinach byle być na zaplanowanych spotkaniach)

„Możliwości rozwoju”, „młody i dynamicznie rozwijający się zespół”, „testerzy w zespole”, „dostęp do najnowszych technologii” są oklepanymi zwrotami. Widząc takie ogłoszenie wizualizuję sobie, że jest możliwość rozwoju w kursach na YouTube bo nie ma budżetu szkoleniowego, w projekcie są tylko juniorzy, testerami są wszyscy, dług technologiczny rozwija się szybciej niż programiści a najnowsza technologia to sprzęt 4 generacje starszy niż prywatny.

W pierwszym kontakcie z firmą bardzo chcę wiedzieć jakie jest doświadczenie zespołu, czy zespół posiada testerów (i jakich), jaki jest budżet szkoleniowy i czy oferowana jest praca zdalne i elastyczne godziny.

Oczekiwania i wymagania

Sekcja w której szukam elementów, które mogą mnie całkowicie dyskwalifikować np. znajomość Unity 3D, C++ itp.. Gdy nie ma elementów całkowicie wykluczających mnie z takiej oferty, sprawdzam technologie i biblioteki, których nie używałem i czy mogę się zapoznać z nimi w miarę krótkim czasie.

Lakoniczne oczekiwania lub wymagania, które są już zawarte w nazwie stanowiska nie powinny znajdować się w ogłoszeniu. Np. dla Senior Android Developer informacja: „Bardzo dobra znajomość platformy Android” albo „Bardzo dobra znajomość zagadnień związanych z programowaniem aplikacji mobilnych” jest jak stawianie wymagania pisania i czytania kandydatom na uczelnię wyższą. Jeśli ktoś nie chciał poświęcić czasu na odpowiednie przygotowanie oferty to po co ja mam marnować swój czas na domyślanie się co autor miał na myśli. Ja rozumiem że nutka tajemniczości i szaleństwa jest potrzebna ale bez przesady.

Ogłoszenie powinno zawierać jasno sformułowane wymagania i oczekiwania, za które pracodawca chce zapłacić (swoją drogą chciałbym zarabiać za same chęci doskonalenia swoich umiejętności). Należy jasno odróżnić wymagania i oczekiwania, gdzie wymagania są koniecznością a oczekiwania są tylko ….. oczekiwaniami?. Z tego względu, że część kandydatów widząc, że wymaganiem jest np. Jira, z której nigdy nie korzystali i nie chcą wykupywać specjalnie subskrypcji może zrezygnować z takiej oferty – należy mieć to na uwadze w przypadku ofert na stanowiska Junior.

W przypadku programistów, gdzie wymagania technologiczne mogą być liczone w dziesiątkach, lista taka powinna być przedstawiona w prostej i szybkiej w czytaniu formie:

Bardziej opisowa mniej przystępna forma powinna uszczegóławiać powyższe wymagania (nie powinny znajdować się tutaj jakiekolwiek ogólniki typu „chęć nauki i rozwoju”):

Wymagania:

Tworzenie kodu produkcyjnego w pełni pokrytego testami jednostkowymi JUnit/Robolectric (teoretycznie każdy Senior powinien testować swój kod, jednakże nie dla wszystkich jest to oczywiste dlatego czasem powinno się sprecyzować wymagania aby wykluczyć osoby, które nie pasują do profilu)
Tworzenie testów UI Espresso
Stosowanie Continuous Integration i Continuous Delivery przy wytwarzaniu oprogramowania
Zarządzanie długiem technologicznym oraz refaktoryzacja starszych części systemu napisanego w Java
Doświadczenie oraz dobra znajomość NDK oraz C++

Oczekiwania

Wspieranie, przekazywanie wiedzy oraz podnoszenie kwalifikacji mniej doświadczonym członkom zespołu poprzez pair programming
Dyspozycyjność 40h tygodniowo

Szczegóły projektu

Najbardziej brakuje mi w ogłoszeniach opisu projektów, tak jakby pracodawcy bali się lub wstydzili pracy, którą oferują. Jak już znajduje się jakaś informacje to pracodawcy starają się wyolbrzymić wartość projektu i firmy np. „Udział w projektach medialnych unikalnych na rynku”.

W ogłoszeniu powinny znajdować się tylko prawdziwe, szczegółowe i istotne informacje na temat projektu:

Zespół składa się z 15 osób z czego 10 osób to część pracująca w Niemczech ~~Praca w dużym, międzynarodowym środowisku~~
Praca nad komunikatorem do obsługi klienta bazującym na sztucznej inteligencji. ~~Udział w projektach medialnych unikalnych na rynku~~

Pochodzenie członków zespołu może wyeliminować osoby ksenofobiczne a przyciągnąć np. znające język niemiecki, które chcą go podszkolić. Międzynarodowe zespoły są świetną okazją aby upiec dwie pieczenie na jednym ogniu. Szczegóły są ważne!

Niektórzy mają dosyć pracy w korporacyjnych strukturach a niektórzy są do tego stworzeni, więc pokaż kim na prawdę jesteś a przyciągniesz osoby o podobnych upodobaniach.

W opisie powinny być konkretne informacje dotyczące tematyki projektu, zaawansowania, metodologii, ilości spotkań, wyjazdów itp. Oczywiście jak najbardziej zwięźle i szczegółowo np.

Aplikacja będąca platformą do adopcji psów ze schronisk z całej polski (link)
Zwinne wytwarzanie oprogramowania (XP – Extreme Programming)
Jira, Confluence, GitLab, Slack
Code Review
Testy: Unit Tests – 80%, Espresso Tests, Appium
Lokalizacja Warszawa, Rondo Daszyńskiego

Bardzo dobrym pomysłem jest przedstawianie profilu projektu poprzez czas spędzony w konkretnych czynnościach w formie graficznej.

Bardziej dokładnie można oszacować godzinowo lub procentowo co rozwieje wątpliwości odnośnie długości pasków:

spotkania 5h tygodniowo
nowe funkcjonalności 30 godzin tygodniowo
utrzymanie 5 godzin tygodniowo

Dla mnie w opisie projektu jest najważniejsza metodologia, struktura zespołu, pokrycie testami, czas spędzony na spotkania, czy jest stosowany Continuous Integration i Continuous Delivery. Jeśli nie, to czy klient jest otwarty na takie usprawnienia.

W branży IT poprzez 1 albo 2 znajomych można znaleźć kontakt do pracownika lub byłego pracownika firmy, która rekrutuje. Każde kłamstwo prędzej czy później wyjdzie na jaw. Nie chodzi o to aby od razu pisać w ogłoszeniu: „Mamy fatalny kod, nie da się z nim pracować, błagam pomocy!” – chociaż myślę, że takie ogłoszenie w świecie IT zrobiłoby furorę.

Miejsce pracy

Miejsce i stanowisko pracy jest całkowicie pomijane w ogłoszeniach. Jeśli nie jest to ogłoszenie o pracę zdalną, chciałbym się dowiedzieć jak będzie wyglądało miejsce pracy, czy jest to piwnica czy wieżowiec, gdzie jest lokalizacja biura czy mam wpływ na wyposażenie. Od stanowiska w pracy oczekuję aby były 2 monitory min. 23 calowe i duże biurko umożliwiające pracę na stojąco (moim zdaniem powinno być wymagane przez przepisy BHP).

Benefity

Za standard uznaje się aktualnie prywatną opiekę medyczną oraz kartę typu multisport jednak przy dobrej stawce benefity są zbędne. Warto jednak wydzielić je w osobnej sekcji.

Przykładowe ogłoszenie

Oferta powinna zawierać jak największą ilość szczegółów ułożoną w sekcjach i czytelną dla kandydata. Np na stanowisko Senior Android Developer oferta mogłaby wyglądać następująco:

Oferujemy

100-130zł/h netto na fakturze przy umowie B2B
Budżet szkoleniowy 5000 zł netto rocznie
Możliwość całkowitej pracy zdalnej
Praca w dowolnych godzinach (konieczność bycia na zaplanowanych spotkaniach)

Wymagania

Tworzenie kodu produkcyjnego w pełni pokrytego testami jednostkowymi JUnit/Robolectric
Tworzenie testów UI Espresso
Stosowanie Continuous Integration i Continuous Delivery przy wytwarzaniu oprogramowania
Zarządzanie długiem technologicznym oraz refaktoryzacją starszych części systemu.
Doświadczenie oraz dobra znajomość NDK oraz C++

Oczekiwania

Bitrise CI/CD | Confluence | GitLab | MRCode | Detekt

Wspieranie, przekazywanie wiedzy oraz podnoszenie kwalifikacji mniej doświadczonym członkom zespołu
Dyspozycyjność 40h tygodniowo

Szczegóły projektu

Aplikacja będąca platformą do adopcji zwierząt ze schronisk z całej polski
Zwinna metodologia zarządzania projektami, wycena zadań na podstawie roboczogodzin (man-day)
Struktura zespołu
- 3 programistów Android (5 lat, 3 lata, 1 rok doświadczenia)
- 2 testerów automatycznych (Appium), 1 tester manualny
- 3 programistów iOS (6 lat, 3 lata, 2 lata doświadczenia)
- 2 programistów web (10 lat, 3 lata doświadczenia)
- 4 programistów backend (12 lat, 10 lat, 2 lata, 3 lata doświadczenia)
Spotkania ~12% (daily 20 min, planning 4 godziny/3 tyg, review 40 min/3 tyg, backlog refinement 2 x 45 min/tyg)
Utrzymanie tylko bieżącego systemu (3 bugfix/miesiąc)
Zwinne wytwarzanie kodu (Extreme Programming)
Pokrycie testami jednostkowymi 78%

Zastosowane technologie

Dialogflow
Google Home
Android Wear 2.0

Miejsce pracy

Warszawa, Rondo Daszyńskiego
Darmowy parking podziemny dla samochodów oraz rowerów
2 monitory 2K 27 cali
Macbook Pro 15 lub 13 do wyboru
Biurko regulowane elektrycznie
Open space + focus room (hot desk)

Benefity

Prywatna opieka zdrowotna
Karta multisport
Piwne piątki

Więcej o firmie

link do firmy
link do aplikacji
link do produktu
link do youtube itp.

Ogłoszenia powinny być ciągle ulepszane oraz uzupełniane o pytanie zebrane od kandydatów dzięki czemu każda kolejna osoba, która wejdzie na ogłoszenie będzie traciła mniej czasu.

Ja wiem, że niektóre elementy odstraszą kandydatów ale jeśli ogłoszenie okaże się stekiem bzdur i napompowaną bańką to taka osoba nigdy już nie przyjdzie pracować do takiej firmy. Swoją drogą bardzo ciekawym rozwiązaniem byłyby jawne pytania na stronie oferty takie FAQ.

Pierwszy kontakt

Pierwsza rozmowa powinna się odbyć za pomocą wiadomości e-mail, w których można rozwiać wątpliwości dotyczące trybu pracy, elastyczności i innych rzeczy, które są kluczowe dla kandydata oraz pracodawcy, a które nie zostały wyjaśnione w ofercie. Szanujmy swój czas.

Pierwsza rozmowa

Gdy mailowo zostały rozwiane wszystkie kluczowe kwestie i oferta jest dla kandydata atrakcyjna to druga rozmowa powinna być wykonana telefonicznie lub przez komunikator w godzinach wolnych od pracy. Nadmiar spotkań oraz telefonów w godzinach pracy może skutecznie wybić z rytmu dnia.

Rozmowa powinna być luźna bez ustalania jakichkolwiek kwot i podejmowania decyzji. W tej fazie powinna być ogólny wywiad o doświadczenie, oczekiwania, wyobrażenia i wartość jaką może wnieść kandydat (swoją drogą nikt mnie nie zapytał nigdy podczas rozmowy o pracę, co wniosę dobrego do firmy). W tej rozmowie może zostać przeprowadzona także wstępna rozmowa techniczna, która wykluczyłaby osoby nie spełniające wymagań np. brak wiedzy w zakresie testowania.

Zadanie

Jest to kontrowersyjny sposób rekrutacji, ponieważ wiele osób uważa, że poświęca własny czas i firma rekrutująca powinna zapłacić za wykonanie takiego zadania. Z drugiej strony firma, która rekrutuje daje zazwyczaj zadania, których nie da się wykonać dobrze i szybko.

Zadanie powinno być proste w przygotowanym już wstępnie repozytorium, które ma szkielet aplikacji, w Readme określone wymagania oraz standardy stosowane w firmie.

Zadanie powinno sprawdzać:

umiejętność programowania
znajomość konkretnych technologii
zastosowania odpowiednich wzorców
znajomości Android SDK
tworzenia oprogramowania otwartego na rozszerzenia
tworzenie oprogramowania zgodnie z zasadami SOLID
umiejętności testowania
znajomości systemu wersjonowania
dostosowywanie się do standardów i konwencji panujących w firmie

Jeśli ktoś chce zarabiać np. o 10zł/h więcej niż w poprzedniej pracy to może poświęcić te 8h na wykonanie zadania aby w ujęciu rocznym zarobić 20 tys. złotych więcej – brzmi jak dobra inwestycja.

Jeśli na stanowisko jest duża liczba kandydatów (co jest mało prawdopodobne) zadanie może poprzedzać rozmowa techniczna, która wyeliminuje najsłabsze ogniwa.

Omówienie zadania z zespołem

Zadanie powinno być udostępnione za pomocą portalu GitHub lub podobnego tak aby zespół mógł odnieść się do kodu. Komentowanie kodu może wywołać pewne dyskusje oraz rozwiać wątpliwości zespołu oraz osób wykonujących zadanie. W pracy zespołowej chodzi o prowadzenie merytorycznych dyskusji oraz uczenie się od siebie.

Komentarz zwrotny jest bardzo cenną informacją dla osoby rekrutowanej. Gdy taka osoba nie przejdzie rekrutacji ze względu na jakość zadania to informacja zwrotna będzie dla niej bardzo cenna. Z drugiej strony informacja zwrotna może ujawnić niekompetencje już istniejącego zespołu dzięki czemu kandydat będzie świadomy sytuacji w firmie.

Kandydaci, którzy pomyślnie przeszli zadanie powinni zostać zaproszeni na rozmowę do biura na omówienie zadania w celu weryfikacji autora oraz weryfikacji np. wiedzy teoretycznej, umiejętności miękkich, poczucia humoru i dopasowania do zespołu.

Spotkanie i wizyta w biurze/dzień próbny.

Teoretycznie rekrutacja mogłaby się już zakończyć i umowa zostać podpisana. Obie strony są zadowolone z warunków oraz ze swoich kompetencji co może pójść nie tak?

Kandydat nie miał styczności z całym zespołem, ze sposobem jego pracy oraz z sytuacją w biurze. Sama wizyta w biurze nie pokaże w jaki sposób zespół pracuje oraz jakie relacje i klimat panuje w zespole. Kłótnie, obarczanie winą, brak odpowiedzialności, brak transparentności, bałagan można zobaczyć tylko gdy już się wejdzie w struktury zespołu. Wiele tak negatywnych emocji w zespole może zdemotywować do dalszej pracy a wyśmienita umowa może okazać się męką.

Z drugiej strony zespół miał styczność tylko i wyłącznie z kandydatem na rozmowie. Osoby starają się zaprezentować jak najlepiej potrafią, panują nad swoim temperamentem i mogą być mocno wyuczone pod kątem rozmów kwalifikacyjnych. Podczas dnia próbnego można zobaczyć czy taka osoba umie współpracować w zespole, stawić czoła problemom, programować w parach i czy pasuje do zespołu. Osoby mające tendencję do narzekania lub obgadywania mogą mieć destrukcyjny wpływ na zespół.

Znam kilka przypadków, w których osoby odchodziły z zespołu lub zostały zwolnione ze względu na niedopasowanie do reszty zespołu.

Przyszły pracodawca powinien zapłacić za dzień próbny tyle ile wynosi koszt dnia wolnego w obecnej pracy. W przypadku gdy kandydat nie ma obecnie pracy nie uważam że brak zapłaty jest karygodny – nie występuje utracenie korzyści. W przypadku gdy kandydat dostanie pracę miłym gestem byłoby zapłacenie za ten dzień, jednak w przypadku wysokich stawek nie jest to aż tak istotne.

Powyższy proces rekrutacyjny może być drogi w oczach pracodawcy a niektóre elementy nawet zbędne. W przypadku początkującego programisty dzień próbny może okazać się przesadą, ponieważ taka osoba dopiero się uczy i nie jest w stanie wystarczająco ocenić sposobu pracy zespołu. W przypadku Seniorów oraz Liderów dzień próbny może sprawdzić czy kandydat ma odpowiednie cechy na dane stanowisko i czy zespół chce z taką osobą pracować.

Podsumowanie

Aby proces rekrutacji był udany obie strony muszą być zadowolone z warunków jakie wynegocjowały. Grunt to szczerość i transparentność. Oferta musi być szczegółowa, bez zbędnych ogólników i upiększeń rzeczywistości. Wszyscy muszą zrozumieć potrzeby i oczekiwania drugiej strony aby nie było rozczarowania. Weryfikacja kompetencji powinna zachodzić w obie strony tzn. kandydat też powinien mieć szansę na weryfikację kompetencji zespołu oraz firmy (jeśli obiecuje mu się pracę z doświadczonym zespołem i możliwość rozwoju). Jeśli pracodawca ma przekonania na zasadzie „my płacimy więc musisz wszystko robić co ci każemy, nawet jeśli jest to najgorsze rozwiązanie” to warto powiadomić o takich zasadach panujących w firmie – niektórzy nie są asertywni, bardzo dobrze się czują wykonując taką pracę i nie lubią gdy ktoś od nich wymaga podejmowania trudnych decyzji. Oczywiście utopią jest znalezienie idealnych pracowników albo idealnego pracodawcy, praca programisty wymaga wielu kompromisów na poziomie zespołu jak i na poziomie rozwiązań technicznych.

Jeśli uważasz treść za wartościową to podziel się nią z innymi. Dziękuję.