HRakterna środa – proces idealny nie istnieje

Podobno ideały nie istnieją. Patrząc na pięknie skrojone, na miarę, stronki internetowe firm IT, można podtrzymywać to stwierdzenie. Idealne RWD, składają się perfekcyjnie, nawet na Safari w iPhonie 5. Nie przystoi, aby tyle szewców chodziło w dziurawych butach.

Stąd każdy dąży do ideału na stronie, żeby po jednym spojrzeniu człowiek nie chciał oderwać od niej wzroku. Żeby przeglądał stronę kilka razy, zagłębiał się w szczegóły, przeglądał twórczość od A do Z. Istne guru UXa i Designu dopieszczają wszystkie strony Software house’ów, tak aby te hipnotyzowały swoją treścią i wyglądem. Oryginalnymi kolorami i pomysłem na prezentację zakładki ‘About us’. Wszystko po to, aby kandydaci wybrali właśnie naszą firmę. Zwieńczeniem tej pracy jest otrzymane CV, ale co dalej? Przez ostatnie lata tworzyłam swój proces rekrutacji, który zmieniał się w zależności od danego stanowiska. Mieścił się jednak cały czas w pewnych ramach, dzięki którym udało mi się zatrudnić dziesiątki osób. W kilku punktach poniżej, opisałam poszczególne etapy rekrutacji:

1. Przegląd CV – jak już kiedyś pisałam, przejrzenie CV zajmuje kilka minut. Jeśli coś jest niejasne, można kandydata dopytać lub przejrzeć jego profil na Linkedin. Tutaj następuje wstępna weryfikacja, po której wiadomo, że junior po Bootcampie z trzy miesięcznym doświadczeniem, nie jest odpowiednim kandydatem na Senior Developera. Jeśli do CV zostanie załączony kod, który zdarza się, że wystarczy do weryfikacji umiejętności technicznych, można na jego podstawie również sprawdzić, czy osoba spełnia nasze oczekiwania. Wiadomo również, że programista programiście nie równy, i co dla jednych jest sufitem, dla innych może być podłogą. Natomiast “odsianie” potencjalnych osób, które nie mają wystarczającego doświadczenia, jest oszczędnością czasu programistów, którzy sprawdzają zadania techniczne. Warto ten etap precyzyjnie przejść, żeby również w oczach własnych kolegów z pracy być profesjonalnym.

2. Zadanie techniczne – wysłanie zadania następuje po wstępnej weryfikacji CV. Jestem zwolennikiem sprawdzania najpierw umiejętności technicznych, aby zwyczajnie nie tracić czasu na spotkania z osobami, które umieją jeszcze za mało lub nie umieją tego co powinny. Dzięki temu zamiast 40 spotkań, można odbyć ich kilka miesięcznie, za to wartościowych. W zależności od stanowiska na jakie rekrutujemy, zadania są różne, nie tylko w zakresie technologii, ale również poziomu trudności. Dobrze przygotowane zadanie, sprawdza nie tylko znajomość samego języka czy frameworków, ale sposób myślenia i rozwiązywania problemów przez rekrutowaną osobę. Na tym etapie, niczym Cezar w systemie zero- jedynkowym, akceptujemy lub odrzucamy kandydata.

3. Rozmowa z HR – kiedy zostaną zweryfikowane umiejętności techniczne kandydata, przychodzi czas na miłe rzeczy. Przyjemna rozmowa o wspólnych celach, planach, opowieści o firmie i wynagrodzeniu. Z doświadczenia mogę powiedzieć, że ta rozmowa przeprowadzona w ‘niebiurowym’ klimacie, daje lepszy obraz sytuacji. Podczas rozmowy obie strony mają swoje pięć minut. HR sprzedaje firmę, przekazując kandydatowi szczegóły, których nie znajdzie na stronie czy w ogłoszeniu. Osoba rekrutowana z kolei może się zaprezentować i przedstawić swoje potrzeby. Jako HR mamy za zadanie sprawdzić, czy CV zgadza się z rzeczywistością, z jaką osobą mamy do czynienia i czy to jest TO. Dając jednocześnie kandydatowi możliwość zapytania o wszystkie detale, których nie znalazł w ogłoszeniu czy na stronie.

4. Rozmowa techniczna – pewnie nie raz słyszeliście o sytuacjach, kiedy programista podczas rozmowy technicznej pisze kod na kartce. Nie muszę tutaj dodawać, że ta praktyka nie jest zbyt przyjazna programistom i stosowanie jej jest ryzykowne. Mam nawet kilku kolegów, którzy po takiej sytuacji zrezygnowali z dalszego procesu. Podczas rozmowy technicznej, która odbywa się z liderem zespołu, CTO lub Developerem znającym daną technologię w firmie, kandydat pytany jest o kwestie głównie techniczne. Skoro jest na tej rozmowie, to zadanie zrobił poprawnie, HR zweryfikował co trzeba, a teraz może zostać zapytany o szczegóły lub wyjaśnienie rozwiązań, które zaproponował w zadaniu. Jest to również czas na pytania o technologie jakie używane są w firmie, o proces tworzenia kodu i projekty od strony technicznej. Pamiętajmy, że Developer z naszego zespołu, którego prosimy o pomoc, jest najczęściej bardzo zajęty, więc wszystkie nietechniczne sprawy, najlepiej załatwiać z kandydatem samemu. Na tym etapie w poprzedniej firmie zapraszaliśmy jeszcze kandydata na kilka godzin do biura, żeby poznać się bliżej. Była to fajna praktyka, która jest możliwa do zrealizowania, jeśli mamy zasoby ludzi, którzy odpowiednio zajmą się kandydatem podczas tego dnia.

5. Decyzja – podejmowana w różny sposób: przez szefa danego działu, CTO albo osobiście przez prezesa. Przekazywana również na różne sposoby, od telefonu przez maila czy osobiście podczas pobytu kandydata w naszym biurze. Jakakolwiek ona nie jest, musi zostać przekazana. Nie odkrywam tu Ameryki, ale zdarzają się sytuacje, że kandydaci, nie otrzymują również odpowiedzi odmownej. Jest to nieprofesjonalne, lecz jak niemal wszystko – do wyprostowania. Świadomy HR zawsze dopilnuje, aby komunikacja podczas całego procesu była klarowna dla obu stron. Warto również przy przekazaniu decyzji dać feedback dlaczego kogoś zatrudniamy albo kogoś nie zatrudniamy. Dla nas to niewiele, a w oczach osoby, która jeszcze nas nie zna, stajemy się godnymi zaufania ludźmi, z którymi warto pracować.

Opera, której siedziba mieści się we Wrocławiu, swój proces zamyka w trzech krokach. Google z kolei przeprowadza zdecydowanie więcej etapów, bo może być ich aż 10 w zależności od stanowiska. Moje znajome firmy swoich etapów mają od 4 do 7, również w zależności od stanowiska. Uważam jednak, że każdy etap który wprowadzamy musi mieć jakiś sens. Jeśli więc dany element układanki nie wnosi żadnej wartości do naszego procesu, warto zastanowić się nad jego moderacją czy usunięciem. Zapewne proces, z którym pracuje daleki jest od ideału, ale dążąc do perfekcji będę moderować go przez kolejne lata.

Zdjęcie główne artykułu pochodzi z pexels.com.

Małgorzata Bekas. Do IT trafiła cztery lata temu, zaczynając od warsztatów z programowania PyLadies. Szybko dostała prace jako QA, chwilę później jako Manager i HR partner w startupach, które pierwsze biura miały w jej dużym pokoju. Aktualnie buduje zespół firmy SNOW.DOG. Wspiera Just Join IT. Kocha i szkoli psy, prowadzi bloga Mam psa. I co teraz? Angażuje się w akcje społeczne pomocy schroniskom i pomaga szukać psiakom domów.

Zespół redakcyjny

RocketSpace.pl

RocketSpace.pl to magazyn portalu pracy przyszłości – RocketJobs.pl. Misją RocketSpace.pl jest zwiększanie świadomości społecznej w kwestiach związanych z rynkiem pracy. Jesteśmy tam, gdzie każdy pracownik white collar. Śledzimy na bieżąco najnowsze trendy na rynku pracy.