Rant na temat rekrutacji w Polsce (i nie tylko?)

Co ja czy inni ludzie kłamiemy w CV?

Tak, dokładnie tak. Może akurat Ty jesteś OK i nie kłamiesz, ale chociażby zobacz, co ludzie piszą w "rekrutacyjne WTF". Jest tam wiele opowieści z drugiej strony barykady.

Poza tym doświadczenie z miejsca A nie jest równe doświadczeniu z firmy B. Można przez 2 lata uczestniczyć w mega rozwijającym i ambitnym projekcie, dzięki któremu się mocno rozwiniesz i zdobędziesz doświadczenie, a można 10 lat klepać strony na wordpressie i przesuwać inputy na formatce. Do tego jeszcze część firm, żeby oszczędzić na kasie to ludzi trzyma w inny sposób, np. kupując ich etykietkami na wizytówce. I potem trafiają się seniorzy 2 lata po studiach.

Tak więc -tutaj jest potrzebna jakaś weryfikacja, bo ani staż, ani nazwa stanowiska wcale niczego nie gwarantują. No i jeszcze taki szczegół - w innych branżach jest brak chętnych do pracy, więc się bierze kto się nawinie, a programowanie jest jedną z niewielu, gdzie jest znacznie więcej kandydatów, niż wolnych stanowisk.

Ostatnio przeglądam sobie Team Blind, Glassdoory itp. często o jakis duzych firmach.
Kiedys slyszalem dobre rzeczy np. o Stripe, które ponoć takie super, niebo a ziemia w porownaniu do Amazona czy Ubera albo nawet Google. Pewnie zalezy glownie od zespolu gdzie sie trafi a tu trafiam na coś takiego: https://www.teamblind.com/post/Avoid-Stripe-oMHuWXW6 xD

To może lepiej aplikować do mniejszych firm ale z jakąś prawdziwą produkcją gdzie mają szybkie rekrutacje gdzie człowiek jednak nie jest kolejnym kafelkiem w excelu xD

Wydaje mi się że niestety nie ma idealnej rekrutacji.

Moją preferencja są zadania do domu. Ale niestety zadanie które idzie zrobić w 3-5h nie bardzo odpowiada na pytanie, co kandydat umie. A zadanie na 30h+ spotyka się z dużym niesmakiem osób które są odrzucane.

Fangii korzystają z LC bo jest to chyba najprostsza droga na zrobienie 5 interview (tak żeby dostać 5 niezależnych ocen)
Czy LC są idealne, oczywiście że nie, i tak jak nie jesteś na bieżąco z algorytmami, to musisz się uczyć pod nie specjalnie. Natomiast chciałbym poznać kogoś kto jest bardzo słaby ale poćwiczył LC i jest w stanie mieć na 4-5 interview na strongly-hire

Najsłabiej wypadają hacker-ranki bo masz mały czas i sprawdzanie w stylu 0-1. Z drugiej strony są najtańsze dla pracodawcy.

A co do pytań które można znaleźć w google. Ja rozumiem, że jak ktoś cię pyta o wymienienie wszystkich konstruktorów stringa to jest głupie pytanie i to można znaleźć w Google.
Ale jak pytam się czym są filtry Blooma (czy np takie trie), a dostaje odpowiedź 'nie wiem ale se mogę w google znaleźć' to wiem, że problemu który one mogą pomóc rozwiązać mi (raczej) nie rozwiążesz.
Bo w pracy nie będzie problemem znaleźć czym są filtry Blooma czy jak je zaimplementować, ale raczej wiedzieć w głowie, że jest coś takiego i kiedy może się przydać.

@amd: Z zadaniami w domu też ten problem, że nie wiadomo jak samodzielnie było one zrobione. Co do tej drugiej części to się zgadzam, jeśli ktoś nie ma pojęcia o jakiś rzeczach np. coś z security czy ze skalowalnością to nie wyszuka tego w Google, bo nawet o tym nie słyszał.

Brałem niedawno udział w rekrutacji gdzie było proste zadanie do zakodowania w domu (max 2h ) za co było płacone 400 zł. Później był interview na którym omawiałem rozwiązanie. Myślę że taka forma jest całkiem fajna. Z kolei jak jestem po drugiej stronie to jakieś proste zadanie do zakodowania + rozmowa techniczna i na 90% można wyczuć czy ktoś jest dobry czy tylko coś tam sobie poczytał przed interview. Tak BTW to rynek przynajmniej Javowcow jest tak wyssany że ostatnio na Senior Backenda miałem gości którzy nie znali Javy, ale nawet jak pytałem ogólnie np po co są thread poole czy immutability to nic nie byli w stanie wydukać:D

Napisałeś kilka kroków jak zostać seniorem 15k, problem w tym, że senior który zarabia 15k musiał przespać ostatnie 5 lat. 15k to dostaje każdy srednio ogarniety programista z 2 letnim stazem. Wiec nic dziwnego ze latwo sie dostac do takich firm.

Rekrutacja nie ma na celu wyłonienia najlepszego kandydata, tylko wystarczająco dobrego kandydata. Jeśli mam dwóch ludzi, za tę samą cenę, z których jeden jest trochę lepszy od drugiego - ale nie jakoś dramatycznie - to świat się nie zawali jeśli weźmiemy gorszego.
Rekrutacja musi też być wydajna. Jeśli jakaś kosztowna zmiana sprawi, że będziemy profilować kandydata o te dwa procent lepiej to wolę jej nie wdrażać.

Teraz wracając do mojego ulubionego tematu, tj. live-coding. Nie rozumiem niechęci do prostych zadań algorytmicznych, ponieważ nie mają one zbyt wiele wad, za to mają kilka zalet.

1. Sprawdzają, czy kandydat potrafi pisać bez Stackoverflow. O ile stronkę lubię i cenię, o tyle uważam SO-DD za antywzorzec, który prawie zawsze skończy się źle.
2. Nie wymagają wiedzy domenowej.
3. Można prześledzić, jak ktoś rozwiązuje problemy, czy panuje nad czasem, czy nie ma gonitwy myśli itp.
   Jedyna wada takiego rozwiązania to myślowy deadlock, tj. kiedy ktoś za bardzo skupi się na błędnym toku myślenia. I tutaj trzeba po prostu czasem kandydata naprowadzać na rozwiązanie.

Zaznaczam, problem do rozwiązania powinien być względnie prosty i dobrany pod poziom stanowiska.

@wartek01: live coding chyba jest jedną z lepszych sposobów na weryfikację

Chociaż osobiście mam jedno traumatyczne przeżycie związane z tą formą rozmowy technicznej
Otóż kiedyś kazano mi zaimplementować bubble sort. Algorytm do sortowania pisałem ostatni raz przed tą rozmową sam nie wiem kiedy. No i się spaliłem.
Zapomniałem na czym polega, coś zacząłem pisać, koło mówi że to chyba przez wstawianie robię. To jeszcze do pieca dorzucił.
Gdyby zadanie było żeby napisać algo do sortowania to pewnie bym zrobił, a tak nie pamiętałem jak te bąbelki latają. W głowie pustka.
To było pierwsze zadanie. Inne mi poszły dobrze ale i tak decyzja na nie.
Czułem się jak debil, miałem takie poczucie wstydu i zażenowania że długo nie mogłem tego rozchodzić.

Wydupczyć się na bubble sort. Masakra.

wartek01 napisał(a):

Rekrutacja nie ma na celu wyłonienia najlepszego kandydata, tylko wystarczająco dobrego kandydata.

Jeśli mam dwóch ludzi, za tę samą cenę, z których jeden jest trochę lepszy od drugiego - ale nie jakoś dramatycznie - to świat się nie zawali jeśli weźmiemy gorszego.

Zgadzam się, że na tym to często polega. Pytanie, czy tak być powinno. Które podejście do rekrutacji jest lepsze:

• bierzemy nawet słabych gości, byleby spełniali pewne minimalne kryteria
• staramy się zatrudniać faktycznie najlepszych

Myślę, że obydwa podejścia mogą się sprawdzić. Jak komuś nie zależy na jakości (a projekt to zwykła klepanka), to może zatrudnić słabych ludzi, bo i tak co mają zrobić, to zrobią, lepiej lub gorzej. Jednak jak komuś faktycznie zależy na jakości (a sam projekt jest trudny), to chyba jednak lepiej szukać najlepszych, zamiast zatrudniać tych słabszych.

3. Można prześledzić, jak ktoś rozwiązuje problemy, czy panuje nad czasem, czy nie ma gonitwy myśli itp.

Sprawdzanie czy ktoś panuje nad czasem każąc mu rozwiązać w ciągu kilku minut zadanie w stresie i sprawdzanie czy ktoś nie ma gonitwy myśli? WTF programista to nie prezenter telewizyjny, że musi "panować nad czasem". I co złego w gonitwie myśli? To chyba dobrze właśnie, jak ktoś myśli i kmini niż jakby nie miał żadnych pomysłów (albo wstydziłby się mówić je głośno).

@___ref___: na pewno bym nie wymagał znajomości definicji dowolnego sortowania. Natomiast jeśli miałeś podane jak to wygląda to ok.

@LukeJL: tak.

Jeśli ktoś nie potrafi zrobić prostego zadania, którego wyklepanie zajmuje 3 minuty (jeśli już zna się rozwiązanie) w 30 minut (lub więcej, ja daję 30-45 minut, nie mam zielonego pojęcia skąd wziąłeś "kilka" minut) to coś jest nie tak. I tak, programista musi panować nad swoim czasem. Co do gonitwy myśli - to jest bardzo duży problem u potencjalnego pracownika, z takimi osobami nie da się pracować bo potrafią kilkukrotnie zmienić koncepcję, ale nie sprawdzić żadnej z nich.

No i jest jeszcze podstawowy problem: https://blog.codinghorror.com/why-cant-programmers-program/amp/

Kiedyś miałem na rozmowie osobę, która:

• wiedziała, że String ma metodę charAt() I length() i wiedziała, co one robią
• jednocześnie nie potrafiła wypisać odwróconego String na wyjście standardowe bez użycia StringBuilder.reverse().
  Człowiek miał 3 lata expa. Nawet gdy jasno powiedziałem, żeby zrobił pętlę od length-1 do zera - nie potrafił.

Można spytać "czy komuś w pracy się przyda takie odwracanie String?". Odpowiedź brzmi prawie na pewno nie". Natomiast ja osobiście takie rzeczy mogę tolerować u stażysty, ale u osób wyżej nie.

I tak, takich historii gdzie ktoś się wywala na najprostszych zadaniach mam więcej.