Rekrutacja, rozmowa techniczna, codility - jak to ugryźć?

0

Cześć, obecnie szukam nowej pracy(backend).
Zastanawia mnie jedna rzecz, rozmowy techniczne w korpo nie różnią się zbytnio od siebie. Pytania to jakieś tam podstawy programowania w języku(u mnie Java) wzorce projektowe, podstawy frameworka itp. Jest to na tyle śmieszne że mając kilka rozmów z różnych firm zadawali te same/podobne pytania. Idąc dalej tym tropem mogę wcale nie potrafić programować, wystarczy że nauczę się tych teoretycznych rzeczy i w sumie mnie przyjmą(zgadza się, na wyższe stanowiska nie ma takich pytań i są one bardziej w stronie optymalizacji oraz najlepszego wykorzystania zasobów systemu/maszynki na której stoją). Znowu jeżeli aplikuje się do mniejszych firm/startupów/softwarehousów to pytania są bardziej realne z tym z czym stykasz się na co dzień. Jakie wy macie zdanie na temat rekrutacji technicznych prowadzonych w korpo jak i w innych firmach?

Duża część firm na kolejne etapy daje do rozwiązania zadania z codility. Tutaj pytanie do was, czy wiedza z zakresu algorytmiki i "wymyślania" algorytmów jest naprawdę na tyle ważna na obecnym rynku pracy gdzie mamy mnóstwo bibliotek, które robią to optymalnie(Jasne że dobrze jest widzieć co dzieje się w "środku", natomiast w każdej chwili można to wygooglować i się dowiedzieć)? Czy jest sens robić zadania na platformach typu HackerRank które przygotują Cię do zadań na portalach typu codility?

1

Moje zdanie jest takie, że są to niepełnosprawne procesy rekrutacyjne. Pytania w stylu „opisz wzorzec fabryka” albo „czy jesteś kreatywny” są bezsensowne. Moim zdaniem bierze się to z tego, że przepytują osoby nie znające się na rekrutacji i ewaluacji umiejętności.

Uwierz mi, że nie w każdej firmie tak jest :)

Jeśli chodzi o Codility, to już było o tym 100 wątków - można założyć, że wartość tych testów jest znikoma i trzeba się uczyć specjalnie pod nie. Szczerze mówiąc, nie jest to wysoki poziom, wystarczy umieć przejść po liście, ew. po grafie. Ja widzę w nich parę plusów, ale te same rzeczy można sprawdzić w inny sposób, niekoniecznie chodząc po drzewie binarnym. Na obronę powiem, że nie wymyślasz żadnych algorytmów, tylko składasz rozwiązanie ze znanych algorytmów i struktur danych - czyli myślenie poziom wyżej niż podejście, które zaprezentowałeś.

2
  1. Zapominasz chyba o okresie próbnym ;) Korpo stać na to zeby cię zatrudnić i potem wywalić po miesiącu jak się okaże że jednak ściemniałeś.Co
  2. Co do algorytmiki to juz trochę zależy do tego gdzie chcesz pracować. Do formatek w HTMLu nie trzeba.
  3. Jeśli celujesz w firmy które robią codility to tak, hakies hackerranki sie przydadzą.
0
SharkSamuraj napisał(a):

mogę wcale nie potrafić programować, wystarczy że nauczę się tych teoretycznych rzeczy i w sumie mnie przyjmą

Nie tak, bo wcześniej testowali cię w codziennej pracy rok, dwa lata.
Jeszcze wcześniej żeby ukończyć te IET AGH też musiałeś coś robić i umieć.

Jest to taki styl rekrutacji, taki "hamerykański. Inni, których znamy i znamy ich wymagania, już cię testowali wcześniej więc my im wierzymy bo w sumie to typowej codziennej roboty i tak nikogo lepszego ani nie znajdziemy ani nie potrzebujemy.

Ta robota to nie gwiazdorzenie na boisku i nie szuka się Gortatów, Jordanów klawiatury.

1

najpierw trzeba se w ogole dostac na taka rozmowe, a nie jest to proste jak sie nie studiowalo na agh albo uw

0

To w sumie zapytam jeszcze bo wiem że tam się kilka razy przewijał na forum. Jakie zdanie macie do zadań do zrobienia? Rozumiem że najlepiej sprawdzają realną wiedzę w podanym zakresie. Czytałem również, że jak ktoś ma rodzinę to krzywo patrzy na tego rodzaju etapy rekrutacji. Natomiast jak ktoś jest ambitny to zrobienie takiego zadania wychodzi na plus bo może się przy okazji czegoś nauczyć :)

0

Chyba sam sobie odpowiedziałeś na to pytanie - każdy ma inny stosunek :)

1
SharkSamuraj napisał(a):

Duża część firm na kolejne etapy daje do rozwiązania zadania z codility. Tutaj pytanie do was, czy wiedza z zakresu algorytmiki i "wymyślania" algorytmów jest naprawdę na tyle ważna na obecnym rynku pracy gdzie mamy mnóstwo bibliotek, które robią to optymalnie(Jasne że dobrze jest widzieć co dzieje się w "środku", natomiast w każdej chwili można to wygooglować i się dowiedzieć)?

Nie wszystko da się "wygooglować". Co nie zmienia faktu, że większość firm ma idiotyczny proces rekrutacyjny oparty o rozwiązywanie problemów, których w codziennych zadaniach nawet nie ujrzysz. Najlepsze są jednak oferty gdzie widać po opisie, że praca opiera się o wiedzę z zakresu architektury, a nie logiki, a na procesie dostajesz do rozwiązania zadanie typu hackerrank.

SharkSamuraj napisał(a):

Czy jest sens robić zadania na platformach typu HackerRank które przygotują Cię do zadań na portalach typu codility?

To zależy czego oczekujesz od pracy. Jak chcesz siedzieć i rzeźbić w algorytmach, optymalizacji to sens jakiś tam jest. Natomiast sporo z tych zadań nijak się ma do realnych zadań w pracy codziennej.

SharkSamuraj napisał(a):

To w sumie zapytam jeszcze bo wiem że tam się kilka razy przewijał na forum. Jakie zdanie macie do zadań do zrobienia? Rozumiem że najlepiej sprawdzają realną wiedzę w podanym zakresie. Czytałem również, że jak ktoś ma rodzinę to krzywo patrzy na tego rodzaju etapy rekrutacji. Natomiast jak ktoś jest ambitny to zrobienie takiego zadania wychodzi na plus bo może się przy okazji czegoś nauczyć :)

Eeeee... Co ma jedno do drugiego? Bez rodziny ambitny, a z rodziną nie? :-)
Kwestia osobistych preferencji. Jak firma ma sensowny proces rekrutacyjny i daje zadanie nad którym nie trzeba siedzieć dniami + można dostać na nie więcej czasu to czemu nie.

Kolega pracuje w SH. Wszyscy dostają jedno zadanie - napisz CRUD. Oczywiście są tam jakieś wytyczne. Z racji tego, że to wytwórnia softu i projekty często się zmieniają to zadanie jest bardzo sensowne. I wbrew pozorom potrafią przychodzić naprawdę konkret rozwiązania lub też totalne faile.

Wniosek z tego taki, że nie zawsze trzeba robić sobie durny proces rekrutacyjny z którego sporo ludzi rezygnuje. W sumie się nie dziwię, bo gdybym aplikował do 5 firm i każda kazałaby mi przechodzić przez jakiś idiotyczny proces to chyba bym ograniczył to tylko do jednej tej na której najbardziej mi zależy.

2
SharkSamuraj napisał(a):

Jakie wy macie zdanie na temat rekrutacji technicznych prowadzonych w korpo jak i w innych firmach?

Zdanie mamy takie, ze jak nam zalezy na pracy w danej firmie, to sie przygotowujemy pod proces rekrutacyjny, ktory ta firma przeprowadza.

W standardowych korpo maja zazwyczaj 1h, zeby cie przepytac, wiec nie sa wstanie zadac ci jakis nadmiernie skomplikowanych pytan, ot przelatuja po wszystkim po trochu, co im potrzeba w projekcie. Jak zle trafia, to cie zwolnia, albo wrzuca w jakis syf.
FANG lubia specyficzny rodzaj pracownikow, moga przebierac w kandydatach, to sobie trzepia po kilka godzin z algorytmow.
Firmy wymyslaja jakis sposob rekrutacji, jakby byl nieskuteczny i nieodpowiedni dla nich, to by z niego zrezygnowaly.

2

Tak między nami to taka rekrutacja jaką opisujesz służy dokładnie jednemu celowi - chcą zobaczyć człowieka i z nim pogadać zanim go zatrudnią, a głupio od razu kogoś zaprosić na piwo.
Dlatego dostajesz zaproszenie na rozmowę, gdzie dostaniesz kilka pytań aby upewnić się, że chociaż widziałeś kod na żywe oczy, ale 90% wartości takiej rozmowy to są wrażenia artystyczne.
Po prostu takie rozmowy traktuj nie jako rozmowy techniczne, tylko sprawdzenie czy spełniasz minimalne kryteria twarde + czy dobrze Ci z oczu patrzy.
W przypadku juniora jakaś rekrutacja techniczna ma sens, ale od mida w górę to musiałbyś mieć na prawdę dobre testy aby określić poziom kandydata.

Ostatnio miałem już 2-3 rozmowy, gdzie mimo rozmowy z osobami technicznymi nie padło żadne pytanie techniczne, a jedynie pogadaliśmy sobie o projektach i "co tam w życiu pan robił".

0
hadwao napisał(a):

Po prostu takie rozmowy traktuj nie jako rozmowy techniczne, tylko sprawdzenie czy spełniasz minimalne kryteria twarde + czy dobrze Ci z oczu patrzy.

Rozmowa ma sprawdzić, czy nie szukasz hiper-projektu, a tym co się w większości przypadków robi w polskich warunkach, znudzisz się śmiertelnie po miesiącu, może dwóch.
Dlatego nawet na juniora (teraz jest COVID i się pozmieniało) w korpo przyjmowano magistrów nauk przyrodniczych, bo ukończenie studiów to raz, a dwa, rokowało, że będą zadowoleni z tego co im dadzą i nie będą zmieniać od razu pracy.
W rekrutacji przyjęcie kandydata wybitnego, nawet najlepszego w zespole, który odejdzie za kilka miesięcy to porażka.

2

Pytanie o wzorce ma sens dla juniora, bo pozwala określić, jak dużo "suchej" wiedzy kandydat posiada, ile czasu zajmie mu wdrożenie się w projekt (oczywiście to ciągle strzelanie w ciemno, ale w wielu przypadkach wystarczy) i czy będzie musiał odkrywać każde koło na nowo, czy może raczej da się z nim pogadać jakimś lingua franca.

Rekrutacja na pozycję powyżej juniora to w większości przypadków bzdura. Dla ludzi z doświadczeniem takie pytania mogą mieć sens, o ile będziemy pytali o wzorce architektury, wdrożeń, jakieś najlepsze praktyki z robienia post mortem itp, ale to i tak sprowadza się do doświadczenia, bo na wyższym poziomie rozwiązania "wymyśla" się rzadziej i nie ma jednego przepisu na sukces. Osobiście czekam, aż branża dorośnie na tyle, że będzie można ufać doświadczeniu kandydatów patrząc na CV, bo jeżeli ktoś pracuje 5+ lat, to pewnie daje sobie radę z inżynierią oprogramowania. Oczywiście zawsze można się do czegoś dowalić ("bo on klepie repozytorium generyczne, jak zwierzę!" albo "gość mockuje w testach, jak w XX wieku"), ale rozsądni ludzie raczej zdają sobie sprawę, że to nie o to chodzi.

Wszelkiej maści algorytmy, klepanie na tablicy czy codility uznaję za mało sensowne. Każda firma mówi, że nie trzeba rozwiązać zadania, liczy się sposób podejścia do problemu, rozbicie na kawałki i myślenie na każdym kroku, ale ja w to nie wierzę — zbyt dużo razy byłem po drugiej stronie i widziałem, co ludzie robią, żeby się na to nabrać. Jak nie rozwiążesz zadania wystarczająco dobrze (co w 90% przypadków oznacza rozwiązanie poprawne i w dobrej złożoności), to choćbyś naprawdę kapitalnie myślał, to odpadniesz. O ile jeszcze rozumiem Codility jako etap wstępny (bo "masa amatorów pcha się do zabawy"), to ręce mi opadły, gdy kiedyś miałem "onsite" przez Internet i druga strona chciała to robić właśnie przez tę platformę. Kompiluję kod, autocompletion nie ma, nie pamiętam, czy tablica ma Length, Size, Count czy coś innego, kompilator krzyczy, rekruter też nie pamięta i mówi, że sprawdzi w dokumentacji, a ja siedzę i marnuję czas na wszystkie permutacje znanych mi nazw.

Jak chodzi o wiedzę informatyczną, to też jest kiepsko. Jeszcze nie pamiętam rozmowy, żeby jakaś wiedza "naukowa" mi się przydała, kiedyś nawet byłem podjarany, bo rekruter pytał mnie, dlaczego reference counting w GC nie zwolni cykli i jak to się ma do problemu stopu, ale potem zorientowałem się, że gość myśli, że Java stosuje RC i w jego mniemaniu powiedziałem, że "Java nie zwolni cykli", więc drążył. Ja produkowałem się z maszyny Turinga, optymalizacji kompilatora, sposobów na rozwiązanie problemu a gość myślał, że "gość klepie tyle lat, a nie wie, że GC sobie radzi z cyklami bez problemu, no po prostu debil". Osobiście zadaję takie "jednostrzałowe" pytania w stylu "co to jest anomalia Belady'ego" albo "ile wynosi kwant czasu w Windowsie", ale to na zasadzie szybkiego sprawdzenia, czy kandydat ma gdzieś coś ciekawego do powiedzenia, a jak nie ma pojęcia, o co chodzi, to nic się nie dzieje.

Osobiście całe te rekrutacje traktuję jako grę. Reguły są takie, że trzeba coś tam umieć w Codility, w miarę szybko i sprawnie odpowiadać, być pewnym siebie, jak to się opanuje, to potem już w miarę z górki. Tylko rekrutacja nie powinna być czymś, co robi się raz na kilka lat przy zmianie pracy, tylko coś, na co chodzi się raz w miesiącu dla rozrywki (czy to jako kandydat, czy jako rekruter z drugiej strony). Wtedy bardzo łatwo jest trzymać wiedzę na świeżo.

0

Dzięki wielkie wszystkim za odpowiedzi wyczerpujące i te krótkie :). Dodało mi to trochę skrzydeł i zmobilizowało. Także jeszcze raz dzięki i miłego dnia :)

0

Codility jest dobre, bo polskie, i tyle, można docenić to jako sukces komercyjny produktu z nad Wisły (z drugiej strony i tak HackerRank wydaje się popularniejszy za granicą), tym niemniej jakoś to słabe jest w mierzeniu realnych umiejętności programistycznych przydatnych w pracy.

To gra na czas przede wszystkim, gdzie masz te 2, 3 kwadranse na wymyślanie trochę w ciemno idealnego rozwiązania. I co tu można zrobić. Albo trzeba myśleć z prędkością błyskawicy, albo trzeba umieć szybko googlować rozwiązań, albo trzeba nauczyć się na pamięć stosowania typowych algorytmów. I wydaje mi się, że to trzecie podejście jest najpopularniejsze - ludzie specjalnie trenują do tego Codility, Hackerrank itp.

Moim zdaniem apki typu Codility powinny być reklamowane bardziej jako narzędzia edukacyjne, takie zagadki programistyczne, które mają cię zmotywować do nauki algorytmów, a nie jako coś, co ma rekrutować ludzi do pracy programisty. W prawdziwej pracy ma się więcej czasu na przemyślenie rozwiązania, a nie, że w pół godziny nie zrobisz taska i już cię zwalniają xD

Ja produkowałem się z maszyny Turinga, optymalizacji kompilatora, sposobów na rozwiązanie problemu a gość myślał, że "gość klepie tyle lat, a nie wie, że GC sobie radzi z cyklami bez problemu, no po prostu debil".

To tak jak kiedyś gościu mnie zapytał, jak dokładnie działa AJAX - i jakoś tak zadał pytanie, że zrozumiałem, że chodzi mu o to, żebym powiedział krok po kroku - więc ja się produkuję, mówię o protokole HTTP, że klient wysyła requesta, a serwer odpowiada, że są nagłówki HTTP itp. itd. I produkuję się, produkuję - a potem gość do mnie "A używał pan tego kiedyś?". Do dzisiaj mam facepalm :D No nie, proszę pana, wyczytałem z wikipedii formułki, a nigdy nie używałem AJAXa (tak mu nie powiedziałem, ale przypuszczam, że tak mógł pomyśleć. Może trochę mój błąd, że za głęboko wszedłem w temat).

0
LukeJL napisał(a):

Moim zdaniem apki typu Codility powinny być reklamowane bardziej jako narzędzia edukacyjne, takie zagadki programistyczne, które mają cię zmotywować do nauki algorytmów, a nie jako coś, co ma rekrutować ludzi do pracy programisty.

UJ TCS
https://forum.tcs.uj.edu.pl/t/codility-szuka-jurorow/5593

0
SharkSamuraj napisał(a):

mogę wcale nie potrafić programować, wystarczy że nauczę się tych teoretycznych rzeczy i w sumie mnie przyjmą

W sumie nie jest to takie wcale bez sensu:

Programista powinien być bystry, umieć zauważać zależności i rozwiązywać problemy. Jeśli kandydat nauczy się przechodzić rozmowy kwalifikacyjne, to znaczy, że rozwiązał pewien problem, umie szukać informacji w internecie i jest duże prawdopodobieństwo, że będzie dobrym programistą (lub po prostu normalnym programistą)

2

Na półce mam "The algorithm design manual". Raz po raz zajrzę do jakiegoś rozdziału. Rozwiążę kilka zadań dla sportu. Wielu konceptów z tamtych zagadnień nie pamiętam bo w codziennych realiach są zbyteczne. Jak która firma jest nastawiona na zatrudnianie sportówców.... proszę bardzo, mamy wolny rynek.

1 użytkowników online, w tym zalogowanych: 0, gości: 1