zbliza sie nowy rok. czas…

Categories Programowanie

zbliza sie nowy rok. czas postanowien i dla wielu czas zmian. dlatego dzisiaj troche (mam nadzieje pomocnie) o rekrutacji w #it

w swoim zyciu jako kandydat uczestniczylem w 9 rozmowach rekrutacyjnych (skutecznosc 8 na 9). jako rekrutujacy przeprowadzilem ok. 1000 technicznych rekrutacji, dla roznych firm (wlasny i obce software house, kontraktornie, firmy z innych branz rekrutujace programistow in-house, agencje reklamowe). wyszkolilem sporo devow, ktorzy dzis ciagna do przodu technologie w kilkunastu firmach. mysle, ze moge dac kilka wskazowek obu stronom. technologia nie robi zbytniej roznicy w procesie, ale ze specjalizuje sie w #js, wiec przyklady beda z tego srodowiska.

na poczatek opowiem o moim procesie, ktory wydaje mi sie byc dosc optymalnym i mocno zachecam rekruterow do jego kopiowania. developerom zas do zapoznania sie, zeby wiedziec co mysli osoba po drugiej stronie.

1. zebranie potrzeb i wymagan
ten punkt jest notorycznie olewany przez wiekszosc rekruterow. dostaja informacje, ze potrzebny jest front-end dev i to wystarczy.
jednak zebranie potrzeb i wymagan jest kluczowe, dlaczego? biorac pod uwage sam front-end mozemy wyroznic naprawde wiele poziomow specjalizacji i zainteresowan. zupelnie inaczej wyglada praca osoby, ktora ma ciac szablony pod wordpressa w agencji marketingowej, inaczej osoby, ktora ma glownie przetwarzac dane w jsie uzywajac gotowych komponentow na froncie, a inaczej praca z DOM i vanilla js przy produkcie takim jak CKEditor.

pytania rekrutacyjne i poziomujace powinny byc dopasowane do wymagan. jest to wazne dla obu stron. rekruter wie, ze sprowadza dobrego kandydata, kandydat wie, ze bedzie robil to co chce.

drodzy rekruterzy – nie bojcie sie dopytywac u swoich klientow – nikogo to nie boli, kazdy sie cieszy, ze robicie robote dobrze.

drodzy developerzy – to dziala w obie strony, przeczytajcie dokladnie oferte, sprawdzcie czym zajmuje sie firma, dopytajcie rekruterow o wymagania (gdy stwierdzilem, ze chce specjalizowac sie w jsie pierwsza rzecza jaka zrobilem bylo wyslanie zapytania do 20 rekruterow – czego wymagaja na starcie od js deva, dostalem odpowiedz od wiekszosci, kilka razy dopytywalem i zbudowalem konkretna liste. dodatkowo kilka osob odezwalo sie w ciagu miesiaca z ofertami, z czego jedna byla kosmiczna i udalo mi sie w nia wbic wlasnie dlatego, ze wczesniej znalem wszystkie wymagania). wiedz co mialbys robic w firmie jeszcze zanim zaaplikujesz.

2. walidacja CV
CV absolutnie nie jest kluczowe, ale:
. jesli widze dziko postawione spacje przed przecinkami, myslnikami albo roznie sformatowane akapity – wiem, ze moze byc ciezko, jezeli ktos niechlujnie podchodzi do swojej wizytowki istnieje duza szansa, ze podobnie bedzie podchodzil do kodu,
. cenie bardzo oprocz wypisania nazwy pozycji (co robi kazdy) wspomnienie w jakich technologiach pracowales i jaka byla Twoja rola w zespole (jakie byly Twoje zadania, jakie taski robiles). dzieki temu nasza pozniejsza rozmowa bedzie duzo plynniejsza (i prawdopodobnie krotsza), bo bede mogl sie przygotowac odpowiednio,
. zainwestuj w szablon cv (20pln w internecie) albo uzupelnij profil na linkedin (moze dzialac zamiast cv) – spraw, zeby graficznie wygladalo ladnie i schludnie, nie potrzeba Ci fajerwerkow
. jezeli nie masz doswiadczenia komercyjnego – nie ma problemu, opisz projekty nad ktorymi pracowales sam

2. rozmowa z kandydatem
moim zdaniem rozmowa face 2 face na zapoznanie jest zupelnie zbyteczna i tworzy dodatkowa stope komplikacji. mozna zrealizowac je w calosci na videocallu z opcja screen share.

podczas rozmowy staram sie dowiedziec paru rzeczy:
– dotychczasowe doswiadczenie kandydata
doswiadczenie bardzo uzaleznione jest od poziomu, ale istotne rzeczy jakie warto jest wylapac to:

. czy kandydat ma swoje projekty
co nam to mowi o kandydacie? to, ze potrafi od zera postawic projekt, jezeli jeszcze jest on gdzies hostowany, to mamy wlasciwie pewnosc, ze rozmawiamy z kims w miare ogarnietym, kto zaznal wszystkich aspektow developerki – od postawienia lokalnie srodowiska, przez zakodowanie rozwiazania po deploy projektu (nawet jesli to zwykla wrzutka przez FTP) i podpiecie domeny. to cenna wiedza, nawet jesli nie bedzie pozniej uzywana

. z jakimi technologiami pracowal kandydat
bardzo czesto czytam w wymaganiach o technologiach, ktore sa zupelnie nieistotne i do nauczenia w 15-30min w zakresie w jakim jest to kandydatowi potrzebne (kiedys tak bylo z gruntem, gulpem, teraz tak jest z dockerem). warto zapytac kandydata co robil w danej technologii, jak widzi jej wykorzystanie, etc. niekoniecznie musza to byc pytania technologiczne, jezeli wiesz do czego sluza dane technologie (drodzy rekruterzy, nie wiecie to pytajcie) to pytania o konkretne komendy jest zupelnie zbedne.

. czy kandydat kiedykolwiek pracowal w zespole
praca solo bardzo rozni sie od pracy w zespole, a zazwyczaj nie rekrutujemy solo devow. warto dowiedziec sie jak zlozony byl zespol – jezeli np. byles jedynym front-endowcem w zespole backendowym patrze na Ciebie inaczej niz gdy pracowales z kilkoma frontami. czy byles leadem i miales kogos pod soba, jak doswiadczony byl Twoj lead, etc. Istotnym jest dla mnie pytanie o metodologie pracy (czy byl to waterfall czy agile). U moich klientow i w moim zespole pracujemy w agile, dlatego dopytuje o znajomosc tej metodologii (czy byla praca w pelnym scrumie, czy realizowane byly wszystkie elementy scruma, etc).

warto tez zapytac o ocene pracy swojego zespolu, co sie podobalo, co sie nie podobalo. na tej bazie mozna wyciagnac opinie odnosnie tego czy kandydat odnajdzie sie w naszym teamie i czy pasujemy do siebie oczekiwaniami

– plany kandydata i w jakim kierunku chcialby sie rozwijac
czasami kandydat nie pasuje swoimi planami do firmy, warto wtedy przedstawic swoje plany i cele i dowiedziec sie czy uda sie zmatchowac, jesli nie warto zyczyc sobie wzajemnie powodzenia i szukac dalej

– umiejetnosci jezykowe
czesto prosze, zeby kandydat opowiedzial o projekcie w ktorym uczestniczyl po angielsku. nie jest to oczywiscie w wielu wypadkach warunek konieczny, ale akurat u mnie jest potrzebny.

– umiejetnosci technologiczne
to juz bardziej rozbudowany temat. moim zdaniem te czesc powinien przeprowadzac rekruter technologiczny, chociaz wyobrazam sobie, ze mogloby to zostac zupelnie oddelegowane rekruterom nietechnicznym (ale musi byc dobrze zrealizowany punkt 1).

jak ja to robie? mam przygotowanych pare prostych i oklepanych zadan (FizzBuzz, kilka zadan na manipulacje obiektami i tablicami, proste uzycie .map, .reduce, .filter, operowanie stringami). wybieram 2 i daje do napisania kandydatowi. widze caly czas na ekranie jak pracuje, moge wiec na biezaco oceniac jego skillsy. to sa zadania pokazujace czy developer w ogole potrafi programowac, nie wymagaja zbytniej wiedzy technologicznej od przeprowadzajacego rozmowe. wyobrazam sobie, ze instruktor nietechniczny moze miec podpowiedzi wczesniej wypisane + wlasciwe rozwiazanie + testy do rozwiazania – cos na ksztalt codility.

wazna uwaga dla kandydata: badz przygotowany. serio w internecie sa setki zadan rekrutacyjnych, istnieje codewars, gdzie mozesz zobaczyc nie tylko zadania ale i rozwiazania. idziesz na rozmowe kwalifikacyjna – spedz 3-4 dni robiac takie zadania. przejrzyj MDNa i liste metod (zwlaszcza arraya i stringa, z nich bedziesz korzystac najczesciej),

po tym punkcie stwierdzamy, czy w ogole chcemy przejsc do punktu nr 3.

3. domowe zadanie technologiczne
swego czasu mialem wrazenie, ze ten punkt jest mocno znienawidzony przez programistow, dlatego ze sam za tym nie przepadalem. doprowadzilem do tego, ze placilem ludziom za czas poswiecony na zadanie rekrutacyjne (sam tak milo zostalem kiedys potraktowany przez shoper.pl – przeszedlem rekrutacje ale nie dogadalismy sie odnosnie formy wspolpracy, jednak ich Prezes stwierdzil, ze przeleje mi pieniadze za rekrutacje). pozniej jednak zrezygnowalem z tego z powodow o ktorych nie ma po co wspominac.

zadanie ma na celu sprawdzenie pracy developera w jego swobodnych warunkach. chce zobaczyc jak ktos pracuje

wazne w zadaniu jest to, zeby:
– kandydat mogl wykonac zadanie w dowolnym czasie,
prosze kandydata, zeby mierzyl czas pracy nad zadaniem, ale nie oczekuje od niego ze skonczy je nastepnego dnia. dajemy sobie rozsadny termin (do 2ch tygodni jesli potrzebuje pilnie, bezterminowo jesli mamy otwarta rekrutacje)

– bylo jasne i przejrzyste,
u nas w zadaniach rekrutacyjnych dajemy oprocz opisu rowniez liste wymagan jakie chcemy, zeby rozwiazanie spelnialo. pracujemy w okreslonym stylu, wiec nie rozumiem dlaczego mielibysmy oczekiwac od kandydata, ze sam sie domysli czego chcemy. rozpisujemy od najprostszych rzeczy (uzyj lintera) po bardziej skomplikowane (fajnie jesli zastosujesz strategy pattern). dzieki temu kandydat wie jakie wymagania musi spelniac jego rozwiazanie – to czy ma te wiedze czy nabedzie ja podczas rozwiazywania jest sprawa drugorzedna, wazne ze przychodzac do pracy bedzie juz to umial.

przyklad
https://drive.google.com/file/d/19F4-YxFX2_LrMgfZcQGhJvB9TyhvTScf/view?usp=sharing (zadanie)
https://drive.google.com/file/d/1aWZdId8tzJjkwMmNUlnygCO5h6Q1-QLK/view?usp=sharing (wymagania)

– pokazywalo potrzebne umiejetnosci,
jezeli rekrutuje na js deva to wybieram najczestsze zadania z jakimi kandydat zmierzy sie w pracy (konsumpcja api, prosty html, uzycie podstawowych konceptow z frameworka ktorego uzywamy)

– nie zajmowalo za duzo czasu,
nasze zadania rekrutacyjne zrobione sa na prosta modle. siadalem do komputera i mierzylem czas w jakim jestem w stanie zrobic dane zadanie – oba sa na 3-4h. i to jest czas wykonania jakiego oczekuje od seniora (+20%), od mida czas x2, dla juniora x10. pamietajmy jednak, ze sam czas jest tylko jednym z wyznacznikow (no ale jesli proste zadanie zajmuje komus 100h to wiedz, ze cos sie dzieje).

– zostalo ocenione,
gdy zadanie zostanie rozwiazane wysylamy feedback technologiczny (niezaleznie od tego czy chcemy kandydata czy nie). zazwyczaj w przypadku kandydatow odnosnie ktorych mamy watpliwosci albo chcemy, zeby cos podciagneli prosimy rowniez o ich poprawienie

od developera oczekuje:
. jasnej komunikacji kiedy projekt zostanie ukonczony (jest to test na slownosc),
. jasnej komunikacji wszelkich watpliwosci i problemow (jak cos jest niejasne to oczekuje pytan – najlepiej z sugerowana odpowiedzia, mam wtedy pewnosc ze nie bedzie sytuacji w ktorej dev marnuje swoj i moj czas w pracy robiac cos zupelnie niezgodnego z oczekiwaniami, bo bal sie zapytac),
. rozwiazania zadania (spelnienia wszystkich punktow z wymagan jakie oczekujemy),
. przetestowania rozwiazania (serio jak sciagam kod i nie da sie go odpalic instrukcjami z readme to wiem, ze developer jest niechlujny)

4. podsumowanie / feedback
najfajniej jest, gdy kandydat sie nadaje. wtedy rozmawiamy, zatrudniamy i w pierwszych dniach pracujemy nad poprawa zadania. gorzej, gdy kandydat sie nie nadaje. wtedy oprocz feedbacku technologicznego komunikuje sie z kandydatem (zazwyczaj rozmowa telefoniczna) tlumaczac dlaczego jednak nie. sa to jedne z ciezszych rozmow, ale wydaje mi sie ze zawsze powinno sie je odbywac. To rowniez dziala w obie strony. Jako rekruter / reprezentant firmy staram sie wyciagnac od kandydata informacje co w procesie mu sie nie podobalo albo co bylo zle. Taki feedback pozwala nastepnym razem zwrocic uwage na zaznaczony problem i albo zmodyfikowac proces albo zwalidowac swoje zdanie.

rekrutacja jaka opisalem sprawdza sie najlepiej na pozycje mocny junior / mid. w przypadku seniorow / leadow wchodzi jeszcze kilka czynikow ktore nalezy brac pod uwage, ale to juz zostawie dla siebie 😉

proces zdecydowanie sprawdzilby sie w kazdej firmie rekrutacyjnej, jezeli wiec jestes rekruterem – korzystaj smialo.

co polecam kandydatom?
. pomysl nad cv
pomysl o punktach, ktore

. dowiedz sie jak bedzie wygladac caly proces,
to wazne czy masz jedna czy piec rozmow, nie chcesz byc nagle na pierwszej rozmowie zaskoczony pytaniami technicznymi, gdy miala to byc luzna pogawedka. dowiedz sie czy bedziesz rozmawiac z osoba techniczna czy nietechniczna – pamietaj, ze powinienes adresowac tresci do rozmowcow, z nietechnicznym rekruterem nie chcesz rozmawiac w zargonie progrmistycznym, bo nic nie zrozumie i nisko oceni Twoje skillsy komunikacyjne.

. nie sciemniaj,
serio sciema pogrzebie Twoje szanse. jezeli zostaniesz przylapany na klamstwie to wszystkie inne istotne rzeczy nie beda juz dalej mialy znaczenia.

. nie boj sie aplikowac jak nie znasz wszystkich technologii,
nie ma problemu, zebys aplikowal na stanowiska z technologiami, z ktorymi nie masz doswiadczenia (zwlaszcza jesli to technologie uzywane pobocznie albo niszowe). zapytaj na wstepie rekrutacji czy ten element jest istotny i w jakim poziomie wymagany. czesto mozesz sie go douczyc w pol godziny. jesli nie znasz powiedz o tym jasno.

. juz o tym pisalem, ale – przygotuj sie do rekrutacji
w internecie publikowane sa listy pytan rekrutacyjnych – „(tu wpisz technologie) developer interview questions” w google naprawde robi robote. dodatkowo jak wspominalem – dla rozgrzania palcow i neuronow codewars / codility

. przejdz przez rekrutacje z druga osoba
dotyczy to zwlaszcza osob, ktore stresuja sie mocno takimi rozmowami (wydaje mi sie, ze to zdecydowana wiekszosc, zwlaszcza gdy to pierwsza rozmowa o prace)

popros kolege, mame, dziewczyne, zeby usiadla z Toba i zadawala Ci przygotowane pytania z kartki. jeden, drugi, trzeci dzien. niech da Ci sie swobodnie wypowiadac. jesli chcesz mozesz nagrywac i odsluchiwac co powiedziales – w ten sposob mozesz sam sie ocenic i podniesc jakosc swoich wypowiedzi. jesli masz innego kolege programiste – przecwicz z nim, to fajna nauka rowniez dla drugiego programisty (w mysl zasady – ucz sie sam a potem zeby rozumiec lepiej ucz innych).

pamietaj, ze po drugiej stronie w rekrutacji czesto bedzie osoba nietechniczna wiec warto, zebys probowal nietechnicznym osobom tlumaczyc tak by zrozumialy. pamietaj, ze Twoja praca to nie tylko kodowanie, a uczestniczenie w rozwoju calego produktu (taki jest cel zespolow programistycznych), mozliwe ze w pracy nie bedziesz rozmawial tylko z ludzmi technicznym (czas rozmow z osobami nietechnicznym bedzie rosl wraz z rozwojem Twojego poziomu i roli w zespole).

. traktuj cala rekrutacje jako nauke i rozwoj
niezaleznie czy rozmawiasz z nietechnicznym rekruterem, czy masz rozmowe technologiczna czy piszesz kod na zadanie domowe – za kazdym razem zastanawiaj sie co z tego wyciagnales i czego sie nauczyles, pros o feedback jesli go nie dostajesz (moim zdaniem to Twoje absolutne prawo), sprawdzaj czego nie wiedziales. jezeli masz zadanie rekrutacyjne – popraw je i wrzuc na koniec na githuba, buduj swoje portfolio.

#rekrutacja #javascript #technologia #czasmaszyn #programowanie #programista15k #praca #pracbaza #hr

jezeli temat jest interesujacy – dajcie znac. przygotuje opis jakie skillsy powinien miec junior / mid / senior / principal i jaka w mojej opinii jest najszybsza droga rozwoju.

jezeli cos w Waszej opinii moge robic lepiej – dajcie mi znac, lubie konstruktywny feedback 🙂