To jest 279. odcinek podcastu Porozmawiajmy o IT, w którym w cyklu rozmów z Łukaszem Drynkowskim z portalu z ogłoszeniami pracy IT SolidJobs, który mam przyjemność współtworzyć, dyskutujemy o tematach związanych z byciem liderem i zarządzania zespołem IT.

Zapraszamy do słuchania i komentowania. A teraz życzymy Ci już miłego słuchania.

Odpalamy!

 

Cześć, Łukasz!

 

Cześć, Krzysztof!

 

Nasze kolejne spotkanie w ramach serii podcastów dla lidera i managera IT, a dzisiaj będziemy mówić głównie o rekrutacji developerów i przyjrzymy się temu, co działa, co nie działa, jak podejść do tego, aby długofalowo ta rekrutacja przyniosła nam korzyść w postaci osoby, która będzie trafiona, jeśli chodzi o nasze wymagania, ale również dopasuje się do zespołu.

Bo nie ma co tutaj ukrywać, taka nietrafiona rekrutacja to nie tylko koszt taki czasowy, bo trzeba ją po prostu powtórzyć, ale też niemały finansowy, bo zazwyczaj kilka osób jest w to zaangażowanych i po prostu te koszty finansowe mogą być całkiem pokaźne, jeśli sobie do tej rekrutacji tak swobodnie będziemy podchodzić. 

Dzisiaj perspektywa managera na właśnie tę rekrutację, więc nie będziemy mówić o przygotowaniu ze strony developera i jak robić CV, to już było wcześniej. Dzisiaj powiemy, jak z tego drugiego krańca tego stolika rekrutacyjnego warto na to spojrzeć.

 

Oczywiście każda sytuacja jest inna. My tutaj się dzielimy naszymi doświadczeniami, naszymi wrażeniami. Tak że mam nadzieję, że wyciągniecie z tego jakieś wnioski. Natomiast pamiętajcie, że zawsze trzeba to wszystko dostosować do konkretnej sytuacji. Każdy projekt jest inny, każda osoba jest inna, każdy zespół ma inną dynamikę.

 

Tak, to nie jest porada inwestycyjna.

 

Tak, to nie jest porada inwestycyjna, dokładnie tak. Tak że w tym odcinku troszkę też wspomnimy o SolidJobs. Mam nadzieję, że tutaj uda nam się sprzedać trochę naszej filozofii i właśnie naszego podejścia i tego, jak SolidJobs pomaga w rekrutacji. Natomiast mam nadzieję, że nie wyłączycie odbiorników i będziecie słuchać dalej, to nie będzie perfidna reklama, tak że zaczynamy.

 

Dokładnie, takie pierwsze skojarzenie, myślę, z rekrutacją to jest zawsze dział HR, rekruterzy, którzy też gdzieś tam pod ten dział HR są podpięci, natomiast to co my będziemy chcieli Wam zaprezentować, sprzedać i polecić to jest właśnie takie podejście inżynierskie do rekrutacji. I co Łukasz, co to właściwie znaczy?

 

Tak, jesteśmy inżynierami, tak że stosujmy metodę naukową. To jest też ten moment, gdzie po raz kolejny polecę książkę Daniela Kahnemana Pułapki myślenia, która też gdzieś tam zainspirowała mnie kiedyś do tego, żeby właśnie tę rekrutację prowadzić w taki sposób bardziej uporządkowany, bardziej naukowy.

Pamiętajmy o tym, że rekrutacja to nie jest tylko ten czas, kiedy rozmawiamy z kandydatem lub kandydatką, ta interakcja face-to-face, rekrutacja to jest cały proces, który jest trochę bardziej złożony, trochę dłuższy.

Pierwszym takim etapem jest etap bardzo taki dla nas IT znajomy, czyli zebranie wymagań. Czyli po prostu musimy sobie odpowiedzieć na pytanie, czego oczekujemy od tego naszego przyszłego pracownika. Też najlepiej sobie podzielić te oczekiwania na jakieś must have i nice to have, bo wiadomo, że to nigdy nie jest tak, że znajdziemy kogoś, kto na 100% będzie nam odpowiadał i 100% po prostu ktoś będzie używał tych samych technologii, których my u nas w projekcie, bo to zapewne tylko u nas jest akurat taki zbiór technologii, taka wiedza domenowa.

Tak że musimy tutaj stwierdzić, co dla nas jest ważne, co jest mniej ważne. I zacznijmy właśnie od czegoś takiego jak karta oceny kandydata.

To jest takie narzędzie i właśnie tutaj pozwolę sobie zareklamować krótko SolidJobs, ponieważ to jest takie narzędzie, które jest wbudowane też właśnie w naszą aplikację i macie to już na tacy. To jest takie narzędzie, które po prostu pozwala na te określone ileś cech kandydata, oznaczyć po prostu jak temu kandydatowi tutaj w tej danej rekrutacji poszło. I chodzi o to, żebyśmy nie opierali się o jakieś wrażenia z rozmowy, o to, jak dobrze nam się z kimś rozmawiało, tylko żebyśmy mogli na koniec tych kandydatów między sobą w taki obiektywny sposób porównać.

Wybieramy po prostu ileś takich cech, które są dla nas kluczowe, i oznaczamy w jakiejś skali, która dla nas jest najłatwiejsza po prostu w użytkowaniu, najbardziej intuicyjna. Oznaczamy, jak dobrze sobie dany kandydat poradził i na koniec będziemy mogli z tych kandydatów po prostu wybrać najlepszych.

 

Tak, myślę sobie, że taki swego rodzaju good feeling też jest oczywiście ważny, ale to takie wrażenie po rozmowie może być właśnie spowodowane tym, że właśnie przed chwilą tę rozmowę skończyliśmy, jesteśmy tutaj jeszcze pod wpływem różnych rzeczy, które się działy i możemy przeceniać albo nie doceniać tego kandydata lub kandydatkę.

Kiedy mamy możliwość oceny jednoznacznej, to możemy zawsze do tego oczywiście wrócić, z taką chłodną głową później spojrzeć i być w stanie wybrać. Też myślę, że nie do przecenia jest to, że po prostu inaczej zapomnimy te różne rzeczy, które gdzieś tam padły na rozmowie, jeśli tego sobie od razu gdzieś w jednoznaczną tabelkę nie wrzucimy.

Chciałbym jeszcze dodać, że bardzo ważne jest to, żeby właśnie określać, jakie jest must have, a jakie jest nice to have, bo najczęściej jest tak, że jako managerowie my bezpośrednio tej rekrutacji nie przeprowadzamy, znaczy w sensie sourcingu, nie wyszukujemy potencjalnych kandydatów na LinkedInie, tylko raczej zajmuje się tym na przykład Recruiter Sourcer.

I jeśli nie zdefiniujemy dobrze właśnie tych wymagań, tych takich twardych, które muszą być spełnione albo tych bardziej takich luźnych, których niespełnienie niekoniecznie przekreśla, to jak gdyby rekruter będzie to traktował jako właśnie te wszystkie dane wyjściowe, którymi się posługuje, więc jeśli źle zdefiniujemy ten oczekiwany profil, to nie możemy później oczekiwać, że dostaniemy CV osób pasujących do tych naszych oczekiwań.

 

Tak, i tutaj może ja kilka opowiem takich historii, co moim zdaniem HR-y robią źle. Właśnie z HR-ami jest taki problem, że oni nie wiedzą, że jakaś technologia czy jakieś narzędzie jest równoważne, czy jest podobną technologią jak coś innego. Jeśli HR-owi powiemy, że szukamy kogoś z RabbitMQ, to będzie szukał kogoś, kto zna RabbitMQ i np. jeśli ktoś inny zna ActiveMQ czy inną jakąś podobną technologię, to już ten HR to odrzuci.

I tutaj właśnie jest ważna nasza tych specjalistów czy też takich osób bardziej technicznych rola, żeby niekoniecznie kogoś odrzucić dlatego, że jakiejś konkretnej technologii nie zna.

Podam jeszcze inny przypadek, np. NHibernate a Entity Framework. Ja bym wolał, jeśli szukam np. do projektu z Entity Frameworkiem kogoś, kto bardzo dobrze zna tego NHibernate’a, umie czytać plany zapytań, umie dobrze indeksy założyć, zoptymalizować zapytania. Naprawdę to jest drugorzędne, czy tą jego technologią, z którą większość czasu miał do czynienia, to był ten NHibernate, czy ten Entity Framework, czy tam jeszcze coś innego.

To jest właśnie coś, co często słyszę w rozmowach z HR-ami albo słyszę taki feedback może od kandydatów, że gdzieś tam zostali odrzuceni, bo właśnie znali nie ten flavor danej technologii czy danego narzędzia. Myślę, że tutaj jest duży błąd, który jest popełniany przez HR i to, że ta rekrutacja jest w ręku tej osoby technicznej, to właśnie tu może dużo pomóc, bo jesteśmy bardziej zorientowani na tego typu sprawy. Tak że często słyszę taki feedback, że czyjeś zgłoszenie zostało odrzucone, bo ktoś nie znał danej domeny, np. finansowej albo medycznej.

To też moim zdaniem jest coś, na co nie powinniśmy zwracać uwagi, szukając kandydata. Okej, może jak mamy tam dwóch czy trzech równoważnych kandydatów już na koniec, to wybiorę np. tego, który ma znajomość tej domeny. Ale wydaje mi się, że akurat znajomość domeny to jest coś, czego powinniśmy nauczyć tego człowieka po zatrudnieniu, a nie szukać tego wcześniej.

 

Tak, tak, dokładnie. Więc bardzo ważne jest zdefiniowanie tych naszych oczekiwań jako manager, jako hiring manager. Jeśli zrobiliśmy to dobrze, no to otrzymujemy po jakimś czasie listę aplikacji, listę CV, no i przystępujemy do ich przeglądania.

Tutaj właśnie, co jest ważne, to w takim pierwszym rzucie określenie pewnych czerwonych flag, pewnych oczywistych rzeczy, które jednoznacznie powiedzą nam, że to nie jest dobry wybór. Coś Ci przychodzi, Łukasz, do głowy, co według Ciebie jest taką jednoznaczną czerwoną flagą?

 

Tak, to zaraz może opowiem, natomiast chciałbym znowu zacząć od anegdoty, bo myślę, że to są takie ciekawe rzeczy, albo anegdota typu właśnie błędy HR-ów, czyli to, co gdzieś tam rozmawiamy z różnymi HR-ami jako SolidJobs, mamy dużo tutaj styczności i słyszymy czasami takie rzeczy, gdzie ja się przerażam na tego typu stwierdzenia.

Na przykład jednym stwierdzeniem było to, że ktoś odrzuca kandydatów, jeśli CV kandydata jest dłuższe niż jedna strona A4. No to pewnie najlepszych kandydatów pani odrzuca, bo pani się nie chce tutaj wykonać swojej pracy.

Też mieliśmy inną sytuację. U nas np. aplikując, pole z numerem telefonu nie jest obowiązkowe, bo chcemy, żeby jak najmniej tych pól było obowiązkowych, żeby po prostu jak najłatwiej można było zaaplikować. I usłyszałem od innej pani z innej firmy, że oni wszystkich kandydatów, którzy nie podają numeru telefonu, to odrzucają od razu. Bo oni nie mają czasu pisać maili do ludzi i czekać, czy ktoś łaskawie im odpowie.

Tak że po raz kolejny smutne, ale prawdziwe historie. Tak że pamiętajcie, żeby numer telefonu zawsze podać, żeby był też na CV, bo tego typu problemy mogą sprawić, że nie znajdziecie tej swojej wymarzonej pracy.

Natomiast wracając do przeglądu CV, no to tak, pierwsze i najważniejsze to właśnie doświadczenie i projekty, w których ktoś brał udział. To, czego osobiście szukam, to szukam w tym CV informacji, za co dana osoba odpowiadała, czym się zajmowała, z jakimi technologiami, z jakimi narzędziami pracowała.

Wiadomo, że tego wszystkiego nie da się też odczytać z CV i to też później dojdziemy do rozmowy kwalifikacyjnej. Moim zdaniem to jest właśnie ważne, żeby dojść do tego, czym rzeczywiście ta osoba się zajmowała, a które w tym CV to są zapisy, które po prostu znaczą, że widziała na oczy daną rzecz.

Wracając znowu do tego przykładu z baz danych, czy to jest osoba, która umie te plany  przeczytać, zaproponować, żeby jakiś indeks założyć, czy po prostu pracowała z NHhibernatem.

 

No właśnie, do tych czerwonych flag zaraz wrócimy, ale może jak już tak ciągniemy, na co warto zwrócić uwagę, to porównać sobie wymagania finansowe tej osoby versus doświadczenie. Czy nie mamy tutaj jakiegoś oczywistego rozdźwięku, myślę, że to właściwie można podciągnąć pod taką czerwoną flagę.

To, co mnie osobiście też odrzuca, to taki rozdźwięk poważny, pomiędzy latami doświadczenia a szeroką znajomością różnych technologii. Każdy, kto troszkę spróbował coś porobić w IT, to wie, że to wymaga czasu po prostu, aby powiedzieć o sobie jako specjaliście.

 

W moim CV w miarę trwania czasu tych technologii jest mniej, a nie więcej. Mam wrażenie, że raczej nastąpiło odrzucenie pewnych rzeczy i skreślenie, czyli te rzeczy, którymi gdzieś tam się tylko liznąłem albo tylko się troszkę zajmuję, to po prostu usunąłem ze swojego CV te rzeczy, a zostawiłem po prostu ten najbardziej core.

 

Dokładnie. Tak samo jak na przykład widzę w tych CV, które teraz tak ładnie są robione i oznaczają jakoś gwiazdkami poziomu znajomości, dajmy na to, jeśli ktoś przypisuje jedną gwiazdkę z jakiejś technologii, to chyba lepiej byłoby to zupełnie pominąć.

 

Tak, a drugi problem jeszcze, jak ktoś ma wszystko na pięć gwiazdek. Chyba że rzeczywiście zatrudniam tutaj jakiegoś senior architekta, ale raczej ja bym unikał w CV gwiazdek, natomiast ten odcinek nie jest z perspektywy osoby, która pisze CV, więc jak są te gwiazdki, no to są, ale raczej to nic nie mówi, nie? To jest tak, że jedna osoba oznaczy sobie trzy gwiazdki, a druga pięć i ta, co zaznaczyła trzy, może tę technologię umieć lepiej niż ta druga. To tutaj są też te błędy poznawcze. Im więcej wiem, tym więcej wiem, czego nie wiem i gorzej oceniam te swoje umiejętności.

Tak, a drugi problem jeszcze, jak ktoś ma wszystko na pięć gwiazdek. Chyba że rzeczywiście zatrudniam tutaj jakiegoś senior architekta, ale raczej ja bym unikał w CV gwiazdek, natomiast ten odcinek nie jest z perspektywy osoby, która pisze CV, więc jak są te gwiazdki, no to są, ale raczej to nic nie mówi, nie? To jest tak, że jedna osoba oznaczy sobie trzy gwiazdki, a druga pięć i ta, co zaznaczyła trzy, może tę technologię umieć lepiej niż ta druga. To tutaj są też te błędy poznawcze. Im więcej wiem, tym więcej wiem, czego nie wiem i gorzej oceniam te swoje umiejętności.

 

Tak to wygląda. Powiedziałeś tutaj o doświadczeniu. Myślę, że warto też spojrzeć, czy tutaj nie mamy do czynienia z osobą, która zbyt szybko zmienia te projekty i wówczas nie ma okazji poznać dogłębnie albo doświadczyć tych decyzji, które są podejmowane. Jakie one mają konsekwencje, jakie mogą przynieść problemy itd. W związku z tym ta nauka też nie jest wówczas optymalna.

Czy chciałbyś jeszcze, Łukasz, o jakichś czerwonych flagach powiedzieć, czy idziemy dalej w tym naszym procesie rekrutacji?

 

Myślę, że tutaj ten odcinek będzie na tyle długi, że musimy przyspieszyć i iść dalej.

 

Tak zatem zróbmy. No i teraz mamy ten screening tego CV, wybieramy potencjalnych kandydatów. W zależności od tego, jak firma sobie układa proces rekrutacji, no to albo mamy jakąś rozmowę techniczną, weryfikację rekrutacji, wiedzy technicznej, dużo różnych możliwości, też jak gdyby nie na tym się dzisiaj skupiamy, dochodzi w pewnym momencie do tej rozmowy z managerem, hiring managerem, z kimś, kto ma wybadać coś więcej, coś może innego niż tylko umiejętności techniczne. I na co tutaj warto zwrócić uwagę?

 

Przede wszystkim też musimy słuchać kandydata. Wiem, że to jest oczywiste, ale musimy słuchać, co on ma do powiedzenia, a też czytać takie sygnały niewerbalne, mi się wydaje, to jest też dość ważne.

Bo wiadomo, że to jest sytuacja stresująca, rozmowa o pracę, ale niekoniecznie jakby to, że ktoś się bardziej stresuje, to musi znaczyć, że będzie gorszym pracownikiem, może być nawet wręcz odwrotnie. Natomiast słuchajmy, co kandydat do nas mówi, też pozwólmy mu zadawać pytania, bo to też jest ważne.

Ja też czasami zastawiam w trakcie rekrutacji takie pułapki i też części informacji nie podaję i oczekuję, że ten kandydat dopyta o pewne rzeczy. Na przykład ostatnio rekrutowałem co prawda nie IT, ale osobę z marketingu, i czekałem na pytanie o budżet marketingowy. Na tej podstawie osoby, które nie zadały pytania o budżet, które moim zdaniem tutaj jest podstawowym pytaniem, to miały już duży, duży, duży minus.

Analogicznie, jeśli chodzi o rekrutację programisty, to np. ja często zadaję pytania o Solid, ale nie o SolidJobs, tylko o reguły programowania. I też np. dopytując się o Dependency Inversion, to najpierw zadaję to pytanie, a potem jeszcze staram się takim prostym zadaniem, mega prostym UML-em, dojść do tego, czy ta osoba wie, o czym mówiła, czy tylko po prostu tę regułkę wyklepała. Czyli daję dwie klasy Interface i proszę, żeby tutaj zaznaczyć, co powinno zależeć od czego, zgodnie z definicją na przykład, tak? Czy tam jakiś przykład jakiegoś tam sendera maili i tam czegoś, i pokaż, jak to powinno zgodnie z tymi regułami być zrobione.

 

Zgadza się. Myślę sobie, że tutaj warto akurat angażować, jeśli mówimy o, tak jakby odszedłeś troszkę od tego tematu luźnej rozmowy, takiej powiedziałbym, związanej z Culture Fit, ten ciężar pożyłeś trochę bardziej na technicznej rozmowie. Myślę, że jeśli tutaj jesteśmy na tym etapie, to warto pewnie zaangażować też inne osoby. z zespołu, bo przede wszystkim to, o czym mówiliśmy we wcześniejszym odcinku, ten manager IT nie zawsze musi być najbardziej kompetentny, nie zawsze jest w stanie bardzo dokładnie tę wiedzę zweryfikować, tu się mogą przydać inni specjaliści.

Pewnie można byłoby długo rozmawiać o tym, jakie metody weryfikowania tej wiedzy technicznej są najlepsze. Nie wiem, czy to jest tutaj najlepszy moment na to, ale to, co pewnie warto by było poruszyć, to czy według Ciebie, jako managera IT, warto, aby dawać taką możliwość skorzystania z AI przy tworzeniu tych rozwiązań, czy w ogóle zakazujemy?

 

Tego nie powiedzieliśmy, ale ja sobie nie wyobrażam, albo inaczej. Wyobrażam sobie, bo miałem kiedyś do czynienia, ale już nauczyłem się, że nie można zrobić takiej rekrutacji na osobę techniczną, programistę np. bez… W ogóle nie tylko osobę programistą, bez po prostu jakiegoś zadania, bez pozwolenia komuś pokazania swoich umiejętności, tych, które będzie codziennie używać w pracy, czyli w przypadku programisty to wiadomo, że to jest jakieś zadanie w formie live codingu lub też wcześniej poproszenie o zrobienie jakiegoś prostego zadania.

Często to też można łączyć, np. ja czasami proszę o zrobienie jakiegoś prostego zadania, np. ściągnięcie po API ze Stack Overflow jakichś danych. I potem z tym zadaniem ktoś przychodzi i kolejny etap to jest taka refaktoryzacja i jeszcze tam dokładam kolejne jakieś klocki, to już robimy sobie razem. I patrzę, jak komuś idzie. I tak, moim zdaniem, jeśli w pracy normalnie korzystasz ze Stack Overflow, z Chata GTP czy tam z innych narzędzi, to nie widzę powodu, żebyś w czasie rozmowy kwalifikacyjnej z tych narzędzi miał nie korzystać.

Nie wiem, jeszcze czekam, nie spotkałem, że ktoś przyjdzie na rozmowę z książką i będzie w książce coś sprawdzał, ale pamiętam na studiach mieliśmy takie mieliśmy takie też egzaminy, gdzie można było mieć swoją książkę i coś sprawdzić i moim zdaniem to jest okej, bo to nie musi być tak, że masz wszystko w głowie, wszystkie reguły, całą wiedzę, nie musisz mieć tego w głowie, ważne, że wiesz, czego szukać i pod jakimi hasłami, i co z czym. Myślę, że to jest ważniejsze niż to, żeby znać na pamięć wszystkie kruczki.

Nie wiem, jeszcze czekam, nie spotkałem, że ktoś przyjdzie na rozmowę z książką i będzie w książce coś sprawdzał, ale pamiętam na studiach mieliśmy takie mieliśmy takie też egzaminy, gdzie można było mieć swoją książkę i coś sprawdzić i moim zdaniem to jest okej, bo to nie musi być tak, że masz wszystko w głowie, wszystkie reguły, całą wiedzę, nie musisz mieć tego w głowie, ważne, że wiesz, czego szukać i pod jakimi hasłami, i co z czym. Myślę, że to jest ważniejsze niż to, żeby znać na pamięć wszystkie kruczki.

 

Tak, albo całą dokumentację jakiejś biblioteki to jest kompletnie bez sensu, bo to nie oddaje kompletnie rzeczywistej pracy, którą wykonuje się na co dzień.

 

Tak, to tutaj taki kiedyś był urban legend właśnie, że ktoś poszedł na rozmowę o pracę, zapytali go się z tej biblioteki i powiedzieli, że jej nie zna się, okazało się, że to był autor tej biblioteki.

 

Tak, tak, kojarzę, faktycznie.

 

To chyba jest prawdziwa historia, ale nie pamiętam tutaj, o co chodziło.

 

To prawda, są historie o ludziach, którzy próbowali się dostać do Google’a i faktycznie odpadali z jakichś rzeczy związanych z biblioteką, którą sami stworzyli, więc wierzę.

Dobrze, no słuchaj, jeśli jako kandydat ma się takie nieszczęście, że aplikuje się poprzez portal z ogłoszeniami pracy, który nie ma obowiązkowych widełek, no to pewnie pojawia się na tej rozmowie...

 

To nie róbcie tego.

 

Tak, po pierwsze tak, popełniliście błąd, ale zawsze możecie się poprawić, a po drugie prowadzi to nieuchronnie do sytuacji, w której w rozmowie z tym managerem musi paść to niekomfortowe pytanie, za ile? No właśnie, co wtedy?

 

Ja właśnie nie lubię tych pytań i to jest dla mnie niekomfortowe rozmawiać z kimś, a tym bardziej jakbym ja miał być po drugiej stronie i mówić, że tyle i tyle. Na pewno znowu słuchajmy kandydata. Fajnie, jeśli kandydat też mówi w widełkach. To też jest zawsze dla mnie na plus.

Dwa, też pamiętajmy, że my zazwyczaj w ogłoszeniu o pracę podaliśmy kwoty brutto, a jeszcze nie spotkałem takiej rozmowy o pracę, a już naprawdę setki ich przeprowadziłem, żeby ktoś mi podał kwotę inną niż netto. Tak że to też zwróćmy na to uwagę.

Co tu mogę więcej powiedzieć? Musimy po prostu sprawdzić, czy to, czego ten kandydat oczekuje, czy to jest adekwatne do tego, jak się zaprezentował i do tego, jaką wartość tutaj może nam dać. Chyba nie ma tu większej filozofii.

 

Dokładnie, ale żeby uniknąć właśnie tej niekomfortowej sytuacji, to lepiej wybierać takie jobboardy, które zapewniają nas, że każda oferta z tymi widełkami będzie.

Okej, a jak manager IT powinien patrzeć na wykształcenie? Czy zwracasz w ogóle na to uwagę? Nie? Czy to coś wnosi do projektu, do zespołu? Czy nie ma znaczenia?

 

Tutaj ja będę kontrowersyjny, bo wiem, że ogólnie w IT jest taki konsensus, że to doświadczenie to jednak jest drugorzędne. Natomiast ja naprawdę wielu ludzi zatrudniłem i zawsze się okazywało, zawsze się w moim przypadku okazywało, że ta osoba z tym wykształceniem jest lepsza niż ta osoba bez tego wykształcenia i też osoba po jakiejś technicznej uczelni zazwyczaj też lepiej się sprawdzała niż osoba po takim nawet uznanym za lepszy gdzieś tam uniwersytecie.

A też warto patrzeć, co to jest za szkoła, bo też samo wykształcenie w szkole melanżu to też niekoniecznie to jest to. Wydaje mi się, że jednak jak ktoś ma w CV taką lepszą uczelnię, to coś to jednak znaczy.

 

Tak, to jest faktycznie taki temat pod tytułem zależy.

 

Tak, wiadomo, że może się zdarzyć super kandydat bez żadnego wykształcenia, a tu może być ktoś po najlepszym uniwersytecie w Polsce, ale na samych trójkach leciał.

 

Tak. Pewnie. Ja do tego podchodzę w ten sposób, ponieważ zatrudniałem osoby, które były na przykład po polonistyce i doskonale się później odnajdowały, więc nie jest to dla mnie coś, co ma decydujące znaczenie, w sensie wykształcenie techniczne, informatyczne, jakkolwiek.

Ale nie ma co ukrywać, że jeśli miałbym do wyboru dwóch kandydatów bardzo zbliżonych i jeden byłby faktycznie po takiej uczelni technicznej, to pewnie skłaniałbym się bardziej w tym kierunku, ponieważ wracamy do tego już któryś raz pewnie tutaj w tych naszych cyklach podcastów, że te podstawy, które ma się opanowane, pozwalają nam później budować, być bardziej elastycznym w poznawaniu nowych technologii. I to jest albo to może być coś, co się wynosi z uczelni, oprócz sterty kserówek, więc nie zaszkodzi pewnie.

 

Na pewno nie zaszkodzi, tak.

 

Dobrze, wiesz, jako manager IT oprócz tego, że uczestniczymy w tych rekrutacjach tak bezpośrednio, szukamy kogoś do naszego zespołu, to również możemy być zaangażowani, powiedzmy, w budowanie jakiegoś employee brandingu albo w generalnie budowanie takiego wizerunku, który pozwoli nam przyciągnąć ten przysłowiowy i mityczny talent.

To jest dosyć ciekawa rzecz, bo jak się popatrzy na różne raporty, zresztą jako SolidJobs też przynajmniej kilka takich wydaliśmy, to tam się przejawiają prawie cały czas podobne aspekty, na które ludzie zwracają uwagę, i myślę, że warto być przynajmniej świadomym tego, że faktycznie tak to działa.

I tutaj wielkie zaskoczenie. Pierwszym takim elementem, na który ludzie zwracają uwagę, kandydując, to jest wynagrodzenie. Wielka niespodzianka, ale tak faktycznie jest. Ale myślę, że jak się popatrzy na zwłaszcza te młode pokolenia, to tam taka autentyczność… Takie nieściemnianie też gra dużą rolę, więc jeśli jako manager IT jesteś zaangażowany w rozbudowę pracy nad employee brandingiem firmy, to warto tutaj, żeby on był autentyczny, prawdziwy, bo bardzo szybko wówczas wychodzi na rozmowie, że na YouTube mówimy jedno, a w rzeczywistości robimy coś zupełnie innego.

 

Tak, np. możemy mówić, że jesteśmy transparentną firmą, a tutaj podawać ogłoszenie bez widełek. Albo możemy mówić, że jesteśmy młodym, elastycznym zespołem, ale pracujemy tylko od 8 do… Do której się pracuje? Do 16.

 

Jak ktoś ma szczęście, to tak.

 

Coś tam, coś tam, ale nadgodziny. Life work balance. To jest to hasło, którego tam się używa. Ale czy jest pan gotowy na nadgodziny? Takie pytanie tutaj. Tak że to jeśli coś mówimy, no to się tego trzymajmy, a jeśli tak nie jest, to jakby po co to mówić tak?

 

No tak, to jest aż tak proste, w sensie to jest aż za proste, mogłoby się wydawać. I teraz jest pytanie, czy lepiej być gdzieś tam, nie wiem, przyciągniętym jakąś taką wizją na przykład do firmy, która kompletnie nie jest prawdziwa, czy lepiej od początku już poznać tę prawdę, stan faktyczny, jak to wygląda.

To też jest pewnie tutaj, myślę, taka rzecz, która przyświeca nam SolidJobs, aby te oferty faktycznie były rzeczywiste, aby oddawały realne warunki pracy, aby mówiły co będziesz robił, gdzie będziesz pracował, ile będziesz zarabiał. To jest ta rzeczywistość, z którą nie da się po prostu dyskutować.

Dobrze, jak moglibyśmy, myślę tutaj o tak zwanej dobrej rekrutacji z perspektywy managera IT, kiedy manager IT może być zadowolony, że faktycznie to przebiegło w dobry sposób, nie tylko pod kątem tego, że udało się zatrudnić osobę, która się pasuje w zespół, ale że sam proces wyglądał tutaj sensownie.

Myślę, że tutaj w tym temacie można było powiedzieć, że jako manager IT nie tylko oceniamy te twarde umiejętności, które oczywiście są istotne, ponieważ zatrudniamy inżyniera, zatrudniamy specjalistę IT, ale też patrzymy na dopasowanie kulturowe i zespołowe.

Bo później to my będziemy musieli w jakiś sposób radzić sobie z zespołem, w którym pojawi się ta osoba, która zawsze wpływa na dynamikę tego zespołu, zawsze coś wnosi od siebie, zawsze zmienia trochę tę grupę ludzi i konsekwencje tych zmian siłą rzeczy na managera gdzieś też się przełożą, będzie musiał sobie z nimi radzić, więc warto jest również pod tym kątem w procesie na tę osobę spojrzeć.

 

Ja też bardzo lubię w rekrutacji też takie pytanie zadać o hobby czyjeś, bo to sprawia, że też trochę rozładowuje się napięcie, też to jest takie trochę w trakcie tej rozmowy, albo czasami na początku zależy, jeśli widzę, że osoba jest taka bardzo spięta i denerwuje się, więc żeby rozładować to napięcie, to też fajnie jest porozmawiać o tym hobby, bo wtedy ktoś mówi o czymś, czego raczej nie spali i o czymś, na czym dobrze się zna, i też fajnie można wtedy tę rozmowę poprowadzić i z tego punktu wyjść do jakichś już kolejnych konkretnych pytań.

 

Dokładnie. Rekrutowanie developerów albo innych specjalistów IT to nie jest jedyne zadanie, które manager IT ma w swoim kalendarzu, więc warto byłoby, aby ten proces, ta rekrutacja była w miarę szybka, przejrzysta, efektywna.

 

A dwa, jak widzimy, że tutaj ktoś nam powie, że jego hobby to sport i bodybuilding, a my tutaj jesteśmy bandą nerdów, to już wiadomo, że to nie to.

 

Może tak, może być zgrzyt, coś tutaj może się nie udać. No tak, wspomniałeś tutaj o książce Kahnemana, o tych pułapkach myślenia i to może być właśnie przykład na taką pułapkę myślenia, że staramy się szukać osób, które są do nas podobne, podobne do już tych członków zespołu, którzy z nami pracują, i nie zawsze to może być najlepsze rozwiązanie, ale oczywiście mówimy tutaj o jakichś tam skrajnościach.

 

Tak, z błędów jeszcze, które mogę wymienić, to na pewno też miałem takie sytuacje, że osoba, z którą rozmawiałem na tej rozmowie kwalifikacyjnej, opisywała te same problemy, które ja miałem u mnie w zespole. Borykała się z tymi samymi problemami w poprzedniej pracy, rozwiązywała te same problemy i to gdzieś tam była nić tego, że daną osobę zatrudniłem, po czym okazało się, że jednak to był błąd, bo mimo że tutaj ta nić porozumienia i to podobieństwo było duże, to się okazało, że jednak nie performowała, nazwijmy to tak brzydko po HR-owemu, jakbyśmy chcieli, mówiąc wprost, członkowie zespołu się wręcz skarżyli, że ktoś nie robi tyle, ile powinien.

 

No tak, bywa i tak, bywa i tak. Co możemy z tym zrobić? Przede wszystkim możemy jako manager zaangażować się w zdefiniowanie tych wymagań początkowych. Nie zawsze to rozwiąże nam wszystkie problemy, ponieważ w tych wymaganiach, które tworzymy, nie da się zawrzeć wszystkich możliwych elementów i bardzo często to są tylko te techniczne problemy. Ale jeśli nie uczestniczymy w ocenie kandydatów, to też nie możemy później mieć za złe, że do naszego zespołu została dokoptowana osoba, która nie spełnia tych naszych założeń, więc to też jest niezbędny krok, żeby się faktycznie jakoś w to zaangażować.

I co, myślę, warto, to uczyć się na swoich błędach albo sukcesach, czyli spojrzeć co jakiś czas, czy ten proces ma sens, co dałoby się tutaj ulepszyć, co dałoby się zmienić, czy ta osoba, która została zatrudniona, spełnia nasze oczekiwania.

 

Tak, to jest coś, co jako HR-y mogłyby się uczyć właśnie od IT, czyli w Scrum jest taka instytucja jak retrospektywa i po prostu na koniec patrzymy na nasz proces, a nie jakby na produkt, tylko właśnie na proces i staramy się ulepszyć sam proces. Czyli patrzymy, jak nam poszło. Też fajnie np. stworzyć sobie taki dziennik doświadczeń i np. też notować, co było dobrze, co było źle do poprawy na następny raz.

Zróbmy taką retrospektywę na koniec. Po jakimś czasie można też zweryfikować, czy to zatrudnienie było okej, np. po tych trzech miesiącach, czy po pół roku. Sprawdźmy, czy mieliśmy rację, gdzie się pomyliliśmy.

 

I w tej naszej rozmowie musiała nastać taka chwila, gdzie pada słowo AI. Nie uciekniemy od tego.

Zerknąłem sobie ostatnio i sprawdziłem, jakie mamy obecnie narzędzia, które AI nam podsuwa właśnie w procesie rekrutacji. Jest tego całkiem sporo. Są oczywiście takie oczywiste rzeczy, jak wyszukiwanie kandydatów pasujących do jakiegoś wzorca. Jest oczywiście automatyczna ocena CV. Tutaj znowu to znaczenie słów kluczowych jest istotne. To, o czym mówiliśmy na początku, może być akurat pewnym problemem, że jeśli ustalimy sobie, że tam ma być RabbitMQ, a ktoś miał Kafkę, to już absolutnie nie wpada, chociaż można powiedzieć, że to jest ten sam zbiór technologii. Pewnie ta osoba mogłaby się w miarę szybko tutaj dostosować, ale ten AI tutaj nas z tego procesu, że tak powiem, tego kandydata wyrzuci z tego tytułu.

Ale ciekawe są też tacy AI asystenci, chyba tak mógłbym tak nazwać, czyli wirtualne byty, które przeprowadzają te pierwsze rozmowy rekrutacyjne i weryfikują, czy ta osoba spełnia te oczekiwania. Ale co ciekawe, takie najbardziej zaawansowane narzędzia tego typu uczą się też na podstawie wcześniejszych rekrutacji, czyli np. jeśli… osoba z jakimiś tam określonymi cechami, doświadczeniem itd. została zatrudniona, jeśli odniosła w tej organizacji przysłowiowy sukces, to jest spora szansa, że ten AI asystent do rekrutacji będzie poszukiwał podobnych osób. Co oczywiście może nas tutaj prowadzić do kolejnych pułapek myślenia i wpadania w jakieś tam uprzedzenia i pytanie, czy to jest dobrze, czy to źle. Ciężko powiedzieć.

W każdym razie tych narzędzi jest naprawdę wiele do automatycznej oceny różnych aspektów rekrutacji. Myślę sobie, że nie ma się co tutaj obrażać jako manager IT, że one istnieją. Być może warto je zastosować, kiedy to ma sens, ale warto też być świadomym, że mogą mieć jakieś uprzedzenia, mogą eliminować właśnie kandydatów, którzy mogliby z powodzeniem zostać zatrudnieni.

 

Dobrze, to przejdźmy jeszcze może do błędów w rekrutacji, czyli co Twoim zdaniem, Krzysztofie, nie działa?

 

Tak, zdecydowanie długa rekrutacja, która powoduje, że nam po prostu te osoby odpadają, wypadają, ponieważ myślę, że dla wszystkich oczywiste jest to, że nie aplikujemy na jedną ofertę i czekamy, aż się tam ten proces rekrutacji skończy. Aplikujemy na ileś tam, więc jeśli ten proces się będzie przedłużał, to ryzykujemy utratę tych najbardziej utalentowanych osób.

To, co tutaj podkreślamy od samego początku, czyli transparentność oferty, rozumiana jako widełki wynagrodzenia, po to żebyśmy nie musieli tracić czasu i nie wiem, angażować tam osobę w kolejne rozmowy, rozwiązywanie zadań itd., żeby na piątym, dziesiątym etapie rekrutacji okazało się, że jednak nie możemy się dogadać ze względów finansowych. Myślę sobie, że to jest bardzo fair dla obu stron, żeby faktycznie tak do tego podejść.

Oprócz oczywiście wynagrodzenia, wszystkie te warunki pracy związane z miejscem pracy, formą zatrudnienia, jakimiś benefitami, obowiązkami, które będą spełniane, czyli taka przejrzystość tej pracy, tej oferty, żeby było wiadomo, na co kandydat się pisze, klikając aplikuj.

Mówiliśmy tutaj o używaniu Stack Overflow, innych narzędzi, nawet AI-owych w procesie rekrutacji. To, myślę, nas tutaj sprowadza do takiego błędu, że czego ja zresztą nie jestem absolutnie fanem, dawanie jakichś abstrakcyjnych, algorytmicznych zadań do rozwiązania, które właściwie nie wiem, co mają sprawdzić.

Według mnie największy sens ma dawanie zadań, które są domenowo jakoś powiązane z tą firmą, do której aplikujemy. Jeśli to jest jakiś startup, firma produktowa itd., zazwyczaj wewnątrz jakiejś domeny tam się, powiedzmy, to wszystko kręci, więc ma największy sens, żeby to było jakieś w miarę bliskie rzeczywistości zadanie.

 

Tak, ja też często mam takie zadania, które gdzieś tam wynikają z tego, że kiedyś mieliśmy jakiś problem z czymś i sobie zapisałem, zmieniłem to w takie mini zadanie i jest zadanie do rozwiązania, takie żywcem wzięte po prostu gdzieś tam kiedyś z produkcji.

Też jedną rzecz jeszcze chciałem powiedzieć, to też wcześniej miałem o tym powiedzieć, ale też dając takie zadanie, to też nigdy nie piszę w wymaganiach, że np. oczekuję, że napiszesz do tego testy jednostkowe. Taka pułapka, sprawdzam, czy w ogóle ten kandydat to zrobi sam z siebie, no i jeśli zrobi, to ma dużego plusa. Jeśli nie, no to ma dużego minusa.

 

Jasne, bo nie zawsze programista ma komplet tych wymagań technicznych czy nietechnicznych w momencie, kiedy przystępuje do realizacji zadania, więc jeśli ma wypracowany ten warsztat, to też właśnie jesteśmy w stanie go ocenić, nie będąc takim idealnym w opisie tego zadania i zostawiając pewne pole tutaj do zagospodarowania po stronie kandydata.

Z takich kolejnych rzeczy, które gdzieś nie działają, i które często dzisiaj podkreślaliśmy i gdzieś tam staraliśmy się uwypuklić, są uprzedzenia. Trzeba być przynajmniej świadomym –  i tutaj książka Kahnemana jest pewnie doskonałym źródłem, że takie uprzedzenia każdy z nas ma. Nie wszystkie da się wyeliminować, wręcz jestem przekonany, że się nie da, ale przynajmniej będąc ich świadomym, jesteśmy w stanie się złapać na momencie, kiedy im gdzieś tam ulegamy. I zatrudnianie takich samych osób jak my, takich samych jak inni członkowie zespołu też na dłuższą metę nie jest pewnie dobrą praktyką.

Myślę, że powoli będziemy zbliżać się do zamknięcia tej naszej rozmowy na liczniku już ponad 45 minut. To chyba będzie najdłuższy odcinek tutaj nie tylko w tej serii, ale też we wcześniejszych. Ale dobrze, bo temat jest szeroki, temat jest ważny. To co? Podsumowujemy. 

 

Z takich kolejnych rzeczy, które gdzieś nie działają, i które często dzisiaj podkreślaliśmy i gdzieś tam staraliśmy się uwypuklić, są uprzedzenia. Trzeba być przynajmniej świadomym –  i tutaj książka Kahnemana jest pewnie doskonałym źródłem, że takie uprzedzenia każdy z nas ma. Nie wszystkie da się wyeliminować, wręcz jestem przekonany, że się nie da, ale przynajmniej będąc ich świadomym, jesteśmy w stanie się złapać na momencie, kiedy im gdzieś tam ulegamy. I zatrudnianie takich samych osób jak my, takich samych jak inni członkowie zespołu też na dłuższą metę nie jest pewnie dobrą praktyką.

 

Myślę, że powoli będziemy zbliżać się do zamknięcia tej naszej rozmowy na liczniku już ponad 45 minut. To chyba będzie najdłuższy odcinek tutaj nie tylko w tej serii, ale też we wcześniejszych. Ale dobrze, bo temat jest szeroki, temat jest ważny. To co? Podsumowujemy.

 

Chciałem najpierw powiedzieć, że jako ten manager myślę, że nie ma ważniejszej rzeczy, którą tutaj możesz zrobić niż dobrze zatrudnić i nie możesz czegoś gorzej spieprzyć niż po prostu zatrudniając niedobrego kandydata. Tak że proces rekrutacji, to jest najważniejsze, co Ciebie jako managera tutaj w firmie czeka. Z tego powodu tutaj o tym rozmawiamy.

I tak, to może dość nietypowo bym chciał podsumować tutaj przy pomocy czegoś takiego jak Solid Recruitment, czyli takiego zbioru naszych właśnie wartości, naszej filozofii, czyli tego, jak rekrutować.

I historia jest taka, że kiedyś sobie tak pomyślałem jak miałem rekrutować, że fajnie byłoby tak rekrutować w taki sposób agile. Tak że szukałem, czy jest coś takiego jak agile recruitment i co okazało się, że jest. Tylko przeczytałem to i okazało się, że to z agile to chyba nie ma nic wspólnego, bo osoby, które to tworzyły, to chyba po prostu użyły buzzwordu I tam był nacisk na narzędzia, tudzież bardzo skomplikowane to wszystko było, wymagało wielu osób. Tak że my chcieliśmy stworzyć coś, co będzie takie lekkie i właśnie zwinne.

I tak powstała nasza propozycja podejścia do rekrutacji, którą właśnie tak nazwaliśmy sobie jako Solid Recruitment.

I jakie tutaj są te podstawowe założenia, czyli po pierwsze metoda naukowa, czyli nie opieramy się na naszych wrażeniach, tylko opieramy się na tym konkretnym wyniku rozmowy i tutaj na przykład takim narzędziem, który by to wspierał, jest ta karta oceny kandydata, ale oczywiście możecie to zrobić w jakikolwiek inny sposób, natomiast my  dajemy już też takie gotowe narzędzie, które ma za zadanie pomóc w tym, czyli pomóc porównać na koniec wyniki tych kandydatów.

Drugi aspekt to jest komunikacja. No i w ramach komunikacji postarajmy się o to, żeby ten proces rekrutacji był jak najbardziej przejrzysty, jak najprostszy i też krótki, bo im dłuższy ten proces, tak jak powiedzieliśmy wcześniej, to ci najlepsi kandydaci mogą nam odpaść.

Kolejną cechą jest feedback, czyli zadawajmy o to, żeby kandydat po tej rozmowie był lepszym specjalistą i nawet jeśli mu się nie uda zatrudnić się u nas w firmie, to żeby z tego udziału w rekrutacji coś wyniósł, żeby też następnym razem mu poszło lepiej, żeby wiedział, wiedział potem na koniec, nad którymi aspektami powinien popracować.

Kolejna część to iteracyjność, czyli to, co mówiliśmy, postarajmy się na koniec zweryfikować cały proces, zweryfikować trafność tego procesu rekrutacji, uczmy się na swoich błędach, zbierzmy też feedback od kandydata, to nie jest tak tylko, że my dajemy feedback, możemy też od kandydata zebrać feedback na temat rekrutacji. Ja się zawsze na koniec pytam, jakie były wrażenia kandydata, co według niego ja powinienem poprawić w rekrutacji. To jest ta interakcyjność.

No i zostały dwa ostatnie, czyli zwięzłość, czyli kolejne etapy powinny być krótkie, sprawne i następować po sobie w miarę szybko, co też jest ważne, żeby nie było tak, że między jednym a drugim etapem rekrutacji dwa tygodnie przerwy mamy.

I ostatni, najważniejszy aspekt, czyli szacunek do tego kandydata, czyli miejmy szacunek do jego czasu, dawajmy to zadanie, które jest do zrobienia w miarę rozsądne, jasno precyzujmy swoje oczekiwania i też oczywiście w ogłoszeniu zawierajmy widełki wynagrodzeń, podawajmy same prawdziwe informacje. Postarajmy się, bo też to ogłoszenie to jest taka wizytówka naszej firmy, pamiętajmy, i postarajmy się o to, żeby to ogłoszenie też jakby reprezentowało sobą te same wartości, które my jako firma wyznajemy.

 

Tak, myślę, że managerowie IT, którzy będą używać tych zasad, nie tylko będą bardziej skuteczni w rekrutowaniu, ale też na koniec dnia sami zaoszczędzą sobie wielu problemów, bo tak jak mówiliśmy, nietrafione rekrutacje to strata czasu i strata pieniędzy.

Dobrze Łukasz, myślę, że będziemy zamykać. Bardzo Ci dziękuję za rozmowę. To był odcinek podcastu o tym, jak może wyglądać rekrutacja developera, na co zwrócić uwagę, będąc managerem IT właśnie w tej rekrutacji.

Zapraszamy wszystkich do wcześniejszych odcinków z tej serii podcastów oraz do dwóch wcześniejszych serii, które mieliśmy okazję z Łukaszem nagrać, a jeśli chcecie się zapoznać z ciekawymi ofertami pracy, jeśli chcecie poznać też i więcej przeczytać na temat tych zasad Solid Recruitment, o których tutaj Łukasz opowiedział, to zapraszamy na stronę SolidJobs, a jeśli jesteście managerem, to to jest doskonałe miejsce, żeby właśnie taką ofertę pracy tam wystawić.

 

Dzięki, Krzysztof, cześć! Do zobaczenia!

 

Dzięki, cześć!