Autor: Maciej Kmon
W historii IT bywały różne okresy rynku pracy dla specjalistów. Sam zacząłem moja przygodę z nim kilka lat temu i oczywiście zaobserwowałem pewne wahania – jak większość z nas. Natomiast to co dzieje się teraz albo urąga logice albo… dzieje się coś innego.
Zapotrzebowanie na wykwalifikowanych pracowników
Z jednej strony CEO firm oraz managerowie zespołów wyraźnie wyrażają potrzebę wykwalifikowanych ludzi do pracy. Oczywiście mamy mocno medialnie nagłaśniany temat layoff-ów w korporacjach, natomiast są to liczby kilkuset do kilku tysięcy pracowników z których w porywach 20-30% to pracownicy IT. Tymczasem ofert pracy w IT wciąż sporo (polecam zajrzeć na IT-Leaders.pl gdzie ekipa cały czas aktualizuje wykaz prowadzonych rekrutacji).
Z drugiej strony na Linkedin co chwilę czytam posty w stylu ,,Node.js developer 7 lat komercyjnego doświadczenia szukam pracy od 3 miesięcy bez skutku”.
Analiza sytuacji
Jak zwykle w tego typu sytuacjach, zacząłem amatorsko analizować.
Pierwszą myślą było – to nielogiczne! Jeśli transakcja może zajść legalnie, osoba posiadająca coś co chce sprzedać (specjalista swój czas, poświęcenie, umiejętności) a osoba kupująca (tak, dla niepoznaki w języku polskim mówimy na nią ,,pracodawca”) jest zainteresowana nabyciem dobra – transakcja powinna zachodzić bez przeszkód. Oczywiście z negocjacjami, umowami itd. Ale żadna z tych rzeczy nie zajmuje 3 czy 5 miesięcy. O co więc chodzi?
Od razu zdradzę – nie dotarłem jeszcze do źródła problemu. Wielu osobom wydaje się, że temat jest prosty, ale o kogo opinię nie pytam dostaję inną odpowiedź. Być może problem jest jednak złożony.
10 sygnałów, że ogłoszenie o pracę może być fałszywe
Rozmijanie się poczynań kandydatów i pracodawców
Moją obserwacją jest trend który polega na znaczącym rozmijaniu się poczynań kandydatów oraz pracodawców i rekruterów (często pracodawca i rekruter to osobne strony biznesu).
Zwróćmy uwagę na zadania rekrutacyjne, które firmy stosują w celu masowego i pasywnego (w przeciwieństwie do rozmowy technicznej gdzie firma jest stroną aktywną w tym samym stopniu co kandydat i inwestuje co najmniej tyle samo czasu) sprawdzenia kandydata pod kątem umiejętności technicznych.
Kilka lat temu kandydaci aplikowali na mniej ofert pracy na raz. To dawało im więcej czasu na wykonanie zadań. Tu warto podkreślić, że rekrutacyjne prace domowe kandydaci robią w wolnym, prywatnym i nieodpłatnym czasie. Niestety nie zawsze jest tego świadomość po drugiej stronie.
Aktualnie jest wiedzą powszechną, iż kandydaci aplikują masowo. Niedawno czytałem wpis osoby, która zaaplikowała na 200 ofert w ciągu 3 miesięcy. Oczywistym jest więc, że jest mniej czasu na robienie zadań oraz mniej powodów aby je robić – w końcu mało kto aplikuje na setki ofert jako hobby czy rozrywkę. Zazwyczaj jest to spowodowane tym, iż większość kandydatów przeczuwa, że ich aplikacja zostanie odrzucona. A jeśli jest taka duża ilość odrzuceń to sens robienia dla każdej firmy nieodpłatnego projektu z perspektywy kandydata z natury rzeczy maleje.
Szacunek dla czasu i wysiłku kandydatów
Posłużę się przykładem z życia. Znajomy, który pracuje w podobnym stack-u do mojego ostatnio miał rekrutację do firmy. Na początek rozmowa z rekruterem i po rozmowie dostał zadanie rekrutacyjne. Miał napisać aplikację – instrukcja zawierała 5 wymagań oraz 4 nice to have. Od rekrutera dowiedział się, te „nice to have” nie są obowiązkowe i że ich brak nie wpłynie na szanse dostania się. Nice to have to były m.in zastosowanie określonego framework-a, napisanie testów oraz zrobienie jakiegokolwiek front-endu (wspomnę, że stanowisko dotyczyło pracy w back-end’zie).
Mój znajomy postanowił jednak podejść do tematu kompleksowo i na wszelki wypadek zaimplementował wszystkie wymagania oraz wszystkie ,,nice to have”. Dwa dni przed weekendem, w którym miał robić zadanie zapytał rekrutera i doprecyzowanie wymagań i poprosił o odpowiedź na kilka pytań. Rekruter obiecał, że przekaże pytanie do klienta.. Ścieżka komunikacji z team lead-erem który będzie sprawdzał zadanie to:
Rekruter -> HR -> Manager Działu -> Team Leader
Jak łatwo zgadnąć, znajomy nie doczekał się odpowiedzi i postanowił poradzić sobie z tym co wie. Napisał aplikację, poświęcił na to około 8h w sobotę i 5h w niedzielę, zgrubnie połowę weekendowego wolnego czasu. Udostępnił repozytorium Team Leaderowi (oraz z jakiegoś powodu został poproszony przez HR do przesłania również im linka, pomimo iż repozytorium jest prywatne).
W czwartek (4 dni później) Team leader po raz pierwszy zajrzał do repozytorium (można to sprawdzić na github) i… 20 minut później dostał informację, iż jego kandydatura została odrzucona. I zero informacji dlaczego. Biorąc pod uwagę jak długą drogę musiała przejść informacja z firmy, gdy dopytywał o dodatkowe kwestie – ten krótki feedback przyszedł z prędkością błyskawicy. Znajomy nie dał za wygraną – poprosił rekrutera o powody odrzucenia. Jednocześnie poprosił mnie o opinię, przesłał mi kod, wymagania i w wolnej chwili poczytałem.
Niedopasowane oczekiwania
Aplikacja działała i robiła wszystko co było wymagane, do tego zostały zrobione wszystkie „nice to have”. Nie było absolutnie żadnych fajerwerków – podobnie jak ja kolega wyznaje zasadę, iż każdy soft zostanie przekombinowany w procesie, więc jeśli to możliwe należy pisać prosto, schludnie i zgodnie z DRY i KISS. Rozbudował sekcje ReadMe i dodawał więcej komentarzy niż zazwyczaj, aby zaprezentować team leader-owi jak podchodzi do rozwiązywania problemów i dlaczego robi X a nie Y.
Schludny projekt, gdybym miał się czepiać – wadą mogło być jedynie nie za dużo testów, ale zarówno unit-owe jak i funkcjonalne. Jak im wspomniał – był już zmęczony w niedziele.
W międzyczasie wrócił do niego feedback – 3 zdania.
Pierwsze mówiło o tym, że wykorzystał ZA MAŁO bibliotek, za mało funkcji framework-a (który był nice to have) i ogólnie napisał za mało kodu (i podane 2-3 biblioteki, które w mojej opinii w takim projekcie byłyby typowym over engineering, robieniem ,,pokazówki” kosztem nieuzasadnionego komplikowania aplikacji. Czyli czymś czego w pracy nikt normalny by nie chciał).
Drugie o tym, że testy są zbyt podstawowe (było w tym trochę prawdy)
I trzecie…odnosiło się do stwierdzenia znajomego w komentarzu zadania, że nie przepada za CSS – dlatego nie spełnia wymagań firmy (o front-endzie nie było mowy w ogłoszeniu).
Powiedzieli mu że mają ogromną liczbę kandydatów na to stanowisko.
Doszliśmy więc do wniosku, że zespół pewnie wymaga kogoś, kto lubi kosztem czytelności i schludności kodu pokazywać ile różnych bibliotek i komponentów jest w stanie upchać na minutę. A skoro ma dużo kandydatów, to mieli w czym wybierać. Szkoda tylko, że nie określili swoich oczekiwań już na wstępie. Nawet w trybie „nice to have”..
Nieoczekiwany obrót sprawy
1,5 miesiąca później skontaktował się ze mną rekruter z nieznanej mi agencji. Okazało się… że firma z rekrutacji kolegi szuka osoby na dokładnie to samo stanowisko (sic!). Zaniemówiłem.
Czyli nie mieli dużej ilości wysokiej klasy kandydatów. Półtora miesiąca w rekrutacji, która trwała tygodnie zanim kolega zaczął się z nimi umawiać.
I nie chodzi o to, że go nie zatrudnili. Ale rzucanie kłód pod nogi na każdym etapie to działanie na które mogą sobie pozwolić firmy naprawdę posiadające kolejki wysokiej klasy ekspertów pod drzwiami (np. Google). To była średnia firma, ale z ogromną ilością pracy.
Dla mnie udział w tej rekrutacji nie miał oczywiście najmniejszego sensu.
Smutne wnioski
Firmy narzekają na kandydatów, którzy zawyżają posiadane umiejętności – można by więc przypuszczać, że kandydat, który szczerze komunikuje swoje nie tylko mocne ale i słabe strony zostanie pozytywnie odebrany.
Czy tego typu feedback nie jest wręcz szkoleniem kandydatów aby 'konfabulowali’ lub w najlepszym razie przemilczali swoje pełne kompetencje? Nie wspomnę już o tym, że sam brak realnego feedbacku i Code Review (znajomy nie dowiedział się nic o tym co jest nie tak z kodem, który napisał spędzając nad nim weekend, poza tym, że jest go za mało) sprawi że mocno się on zastanowi czy wykonać zadanie dla innej firmy.
Przykład jest długi, natomiast niewątpliwie podkreśla on trend totalnego niedopasowania kandydatów i pracodawców podczas procesu rekrutacyjnego.
Kto może temu zaradzić?
Kto może lepiej zsynchronizować ewolucje firm i kandydatów?
Nie wiem, ale w mojej opinii najłatwiej (co nie znaczy łatwo, bo trzeba pamiętać, że pracodawca jest klientem rekrutera, a klient podobno ma zawsze…), największą szansę ma to w dalszym ciągu zmienić rekruter.
Rekruter jest osobą która łączy dwie strony rekrutacji. Zapewne nieczęsto pada to z ust programistów ani firm… natomiast specjaliści od rekrutacji – być może dzisiaj to wy możecie zrobić refactoring i naprawić coś co nie działa… I trzymam kciuki abyście dali radę… zanim zmienią się wymagania.
ps. wiem z kuluarów, że ekipa IT-Leaders.pl pracuje nad rozwiązaniami, które będą w stanie uzdrowić rynek rekrutacji. Mocno kibicuję!
Maciej Kmon
