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

Chciałem to napisać po prostu w ""Rekrutacyjne WTF" ale nie wiedziałem jak to ująć, bo raczej nie miałem problemu z jakimiś konkretnymi rekrutacjami. Miałem problem z prawie każdą i to zwykle ten sam. Dodatkowo, mam wrażenie że to, że rekrutacja była przeprowadzona w przyjemny i logiczny sposób bardzo pozytywnie wpłynęło na mój ostateczny wybór firmy. Gadałem z kilkoma znajomymi, którzy uważają tak samo jak ja. Po rekrutacji natrafiłem jeszcze na poniższy filmik, który dokładnie ujął to co chciałem przekazać, ale mówił o rynku programistów w USA.

Standardowa rekrutacja

TL;DW: Algorytmiczne interview polegają na wkuwaniu na pamięć, a to co sprawdzają czyli kodowanie na czas i pod presją, nie przyda się w 90% firm.

W Polsce mamy podobnie, ale często zamiast algorytmicznych problemów dostajemy dosłownie pytania które sprawdzają czy kandydat wie coś, co można wygooglować w 5 sekund. I tutaj mamy jeszcze dodatkowy problem z rekrutacjami on-line, gdzie faktycznie jest to możliwe, nawet bez wiedzy rekrutera. W niektórych rekrutacjach dosłownie udzielałem odpowiedzi "nie wiem, ale jak chcesz to wygoogluje Ci odpowiedź jak dasz mi 10 sekund" i obstawiam że nie było to pozytywnie odbierane.

Jak zostać w Polsce Programistą 15k

1. zapisz się na 15 interview na Seniora, najlepiej żeby były zdalne
2. Na każdym zapisuj pytania i wkuwaj na pamięć odpowiedzi (albo po prostu miej je spisane na drugim ekranie)
3. Na pierwszych pięciu prawdopodobnie Cię 'wyśmieją, ale zapisuj pytania i nie przejmuj się.
4. ???
5. Profit! Na kolejnych dziesięciu dostaniesz ofertę pracy jako Senior Developer, możliwe że z wyższą stawką niż początkowo chciałeś.

Naprawdę żaden z rekruterów nie widzi problemu z takim podejściem? Z moich rozmów wynika że doskonale zdają sobie sprawę że kandydat bierze udział w wielu procesach rekrutacyjnych, ale powtarzalność pytań rzadko zdaje się im zapalać nad głową lampkę.

Inne typy rekrutacji, albo czy da się jeszcze pogorszyć ten proces

Tutaj będzie moja sekcja "Rekrutacyjnych WTF":

1. Kodowanie w Google Docs, oczywiście na czas i głównie sprawdzające jakie metody/funkcje znasz
2. Kodowanie na czas gdzie jednocześnie wymaga się rozwiązania dobrego i przemyślanego, ale również kompilującego się i działającego.
   *Śmieszna anegdotka, miałem dwa "kodowania na czas" w rekrutacji do tej samej firmy, z innymi osobami. Po rekrutacji dostałem feedback:
   w pierwszym za bardzo skupiłem się na zadawaniu pytań żeby dostarczyć optymalne rozwiązanie i przez to nie dostarczyłem działającego rozwiązania na czas (w skrócie, koduj szybciej),
   w drugim co prawda dostarczyłem działające rozwiązanie, ale powinienem więcej czasu poświęcić na zastanowienie się nad algorytmem, bo nie był optymalny. You just can't win...
3. Kodowanie na czas w którym główny nacisk nakłada się na używanie jednej, konkretnej klasy z którą ktoś mógł nigdy nie mieć do czynienia.
4. Interviewer siedzi nad tobą i patrzy jak kodujesz, ale na pytania CO DO TREŚCI ZADANIA odpowiada lakonicznie lub wcale

Dobre typy rekrutacji

Jak można więc ten proces poprawić? Spotkałem się z kilkoma firmami które kompletnie inaczej podchodzą do rekrutacji i według mnie kilka kroków które bardzo pozytywnie wpłynęły na sprawdzenie wiedzy i satysfakcje kandydata:

1. Wypytywanie z wiedzy w formie luźnej rozmowy o doświadczeniu do tej pory lub pracy w ostatniej firmie. Zadawanie pytań na podstawie tego co opowiada kandydat, na przykład: pracowałeś w TDD? To opisz jak to wyglądało. Zmieniłbyś coś? Co według ciebie było złego/dobrego w tym podejściu.
2. Kodowanie NIE NA CZAS!!! Daj kandydatowi problem do rozwiązania i kilka dni na dostarczenie rozwiązania. Oczywiście szanujmy się i niech to będzie maks 2h kodowania, prosty problem. W ten sposób kandydat nie musi kodować pod presją i może zapoznać się z problemem, klasami, czymkolwiek co jest potrzebne.
   *Żeby upewnić się że to kandydat to pisał, zrób follow up call w którym mówisz "Klient zmienił troche wymagania, jak byś to wprowadził?" Albo po prostu wypytaj dlaczego tą część kodu napisano w taki sposób a nie inny, czy gdyby wymagania były takie i takie to zrobiłbyś to inaczej?
3. "System design" interview, prawdopodobnie dopiero przydatne na wyższe stanowiska, ale bardzo dobrze sprawdza wiedzę z wielu zakresów. Według mnie interview z kodowania można by również poprowadzić w tym kierunku, tzn. rozmawianie o tym jakie rozwiązanie byś tu zaimplementował i dlaczego, bez pisania konkretnego kodu (albo tylko pseudokodu). Ale niestety nie spotkałem się z czymś takim

Am I being crazy?

Czy tylko ja widzę te problemy? Na pewno nie jestem ani najbardziej doświadczonym, ani (NA PEWNO) najbardziej błyskotliwym programistą. Nie jestem też jedynym programistą który chodzi na rekrutacje. Dlaczego pomimo tego wszystkiego, rekrutacje dalej wyglądają tak samo w 70% firm? Czy może ktoś mi to rozjaśnić i dać pozytywne strony tego na co właśnie narzekam?

W sumie jest tak jak piszesz, no może jednak ktoś bez doświadczenia nie zostanie programistą 15k chodząc jedynie na rozmowy - jednak ten brak doświadczenia prędzej czy później wyjdzie, często (zwłaszcza w instytucjach finansowych) jest też background check, który może też wykryć czy ktoś nie ma żadnego doświadczenia.

Czy tylko ja widzę te problemy? Na pewno nie jestem ani najbardziej doświadczonym, ani (NA PEWNO) najbardziej błyskotliwym programistą. Nie jestem też jedynym programistą który chodzi na rekrutacje. Dlaczego pomimo tego wszystkiego, rekrutacje dalej wyglądają tak samo w 70% firm? Czy może ktoś mi to rozjaśnić i dać pozytywne strony tego na co właśnie narzekam?

A dlaczego ludzie uważają BMW za samochód bardziej prestiżowy niż Opel? Dlaczego kobiety wiążą się z patusami? Dlaczego Putin zaczął wojnę zamiast żyć sobie w spokoju?

Bo tak po prostu działa świat ¯_(ツ)_/¯ można to zaakceptować lub nie

Czemu ingorujesz kompletnie zalety takiego rozwiązania? Nie jestem jego zwolennikiem ale trzeba je zauważyć:

1. Jeśli, ktoś potrafi szybko napisać algorytm to znaczy, że jest raczej inteligentny i poradzi sobie też dobrze z prostymi zadaniami. Jeśli możemy wybierać pomiędzy lepszym a gorszym programistą to wybierzmy tego lepszego.
2. Jeśli ktoś wykuje te algorytmy to znaczy, że mu się chciało i potrafi zauważać wzorce - nawet jeśli nie jest inteligenty i tak może się przydać.

anonimowy napisał(a):

Czemu ingorujesz kompletnie zalety takiego rozwiązania? Nie jestem jego zwolennikiem ale trzeba je zauważyć:

1. Jeśli, ktoś potrafi szybko napisać algorytm to znaczy, że jest raczej inteligentny i poradzi sobie też dobrze z prostymi zadaniami.

A jak ktos napisze go troche wolniej to inteligentny juz nie jest i nie poradzi sobie z prostymi zadaniami? Tego typu zadania weryfikuja jedynie umiejetnosc rozwiazywania zadan rekrutacyjnych na czas - nic wiecej.

Nie są broken, mi zajmuje około 60-90 minut np. wyczaić kandydata czy ogarnia np. Java + Springa + AWS. Wystarczy poprosić o share'owanie ekranu i poprosić porobić parę rzeczy, od razu widać obycie.

anonimowy napisał(a):

Czemu ingorujesz kompletnie zalety takiego rozwiązania? Nie jestem jego zwolennikiem ale trzeba je zauważyć:

1. Jeśli, ktoś potrafi szybko napisać algorytm to znaczy, że jest raczej inteligentny i poradzi sobie też dobrze z prostymi zadaniami.

Albo farmił rok na leetcode, a zejsra się przy najprostszym casie biznesowym, napisze nietestowalny kod niezgodny z wymaganiami.

@urke Przecież inne aspekty też mogą sprawdzić przy rekrutacji. Spotkałeś taka osobę co ogarnia algorytmy i farmila długo leetcode a nie potrafiła programować?

Ja ostatnio przeszedlem sporo rozmow wysylalem na potege CV do roznych firm od software houes-ow az po kontraktornie i firmy produktowe.

Jak zaczynalem sie rekrutowac bylem Midem.... 3 msc i bodajze 9 technicznych interview pozniej juz bylem Seniorem....
Pierwsza oferte otrzymalem 18k b2b konczylo sie na ofertach 25k b2b. W 3 msc tak duzy "skok" umiejetnosci no po prostu "szok i niedowierzanie... "
Zaczynalem rekrutowac sie z marszu z kazdym kolejnym interview mialem "lepsze odpowiedzi"

przyklad nr 1: "Co to jest Singleton ?"

1. interview: Wzorzec projektowy ze 1 instancja i ze antypattern (ze trudno testowac, i refactor psuje i efekt zlego desingu bla bla) ze praktyczne zastosowanie to logger.
2. interview: to co wyzej + no i ze mamy singleton ze mozna go zaimplementowac tak czy siak i ze jest Borg ktory sie rozni tym czy tamtym - ladnie skladnie argumentowalem podalem przyklady z zycia itp itd.
   Tak szczerze to nie wiem zupelnie na jakiego grzyba mi ta implementacja Singletona i najpewniej to zapomne niedlugo.

przyklad nr 2: "SOLID"

1. interview zasady znam mysle ze uzywam i wiem na czym polegaja - rozwinalem skroty o kazdym cos powiedzialem a przyklady na szybko w glowie jakies wymylilem - wmiare sensowne chyba :P
2. interview to samo co wyzej w sposob przemyslany i przyklady mialem w glowie 'przygootoowane' i odpowieednio dobrane wczesniej zeby najlepiej odzwierciedlaly te zasady

przyklad nr 3: "Python GIL/ Threading itp" pytanie mordowane przez wszystkich :D

1. interview - no i znowu wiem co to GIL ze concurrency ze zmiana contextu ze w IO Bound w sumie daje rade ze jest threadsafe itp itd
2. interview - no a tutaj znowu to samo ale ladnie elegancko i rozszerzone o info o garbage collector w py o zasade dzialania + nawet obejrzalem sobie kilka filmikow na yt z pyconow gdzie python core developerzy o tym mowia i na rozmowie podalem nazwiska konkretnych kolesi

I tak wiekszosc standardowych pytan odnosnie teorii z programowania mozna "rozklepac" cos tam sie nauczylem utrwalajac ale tak naprawde usystematyzowalem wiedze i podrasowalem swoje odpowiedzi na pytania. Jestem takim samym januszem developmentu jak bylem i moj kod jest tako samo "dobry" albo tak samo "zly" niezaleznie jak pieknie odpowiadam na postawione wyzej pytania a Singletona typu Borg lada chwila zapomne albo juz zapomnialem...

Zmierzam do tego ze przy takich super teoretycznych rozmowach mozna wzglednie latwo podbic swoje "Seniority" cwiczac na interview a co za tym podniesc sobie stanowisko czy $.

Wiem ze Ameryki nie odkrylem ;p ale moze komus kto sie zasiedzial w 1 firmie otworzy to oczy tak jak mi.

Kodowanie NIE NA CZAS!!! Daj kandydatowi problem do rozwiązania i kilka dni na dostarczenie rozwiązania

Tylko, żeby to było ciekawe, a nie traktowanie kandydata jak przedszkolaka i podsuwanie zadania, które jest nudne, a jedynie sprawdza podstawy.

Dwie rekrutacje w dwóch firmach do projektu używającego biblioteki Three.js (grafika 3D w przeglądarce):

• dobre zadanie - masz stronkę, która ładuje model 3D i umożliwia poruszanie kamerą (jest już napisany kod). To, co musisz zrobić, to 1. zadbać, żeby aplikacja nie kolidowała z eventami przeglądarkowymi (musiałem oczywiście pod Safari to dostosowywać specjalnie) 2. napisać zoom-to-pixel (i to był problem, nad którym się wiele godzin głowiłem, bo miałem istniejącą kontrolkę do obrotu kamery, ale nie wspierała zoom-to-pixel. I jak to zaimplementować w sprytny sposób? Plus musiałem wyobrazić to sobie geometrycznie i użyć odpowiednich funkcji do przeliczeń na wektorach).

Zadanie jednocześnie:

• ciekawe
• będące wyzwaniem
• takie, które można spotkać na produkcji

I zrobiłem, nawet byli zadowoleni i przeszedłem do kolejnego etapu (co prawda później odpadłem po tym kolejnym, bo to ileś etapowa była rekrutacja)..

Dla odmiany zadanie z tej samej biblioteki w innej firmie na live codingu:

• postaw projekt od zera i wyświetl tekst HelloWorld w 3D

I to spieprzyłem koncertowo. Byłem zestresowany, plus wtedy pisałem dłuższy projekt w Three.js i umiałem się posługiwać tą biblioteką, ale... zapomniałem, jak się stawia nowe projekty (co nie jest oczywiste, Three.js wymaga inicjalizacji - utworzenia renderera, sceny, kamery, świateł i dopiero później można cokolwiek wyświetlać. A jak się chce tekst wyświetlić, to trzeba najpierw załadować fonta itp. Więc łatwo się pomylić i co chwila się myliłem).

Tylko to zadanie niewiele sprawdzało tak naprawdę. Ale mam wrażenie, że gość, który mnie rekrutował, sam nie miał pojęcia o tej bibliotece i dał, bo myślał, że to powinna być chwila, że w 5 minut to zrobię. A robiłem jakoś 40 minut. Tylko, że w realnej pracy poświęcenie 40 minut na inicjalizację projektu to nie jest dużo. No i w moim CV był link do o wiele bardziej zaawansowanego projektu niż to zadanie rekrutacyjne, więc to też zabawne, że na zaawansowany projekt nie spojrzeli, a ocenili tylko po tym, że miałem pewne randomowe problemy w stawianiu nowego projektu od zera.

w Polsce

Pierwsza firma była międzynarodowa (podczas rekrutacji gadałem z ludźmi kilku kontynentów) i zajmowała się tylko 3D (software house ale robiący apki 3D).
Druga firma była polska, jakiś outsourcing chyba, i szukali programisty do konkretnego projektu, gdzie akurat było 3D.

Jezeli tak łatwo jest wykuć zadania typu leetcode, to dlaczego 90% kandydatów których przepytuję wywala się na części rozgrzewkowej? I połowa z nich nie potrafi zakodować prostej pętli.

Najgorsze jest to, że oni wszyscy przeszli wstępny screening... I wszyscy wiedzą jakich zadań oczekiwać w rekrutacji do FANG.

Mówi się, że rekrutacje są po to, by znaleźć najlepszego kandydata. Ale "najlepszy" wcale nie musi oznaczać kogoś z największymi umiejętnościami technicznymi - firmy szukają ludzi, którzy będą w wstanie wtopić się w istniejącą strukturę i w niej pracować. Wielkie korporacje typu FAANG mają, generalnie, dwie cechy:

1. Dużo korpobetonu
2. Rozpoznawalną markę

Punkt pierwszy powoduje, że częścią sprawdzania culture fit musi być zdolność potencjalnego pracownika do radzenia sobie z corpobullshit typu konieczność zaklepania zmiany w projekcie przez hierarchię co najmniej 3 managerów, albo konieczność składania wniosków formalnych do działu zaopatrzenia, żeby dostać papier do drukarki. Masa ludzi będzie się źle czuła w takim środowisku - dlaczego więc nie zmienić środowiska?

Ponieważ punkt drugi - taki Goolag nie musi zamartwiać się tym, że ich proces rekrutacyjny poskutkuje odrzuceniem tego jednego kandydata na sto tysięcy, który jest technicznym superwymiataczem i naprawia bugi po prostu patrząc karcąco na komputery, aż bity ze strachu same się ułożą poprawnie - bo w ciągu roku przepracowują ponad milion kandydatów, więc takich gurusów jeden-na-sto-tysięcy przewinie się co najmniej dziesięciu. Dla kogo innego będzie to niepowetowana strata i zaprzepaszczenie okazji, które nadarza się raz w życiu - oni nazywają to kwietniem.

Ale wiesz że to wszystko jest spowodowane tym, że w większości firm nie ma osób odpowiedzialnych za techniczną rekrutacje?

To wygląda tak że przychodzi manager, mówi: "mamy tutaj kandydata", i wybiera jednego z programistów w projekcie żeby go przepytał. Ale ten ktoś wcale nie musi umieć robić rekrutacji. Jego jedynym atutem jest to że już jest w projekcie, a rekrutowany nie. (Noi to że był wcześniej sprawdzony przez poprzedniego programistę).

Rekrutacja to jest coś czego nie ogarniam
jest to (z mojej perspektywy) jedyny moment gdzie trzeba wykazać się największą wiedzą, która z realną pracą ma co najwyżej mało wspólnego.

przykład z mojego życia - firma szuka ludzi bo trzeba zrobić mega integrację, system rozproszony, nacisk na performance i na współbieżność, na rozmowie przetrzepali mnie z asynchroniczności, jakieś szmery bajery, pipeline, channels, synchronizacje itp itd (.net)
po czym w pracy okazało się że trzeba na szybkości zrobić coś w starym synchronicznym systemie, bo nagle klienci się uruchomili. Nawet jednego asnyc await nie napisałem.
Liczyłem, że wiedza utrwali się i rozwinie w praktyce, tym czasem, moja wiedza dot współbieżności w .net zaczęła usychać (nic w tym dziwnego)

przykład nie z mojego życia, projekt kilkudziesięcioletni, praca w nim to głównie utrzymanie, biznesowo fajny, technicznie masakra - kolega kiedyś mówił, że sam nie wie jak ma rekrutować, bo czy senior czy mid czy junior, praca wygląda +/- tak samo, problem na twarz i pchasz, a senior od juniora to przede wszystkim różni się znajomością systemu i biznesu, a nie tzw. dojrzałością techniczną

moim zdaniem rekrutacja idealna to: masz kandydacie serdeczny kod, powiedz co on robi
kto będzie bliższy prawdy/szybszy ten wygrywa :)
może być też opis storyjki i powiedz kandydacie serdeczny co trzeba zrobić - jak farmaceuta w aptece odczytuje doktora, tak dev odczytuje PM-a, BA - czy jak tam zwał tą funkcję

bo w pracy kod to się głównie czyta, a tylko czasami pisze

z mojej perspektywy to główne problemy w pracy to:

1. rozumienie biznesu
2. komunikacyjne
3. w jasnym formułowaniu myśli
4. w czytaniu czy to dokumentacji czy to kodu (miałem kiedyś takiego pisarza historyjek, który tak dziwnie formatował tekst, że trzeba było zrozumieć jego formę/szablon, aby potem zrozumieć treść)
5. w szukaniu, wiedzy, człowieka, łączeniu kropek - tzw zdolności analityczne

problemy techniczne, moim zdaniem, są najłatwiejsze do ogarnięcia

Opiszę moje doświadczenia.
Nigdy na rekrutacjach nie dostałem dwóch takich samych pytan. Każda była inna. Najdłuższa trwała 2 godziny (techniczna część) i w tej pracy też zdobyłem najwięcej doświadczenia.

Na żadnej z chyba 20 rozmów nie miałem programowania na żywo, raczej jakiś prosty kodzik ogarnąć lub opisać jak bym coś zrobił.

@ItsFine: Mam wrażenie że aplikujesz tylko do samych korpo. Tam niestety masz czesto sztywne reguły i dzieje się to wszystko o czym pisałeś. Jednakże to pociąga za sobą duża rotację pracowników, często też kod bywa "różnej" jakości, bo może Ci się trafi zapyziały senior, co wszystkie rozumy pozjadał.

Myślę że problem rozwiąże się sam, gdy programiści po prostu nie będę brać ofert gdzie wymaga się kodowania na czas.

Ask HN: When did 7 interviews become “normal”?

Różni ludzie mają różne preferencje

Jak można więc ten proces poprawić? Spotkałem się z kilkoma firmami które kompletnie inaczej podchodzą do rekrutacji i według mnie kilka kroków które bardzo pozytywnie wpłynęły na sprawdzenie wiedzy i satysfakcje kandydata:
Kodowanie NIE NA CZAS!!! Daj kandydatowi problem do rozwiązania i kilka dni na dostarczenie rozwiązania.

Ja na przykład wolałbym dostać jakieś zadanko na pół h podczas rozmowy niż dostawać jakieś mini projekciki do zaklepania w swoim czasie.

A w dodatku im więcej etapów tym coraz gorzej to świadczy o rekrutujących

zapisz się na 15 interview na Seniora, najlepiej żeby były zdalne
Na każdym zapisuj pytania i wkuwaj na pamięć odpowiedzi (albo po prostu miej je spisane na drugim ekranie)
Na pierwszych pięciu prawdopodobnie Cię 'wyśmieją, ale zapisuj pytania i nie przejmuj się.
???
Profit! Na kolejnych dziesięciu dostaniesz ofertę pracy jako Senior Developer, możliwe że z wyższą stawką niż początkowo chciałeś.

a za jakiś czas zrywają z tobą współpracę / nie przedłużają umowy

serio, nie tylko ciężko mi sobie wyobrazić jakby taka osoba mogła funkcjonować w zespole, to dodatkowo słyszałem o takim przypadku gdzie pracownik (lub ex) danej firmy powiedział kandydatowi z czego tam pytają i faktycznie udało się gościowi przejść rozmowę

ale wywalili go chyba po 3 miesiącach.

@anonimowy:

Jeśli, ktoś potrafi szybko napisać algorytm to znaczy, że jest raczej inteligentny i poradzi sobie też dobrze z prostymi zadaniami. Jeśli możemy wybierać pomiędzy lepszym a gorszym programistą to wybierzmy tego lepszego.

inteligentny albo po prostu zetknął się z danym lub podobnym problemem

Na olimpiadzie z matmy również masz tzw. "wytrychy olimpijskie"

1a2b3c4d5e napisał(a):

Ask HN: When did 7 interviews become “normal”?
(...)
A w dodatku im więcej etapów tym coraz gorzej to świadczy o rekrutujących

Też tak myślałem, ale jak poczytałem o tym na HN, to zaczynam postrzegać to inaczej. Faktycznie po jednym etapie ciężko sprawdzić kandydata. Zatrudniasz randomów. I jak cię zatrudnią w takiej firmie, to dlatego, że miałeś farta/dobry timing. Jak cię odrzucą, to też raczej przez przypadek.

A wiele etapów, to dopiero jest coś. Rekrutacja staje się przygodą i czelendżem. Jako firma wtedy możesz faktycznie sobie ustawić jakieś swoje standardy rekrutacji i przefiltrować sobie wszystkich i zatrudniać tylko tych, którzy nie zostaną wyeliminowani po iluś etapach.

Jeśli zaś przejdziesz jako kandydat taką wieloetapową rekrutację, to poczujesz się mocny, że jednak ktoś cię sprawdził i że się faktycznie nadajesz, że to nie przypadek. A jak cię odrzucą, to też możesz się pocieszać, że przecież dotarłeś do któregoś etapu i przynajmniej zobaczyłeś, jakie pytania zadawali, to potem w następnej firmie będzie łatwiej.

@LukeJL:

Faktycznie po jednym etapie ciężko sprawdzić kandydata.

gdzie jest granica? 2 etapy? 3? 4? 5? 10? mam sobie rezerwować czas po pracy bo jakaś firma chce ze mną zrobić tygodniowy maraton rekrutacyjny? a co jeżeli rekrutuje do 2 czy 3 (co chyba i tak jest słabym wynikiem)?

to może urlop wezmę aby te wszystkie rekrutacje ogarnąć :D

Jeśli zaś przejdziesz jako kandydat taką wieloetapową rekrutację, to poczujesz się mocny, że jednak ktoś cię sprawdził i że się faktycznie nadajesz, że to nie przypadek. A jak cię odrzucą, to też możesz się pocieszać, że przecież dotarłeś do któregoś etapu i przynajmniej zobaczyłeś, jakie pytania zadawali, to potem w następnej firmie będzie łatwiej.

prędzej bym powiedział że od tego co faktycznie pojawiło się na tej rozmowie i ewentualnie gdzie się rekrutowałem, a nie ile było etapów

śmiem twierdzić że na 1 spotkaniu 1.5h czy 2x 1.5h można bardzo dużo rzeczy wyciągnąć z kogoś

Mysle ze Twoje problemy przy rekrutacji i kompleksy spowodowane są tym, ze jestes po prostu słaby i jeszcze brakuje Ci doswiadczenia/umiejetnosci. A odpowiedzi typu "jak chcesz to znajde w Google" pokazuja niejako postawe roszczeniową i cwaniacką. Niestety przy rekrutacji trzeba być miłym i przynajmniej udawać poczciwego. A jezeli nie znasz odpowiedzi na jakies pytanie, to trzeba wprost to przyznac + dobrze jest lać wodę i nawet jesli cos Ci sie wydaje ale nie jestes pewien to o tym mowic przedstawiajac swoj tok rozumowania.

Co do tych pytan typu "wykuj i bedziesz seniorem za 15k" to w skrajnych przypadkach moze tak byc, tylko jaki to ma senS? Jezeli jestes bardzo slaby to potem w pracy mogą to zweryfikowac lub/i bedziesz się bardzo w niej męczył.
Prawdopodobnie potem bedzie na forum kolejny temat typu Wylewanie żali, że nie wyrabiam się z taskami i zasuwam darmowe nadgodziny za frajer...

Niemniej jednak w ten sposob wyzej opisany mozesz przejsc rekrutacje w kontraktorni gdzie szukaja byle kogos zapchaj dziura na szybko do klienta byle prowizje zgarnac. Mozliwe nawet ze jak trafisz do jakiegos banku czy innwgo korpo do projektu gdzie jest burdel to jakos to bedzie i schowasz się w tle nawet bedac slabym.
Jednak gdy rekrutacja na seniora jest powiedzmy "normalna" nikt nie zadaje raczej tego typu pytan, tylko pytaja o use csy konkretne, problemy co bys zrobil wtedy i wtedy. Jezeli ktos umie prowadzic rekrutacje umie tez latwo wyczuc czy jestes ogarniety, slaby czy słaby + ściemniacz.
P.S. Najfajniej jest być ogarniętym + umies ściemniac gdy trzeba.

Jest pewien minut googlania w 10s. Można w 10s wygooglać jak wygląda pętla for each w danym języku, ale oczekiwałbym, że kandydat będzie to wiedział. Można w 10s wygooglać jakiś specyfiki w danym języku i można się przy tym upierać, że tenże specyfik jest rzadko potrzebny i znaczna część ludzi go nie zna, ale dla mnie to pokazuje, że ktoś z wieloletnim doświadczeniem był zainteresowany tematem i wgłębiał się w szczegóły, bo go to bawi i jest ciekawski. Ile rozmów sam przeprowadziłeś jako interviewer?

Ja sie przebranzawialem wiec wedlug mnie rekrutacje w IT są bardzo głupie. W poprzedniej branży głównie pytali o doświadczenie i czy to jest to co pasuje do firmy oraz o znajomość procesów itp. Ale kwiatków też nie brakowało tam gdzie był kreatywny dział HR.

Robiąc takie same rekrutacje dla ludzi z 6-10 lat doświadczenia trochę odbieram za brak szacunku czy lenistwa bo "taki mamy proces i co nam zrobisz i mam X ludzi na twoje miejsce".
Co ja czy inni ludzie kłamiemy w CV?

Jak dostaje jakas bzdure typu lista ciagow znakow i chodzenie po indexach to mnie osłabia.

Osobiscie to na codzień potrafilem robić w Golangu, Kotlinie, Pythonie, bashu, yamlu, terraformie. Kiedys jak klepalem jakis kod jednej aplikacji to pamietalem dobrze syntax ale przy mnogosci technologii zaczyna sie to mylic ;) No ale ja przeszedlem z roli klepacza do infry więc troche inna rzecz.

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.

1. 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.