Czy zadania algorytmiczne na rekrutacji mają sens?

Hej,

Ciekawy jestem co myślicie o serwowaniu zadań "algorytmicznych" podczas rekrutacji.
Mam na myśli różne programistyczne łamigłówki, nie koniecznie wymagające głębokiej wiedzy o algorytmice.
Z tego co się orientuję jest to metoda często stosowana przez różne znane korporacje.
Powstały na ten temat nawet książki.

Zdaje się, że bywa to traktowane jako zawoalowana forma testu inteligencji.
To znaczy założenie jest takie, że jak ktoś umie rozwiązać te zdania, to jest bystry.

Z drugiej strony, umiejętność ich rozwiązywania jest chyba w dużym stopniu kwestią praktyki.
A to czy kandydat rozwiązał wcześniej 1000 podobnych zadań czy 0 nie jest już uwzględniane.
Tak że super-bystrzak który sobie poradził z marszu jest nieodróżnialny od pracowitego przeciętniaka...

Tak mnie naszło na przemyślenia, bo osobiście mam z tymi zadankami pewien problem.
W trakcie (nielicznych) rekrutacji co prawda udawało mi się póki co uporać z tym etapem, jednak nie czuję się mocny.

Jakie są Wasze doświadczenia?
Spotkaliście się z takimi zadaniami na rekrutacji?
Rozwiązujecie je w ramach treningu czy przygotowań?
Uważacie że są dobrym wyznacznikiem "jakości" kandydata?

Akurat podlinkowana książka to taka algorytmika bardziej, niż zagadki programistyczne.
Jak zmieniasz firmę na jakakolwiek i dostajesz pytania typu ‚co zwróci x = 4/3//6+*6 * x; x = 4x w pythonie w wersji 2.7.3?’ Albo leetcode to podziękuj zwyczajnie i szukaj dalej.
Gorzej jak takie zadanie dostaniesz od firmy gdzie chcesz się dostać, typu faang. Wtedy pozostaje zacisnąć zęby i grindowac leetcode.

Generalnie temat wałkowany wielokrotnie, użyj funkcji szukaj

Trochę tak jest jak napisałeś. Trzeba mieć to dobrze przećwiczone i jeżeli twoja uczelnia położyła na to duży nacisk podczas studiów, to masz łatwiej. Nie jest to test na inteligencje.

Czy to sprawiedliwe? W pewnym sensie tak, bo wiadomo czego się spodziewać i jak się przygotować. To tak jak z maturą z matmy, sprawdza jakąś tam podstawową wiedzę i biegłość.

Czy ta wiedza będzie użyteczna w normalnej pracy ? Zapewne nie.

Jeżeli Ci zależy to grinduj leetcode. W przeciwnym wypadku poszukaj firmy, która inaczej prowadzi rekrutacje. Ostatnio coraz częściej popularne stają się zadania domowe. Też mają swoje wady, a jak poświecisz zbyt dużo czasu, a i tak Cię odrzucą, to poczujesz rozczarowanie.

Problem w tym, że jak się slyszy o algorytmach na rekrutacji to wszyscy mają na myśli co najmniej najkrótsze ścieżki, a wystarczy robić jakieś binary search, tree traversal, jakieś zadanko na nested loops (choinka czy coś w ten deseń) I teraz czekam na argumentację tych wszystkich, którzy twierdzą, że w pracy algorytmy nie są potrzebne.

@Saalin: No potem w pracy nic nie zakodują co będzie się równało z czymś więcej niż wywołaniem jakiejś libki z neta, bo będzie za trudne :D

A tak wracając do tematu, zadania, na które trzeba "wpaść", żeby je rozwiązać nie są najlepsze, ale na większości rekrutacji jak się spotkałem z zadaniem, trudniejsze było zrozumienie co trzeba zrobić niż sama implementacja.

To jest prosty test sprawdzenia czy Ci zależy na tej firmie. Jeżeli tak, to będziesz się uczył specjalnie pod nią, żeby zdać i o to chodzi raczej.
Natomiast też rzadko kończy się na tym. Często są też pytania o np wzorce projektowe.

Zdaje się, że bywa to traktowane jako zawoalowana forma testu inteligencji.
To znaczy założenie jest takie, że jak ktoś umie rozwiązać te zdania, to jest bystry.
Z drugiej strony, umiejętność ich rozwiązywania jest chyba w dużym stopniu kwestią praktyki.

Dokładnie tak jest. Takie rodzaje testów wprowadzono historycznie właśnie w celu wyłowienia "inteligentnych" kandydatów i miało to sens dopóki ludzie nie zaczęli grindować leetcodów. To jest trochę jak z szachami - jak posadzisz dwie osoby które dopiero co nauczyły się jak ruszają się bierki, to inteligentniejszy będzie wygrywać. Ale jak dasz im czas na naukę otwarć, teorii i poćwiczenie taktyk, to sytuacja może nagle odwrócić.

Na szczęście firmy powoli ogarniają co się stało i zmieniają taktykę oraz pytania na interview, np. na dyskusję na temat designu i architektury jakiegoś systemu rozproszonego.

Rozwiązujecie je w ramach treningu czy przygotowań?

Nie. Wychodzę z pewnych prostych założeń:

1. Jeśli firma na interview pyta o rzeczy które w pracy tam nie są potrzebne, to nie chciałbym tam pracować, bo zespół będzie składał się z ludzi zrekrutowanych w ten sposób i jest duża szansa, że będzie słabo. Np. dostaniesz jakiegoś kto wie ile piłeczek pingpongowych zmieści się w maluchu, ale nie umie napisać linijki kodu ;)
2. Jeśli firma na interview pyta o sensowne rzeczy, ale ja nie umiem odpowiedzieć, to znaczy że ta tematyka czy technologia mnie nie interesuje, więc to pewnie nie praca dla mnie.

Skillowanie "pod interview" w moim odczuciu będzie skutkować brakiem zadowolenia z pracy.

Mają sens, jeśli są pretekstem do pogadania (kandydat <-> sprawdzający jego wiedzę programiści).

Sprawdzanie, jak komuś poszło rozwiązywanie jakiegoś przypadkowego algorytmu w ciągu kilku(nastu/dziesięciu) minut nie ma wiele sensu.

Jednak implementowanie algorytmu może być pretekstem do pogadania bądź później ("podobało nam się twoje rozwiązanie, ale to mógłbyś zrobić lepiej") albo w trakcie robienia. W ten sposób obie strony korzystają: firma może sprawdzić, jak dany programista myśli, jakie ma podejście do rozwiązywania problemów (nawet jeśli ktoś nie rozwiąże czegoś), a kandydat może dostać feedback i nauczyć się czegoś z algorytmów (nawet jeśli nie zostanie zatrudniony) albo po prostu sobie pogadać z programistami (dobrze jest jak są to programiści z tego samego zespołu, z którym będzie pracować)

Mam ambiwaletne uczucia z przewagą na nie
Z jednej strony zadanko algo może coś powiedzieć o człowieku (z całym bagażem o którym pisał @Shalom leetcode, hackerrank itd)
Jak sobie radzi
Jak myśli
Jak kombinuje

Z drugiej
Od czasu do czasu mam fazę na zadanka bo do mojej pracy to ma to się jak pięść do nosa i zwyczajnie rdzewieje w tym temacie. Mi ta wiedza strasznie szybko ulatuje,a codzienna praca nie pomaga w konserwacji.
Czyli przydatność w pracy.
Taki przykład z mojego życia
W programie trzeba było napisać dość skomplikowany algo. Zespół międzynarodowy, około 100 osób. Firma zleciła napisanie tego na zewnątrz.
Trochę z tym mi było tak sobie. My to sobie możemy klepać bugi i pierdoły, a poważna robota jest dla poważnych ludzi.
Nawet jak była okazja to nie dla psa kiełbasa.

Zależy kto to ocenia
Automat jest bezduszny i co tu można powiedzieć więcej
Człowiek może być tak samo bezduszny, miałem jedną rekrutację gdzie prowadzący miał swój pomysł, a każde odstępstwo uważał za dyskwalifikujące. Czyli albo idziesz jego ścieżką albo nie nadajesz się.

Ogólnie kiedyś to był ogromny sens, gdy dev musiał sam napisać i listę i sortowanie i stringa, teraz to wszystko jest w bibliotece standardowej. Dodatkowo jeśli praca to utrzymanie albo crud to przerost formy nad treścią.

Jak wykorzystują w pracy na codzień, to jak najbardziej.

W większości przypadków chyba na live coding pokazać jakiś sensowny kawałek kodu + kazać przeanalizować + coś dodać.
Albo zaprojektować kod pod jakiś case/sprawdzić czy nie popełnia błędów juniora pisząc kod i zobaczyć czy ktoś się nada do naszej firmy.

Jesli ktos cie zapyta na rekrutacji o rozwiazanie zadan i algorytm to zapytaj go jakie jest wynagrodzenie za to zadanie i jesli ich to zdziwi to wyjdz, bo to jest brak szacunku

Takie zadania maja sens, jeśli chce się sprawdzić jak kandydat kombinuje, komunikuje się, czy umie zaaplikować podpowiedzi. Czyli nie sprawdza się, czy umie odtworzyć z pamięci/doświadczenia jakieś rozwiązanie, ale jak sobie radzi w sytuacji zupełnie nowej, kiedy trzeba coś wymyślić. Algorytmy i struktury danych to tylko narzędzia, zamiast tego mogłyby być bazy danych i kolejki - trzeba zbudować coś nowego. Nie chodzi o to, aby wymyślać drzewo czy kolejkę priorytetowa, ale aby umieć coś z tego skleić.

Nie jest to oczywiście etap wystarczający. Do sprawdzenia wiedzy z jakiejś dziedziny czy projektowania i wdrażania systemów robi się inne rozmowy.

Czyli ci z olimpiady informatycznej się wyuczyli ? Brałem w niej udział ale zrezygnowałem, Bo były łatwiejsze sposoby zdobycia indexu. Kiedyś na OI było tak że 40% laureatów było z 1 szkoły a z 3 szkół było 80 %. A to konkurs na całą Polskę. Będący taką rekrutacją wstępną na olimpiadę międzynarodową.

Czyli ci z olimpiady informatycznej się wyuczyli

Oczywiście że tak. Wiadomo, to nie jest tak, że nie trzeba mieć pewnych predyspozycji, ale większość laureatów OI czy OMa to nie są "zdolni ludzie z ulicy" tylko ludzie którzy grindowali zadania mocno. To jest kombinacja tych czynników.

Kiedyś na OI było tak że 40% laureatów było z 1 szkoły a z 3 szkół było 80 %. A to konkurs na całą Polskę

To jest tzw. "samospełniająca się przepowiednia" i sprzężenie zwrotne.

1. Mówisz wszystkim że szkoła X ma najlepsze wyniki na olimpiadach i najlepiej przygotowuje
2. Ludzie zainteresowani olimpiadami idą do tej szkoły, żeby zwiększyć swoje szanse
3. Szkoła ma teraz samych zdolnych uczniów którzy chcą i będą ciężko grindować pod olimpiadę i w efekcie będą mieli na niej dobre wyniki
4. Szkoła osiąga najlepsze wyniki na olimpiadach i wracamy do punktu 1

Podobnie wygląda sytuacja z "prestiżowymi uczelniami". Ten "prestiż" przyciąga lepszych i bardziej pracowitych studentów co przekłada się następnie na wyniki z których wynika prestiż.

Zadania algorytmiczne na rekru nie sprawdzają nic poza umiejętnością rozwiązywania takich zadań. Można przysiąść na jakimś codility czy innym toolu i sobie to porozwiązywać. Tylko czy to finalnie przełoży się na jakąkolwiek prace w realnym projekcie?

Ma sens, dla firm. Bo nie muszą sami się wielce trudzić z weryfikacja zadań. Często jest to zautomatyzowane. Więc mniej czasu na tym spędzają

A na ile ma to realnie sens, nie wiem. W innych branżach też wiele rzeczy nie ma sensu na rekrutacji. Ale ważne, że osoba aplikująca wykazała zaangażowanie i pokazała, że naprawdę chcę tam pracowac. No wyuczyli się pod to ale nie musieli, skoro tego się nauczyli to pewnie innych rzeczy też się nauczą ;)

A gdzieś indziej pozwala na zbicie stawki ;)

W mojej opinii idealny proces rekrutacji wyglada tak:

1. HR (30min) krotko o: firmie, projekcie, zespole, stosie technologicznym wymaganiach i procesie rekrutacji wraz z info o widelkach
2. Rozmowa nietechniczna ogolna z Tech Leadem/Team Leadem/Inzynierem (1h) - celem tej rozmowy jest poznanie kandydata zweryfikowanie jego motywacji tego czym chce sie zajmować jakie ma ambicje techniczne itp itd oraz szansa dla kandydata żeby zweryfikować czy odpowiada mu model pracy, projekt, i czy jest "flow" tutaj tez przewijaja sie pytania o doswiadczeniu o problemach technicznych o projektach technologia i skali tych projektow
3. Zadanie rekrutacyjne domowe (~ 15h-20h) mysle ze w tym czasie cos fajnego mozna juz napisac i jednoczenie firma moze zweryfikowac poziom
   i tutaj technologie raczej do wyboru (ja jako kandydat staram sie bawic nowymi rzeczami ktorych nie znam zeby cos dla siebie z tego wyciagnac przy okazji)
4. Rozmowa techniczna (1h-1,5h) - typowa rozmowa techniczna np. o zadaniu ale i rowniez o "dobrych praktykach" technologiach i innych elementach
5. Rozmowa z managerem/Dyrektorem/CEO itp itd zaleznie od firmy jej modelu struktury o soft skillowych elementach itd itp
6. oferta

Mi sie tutaj ogolnie 'codility' czy inny livecoding nie miesci i wydaje mi sie raczej "zbedne" mysle ze dobrych kandydatow mozna wyczaic po profilu na LI + wyczaic ich na lvl 2. Tak wiem bardzo czesto trafiaja siie bajkopisarze i ludzie klamia na Linkedinie wpisuja sobie technologie obok ktorych tylko "stali" albo widzieli ew. tez na interview wala scieme. Lubie miejsca gdzie dobiera sie ludzi rowniez pasujacych "soft skillowo" dlatego bardzo mi sie podoba ten lvl 2 gdzie po prostu moge zadac pytania i pogadac wmiare "na luzie"
jak ktos widzi rozne tematy co robil ja chetnie powiem co ja robilem itp itd pare pytan technicznych tez spoko - takie "otwarte" do dyskusji sa najlepsze.

Tak wiem ze nie wszyscy kandydaci chca sie angazowac w taki proces tak samo jak nie wszystkie firmy chca poswiecac zasoby na taki proces. Ja juz po lvl 2 wiem czy chce / czy nie chce i ow Lead/osoba juz tez ma obraz czy rokuje czy nie rokuje. Na start 1,5h inwestycji czasu z 2 stron jest "OK" w mojej opinii.

W zyciu pracowalem zarowno z wymiataczami z leetcode jak i z osobami bardzo przecietnymi w tej materii i nie zauwazylem zadnej korelacji. Jako inzynier i czlowiek wsrod wpolziomkow w teamie cenie bardziej: zdrowy rozsadek/pragmatyzm/ chec poszerzania kompetencji/ znajomosc dobrych praktyk / soft skille/ wiedze ogolna i najwazniejsze dobry inzynierski mindset. W mojej opinii LeetCode ani tego nie potwierdza ani temu nie zaprzecza. Tak samo wcale nie uwazam ze trzeba byc maszyna co pali punkty w JIIRze bo czasem lepiej madrze stac niz glupio biegac.

Jak komus bardzo zalezy to spoko moge klepac LeetCode do poziomu "Medium" sobie radze od czasu do czasu sobie cwicze ale nie traktuje tego jako 'must have' albo wyznacznik. Ani nie robie tego pod interview tylko dla siebie i hobbystycznie. Ostatecznie fajnie czasem sobie poglowkowac typu sudoku/krzyzowki czy szachy whatever inna forma tego typu aktywnosci dla mnie.

Zadanie rekrutacyjne domowe (~ 15h-20h) mysle ze w tym czasie cos fajnego mozna juz napisac i jednoczenie firma moze zweryfikowac poziom
i tutaj technologie raczej do wyboru (ja jako kandydat staram sie bawic nowymi rzeczami ktorych nie znam zeby cos dla siebie z tego wyciagnac przy okazji)

Hahahahahaha, to może działac jak chcesz iśc do FB czy innego Amazona, ale kto ze zdrowym rozsądkiem będzie chciał marnować 30 h życia na jakąś jedną z miliona firm?
A zamiast zadań algorytmicznych lepiej zastosować DevsKillera.

@scibi_92:
@ledi12:

Jest tyle firm do wyboru iż każdy może samodzielnie wybrać co mu odpowiada. Każdy ma swoje priorytety i ambicje. Ja nie chce oceniać czyichś motywacji.
Podzieliłem się swoim punktem widzenia teraz troche go rozszerzę.

W ciagu ostatniego miesiąca wykonałem 3 zadania rekrutacyjne i poświęciłem na każde ~10h-20h. Wybrałem zadania które mnie interesowały i z firm które mnie interesowały.
Zanim zacząlem wykonywać jakiekolwiek zadania odbyłem 1h rozmowe z osobą z teamu żeby się upewnić czy pasuje i czy pozornie mi będzie odpowiadać dane środowisko.
Nie wykonuje wszystkich zadań tylko wybrane. Na zadania nie otrzymałem feedbacku opisowego tylko 3 x 'TAK' i chęć dalszej rekrutacji. Co więcej gdy 1 etapem jest zadanie techniczne to go nie wykonuje bo nie inwestuje czasu w coś o czym nic nie wiem - cenie swój czas ale jednocześnie jestem gotów podjąć extra wysiłek jeśli dane miejsce wydaje się być atrakcyjne - taka inwestycja obarczona ryzykiem - dla mnie to do zaakceptowania.

Dla przykładu zaaplikowałem kiedyś do Allegro - zadzwoniła Pani rekruterka na 5 min powiedziała że wysyła mi zadanie i to 1 etap rekrutacji i nara i nie miałem szansy zadać żadnego pytania ani nic - więc podziękowałem za rekrutację.

Co do devskiller nie spotkałem się z rekrutacja przez tę platforme w żadnej firmie z kapitałem spoza Polski.

Mam 8 lat doświadczenia i aspiruje do bycia "Seniorem" - wykonywałem zadania dla firm z Europy lub US - firmy oferowały widełki które były atrakcyjne i ponad stawki w Polsce i miały bardzo profesjonalny proces rekrutacji. Co więcej ja celuję w inny model i kulturę pracy niż w Polsce mam na myśli to że nie chce pracować z Polskim managementem.
Nie chce krytykować ani nic po prostu takie mam doświadczenia i preferencje to wszystko.

Jeśli np. specjalizujesz się w jakiejś relatywnie wąskiej dziedzinie to uwaga NIE - nie aplikujesz do 1 z miliona firm bo firm które zajmują się konkretną dziedziną technologią jest kilka w Europie i kilka na świecie i np. ludzie się często znają i szanują swój czas.

Co więcej wielu znajomych przechodziło podobny proces rekrutacji i były to osoby z większymi umiejętnościami i doświadczeniem niż ja i apliikowały na stanowiska powyżej 'zwyklego' Seniora.

Jedyne zadanie z algorytmów, po którym nie mam niesmaku to było zadanie opisowe.
Była to rozmowa z tech leadem, już ostatni etap rekrutacji, pokazali mi biuro, gadaliśmy o pierdołach i powiedział, ze jak wcześniej gadaliśmy to nie miał czasu mi zadać pytania, które zadawali każdemu.
Pytanie brzmiało:
Masz 9 kulek, jedna z nich jest odrobine cięższa od reszty, masz wage (taką starą, pochylnie, nie wiem jak to wytłumaczyć) i masz wykonać jak najmniej operacji (ważeń) żeby znaleźć tą cięższą kulę.
Fajne, krótkie, przyjemne, daje szanse na poznanie toku rozumowania i pokazuje jak ktoś potrafi przelać myśli na słowa

W embeded, w którym lata temu się rekrutowałem i dostałem na pierwszą prace w IT miałem pytania o podstawowe struktury i algorytmy - takie które są typowo implementowane w systemach operacyjnych/czasu rzeczywistego i które wypadało by znać z teoretycznego punktu widzenia na tyle by umieć je zaimplementować bez zagladania do wikipedi przy kwestiach takich jak wstawianie elementu do kolejki. Bo to jednak trochę słabo celować w np. programistę bare metal i po raz pierwszy ogladać zaimplementowany kod obsługujący listę jedno czy dwukierunkową. Tam powiązanie jednego z drugim było dla mnie oczywiste.

Mniej naturalnie by w mej opinii wyglądało gdyby ktoś się rekrutował do klepania frontendu sklepów z karmą dla psów i go na rekrutacji maglowanoa z balansowania drzew czerwono-czarnych czy kilkunastu implementacjii funkcji haszujacych.

Rekrutacja powinna odzwierciedlać to co będzie się później robić w pracy.
Inaczej będziecie narzekać że miało być co innego a robicie co innego.

smieszekheheszek napisał(a):

Rekrutacja powinna odzwierciedlać to co będzie się później robić w pracy.

Czyli: na pierwszym etapie rekrutacji nic nie robisz, tylko czekasz na dostępy XD

Na drugim etapie będzie symulowany standup, masz być jutro punktualnie o wschodzie słońca. Sprawdzimy twoją dyscyplinę.

Trzeci etap rekrutacji sprawdzi twoje miękkie skille. Przeklikaj się przez Jirę, znajdź taska nr 2137, a potem napisz wiadomość do autora z pytaniem, o co mu k... chodziło. Masz być komunikatywny i asertywny.

Czwarty etap, techniczny. Przygotowaliśmy dla ciebie spaghetti kod, musisz się w nim odnaleźć i dopisać do niego ficzer. Nieważna jakość kodu - możesz pisać spaghetti, bylebyś zrobił to szybko, bo im szybciej zrobisz, tym więcej punktów.

Jak najbardziej sprawdza się. Ja ostatnio zadaję zadanie żywcem wyjęte z naszego codebase. Aktualna wbita wersja to 35 lini kodu w 4 metodach. Sam problem to stworzenie wyspecjalizowanej kolekcji, w której co od razu zaznaczam liczy się wydajność pewnych operacji. Można w miarę sensownie zaimplementować na co najmniej 3-4 sposoby, a ciągle liczę że ktoś wymyśli kolejny. Jak zostanie czasu to proszę by ją przerobić by była thread-safe. Wszystko w 100% związane z robotą.

Za to zadawanie dość abstrakcyjnych problemów, które ciężko rozłożyć bez konkretnych algorytmów uważam za przesadzone. Chyba, że te konkretne algorytmy to zwykły DFS/BFS.

Sensowne zadania algorytmiczne takie tekstowe są dobrym testem na sprawdzenie jak kandydat myśli podczas rozwiązywania zadań. Sprawdza czy wie kiedy jakiej struktury użyć itp.
Zwłaszcza jeśli rekrutacja jest w formie "pair programming", wiec dodatkowo pokazuje czy potrafisz współpracować w razie problemów z zadaniem.

W wielu firmach nie przyda się aż taka znajomość algorytmów ale przynajmniej wiesz że osoby z którymi pracujesz potrafią myśleć nad dobrym rozwiązaniem problemu wiec jest szansa że kod będzie trzymał wyższy standard. Oczywiście nie jest to gwarancja no ale w jakiś sposób trzeba zweryfikować cechy kandydata w bardzo krótkim czasie.

Dodając do postu powyżej, sam teraz pracuje dla firmy która tworzy bibliotekę w kotlinie i kluczowa jest dla nas wydajność wiec kładziemy spory nacisk na to gdzie jakie dane są używane, jakie algorytmy, omawiamy na spotkaniach pomysły rozwiązań itp