Siema,
Tak się składa, że wolę rozwiazywać sensowne zadanie domowe, choćby miało zająć tydzień, niż w 40min klepać nikomu niepotrzebny algorytm.
Czy wiecie/spotkaliscie sie/macie doswiadczenie z firmami ktore takie zadania zadaja w Warszawie? Chodzi o rekrutacje na Mida.
Pozdrawiam
A do czego komuś ma być potrzebne "sensowne zadanie domowe"?
krsp napisał(a):
A do czego komuś ma być potrzebne "sensowne zadanie domowe"?
Można sprzedać. Dajesz aplikującemu nanoserwis do wyklepania jako zadanie domowe i po miesiącu masz już z 100 nanoserwisów gotowych do uruchomienia na produkcji
Sensowne nie wiem. Często jest to naklepanie jakiegoś prostego CRUDa w webówce.
Allegro cos tam miało z odpytywaniem githubowych repozytoriów.
imo to jedno i drugie jest średnie, i ogólnie rekrutacje uważam za męczące i nie mające wiele wspolnego z rzeczywistoscia.
Faktycznie robienie takiego zadania potrafi znacząco rozwinąć (zwłaszcza merytoryczny feedback pomaga), aczkolwiek nie stawiałbym tego jak cel samym w sobie - celem procesu rekrutacyjnego jest przetestowanie sowich możliwości i zbadanie, ile się jest wart na rynku pracy (a także przyjęcie jakiejś oferty, jeśli się chce).
Jeśli tak czy inaczej chcesz się przetestować teraz, to możesz aplikować np do SoftwareMill - oni co prawda pracują 100% zdalnie a nie w Wawie, ale jak się u nich rekrutowałem to było zadanie do zrobienia takie na kilka dni.
Brut napisał(a):
Tak się składa, że wolę rozwiazywać sensowne zadanie domowe,** choćby miało zająć tydzień**, niż w 40min klepać nikomu niepotrzebny algorytm.
Trzeba mocno nie szanować swojego czasu. Coś takiego odpowiada darmowym dniom próbnym w gastro.
Ogólnie podoba mi się taki sposób weryfikacji umiejętności, pod warunkiem, że jest to mały fragment, a nie cała aplikacja z setką wymagań do napisania. Zresztą ogólnie lepiej jest, gdy aplikacja jest dostarczona, a trzeba coś dodać/zmodyfikować, niż pisać od zera, bo pisanie od zera jest bardziej czasochłonne, a niczego sensownego nie sprawdza, a modyfikacja rozwiązania bardziej odpowiada rzeczywistości, gdy trzeba czyjś kod przeczytać, żeby coś dopisać.
Z tymi zadaniami to uważaj, ja akurat wolę algo, bo idziesz na rozmowę piszesz i tyle, a nie siedzisz w domu i wolnym czasie piszesz im cruda za darmo.
Chodzi dokładnie o to co napisał @Pinek, ze zrobienie takiego zadania więcej mnie nauczy, a w rezultacie i tak strace mniej czasu, niz na przygotowanie do rekrutacji z data structures. Jesli takie zadanie domowe ma duzo wspolnego z rzeczywistoscia to dodatkowy plus.
Po prostu kwestia preferencji, ja nie piszę na codzień agorytmow dfs/bfs z kolegą stojącym obok i patrzącym mi na ręce i nie jestem pewien na ile sprawdza to umiejetnosci kandydata a na ile pozwala przepuscic jeden rodzaj programistow do nastepnego etapu rekrutacji.
Nie wiem skąd założenie, że zadanie domowe jest sensowne i co w twoim mniemaniu znaczy sensowne zadanie domowe.
szarotka napisał(a):
takie zadanko zrobi każdy
Skąd to przeświadczenie? Niektórzy oleją bo nie będą mieli czasu / motywacji, niektórzy tak naprawdę to dopiero wcześni juniorzy i jednak się wycofają...
Robiłam kiedyś zadanko - crud w springu - czy sensowne? Dla mnie nie, bo pisać cruda można się nauczyć w kilka dni
Ja wiem, że tu na forum ludzie uwielbają nazywać CRUDem wszystko, co pozwala na zmienianie jakichś danych i ich jakiś odczyt... ale jeśli w takim zadaniu te dane jakoś się filtruje / mapuje, to już powstaje jakaś logika, programista ma szeroki wybór co do tworzenia struktury pakietów i klas, pokazuje czy zadbał o przypadki brzegowe, czy mysli o security, jakie API wystawia, jak pisze testy (i czy w ogóle je pisze), w jaki sposób trzyma propertiesy, czy myśli o logowaniu (w sensie logi, nie security), czy przygotował jakieś sensowne README dla użytkownika, czy dodał swaggera...
Więc come on, ale że (komercyjnie)
cruda można się nauczyć w kilka dni
to się nie zgadzam.
Ogólnie rekrutacje programistów trochę przypominają sytuacje jakby architekt albo budowlaniec dostali na rozmowie kwalifikacyjnej klocki lego i kazali im budować dom...
szarotka napisał(a):
takie zadanko zrobi każdySkąd to przeświadczenie? Niektórzy oleją bo nie będą mieli czasu / motywacji, niektórzy tak naprawdę to dopiero wcześni juniorzy i jednak się wycofają...
W sensie każdy, komu zależy i komu się chce. To że część kandydatów oleje, to fakt. Aczkolwiek firma ma stosunkowo wysokie widełki na rynku, więc raczej ludzie znajdują motywację :)
Ja wiem, że tu na forum ludzie uwielbają nazywać CRUDem wszystko, co pozwala na zmienianie jakichś danych i ich jakiś odczyt... ale jeśli w takim zadaniu te dane jakoś się filtruje / mapuje, to już powstaje jakaś logika, programista ma szeroki wybór co do tworzenia struktury pakietów i klas, pokazuje czy zadbał o przypadki brzegowe, czy mysli o security, jakie API wystawia, jak pisze testy (i czy w ogóle je pisze), w jaki sposób trzyma propertiesy, czy myśli o logowaniu (w sensie logi, nie security), czy przygotował jakieś sensowne README dla użytkownika, czy dodał swaggera...
Zgadzam się absolutnie. Mój CRUD był ok, CRUD mojego kumpla był mega wypasiony, widziałam też gorsze CRUDy, kończyło się tym, że jeżeli ktoś spełniał normy: działa, są testy, jest względnie clean to był 2. etap - rozmowa.
Generalnie z mojego doświadczenia zadania nie mają na celu rekrutacji, tylko odrzucić osoby, które zrobią jakiś WTF.
Rekrutacje takie są dlatego że paniom z HR nie chce się chociaż pobieżnie zweryfikować wysłanego CV. Jak ktoś jest midem (czyli ma ponad 5 lat expa jak na warunki PL) i nie zmieniał firmy co kwartał to i tak ogarnie 99% tego szamba co pływa na rynku. Jak jest wolny to się po prostu dzwoni z prośbą o referencje do poprzedniego pracodawcy. Resztę powinna załatwić rozmowa.
loza_wykletych napisał(a):
Jak jest wolny to się po prostu dzwoni z prośbą o referencje do poprzedniego pracodawcy.
Polacy to naród mściwych ludzi, a odejście z pracy jest traktowane jak zdrada, wiec wątpię czy referencję będą dobre :(
Rekrutacje takie są dlatego że paniom z HR nie chce się chociaż pobieżnie zweryfikować wysłanego CV.
Aż nie chce się tego komentować, ale panie z hr weryfikują cv i nie wysyłają zadania do każdego żeby nie marnować czasu programistów, którzy uczestniczą w rekrutacji
Jak ktoś jest midem (czyli ma ponad 5 lat expa jak na warunki PL) i nie zmieniał firmy co kwartał to i tak ogarnie 99% tego szamba co pływa na rynku.
Nie zgadzam się. Ktoś kto się zasiedział i zna tylko jeden sposób kodzenia (tak jak od studiów w tej firmie się robiło), jeden framework, często potrzebuje czasu i zaangażowania żeby poznać inne technologie. Wiadomo, że z taką podstawą ogarnie, ale nie sam, jak go wrzucą do projektu. Generalnie ocenia się kandydata przez pryzmat doświadczenia (w tym lat), ale głownie tego co robił i zna a nie że masz 5 lat na papierku, bierzemy.
imo w większości przypadków powinno starczyć spojrzenie w CV i pogadanie godzinki.
Pracuje X lat w zawodzie, bardzo sensowne pytać mnie totalnych podstaw jakbym kłamał w CV i tak naprawde pracował w biedronce.
Pinek napisał(a):
Ja wiem, że tu na forum ludzie uwielbają nazywać CRUDem wszystko, co pozwala na zmienianie jakichś danych i ich jakiś odczyt... ale jeśli w takim zadaniu te dane jakoś się filtruje / mapuje, to już powstaje jakaś logika, programista ma szeroki wybór co do tworzenia struktury pakietów i klas, pokazuje czy zadbał o przypadki brzegowe, czy mysli o security, jakie API wystawia, jak pisze testy (i czy w ogóle je pisze), w jaki sposób trzyma propertiesy, czy myśli o logowaniu (w sensie logi, nie security), czy przygotował jakieś sensowne README dla użytkownika, czy dodał swaggera...
No ale przemapowywanie tego do śmego, setupowanie logów czy security akurat się przewija zawsze i wszędzie (przynajmniej w webowym/serwerowym backendzie) i zrobienie tego to żadne osiągnięcie - to po prostu ma być i tyle, a w firmowe "gusta" odnośnie np. nazewnictwa własnych propertiesów, formatowania logów, ogarnięcia tracingu etc i tak możesz się nie wstrzelić. Chyba jeden sposób na wyróżnienie się, to zrąbanie tego w widowiskowy sposób :D
Jak będziecie chcieli aplikować do wymarzonej firmy, to znajdziecie czas na zrobienie zadania, gwarantuję :)
Nie bronię zadań domowych - sprawdzanie ich zajmuje sporo czasu.
Charles_Ray napisał(a):
Jak będziecie chcieli aplikować do wymarzonej firmy, to znajdziecie czas na zrobienie zadania, gwarantuję :)
Ja od roku się zbieram i chyba dalej mi się nie chce
Charles_Ray napisał(a):
Jak będziecie chcieli aplikować do wymarzonej firmy, to znajdziecie czas na zrobienie zadania, gwarantuję :)
Jak kraść to księżniczki, jak kochać to miliony *Proszę mnie nie poprawiać, że to chyba inaczej leciało
*
Jak zachwalać swoją ofertę to mówić o niej "wymarzona".
Nie ograniczać się do "u nas nowoczesne technologie, projekty rozwojowe".
Ale co by nie mówić to rozwiązywanie zadań pod presją czasu i dużą ilością stresu występuje także w zwykłej pracy gdy np, wywali nam się deploy i musimy szybko naprawić skrypty bo Grażyna nie może zamówić karmy dla kota swojej cioci o strony wujka Zenka, więc uważam, że takie rozwiązywanie zadań algorytmicznych na rekrutacjach to też w pewnym sensie ważna próba psychiczna dla pracownika która pokazuję czy potrafi myśleć pod presją czasu i obowiązku przed nim stojącym
Ja tam sam nie wiem co lepsze. Algorytmiczne są wg mnie spoko jako wstępne selekcja, o ile nie jest przekombinowany poziom trudności i jakiś sensowny czas (w sensie nie za długi) np 1h. Wtedy wchodzisz w linka pierwszy look i wiesz czy chce ci się robić czy nie. Crudy można maglować bez końca, zawsze jest coś do poprawy.
Osobiście nie lubie robić algorytmów przy rekruterach, wtedy raczej wolę już raczej jakieś biznesowe zadania.
Kiedyś miałem kontakt do firmy która rekrutuje zlecając dwu-tygodniowe "zadanka" z udostępnieniem kodu i przeniesieniem praw z tego co pamiętam.
Chyba byli ze Szczecina. Urządzają nawet grupowe telekonferencje jak się nie chcesz zgodzić.
Wtedy nie wiedziałem, że ktoś by się dał na to nabrać, ale jak znajdę ten telefon to podeślę.
vpiotr napisał(a):
Kiedyś miałem kontakt do firmy która rekrutuje zlecając dwu-tygodniowe "zadanka" z udostępnieniem kodu i przeniesieniem praw z tego co pamiętam.
Znam właściciela agencji reklamowej który ma non stop otwarte rekrutacje projektowo-zadaniowe.
Najczęściej dla "grafików komputerowych" ale dla programistów front-end też są zadania.
Zatrudnia (umowy śmieciowe ale "zatrudnia") ekipę współpracowników zdalnie, 3 osoby w biurze (licząc z sekretarką).
Biznes dobrze mu idzie, klientom zawsze przedstawia co najmniej trzy projekty, nie raz pięć.
Gdyby miał płacić współpracownikom za wszystkie mock-projekty to nie byłby konkurencyjny cenowo, zatem systematycznie "rekrutuje" i daje zadania. Ludzie siedzą całymi dniami i nocami, dłubią, kodzą. Idą na prezentację szkice, źródłowe pliki grafików, "wyglądające prawie jak gotowe" produkty webowe.
Nie potępiam, nie ganię. Bywało, że projekty wyjątkowo zdolnego grafika od razu zostały zaakceptowane przez klienta, wtedy oczywiście zapłacił za wykorzystany pomysł, Kiedy klientowi spodoba się tylko mniejszy fragment, wtedy nie płaci rekrutowanym, z wykorzystaniem "pomysłu" pracują stali (współ)pracownicy
szarotka napisał(a):
Nie wiem skąd założenie, że zadanie domowe jest sensowne
Zadanie domowe polega na stworzeniu kompletnej, działającej aplikacji, czyli na tym samym, na czym polega praca programisty.
Zanim zacząłem weryfikować kandydatów lata temu, to też myślałem, że jak ktoś ma w CV 5+ lat doświadczenia, to na rozmowie będzie wysoki poziom, gadanie o jakichś ciekawych historiach, nieszablonowych rozwiązaniach, dyskusjach o sensie istnienia, racji bytu i celu egzystencji.
Potem zacząłem weryfikować kandydatów i zrozumiałem, że zadanie "odwróć tablicę intów w miejscu" nie jest trywialne. Ba, ludzie wykładają się na prostszych rzeczach, jeden kandydat tak się "zestresował", że aż zapomniał, jak się neguje liczbę. Najlepszą historię miałem, jak w połowie rozmowy telefonicznej kandydat stwierdził, że musi przeparkować samochód. Poszedł i już nie wrócił :(
Tylko oni wszyscy mieli jakieś sensowne CV i w pracy dawali radę przez lata, więc ja już nie wiem, czy to odwracanie tablicy jest takie trudne, czy może jednak oni nie potrafili programować. To oczywiście nie jest wada, jak się startuje na architekta, to już nie trzeba ruszać kodu i można machać rękami jak na rekrutacji, ale jak się jednak uderza na zwykłego kodera, to jednak dobrze jest ogarniać takie rzeczy. Ale po wielu latach weryfikowania mam taki wniosek, że rekrutacja to strata czasu. Algorytmika na tablicy może i pokazuje myślenie, ale nie pokazuje kodowania, potem taki gość ma 10+ lat doświadczenia i nie ogarnia generyków. Pytanie o frameworki nie ma sensu, bo od tego jest dokumentacja, poza tym to się tak często zmienia, że naprawdę nie chce się tego zapamiętywać. A zadanie domowe to już szczyt marnowania czasu, ludzie na review potrafią dyskutować kilka dni o nazwach zmiennych czy innych głupotach, to przecież takie zadanko po godzinach będzie loteryjką polegającą na "wstrzeleniu się w gust". Pytania z informatyki też do niczego, bo kto by znał efekt Rungego, anomalię Belady'ego, albo różnice między architekturą von Neumanna a Harvarda - ani to potrzebne w korpopracy, ani jakoś specjalnie zachęcające do przemyśleń.
Jak dla mnie rekrutacja powinna trwać godzinkę. Dla kodera pogadać o najfajniejszych projektach, największych wtopach, ogólnym podejściu do rozwiązywania problemów, zapytać o nazwę jakiegoś debuggera, profilera, narzędzia do load testów, HTTP proxy czy coś, dla architekta to samo, tylko na poziomie architektury i gotowe. Jak kandydat jest dobry, to sam powie nam wszystkie buzzwordy i zaprezentuje lingua franca.
Afish napisał(a):
Najlepszą historię miałem, jak w połowie rozmowy telefonicznej kandydat stwierdził, że musi przeparkować samochód. Poszedł i już nie wrócił :(
No to jest taki moment, w którym nawet ja zacząłbym się zastanawiać, co ze mną jest nie tak. ;)
Tylko oni wszyscy mieli jakieś sensowne CV i w pracy dawali radę przez lata, więc ja już nie wiem, czy to odwracanie tablicy jest takie trudne, czy może jednak oni nie potrafili programować.
Nie wiem jak inni, ale ja czasami mam tak, że jak dostanę jakieś proste pytanie, to się gubię, bo zaczynam doszukiwać jakichś haczyków.
Poza tym, sam klimat i forma rozmowy ma wpływ na odpowiedzi, ja kiedyś byłem tak przesłuchiwany, że w końcu powiedziałem, że konstruktor nie może być prywatny.
A zadanie domowe to już szczyt marnowania czasu, ludzie na review potrafią dyskutować kilka dni o nazwach zmiennych czy innych głupotach, to przecież takie zadanko po godzinach będzie loteryjką polegającą na "wstrzeleniu się w gust".
I bardzo dobrze!
Bo jeśli jakaś firma wymaga wstrzeliwania się w gust i prowadzone są w niej wielodniowe rozmowy o nazwie zmiennej, to ja nie chcę tam pracować. A sensowne zadanie z sensownym review/pair programming później pozwala stwierdzić, czy kandydat potrafi napisać działający, testowalny i rozszerzalny kawałek kodu i obronić swoje decyzje.
Oczywiście, jeśli firma nie potrafi wymyślać i weryfikować takich zadań, to to się nie uda, ale jak pisałem - to jest zysk dla mnie, jako kandydata.
Jak dla mnie rekrutacja powinna trwać godzinkę. Dla kodera pogadać o najfajniejszych projektach, największych wtopach, ogólnym podejściu do rozwiązywania problemów, zapytać o nazwę jakiegoś debuggera, profilera, narzędzia do load testów, HTTP proxy czy coś, dla architekta to samo, tylko na poziomie architektury i gotowe. Jak kandydat jest dobry, to sam powie nam wszystkie buzzwordy i zaprezentuje lingua franca.
No ja ostatnio właśnie miałem taką rozmowę (wcześniejsze kilka razy to były zadania). Efekt jest taki, że pieniądze się niby zgadzają, ale bez interfejsu nie może być klasy, do przechowywania 30 obiektów po kilkunaście bajtów danych tworzone jest readonly struct, bo "klasy są niewydajne" (ale już to, że coś używane jako "baza danych" ma transfer 10kB/s to niewydajne nie jest), a do tego stawiają spację przed każdym nawiasem otwierającym w definicji i wywołaniu metody.
Tak więc, generalnie nie polecam, sama taka rozmowa to za mało, żeby wykryć patologie.
somekind napisał(a):
No to jest taki moment, w którym nawet ja zacząłbym się zastanawiać, co ze mną jest nie tak. ;)
Jak odchodziłem z jednej firmy, to szukałem kogoś na swoje miejsce i pytałem o rzeczy, które robiłem w ostatnim tygodniu pracy. Kandydat miał ochotę wyjść, jak pytałem, czy kiedyś dekompilował binarki dotnetowe, implementował czas Lamporta, analizował zrzuty pamięci czy podglądał ruch sieciowy przez proxy TLS. Oburzenie trochę mu przeszło, jak pod koniec wyjaśniłem mu, że dokładnie takie rzeczy będzie musiał robić. Najwyraźniej pytanie o rzeczy praktyczne też jest kiepskie.
Nie wiem jak inni, ale ja czasami mam tak, że jak dostanę jakieś proste pytanie, to się gubię, bo zaczynam doszukiwać jakichś haczyków.
Poza tym, sam klimat i forma rozmowy ma wpływ na odpowiedzi, ja kiedyś byłem tak przesłuchiwany, że w końcu powiedziałem, że konstruktor nie może być prywatny.
Przesłuchiwania nie robię, a przynajmniej jeszcze nikt z kandydatów nie dał mi takiego feedbacku. Ja im nawet wysyłałem pytania przed rozmową, żeby wiedzieli, z czego się przygotować. Może mam skrzywione podejście, bo nie uważam, że napisanie kawałka kodu na tablicy jest jakoś stresujące, ale jeżeli ktoś tak ma, to może lepiej nad tym popracować w wolnym czasie? Pójście na rozmowę raz w miesiącu nie jest jakoś strasznie wymagające, poza tym raczej wiadomo, że na rekrutacjach trafia się kodowanie na kartce, no i zawsze można zapytać osobę z HR, jak będzie wyglądał proces.
I bardzo dobrze!
Bo jeśli jakaś firma wymaga wstrzeliwania się w gust i prowadzone są w niej wielodniowe rozmowy o nazwie zmiennej, to ja nie chcę tam pracować. A sensowne zadanie z sensownym review/pair programming później pozwala stwierdzić, czy kandydat potrafi napisać działający, testowalny i rozszerzalny kawałek kodu i obronić swoje decyzje.
Tak, tylko to zajmuje masę czasu. Dla kandydata jest to problem, szczególnie w przypadku procesu na miejscu, bo trzeba dojechać, klepać jakieś tam crudy, do tego ludzie potem narzekają, że nie mają swojego IDE, klawiatury, skrótów klawiszowych, swojego krzesełka i kubeczka A dla rekruterów też jest to masa czasu, która w większości jest zmarnowana, bo większość kandydatów się nie nadaje.
No ja ostatnio właśnie miałem taką rozmowę (wcześniejsze kilka razy to były zadania). Efekt jest taki, że pieniądze się niby zgadzają, ale bez interfejsu nie może być klasy, do przechowywania 30 obiektów po kilkunaście bajtów danych tworzone jest readonly struct, bo "klasy są niewydajne" (ale już to, że coś używane jako "baza danych" ma transfer 10kB/s to niewydajne nie jest), a do tego stawiają spację przed każdym nawiasem otwierającym w definicji i wywołaniu metody.
Rekrutacja to proces obustronny, kandydat też ma prawo dowiedzieć się o firmie jak najwięcej. Jeżeli dla Ciebie ważne są spacje przed nawiasami, to mogłeś poprosić o przejrzenie ich kodu.
Tak więc, generalnie nie polecam, sama taka rozmowa to za mało, żeby wykryć patologie.
Dla mnie proces rekrutacyjny to za mało, po okresie próbnym powinna być sensowna rozmowa z współpracownikami i potem odstrzał kandydata, jeżeli ten się nie nadaje, a z takim podejściem można zrobić prostszy i krótszy proces. Tylko to kosztuje masę czasu, pieniędzy, dodatkowo w przypadku wizy i przeprowadzki jest to spory problem. No i firma musiałaby potrafić zaakceptować fakt, że proces rekrutacyjny jest wadliwy, ale przecież każda rekrutuje tylko najlepszych z najlepszych (tak jak wszędzie jest młody zespół i najnowsze technologie dla lidera branży), więc to oczywiście odpada.
Wprowadźcie w końcu te związki zawodowe/gildie z powrotem i problem z głowy. Każdy kto chce iść wyżej niż codemonkey będzie musiał swoje odcierpieć jako czeladnik a później wystarczy tylko rzut oka na listę pod kim się uczył żeby wiedzieć czego się spodziewać.
Dla tych co stwierdzą że przez to wybitne jednostki mogą się zmarnować odpowiadam - popatrzcie na tą konwersację i odpowiedzcie, gdybyście mieli pulę kandydatów i losowo z nich przydzielali zadanka, losowo white-board coding, codility a losowo uprzejme rozmowy to czy wynik tych rekrutacji by się zmienił jakoś w stosunku do tego co jest teraz?