Czy LeetCode to teraz standard?

Hej, dawno nigdzie sie nie rekrutowałem. Jak zacząłem sie ostatnio rozglądać to czesto widze, że ludzie piszą, że rekrutacja to leetcode medium/hard. Czy to jakis obecnie standard rekrutacji? I zostaje mi po prostu przysiąść i sobie poprzypominać? Bo szczerze to wyszedłem z wprawy w rozwiązywaniu takich rzeczy.

To standard u Google gdzie mają pewno z tysiąc kandydatów na miejsce i mogą sobie wybrzydzać i u Januszexów które ich nieudolnie małpują.

Często spotykane w firemkach, co to chcą na siłę mieć dobrą renomę i często płacą poniżej stawek rynkowych/mniej od konkurencji gdzie liczy się skill, a nie wykucie merge sorta na pamięć :)

Czesciej spotykam sie z Codility na rekrutacjach

W stanach na zachodnim wybrzeżu to może jest standard, u nas raczej rzadkość poza amerykańskimi firmami (Google Amazon i inne mniejsze,w Krakowie na przykład Qualtrics ale zadają pytania na poziomie pierwszego semestru na studiach).

Wiekszosc tych duzych korpo z dużymi produktami o wiekszym zasiegu i z wieksza iloscia uzytkownikow to chyba jednak robi leetcode itp. :/
Na rekrutacji to moze z 3 lata temu bylem, ale z rok temu jak pytalem o process to wszedzie tylko algorytmy.

I szczerze to nie chce mi sie specjalnie przygotowywac na rekrutacje :/
I tak z 5 lat temu tez robilem DFS / Dijkstre na rekrutacji ale teraz z marszu to nie wiem czy bym zrobil :D

nigdy się nie spotkałem z algo na rekrutacji

prawie zawsze były to dość praktyczne, dotyczące day-to-day stuff rzeczy, nigdy fanciness

Ostatnio byl fajny watek na reddit w ktorym dobitnie wszyscy lali ciepłym moczem na rekrutacje typu leetcode. Osobiscie znam 3 ludzi, ktorzy robia takowe dla sportu tylko po to zeby na koniec nie przyjac oferty, argumentujac beznadziejnym procesem rekrutacji, ktory nie jest zwiazany z codzienna praca

Z mojego doswiadczenia tez mam niemiłe wspomnienia. Procesy w ktorych kazano mi pisac algo nie mialy nic wspolnego z takimi zadaniami na co dzien (DevOps/SRE here). Dlatego teraz jak ktoś mi proponuje taką formę to albo rozwiązuję dla sportu wykluczając firmę albo rezygnuję na starcie.

Warto natomiast rozwazyc taki proces jeśli oparty jest o jakies zadanie z dnia pracy - co zdarza sie bardzo, bardzo rzadko (u mnie raz na kilkanaście).

@japanlofi: @karsa: a w sumie jak powinna wygladac rerkutacja na Devops/SRE ? Bo u mnie zawsze jakos to bylo tak ze wpadalem w QE/perf testy -> tam trzeba bylo ogarniac zestawianie systemu itp. I z czasem okazywalo sie, ze potrzeby spore, a robotnikow malo i w sumie szkoda zebym robil QE jak potrafie inne rzeczy ogarniac.

edit: Link z komentarza od @karsa, moze sie komus przyda: https://github.com/mxssl/sre-interview-prep-guide

Dużo zależy od firmy, z tego co zauważyłem to najczęściej algorytmy i struktury danych są na rozmowach do dużych korpo, szczególnie zagranicznych, do jakiś małych firm to rzadziej. Pewnie wzięło się to z USA gdzie jest to teraz standard w każdej większej firmie. Kiedyś zamiast algorytmów i struktur danych były brain teasery typu "ile piłek tenisowych zmieści się w samolocie" , teraz jest DSA, może w przyszłości będzie coś innego. Są osoby (pewnie większość), które nie lubią takiego procesu ale zostaje albo się przystosować albo rekrutować się do innych firm.

Co do wielkich korpo to praktycznie zawsze są one przy rekrutacji na stanowisko Software Engineer, gdzie nawet język programowania można wybrać w jakim będzie się to pisać - czyli raczej bez wąskiej specjalizacji.

No i warto zauważyć, że te algorytmy to tylko część rekrutacji - w BigTech gdzie jest po kilka rozmów to jest też część na wiedzę domenową, część behawioralna itd. W mniejszych firmach pewnie jest coś podobnego, że jak jest tylko jedna rozmowa to algorytmy to tylko jej jakaś część.

Kilka przykładów firm z rekrutacji które ostatnio przechodziłem i były algorytmy to Allegro, MicroStrategy, Unit8. Na juniora to trafiały się raczej LeetCode easy/medium, ale raczej standardowe (na sam poziom czasami nie warto patrzeć bo zdarzają się easy trudniejsze od medium, czy medium takie że raczej nie widząc takiego zadania wcześniej praktycznie niemożliwym jest rozwiązanie go w 30 min bez żadnych bugów, hardy niektóre to też niezłe ale to już jakby się miało trafić to pewnie w rozmowie do FAANG), jako że proces ten już trochę trwa to w internecie jest dużo materiałów jak się do czegoś takiego przygotować.

Ktoś może ogarniać dobrze LeetCode, ale jakbym mu kazał wyrzeźbić CRUDA w Springu i Hibernate wraz z testami jednostkowymi, postawieniem tego na Kubernetesie, opowiedzeniu o paru wzorcach projektowych, czy transakcjach albo koncepcji semaforów ogólnie w IT i widzę że gość nie ogarnia no to po prostu go nie zatrudniam. W mojej kontraktornii potrzebujemy wyrobników, co wyklepią PoC'a dość szybko w Sprincie i będzie dobrze.

Aż się zdziwiłem że 4p tak chłodno podchodzi do LC sądząc po komentarzach.

Standard, czy nie; LC to sprawdzona droga do najlepszych zarobków dla IC. Ciekawe że pojawił się wątek o Reddit. Polecam więc przejrzenie sobie innej społeczności - teamblind (aplikacja Blind). Regularnie co 2-4 tygodnie pojawiają się tematy typu "thank you Blind community, LC changed my life" i historie jak ludzie wskoczyli z pozycji $60k rocznie na $300-500k rocznie w dwa lata. A z Redditem tam delikatnie mówiąc polemizują (w drugą stronę pewnie też).

I nie ma tu znaczenia że LC nie jest idealnym narzędziem do odsiewania kandydatów. Żadne nie jest. Kandydata nie ma obchodzić czy zasady są słuszne, tylko jak najlepiej grać w korpogrę.

@klme

ludzie wskoczyli z pozycji $60k rocznie na $300-500k rocznie w dwa lata.

no nie wiem, ciężko mi w to uwierzyć że różnica pomiędzy 60k devem, a 500k devem jest LC + ewentualnie skok do 1 firmy meanwhile

Druga sprawa o ktorej warto wspomniec to psychologia. Opiszę pokrótce.

Jezeli ktos jest w stanie grindować algorytmy (ktos tam pisał ze ludzie robia po rok-dwa) po pracy w czasie wolnym to takze ma to drugie dno dla tej firmy, ze po dostaniu pracy tak szybko z niej nie zrezygnuje, będzie to nagroda. (inwestowanie czasu wczesniej bez pokrycia)

Druga sprawa to tez target ludzi ktorzy brną w tą zabawę. To tez juz jest wstępny etap odsiania ludzi. Bo ja już z rodzina na glowie nie wyobrażam sobie z mlodym gościem po studiach rywalizować o to jakie algorytmy porobiłem i ile czasu na to poświęciłem. Po prostu praca w tego typu firmach tez nie jest dla kazdego.

Algorytm swoja droga, ale takze ma to aspekt psychologiczny, który nie zostal wymyslony tak o, tylko to sie kalkuluje i nad tym tegie glowy siedza (nie mowie tu o programistach).

Swoja droga bralem tez to pod uwage wszystko ze zdecydowalem sie pojsc w niszę w IT, gdzie czasem nie ma w ogole kandydatow, albo sa niekompetentni przez co algorytmy to ostatnia rzecz ktorej sie boje na rekrutacji.

Moim zdaniem warto znać algorytmy i struktury danych oraz potrafić rozwiązywać problemy z LeetCode i innych tego typu stron na poziomie conajmniej medium, ponieważ poszerza to znacząco horyzonty programistyczne.
Dodatkowo statystycznie mając dwie grupy kandydatów:

1. Radzi sobie dobrze z zadaniami LeetCode itp
2. Nie radzi sobie z tego typu zadaniami
   można przyjąć, że w tej pierwszej grupie jest więcej osób dobrych albo bardzo dobrych niż w tej drugiej.
   Nie mam tutaj na myśli startowania w konkursach na czas.

Może i w codziennej pracy nie spotyka się za często tego typu zadań, ale nigdy nie wiadomo kiedy coś takiego się trafi.

Często przeglądam i widzę słabo napisany kod, właśnie z tego powodu, że ludzie nie znają algorytmów - to od razu widać.
Przykład - usunięcie duplikatów z tablicy wiele razy widziałem w podwójnej pętli for, czyli O(n^2), a żeby to napisać lepiej nie trzeba wcale być algorytmicznym mistrzem, a to tylko jeden z prostszych przykładów.

Nieznajomość algorytmów objawia się też na wiele innych sposobów:

• złe projektowanie klas
• wynajdywanie koła na nowo
• nieczytanie kodu
• nieznajomość bibliotek
• niepotrzebne komplikowanie kodu
• nieznajomość wielu technik programowania

Rozwiązując zadania algorytmiczne moim zdaniem można bardzo podnieść swoje umiejętności progrmistyczne.
Nawet jeżeli nie potrafi się samemu rozwiązać zadania to można się tego nauczyć patrząc na rozwiązania innych.
Przeglądając rozwiązania innych można poznać wiele sposobów rozwiązania tego samego problemu o różnej wydajności, a pracując jako programista często trzeba przeanalizować kilka rozwiązań i wybrać najlepsze, więc w ten sposób uczymy się też tego typu umiejętności.

Mógłbym pisać tak długo. Nieprzekonanych i tak nie przekonam.
Taka dyskusja trochę przypomina mi (pewnie porównanie nie będzie do końca trafne) coś na zasadzie:

1. Programista A zna tylko goto (ewentualnie tylko tablice)
2. Programista B zna goto, ale umie też przeiterować kolekcję używając for (zna np. listy)
   Programista A mógłby powiedzieć, po co mi tam znać te wszystkie iteracje, zawsze mogę sobie zrobić goto, albo po co mi znać listy zawsze stworzę sobie wystarczająco dużą tablicę, albo po co mi tam znać te listy, zawsze stworzę sobie odpowiednio dużą tablicę :)

Az sobie odpalilem to let code i zrobilem pare zadanek. Wrazenie? Tak jakby rekrutowali kogos na pilota samolotow pasazerskich i kazali mu biegac po placu z rozlozonymi rekami i wymagana onomatopeja zeby nasladowac silniki.
Sam brak IDE i Intellisense robi ogromna roznice.

Zadziwiające jest to, że programowanie to ciągłe poszerzanie wiedzy i umiejętności, nauka wielu frameworków, bibliotek itp. i tego nikt nie uważa za bez sensu, bo teraz szukają programistów Springa, za rok programistów czegoś innego. Przed nauką tego typu rzeczy nikt nie ma oporów. Wszyscy chętnie uczą się nowych frameworków, które zmieniają się co jakiś czas.

Natomiast nauczenie się czegoś raz i porządnie, co przyda się w całej karierze jest traktowane jako coś bezsensownego i bezcelowego :)

Wydawało mi się, że programiści to ludzie głodni wiedzy, a na podstawie tego wątku i komentarzy, widzę, że wcale niekoniecznie :(

Zaryzykuję może jeszcze takie porównanie.
Mamy dwóch neurologów (edit: neurochirugrów :)):

1. Nie potrzebna mi jest znajomość budowy mózgu, wystarczy że wiem jak zbudowana jest czaszka i osadzone w niej oczy, jakoś sobie poradzę w razie czego doczytam przed operacją co i jak
2. Znam bardzo dobrze budowę mózgu

Do którego z nich byście się wybrali na operację? :)

CyanApple napisał(a):

Zaryzykuję może jeszcze takie porównanie.
Mamy dwóch neurologów:

1. Nie potrzebna mi jest znajomość budowy mózgu, wystarczy że wiem jak zbudowana jest czaszka i osadzone w niej oczy, jakoś sobie poradzę w razie czego doczytam przed operacją co i jak
2. Znam bardzo dobrze budowę mózgu

Do którego z nich byście się wybrali na operację? :)

Do chirurga :p

Natomiast nauczenie się czegoś raz i porządnie, co przyda się w całej karierze jest traktowane jako coś bezsensownego i bezcelowego

@CyanApple: tylko że to bzdura. Tak jak ze wszystkim innym, to trzeba ćwiczyć. To że dziś umiesz rozpykać jakieś LC hardy z biegu, wcale nie oznacza że za rok albo dwa, bez ćwiczenia, nadal będziesz. Szczególnie jeśli teraz to wyskillowałeś a nie byłes w tym kierunku naturalnie uzdolniony.

Nieznajomość algorytmów objawia się też na wiele innych sposobów:
złe projektowanie klas
wynajdywanie koła na nowo
nieczytanie kodu
nieznajomość bibliotek
niepotrzebne komplikowanie kodu
nieznajomość wielu technik programowania

Nie wiem skąd te wnioski. Problemy algorytmiczne w stylu LC kończą się zwykle może z 50 linijkami spaghetti, byleby zadziałało. Nijak się ma to do projektowania oprogramowania które da się utrzymywać albo do jakiegoś Clean Code.

można przyjąć, że w tej pierwszej grupie jest więcej osób dobrych albo bardzo dobrych niż w tej drugiej.

Google jakiś czas temu opublikowało artykuł z którego wynikało że nie ma u nich żadnej korelacji pomiędzy tym jak kandydat skillował leetcoda na rekrutacji a tym jaki jest jego późniejszy performance w pracy. Kiedyś może i tak było, jak ludzie nie skillowali takich platform i jakichś cracking the coding interview, ale teraz to bez różnicy. To trochę jak z graniem w szachy -> jak posadzisz dwóch gości którzy nie umieją grać i nauczysz ich zasad, to inteligentniejszy z nich będzie wygrywać. Ale wystarczy ze ten słabszy poświeci chwilę czasu na teorię, nauczy sie jakiegoś jednego otwarcia i będzie orać tego drugiego bez litości.

Uprawianie rekrutacji w stylu Cracking the Coding Interview przez małe firmy to jest po prostu kult cargo. Zastanówmy się najpierw jakie cele ma taka rekrutacja:

• zminimalizowanie false positives - zwalnianie pracowników z FAANG jest kosztowne,
• chcemy przyciągnąć największe talenty (najwyższe IQ), które będą pracowały przez wiele lat i budowały bardzo customowy codebase.

Celem rekrutacji w firmach kontraktorskich jest to, żeby znaleźć najlepszego pracownika do danej pracy za najniższe pieniądze. Firmy kontraktorskie nie przejmują się tym, że zatrudnią badziewiaków bo nie piszą dla siebie codebase'u. Dla nich to jest nawet lepiej zatrudnić 10 badziewiaków i opchnąć ich do klienta bo dostają prowizję*10.

O ile FAANGI są w stanie zapłacić takim kandydatom, żeby przyszli i nie odchodzili to w jaki sposób mała firma kontraktorska ma niby konkurować z rynkiem gdzie co chwila pojawia się firma, która podbija stawki i rotacja jest taka, że ludzie zmieniają firmę co 6 miesięcy. Mało firm jest w stanie sobie pozwolić na tworzenie customowego codebase'u tak jak robi to Google. Finalnie, wszędzie jest taki sam stack technologiczny, tj. spring, aws, python, może ruby, js. Więc skacząć z jednej firmy do drugiej moim największym assetem powinna być znajomość stacka. Skacząć do FAANGa nie jestem w stanie znać stacka bo oni mają customowego stacka.

Wyobraź sobie, że zapłaciłeś 10x więcej za rekrutację, bierzesz jakiegoś kozaka IQ 200 i ten kozak nie potrafi delegować, jest indywidualistą i nie dzieli się wiedzą. Po co Ci taki geniusz skoro masz prostą apkę do napisania? Po 6 miesiącach kozak się zwija bo gdzieś płacą 100 zł więcej. Czy naprawdę pracowity średniak z IQ 120 nie potrafi zrobić tej samej pracy? Przepłaciłeś bo zapłaciłeś za skillset, którego nie potrzebowałeś. Tylko, że nie możesz się chwalić na LI, że macie zajebisty proces rekrutacyjny z liczeniem piłeczek w autobusie. Że też ludzie się wciąż na to nabierają.

@Shalom:

Shalom napisał(a):

Natomiast nauczenie się czegoś raz i porządnie, co przyda się w całej karierze jest traktowane jako coś bezsensownego i bezcelowego

@CyanApple: tylko że to bzdura. Tak jak ze wszystkim innym, to trzeba ćwiczyć. To że dziś umiesz rozpykać jakieś LC hardy z biegu, wcale nie oznacza że za rok albo dwa, bez ćwiczenia, nadal będziesz. Szczególnie jeśli teraz to wyskillowałeś a nie byłes w tym kierunku naturalnie uzdolniony.

Jasne, że trzeba to ćwiczyć, tak samo jak znajomość frameworków, tyle że jak dojdziesz do poziomu, na którym umiesz rozpykać hard to nie zdegradujesz się w ciągu roku tak, że nie będziesz potrafił rozwiązać easy, a żeby wrócić na poziom hard będziesz potrzebował o wiele mniej czasu niż ktoś kto ma problemy z easy.

Za rok zapomnisz, ale pod warunkiem jeżeli wykułeś to na pamięć bez zrozumienia.
Jeżeli się tego nauczyłeś ze zrozumieniem tj. przeszedłeś przez kilka etapów:

1. nie wiem jak to zrobić
2. analizuję czyjeś rozwiązanie + czegoś nie znam doczytuję
3. już wiem jak to działa
4. rozwiąże to sam 2-3 razy
5. zaaplikuję to rozwiązanie do rozwiązania kilku podobnych problemów
   to raczej tego tak łatwo nie zapomnisz.

Oczywiście, że są osoby które sobie z tym radzą lepiej lub gorzej, ale zastanówmy się, czy Ci co sobie z tym nie radzą na pewno powinni być programistami?

Nie wiem skąd te wnioski. Problemy algorytmiczne w stylu LC kończą się zwykle może z 50 linijkami spaghetti, byleby zadziałało. Nijak się ma to do projektowania oprogramowania które da się utrzymywać albo do jakiegoś Clean Code.

Jeżeli w ramach rozwiązywania problemu wytworzyłeś 50 linijek spaghetti to czy Twój kod produkcyjny nie będzie taki sam?
Kod spaghetti powstaje, jeżeli próbujesz rozwiązać jakieś z tego typu zadań bez wcześniejszego zastanowienia się nad problemem np. nie zastanowisz się na początku nad przypadkami jakie mogą wystąpić tylko od razu przystępujesz do programowania.

Jeżeli do leetcode podchodzisz na zasadzie, żeby jakoś zadziałało to pewnie tak samo do kodu produkcyjnego :)

można przyjąć, że w tej pierwszej grupie jest więcej osób dobrych albo bardzo dobrych niż w tej drugiej.

Google jakiś czas temu opublikowało artykuł z którego wynikało że nie ma u nich żadnej korelacji pomiędzy tym jak kandydat skillował leetcoda na rekrutacji a tym jaki jest jego późniejszy performance w pracy.

Poproszę tutaj o linka, bo tak można napisać wszystko :)

CyanApple napisał(a):

Nieznajomość algorytmów objawia się też na wiele innych sposobów:

• złe projektowanie klas
• wynajdywanie koła na nowo
• nieczytanie kodu
• nieznajomość bibliotek
• niepotrzebne komplikowanie kodu
• nieznajomość wielu technik programowania

Absolutnie nic z tej listy nie ma związku z algorytmami. Rzekłbym nawet, że w wielu przypadkach to będą objawy właśnie znajomości algorytmów.
Można też w drugą stronę - dobrze projektować nieskomplikowany kod, znać biblioteki i techniki, i nie znać algorytmów.

@twoj_stary_pijany:

twoj_stary_pijany napisał(a):

Skacząć do FAANGa nie jestem w stanie znać stacka bo oni mają customowego stacka.

Jesteś pewien, że tylko FAANG ma customowego stacka? :> Nie wydaje mi się, robisz tutaj duże uproszczenie.

Wyobraź sobie, że zapłaciłeś 10x więcej za rekrutację, bierzesz jakiegoś kozaka IQ 200 i ten kozak nie potrafi delegować, jest indywidualistą i nie dzieli się wiedzą. Po co Ci taki geniusz skoro masz prostą apkę do napisania? Po 6 miesiącach kozak się zwija bo gdzieś płacą 100 zł więcej. Czy naprawdę pracowity średniak z IQ 120 nie potrafi zrobić tej samej pracy? Przepłaciłeś bo zapłaciłeś za skillset, którego nie potrzebowałeś. Tylko, że nie możesz się chwalić na LI, że macie zajebisty proces rekrutacyjny z liczeniem piłeczek w autobusie. Że też ludzie się wciąż na to nabierają.

Patrzysz bardzo stereotypowo.
Dlaczego zakładasz, że ktoś o IQ 200 jest indywidualistą?
Czy jak to nazwałeś średniak o IQ 120 też nie może być indywidualistą?
Czy to, że ktoś jest średniakiem od razu oznacza, że dzieli się wiedzą? :)
Skąd wiesz, czy przełaciłem za skillset, którego nie potrzebowałem?
Może mój programista zrobił w tydzień to co średniak robiłby przez pół roku i pomimo tego, że zapłaciłem mu za miesiąc więcej to jednak zaoszczędziłem 5 miesięcy pracy średniaka?

WhiteLightning napisał(a):

@japanlofi: @karsa: a w sumie jak powinna wygladac rerkutacja na Devops/SRE ? Bo u mnie zawsze jakos to bylo tak ze wpadalem w QE/perf testy -> tam trzeba bylo ogarniac zestawianie systemu itp. I z czasem okazywalo sie, ze potrzeby spore, a robotnikow malo i w sumie szkoda zebym robil QE jak potrafie inne rzeczy ogarniac.

edit: Link z komentarza od @karsa, moze sie komus przyda: https://github.com/mxssl/sre-interview-prep-guide

Niestety ten link moze sie przydac tylko na jakas bazowa wersje DevOps/SRE/Platform Engineer etc. Fakt, ze na to pierwsze stanowisko mozna nie miec za bardzo doswiadczenia, natomiast kolejne dwa wymagaja zazwyczaj tego pierwszego ;-)

Gdyby mi ktos kazal rekrutowac na to stanowisko to generalnie dopytalbym co robil do tej pory, a wiedzac co sie robi prosto zadac sensowne pytania. Niestety te prezentowane w linku wyzej i podobnych sa bardzo ogolne.

Wracajac do Twojego pytania @WhiteLightning, firmy nie umieja w rekrutacje na to stanowisko, bo z perpsektywicznego HR'owego mozdzka wynika, ze szukaja jednego czlowieka na 5 stanowisk. Jesli masz farta i pozniej przyjdzie ktos tech, kto wie czego szuka to - masz farta. Jesli masz pecha to pozniej przyjdzie beton, ktory nie ma pojecia kogo szuka, ktos mu powiedzial, ze istnieje ktos taki co sie zwie DevOps i on robi generalnie wszystko.

• Pozniej oczekiwalbym, ze ogarnia wirtualizacje.
• Ma solidna wiedze z Linuxa.
• Konteneryzacje, chcialbym zobaczyc jak buduje nawet Dockerowy image z testowa apka, przygotowana wczesniej przeze mnie i udokumentowana w taki sposob aby umozliwic mu odpalenie jej w kontenerze. Do tego punktu oczywiscie pogadalibysmy troche glebiej o konteneryzacji. Zaletach, wadach, security, a nastepnie przechodzimy do...
• Zarzadzania konteneryzacja. Wiadomo, ze mam tu na mysli samego juz Kubernetesa. Ilosc potencjalnych pytan jakie mozna tutaj zadac (UWAGA! Nalezy faktycznie umiec dobrze sformulowac pytanie tak zeby nie bylo niescislosci) jest ogromna. Np.

- Chcialbym wiedziec jakie kroki wykonalby po postawieniu prostego klastra.
- Czy robienie 2 Master Node to dobry czy zly pomysl? Uzasadnij.
- Jak ogarnalby zarzadzanie klastrami w roznych lokacjach / strefach czasowych?
- Jak przeprowadzi update Kubernetesa do nowszej wersji
- Ustawianie limitow - jak ustalac je poprawnie. Dlaczego limit na CPU moze byc zlym pomyslem/lub dobrym - podchwytliwe.
- Jak dziala skalowanie wewnatrz Kubernetesa?
- A̶u̶t̶e̶n̶t̶y̶k̶a̶c̶j̶a̶ Uwierzytelnianie za pomoca Kubernetes identity dla mikroserwisow.
- Wyjasnic graceful shutdown.
- Custom resources - biore od kazdej druzyny po 200zl i slucham panstwa.

Przede wszystkim chcialbym wiedziec z jakimi odmianami k8s pracowal do tej pory

• Wiedza chociaz w teorii odnosnie tego mitycznego SDLC.
• Programowanie: w czym ogarnie jakis task, ktory wymaga napisania kawalka kodu - tutaj poprosilbym o rozwiazanie jakiegos zadania z zycia wzietego - nawet jakiejs uproszczonej wersji.
• Automatyzacja: Terraform i Ansible - lub alternatywy np. Puppet, Chef, Pulumi.
• Gdybym mial dac jakis task to najchetniej wlasnie cos co wymagaloby polaczenia wielu obszarow. Np.
  Zbuduj kontener w ktorym bedziesz miec swoje srodowisko programistyczne np. Python, Go, JS. Nastepnie napisz kod, ktory zbiera z dwoch maszyn dane np. ilosc plikow w wybranych katalogach oraz konkretne dane o maszynie i generuje z tego JSON albo wrzuca to do CSV. Caly proces uruchamiania, zbierania informacji wykonaj za pomoca Ansible. Ewentualnie dorzucilbym zeby kompilacje kodu wykonywal na maszynie z ktorej ma pobierac te dane, a nie w swoim srodowisku.

Zadanie moze wydawac sie kompletnie bez sensu ale ma wiecej sensu niz ganianie kogos zeby pisal algorytmy, ktorych w pracy nie wykorzysta ;-)

• Pogadalbym o budowaniu calego CICD. Czy ma juz z tym doswiadczenie. Budowal/obslugiwal. Jesli tak to z czego ono sie skladalo? Jesli budowal to dlaczego akurat wybral Jenkinsa i sie tym chwali w momencie w ktorym chce pracowac ze mna w zespole - tutaj rekrutacja by sie zakonczyla :D
• Czy zna GitOps? Jesli tak to kiedy ma on sens? Moze zawsze ma sens?
• Rodzaje i strategie Deploymentow?

W zasadzie moglbym tak pisac 5x tyle. Wszystko tez zalezy od tego do czego mialbym zatrudniac tego czlowieka. Jesli mam jakis legacy projekt na starych zabawkach to powyzsza calosc praktycznie nie ma sensu poza moze VM, Linuxem i teoretycznymi koncepcjami.

@CyanApple:

Rozwiązując zadania algorytmiczne moim zdaniem można bardzo podnieść swoje umiejętności progrmistyczne.

Z mojego doświadczenia robienie tego typu zadanek nie wiele mi dawało w porównaniu do robienia prawdziwych projektów.

Spróbuj sobie napisać edytor tekstu, OSa, engine bazki, kompilator, gita, przeglądarkę czy inne podobne

to zyskasz na tym pewnie order of magnitude więcej, bo nie tylko masz tutaj projektowanie złożonych systemów - czego nie ma w LC, a jest wszędzie indziej - od crudów, po złożone systemy informatyczne, a w dodatku tonę wiedzy którą będziesz musiał zdobyć aby móc ruszyć

no i jeszcze - co lepiej brzmi napisałem własny OS czy klepnąłem 50 zadanek na LC

Już nawet nie pisze że taki prawdziwy projekt możesz wystawić na świat, nauczyć się releasować/deployować, przygotowywać installery/paczki, projektować sensowne API, męczyć z breaking changes, a takie kodziki na LC to co najwyżej na GH wrzucić i podrzucać studyntom :P

Rekrutowali wy sie ta do gugla/projektu googla kiedys? EPAM szukal swego czasu ludzi do projektow dla gugla, oni tam wszystko maja customowe, to co maja pytac ze wiosny/sprężyny, jak u nich wszystko inaczej. A pozniej małpki małpuja i jeszcze teorie do teog dorobia

A taki delikwent co zna algorytmy i jest l33t to bardziej niebezpieczny niz ten co nie zna bo bedzie wszedzie robil optymalizacje na listy z length 15 itemow.

Trzeba sobie zdac sprawe z kilku rzeczy, które jednak wyrozniaja FAANG od innych organizacji i nie mowie, że to dobrze albo zle;

1. Customowy stack technologiczny
2. Bardzo dużo zależności i duża zmienność

To powoduje, ze na codzień inzynierowie maja do czynienia z duzą zlozonoscia, z ktora musza sobie radzic, aby byc efektywnym. Pomaga wiedza i doświadczenie, ale przede wszystkim niezbedna jest umiejetnosc szybkiej nauki i adaptacji (tzw. umiejętności poznawcze).

Jak to sprawdzic podczas rekrutacji? Pewnie mozna na wiele spodobow, w FAANG robi sie tak, że daje sie kandydatowi nietrywialny problem do rozwiazania (ale nie tzw. brain teaser, bo udowodniono, że to nic nie wnosi). Algorytmy i struktury danych (LeetCode in gereral) to takie klocki Lego, ktore w zalozenie zna kazdy (mozna sie przygotowac przed interview, wiec nie jest o zaskoczeniem) i trzeba wpasc na rozwiazanie zlozonego problemy z ich uzyciem. Trudnosc jest w problemie, nie w algorytmach, aby sprawdzic jak kandydat atakuje zlozonosc i niepewnosc. Niestety z powodu (1) nie ma sensu pytać „Jak zrobil(a)byś to w Springu?” ;) bardziej „Jakbys zaprojektował(a) Springa, zeby dalo sie zrobic X?”.

Oczywiscie nie kazdy chce sie bawic w algorytmy i to jest OK. Nie kazdy tez chce pracowac z customowym stackiem albo w wielkiej organizacji na tysiace inzynierow - to jest OK.

Jezeli w organizacji nie zachodzi (1) i (2), to widze ograniczony sens w tego typu rozmowach.

@1a2b3c4d5e:

1a2b3c4d5e napisał(a):

Spróbuj sobie napisać edytor tekstu, OSa, engine bazki, kompilator, gita, przeglądarkę czy inne podobne

to zyskasz na tym pewnie order of magnitude więcej, bo nie tylko masz tutaj projektowanie złożonych systemów - czego nie ma w LC, a jest wszędzie indziej - od crudów, po złożone systemy informatyczne, a w dodatku tonę wiedzy którą będziesz musiał zdobyć aby móc ruszyć

no i jeszcze - co lepiej brzmi napisałem własny OS czy klepnąłem 50 zadanek na LC

Już nawet nie pisze że taki prawdziwy projekt możesz wystawić na świat, nauczyć się releasować/deployować, przygotowywać installery/paczki, projektować sensowne API, męczyć z breaking changes, a takie kodziki na LC to co najwyżej na GH wrzucić i podrzucać studyntom :P

Jedno nie wyklucza drugiego.
Nigdzie nie napisałem, że na rozwiązywaniu zadań z leetcode należy poprzestać i że to sprawia, że ktoś jest master programistą.
Moim zdaniem bez znajomości algorytmów i struktur danych nie jesteś w stanie napisać nic z tego co wymieniłeś.

nowy_kret_2 napisał(a):

Rekrutowali wy sie ta do gugla/projektu googla kiedys? EPAM szukal swego czasu ludzi do projektow dla gugla, oni tam wszystko maja customowe, to co maja pytac ze wiosny/sprężyny, jak u nich wszystko inaczej. A pozniej małpki małpuja i jeszcze teorie do teog dorobia

A taki delikwent co zna algorytmy i jest l33t to bardziej niebezpieczny niz ten co nie zna bo bedzie wszedzie robil optymalizacje na listy z length 15 itemow.

Nie trzeba pracować w Google, żeby nie korzystć z Javy i nie pracować w Springu :) To, że Spring jest używany w wielu projektach na prawdę nie znaczy, że we wszystkich i tylko FAANG z niego nie korzysta.

Wszystko z rozsądkiem, a jednak bardziej niebezpieczni są tacy, co nie znają i będą sprawdzać czy element istnieje w bardzo dużej posortowanej tablicy liniowo, albo tacy co będą w pętli uruchamiać setki zapytań do bazy danych.

Znajomość algorytmów jest ważna, a ucząc się rozwiązywać tego typu problemy przy okazji można się nauczyć wielu przydatnych sztuczek programistycznych. Można też nauczyć się dobrych praktyk, nikt nie każe rozwiązywać tego typu zadań pisząc kod spaghetti.

Nie rozumiem tego oporu wiedzy przed poznaniem algorytmów i struktur danych. To są przecież podstawy, które każdy programista powinien znać.

@CyanApple

Moim zdaniem bez znajomości algorytmów i struktur danych nie jesteś w stanie napisać nic z tego co wymieniłeś.

to jest zawsze najważniejszy punkt tych wszystkich śmiesznych dyskusji nt. grindowania a&ds, a mianowicie:

Co to znaczy znajomość A&DS

bo śmiem twierdzić że np. przy edytorze kodu, przeglądarce i kompilatorze to głównie drzewka będą ci potrzebne

ale przecież dla kogoś to nie będzie jakaś super znajomość A&DS, a dla kogoś w sumie to tak.

A zatem zdefiniuj co rozumiesz przez znajomość.