Cześć!
Wraz z zespołem próbujemy zdiagnozować problemy związane z procesem rekrutacji technicznej od strony osób odpowiedzialnych za to w swojej firmie.
Wielka prośba o zaznaczenie najbardziej palącego dla Was problemu! Można wybrać tylko jedną opcję.
Z góry wielkie dzięki za Wasze odpowiedzi!
Kandydaci, ktorzy nie potrafia tego co wpisuja w CV. Przyklad z mojej poprzedniej firmy, trafia do nas 10 CVek ludzi, ktorzy sprawia wrazenie takich co to warto ich zaprosic na rozmowe. 5 osob okazalo sie, ze pisze o rzeczach, ktorych nawet dobrze nie uzywaly bo w zespole uzywalismy, ale akurat nie ja sie tym zajmowalem to moj osobisty faworyt :D.
Potem pozostale 5 to taki mix. Czasem ktos, sprawia wrazenie ogarnietego ale cos tam mu nie idzie akurat z puli naszych pytan. Innym razem kandydat technicznie brzmi dobrze, ale nie wiadomo czy to stres, czy usposobienie i brzmi jakby za kare przebywal na rekrutacji. Ale to juz mniejsza, najwiekszym problemem jest to, ze zmarnowalismy 5h na ludzi, ktorzy w ogole nie powinni sie na tych rozmowach pojawic.
Nie mam problemu z przeznaczeniem czasu na rozmowę rekrutacyjną, bo zatrudnienie odpowiednich ludzi to jedna z najważniejszych rzeczy w projekcie. Trochę mnie wkurza, jeżeli kandydat(ka) naściemniał w CV, albo ktoś po drodze naściemniał w drugą stronę.
Brak projektów na GitHubie.
Tak, wiem. Musisz opiekować się niepełnosprawnym dzieckiem i nie masz czasu na side projekty, masz psa albo codziennie wieczorem miesiączkę.
O dziwo u mnie w pracy jest dobrze jeśli chodzi o sam proces rekrutacji, wstępną filtrację kandydatów itp. Największą bolączką dla mnie są zwyczajne problemy natury technicznej- przerywanie połączenia, dzielenie pulpitu nie działa mimo że powinno czy kandydat w ogóle ma problem z dołączeniem do spotkania (ha tfu MS Teams).
Mnie odrzuca jak gość który mnie rekrutuje jest gburowaty, czy z lekkim ego. Idzie to wyczuć na rozmowie.
Jedną z rzeczy która mnie wkurza ostatnio to brak jakiejkolwiek treści w CVkach. Później tracisz mnóstwo czasu na tej cholernej preselekcji gdzie w ciągu 10 minut osoba okazuje się być niewypałem bo nie jest mi w stanie powiedzieć nic o tym nad czym pracuje (co to za projekt, na cholerę to komu, jak wygląda architektura, ich rola w zespole) z wyjątkiem tego że klepią to w JSie, Pythonie czy innej Javie. Klepię bo mi lead kazał a testy piszę bo Jenkins na mnie krzyczy jak mam mniej niż 80% coverage.
Żadne właściwie, jak robię review sam.
Jeśli z kimś kto już pracuje na stanowisku, to często te osoby mają ochotę proponować jakieś durne zadania, typu napisz drzewo binarne, albo coś takiego. Często muszę walczyć o to że takie zadania nie mają sensu.
No to jest piękne "Kandydaci są oporni względem robienia zadań rekrutacyjnych."
albo to
"Stres kandydata w trakcie rozmowy live powoduje, że nie mogę go dobrze sprawdzić. "
Cała ankieta wygląda jak usprawiedliwienie obecności hrów na rozmowie technicznej,
To może jeszcze
-przysyłanie randomowych ludzi na rozmowę (albo poleconych kolesiów)
-nie uwzględnienie osób technicznych podczas wyboru i weryfikacji cv
-konieczność ukrycia prze kandydatem prawdy po naściemnianiu przez hr
-przysyłanie randomowych ludzi na rozmowę (albo poleconych kolesiów) No ale jak randomy są złe i ci z polecenia są źli to kto jest dobry?
dev_null napisał(a):
osoba okazuje się być niewypałem bo nie jest mi w stanie powiedzieć nic o tym nad czym pracuje (co to za projekt, na cholerę to komu, jak wygląda architektura, ich rola w zespole)
Ahhh spowiedź przed jegomością rekruterem. Przecież często jest NDA, więc padają jedynie jakieś ogólniki, a ujawnienie szczegółów o tym dla kogo, co i jak, kompletnie przekreślałoby kandydata jako kogoś zaufanego.
Brak umiejętności rekrutowania technicznie :p.
Zawsze zastanawia mnie kim była pradawny kurczak który określił kanon pytań xD.
Btw ostatnio szukałem firmy która mogłaby zorganizować szkolenie osób technicznych na temat rekrutacji i nie znalazłem xD.
baryel napisał(a):
dev_null napisał(a):
osoba okazuje się być niewypałem bo nie jest mi w stanie powiedzieć nic o tym nad czym pracuje (co to za projekt, na cholerę to komu, jak wygląda architektura, ich rola w zespole)
Ahhh spowiedź przed jegomością rekruterem. Przecież często jest NDA, więc padają jedynie jakieś ogólniki, a ujawnienie szczegółów o tym dla kogo, co i jak, kompletnie przekreślałoby kandydata jako kogoś zaufanego.
Trochę przesadzasz. Faktycznie ogólniki takie jak...
Senior <język> Developer
Używałem <język(i)> oraz <narzędzie>, <framework(i)> i <długa lista dodatkowych technologii która równie dobrze mogła być tylko pastą>
...niewiele mówią.
Coś jak poniżej mówi już znacznie więcej, a nie obnaża żadnych szczegółów które można by uznać za poufne. Jednocześnie pozwala mieć dobry punkt zaczepienia podczas rozmowy technicznej.
Senior <język> Developer
Pracowałem nad wieloma projektami, w tym flagowym projekcie firmy mającym na celu wprowadzenie produktu na rynek X. System opierał się o luźno powiązane mikroserwisy oparte o architekturę event-driven, komunikujące się ze sobą za pomocą <nazwa brokera>. Dodatkowo, byłem odpowiedzialny ze wprowadzenie integracji z zewnętrznymi systemami, do czego musiałem wykorzystać szereg różnych technologii takich jak REST API, gRPC oraz przyjmowanie plików CSV w integracjach z systemami legacy.
Zakres moich obowiązków dotyczył również wsparcia młodszych programistów, udział w planowaniu i estymowaniu prac oraz doradzanie biznesowi z perspektywy technicznej co przekładało się na podejmowanie strategicznych decyzji w kierunku doboru technologii, architektury i rozwoju systemów w firmie.
Technologie jakie używałem to głównie (ale nie tylko):
<krótka lista technologii>
Aventus napisał(a):
Senior <język> Developer Używałem <język(i)> oraz <narzędzie>, <framework(i)> i <długa lista dodatkowych technologii która równie dobrze mogła być tylko pastą>...niewiele mówią.
Coś jak poniżej mówi już znacznie więcej, a nie obnaża żadnych szczegółów które można by uznać za poufne. Jednocześnie pozwala mieć dobry punkt zaczepienia podczas rozmowy technicznej.
Senior <język> Developer Pracowałem nad wieloma projektami, w tym flagowym projekcie firmy mającym na celu wprowadzenie produktu na rynek X. System opierał się o luźno powiązane mikroserwisy oparte o architekturę event-driven, komunikujące się ze sobą za pomocą <nazwa brokera>. Dodatkowo, byłem odpowiedzialny ze wprowadzenie integracji z zewnętrznymi systemami, do czego musiałem wykorzystać szereg różnych technologii takich jak REST API, gRPC oraz przyjmowanie plików CSV w integracjach z systemami legacy. Zakres moich obowiązków dotyczył również wsparcia młodszych programistów, udział w planowaniu i estymowaniu prac oraz doradzanie biznesowi z perspektywy technicznej co przekładało się na podejmowanie strategicznych decyzji w kierunku doboru technologii, architektury i rozwoju systemów w firmie.
Jak dla mnie to jest dokladnie to samo. Roznica jest taka, ze opcja nr 2 to jest opcja nr 1 + lanie wody. Jezeli produkt jest dopiero wprowadzany na rynek to zapewne ani go nie znasz, ani kandydat nie moze Ci powiedziec na czym polega. Co to w zasadzie zmieni? Tak czy siak powinienes rozmawiac o technologiach i architekturze, a nie konkretnej domenie. No chyba, ze wymagales tej domeny to okej.
@Seken: Różnica jest taka, ze w 2 przypadku, dzięki temu "laniu wody" mam wrażenie, że chociaż wie na czym ten projekt polegał i w jakiej technologii był. W pierwszym przypadku równie dobrze mógł parzyć przez 3 lata kawę scrum masterowi.
Senior <język> Developer Używałem <język(i)> oraz <narzędzie>, <framework(i)> i <długa lista dodatkowych technologii która równie dobrze mogła być tylko pastą>
Jezeli po takim wpisie myslisz, ze kandydat nie wie w jakiej technologii pracowal... to moze problem jest po Twojej stronie :)?
moze problem jest po Twojej stronie? Możliwe, tylko jeszcze nie wiem, czy z przyswajaniem tekstu, czy wymaganiami. Napisałem to dlatego, że miałem ostatnio paru kandydatów, którzy tech stack mieli bardzo szeroki, ale też dość płytki.
Seken napisał(a):
Jak dla mnie to jest dokladnie to samo. Roznica jest taka, ze opcja nr 2 to jest opcja nr 1 + lanie wody. Jezeli produkt jest dopiero wprowadzany na rynek to zapewne ani go nie znasz, ani kandydat nie moze Ci powiedziec na czym polega. Co to w zasadzie zmieni? Tak czy siak powinienes rozmawiac o technologiach i architekturze, a nie konkretnej domenie. No chyba, ze wymagales tej domeny to okej.
Cóż, możemy się zgodzić że się nie zgadzamy :) Choć muszę przyznać że bardzo selektywnie skupiłeś się tylko na fragmentach mojego przykładu, bo mniemam że stąd stwierdzenie powinienes rozmawiac o technologiach i architekturze, a nie konkretnej domenie? Przecież mój przykład używa technologii i architektury, w oparciu o konkretną domenę (która również ma znaczenie). Po prostu chodzi o ubranie suchej listy technologii w jakiś kontekst pozwalający bardziej rozwinąć temat.
Tak czy inaczej, do tej pory w moim przypadku przykładanie wagi do takich aspektów w CV dobrze się sprawdza.
@Aventus:
Rozumiem, kazdy ma swoje preferencje :).
Aventus napisał(a):
Tak czy inaczej, do tej pory w moim przypadku przykładanie wagi do takich aspektów w CV dobrze się sprawdza.
Po prostu troche nie wyobrazam sobie opisywac tych wszystkich projektow w CV. Potem to sie konczy jak pewien uzytkownik, ktory mial CV na chyba 10 stron i "wszystko bardzo potrzebne" :P.
Jestem zwolennikiem dopytywania jezeli cos mnie zainteresowalo, zamiast czytac mase nieistotnych rzeczy.
Pracowałem nad wieloma projektami, w tym flagowym projekcie firmy mającym na celu wprowadzenie produktu na rynek X, gdzie jeden jest użyty jako dokładniejszy przykład (ale nadal wystarczająco ogólnikowo moim zdaniem).
Ja mam taki problem że HR piszą jakieś pierdoły w ogłoszeniu i potem przychodzi mi kandydat który mówi że C++ nie zna bo w ogłoszeniu był Python i on na Pythona przyszedł. A drugi jest taki że C++ nikt już dzisiaj nie chce się uczyć i nawet nie wiem jak pytać żeby cokolwiek ten kandydat wydusił z siebie przy naszym managerze.
Aventusale nie wiadomo czy to stres, czy usposobienie i brzmi jakby za kare przebywal na rekrutacjiciekawe, sam kilkakrotnie miałem sytuację gdzie odnosiłem takie samo wrażenie jak Ty. W większości przypadków to raczej stres. Mamy obecnie 2 osoby które sprawiały takie wrażenie podczas rekrutacji, a na co dzień są całkowicie inne (w pozytywnym sensie). Morał z tego taki że u każdego inaczej przejawia się stres, więc warto na to brać poprawkę prowadząc rekrutację. Szczególnie w naszej branży.