Czy bycie dobrym w rozwiązywaniu algorytmów pomaga Wam znaleźć atrakcyjniejszą pracę?

Niektóre firmy z tej wyższej półki (GAFAM) prowadzą rekrutację w oparciu o umiejętność rozwiązywania algorytmów. Przykładowe zadania można znależć na przykład na stronie leetcode.

Tak, też się z tym spotkałem (akurat niekoniecznie w lepszej firmie). Dostałem do zaimplementowania na żywo dwa proste algorytmy:
1) znalezienie w tablicy dowolnej pary liczb, która się sumuje do X;
2) losowe odtworzenie playlisty bez powtórzeń;
3) znalezienie wszystkich podzbiorów wejściowego zbioru;
Plus optymalizacje i udowadnianie złożoności.

Potem, podczas feedbacku, zadałem pytanie "Czy faktycznie aż tyle się u Was klepie algorytmów, że o to opieracie pół rekrutacji?". Dostałem odpowiedź "nie, ale taką mamy politykę rekrutacji." ¯\_(ツ)_/¯

(Pominę fakt, że ten ostatni program to musiałem gościowi odpalić, bo nie zrozumiał rekurencyjnego podejścia: findAllSubsets(result, i, j) = findAllSubsets(result, i+1,j) + findAllSubsets(result+t[i], i+1, j) xD)

Ja mam januszową małą firmę i robimy małe projekty na zlecenie. Próbowałem na początku rekrutować algorytmami i nie działało mi to za dobrze. Nie robiłem dużo rekrutacji, więc ciężko tu o jakąś statystykę, ale teraz patrzę bardziej na to, czy ktoś robił już coś w tych frameworkach, co my - czyli jakieś pytania i zadanka z Reacta, itp. No i, czego wcześniej nie doceniałem, na zapał i motywację, czy ktoś interesuje się w ogóle jakimiś technologiami webowymi i nowościami, czy bardziej interesują go algorytmy (tak jak mnie - paradoksalnie). Umiejętność pracy z większymi projektami niż jeden plik też jest nieoceniona.

Kiedyś raz pracowałem przez 2 lata nad systemem do rekonstrukcji modeli 3D ze skanów - chmury punktów, itp. - i guess what - i tak przez ogromną większość czasu szukałem i wdrażałem biblioteki open-source'owe z algorytmami, które ktoś już napisał i udostępnia za darmo.

Nie mam danych, ale zgaduję, że wygląda to tak, że 90% popytu rynku pracy to robienie prostej i żmudnej chałtury (której perfekcja wymaga jednak doświadczenia, żeby robić to szybko), 9% wymaga jakiegoś skilla, a może 1% wymaga skilla z jakiegoś typu algorytmów. No i teraz w zależności, jak ważnym czynnikiem jest wynagrodzenie (pewnie kluczowym?) - stawki wyznacza podaż i popyt, więc bardzo możliwe, że na tych najprostszych rzeczach stawki będą największe. Teoretycznie przynajmniej.

Są też firmy z quant finance, które wymagają algorytmów jak mniemam, a płacą dużo - ale to pewnie ze względu na to, żeby ich tajemnice nie wyciekały, o zaufanie też tu chodzi. (trochę jak rynek handlarzy kokainą - w branżach, gdzie potrzebne jest zaufanie, ceny nie spadają nawet jeśli zwiększy się podaż - cytując Netfliksa)

A wracając jeszcze do rekrutacji algorytmami tam, gdzie potem nie są one potrzebne. To jest coś, co łatwo na rekrutacji sprawdzić (w przeciwieństwie na przykład do umiejętności ogarnięcia dużego codebase, co wyjdzie już tylko w praniu) i firmy chętnie stosują to jako czynnik przesiewowy. Jeśli ktoś to umie, to raczej nauczy się też innych rzeczy, jeśli nie zabraknie mu motywacji. A jeśli ktoś nie umie algorytmów i nie wiadomo o nim nic innego, to na wszelki wypadek możemy go nie zatrudniać. Zazwyczaj koszt zatrudnienia niewłaściwej osoby jest nieporównywalnie większy niż koszt niezatrudnienia właściwej osoby. (był chyba o tym jakiś Ted talk)

Fajnie, gdyby wypowiedział się w tym temacie jeszcze ktoś, kto pracuje w quant finance, ktoś, kto pracuje przy jakichś algorytmach (komercyjnie?) i może "ktoś" ze SpaceX? ;)

W zeszłym roku zmieniałem pracę, przeszedłem 7 procesów rekrutacyjnych. Ponadto sam pracowałem dość sporo jako rekruter.
Jako rekrutujący zawsze sprawdzałem wiedzę o algorytmach i strukturach danych i uważam to za dobry wyróżnik i zwracałem na to uwagę. Podobnie gdy sam się rekrutowałem to kilka firm sprawdzało moja znajomość w tym zakresie. I uważam że były to raczej te lepsze, jedną z nich wybrałem :)
Ale, ale ale istniej wiele umiejętności które się o wiele częściej przydają w pracy komercyjnej. I żadne zadanie z algorytmiki które sam zadałem lub otrzymałem nigdy nie przekraczało trudności łatwiejszych spośród zadań C. Nawet zadania które wymienił Krzysztof uważam za nieco za trudne na rozmowę kwalifikacyjną.

Zajmuję się rekrutacją programistów od kilkunastu lat. Uważam, że podstawowa znajomość algorytmów jest kluczowa - ale tylko podstawowa. Moje ulubione zadanie dla kandydatów to "znajdź w tekście najczęściej występujące słowo". Bardzo łatwe - trudność na poziomie grupy "C" w początkowych rundach. Trzeba po prostu umieć użyć struktury typu map<string,int>. Jednak to mi wręcz idealnie odsiewa ludzi, którzy potrafią coś zaprogramować od tych, którym się wydaje, że potrafią.
Trudno uwierzyć, jak mało kandydatów potrafi zrobić to zadanie. 60-80% napływających CV odrzucam po samym CV. Z pozostałymi kandydatami spotykam się. Spośród tych 75% nie potrafi zrobić tego zadania, często pomimo ukończenia tzw. "studiów informatycznych", ale na uczelniach typu "Wyższa Szkoła Informatyki i Umiejętności". Zdarzają mi się nawet osoby, które nie potrafią zrozumieć treści zadania, pomimo że służę wszelkimi wyjaśnieniami.

Tak naprawdę ważne jest, żeby programista miał "inteligencję programistyczną", którą oczywiście łatwo sobie wyrobić algorytmiką. Jednak sama znajomość algorytmów i umiejętność rozwiązywania problemów algorytmicznych najczęściej nie jest bezpośrednio użyteczna w typowej pracy programisty.

W wartościowej pracy dobrego programisty umiejętność myślenia algorytmicznego jest kluczowa. Dlatego uważam, że zarówno konkursy są świetnym treningiem, jak i testowanie kandydatów przez algorytmy to całkiem dobra metoda.

Może niekoniecznie są to dokładnie tego samego rodzaju algorytmy co w potyczkach -- może zamiast myśleć o grafach trzeba myśleć o komunikacji w internecie, albo może o cache'ach procesorów, albo może o zaokrągleniach w obliczeniach numerycznych, albo o optymalizacji przybliżonej, itd. Ale i tak jest to ten sam rodzaj algorytmicznego myślenia.

Moje podejście jest takie, że jeśli jakieś zadanie programistyczne jest "nudne", tzn nie wymaga zbyt wiele myślenia, to to oznacza, że można je szybko zaimplementować i mieć z głowy. Jeśli nie da się czegoś szybko zrobić, to znaczy że tam jest jakiś problem do rozwiązania.

Mówię tu o pracy czysto programistycznej -- jest dużo ludzi, dla których programowanie to tylko mała część pracy, a głównie zajmują się czymś innym, to wtedy siłą rzeczy mają problemy zupełnie inne niż algorytmiczne.

tl;dr Tak, myślę, że znajomość algorytmów pomogła mi znaleźć lepszą pracę

To ja jeszcze może się wypowiem z perspektywy stażu/"new grad hire". Praktycznie każda moja rozmowa do większych firm na pozycje software developer w większości opierała się na rozwiązywaniu problemów algorytmicznych (prostszych bądź trudniejszych). Oczywiście podczas rozmowy o pracę implementacja rozwiązania nie jest jedynym czynnikiem i można zostać odrzuconym pomimo napisania FFT w 30 min.

Gdy zatrudnia się ludzi z doświadczeniem to można się pytać o znajomość frameworków i poprzednie projekty, jednakże do sprawdzania studentów bez doświadczenia algorytmy świetnie się sprawdzają. Nie chcesz odrzucić zdolnego studenta tylko dlatego, że jeszcze nie programował w dziedzinie którą się zajmujesz. Również szkolenie nowego pracownika w dużej firmie jest porównywalnie mniej kosztowne niż w małej firmie, więc chętniej zatrudniają ludzi bez doświadczenia w konkretnej technologii.

Spróbuję trochę sprostować #25290 na temat "GAFAM"

Algorytmy są maglowane w ten czy inny sposób ale głównie dla new grads, czyli ludzi bez doświadczenia w CV. Dla ludzi, którzy parę lat w branży już pracują to dużo ważniejszy jest tzw. system design plus udokumentowane doświadczenie w konkretniej dziedzinie pod dane stanowisko - np. machine learning, distributed systems, itd.

Dwie uwagi:
1. algorytmy z potyczek może się nie przydają, ale zdecydowanie przydaje się umiejętność swobodnego i szybkiego przelewania myśli na działający kod.
2. trzeba również pamiętać, że wiele osób które rekrutują w takich wielkich firmach to nie są żadni wymiatacze algorytmiczni, taki Google to z grubsza koło 100tyś tzw. inżynierów ma, i najczęściej biorą jakieś gotowe pytania z wenętrznej bazy danych niekoniecznie rozumiejąc różne aspekty problemu który zadają kandydatowi - łagodnie to ujmując.