Ładuję...
photo
szopa
03:46 06/09/2009
Po przemyśleniu zdałem sobie sprawę, że #codility jako metoda presecreeningu i *wstęp* do właściwej rozmowy technicznej wcale nie musi być takie złe. Zastanawiałem się skąd się wzięła moja początkowa bardzo nieprzychylna reakcja i dochodzę do wniosku, że sporą część winy ponosi interfejs kandydata. Połączenie ograniczenia czasowego, nieoczywistego UI (niby jest pomoc, ale na jej oglądanie zużywa się czas, a zegar tyka) i próby programowania w przeglądarce zamiast w prawdziwym edytorze (do czego interfejs zachęca) jest *potężne*... Dla mnie to było jedno z najbardziej traumatycznych user experience ostatnich lat (chyba tylko USOS to przebija)... Znamienne jest to, że w prezentacji autor kod *wkleja*, a nie wpisuje...
  1. photo Mekk Jako prescreening mógłby wystarczyć FizzBuzz ;-)
    Zresztą - jak już mgmt+hr dostaną takie narzędzie, to po co jakieś rozmowy itd, przecież wyjdą punkty ;-) [odpowiedz]
  2. photo szopa @jwr - akurat w rozmowach kwalifikacyjnych do #Google nie było ograniczeń czasowych, a rekruterzy byli wyjątkowo pomocni (dopytując się o różne corner cases jeśli ich nie zauważyłem, itp.). odnosiłem wręcz wrażenie, że rozwiązanie na które oni patrzą jest bardzo ramowe i że niemalże rozwiązują zadanie na bieżąco ze mną. ostatnia rozmowa źle mi poszła ponieważ byłem zupełnie nieprzygotowany z jej zakresu (uroki _Implementacji systemów baz danych_ odkryłem dopiero kilka miesięcy później). całe doświadczenie oceniam jednak jako wyjątkowo pozytywne: *bardzo* dużo się przy okazji nauczyłem. jedyne 2 zarzuty jakie można do Google mieć to czasochłonność i słaby feedback po porażce (jeden adres bibliograficzny oszczędziłby mi wiele frustracji)... właściwie nie porównywałbym codility do procesu rekrutacyjnego Google, bo to trochę jak porównywanie Daewoo Tico do Mercedesa... [odpowiedz]
  3. photo szopa @ms - moje doświadczenia jeśli chodzi o kolokwia/egzaminy programistyczne są zarazem niewielkie jak i przyjemne, czyli raczej nie tam upatrywałbym źródeł swojej traumy. jeśli edytor ma jedynie służyć wykrywaniu jeleni którzy nie wiedzą jeszcze, że to *zło* i że nie należy z niego korzystać, to już wolałbym dialog uploadu pliku. poza tym przyznam, że trochę dziwnie mi się dyskutuje z anonimem. [odpowiedz]
  4. photo szopa @jwr - idea #codility jest chyba taka, że chcesz odfiltrować z masy ludzi odpowiadających na ogłoszenie tych, którzy ewidentnie nie potrafią programować. coś w rodzaju bardzo wyrafinowanej captchy. w tej roli to *może* działać. [odpowiedz]
  5. photo 13marcin @szopa - dzięki za uwagi na temat usability, zwłaszcza help'u i tykającego zegara - będziemy poprawiać :) Jeśli chodzi o podejście do tego typu testów, to #Codility daje możliwość ustawienia ilości czasu, więc nie musi to być bardzo stresujące przeżycie. Z drugiej strony nie zawsze masz wyluzowane warunki pracy i czasem (czytaj naogół) projekt oddaje się w ostatniej chwili - nikt Cię wtedy po plecach nie poklepie, żebyś się odprężył. Ponieważ każdy może Codility za darmo przetestować, łatwo się przekonać, że będziemy mogli Wam pomóc w rekrutowaniu programistów.
    ps. kod był wklejany, bo w wymogach Seedcampu demo musiało mieć poniżej 2min - oszczędzaliśmy gdzie się dało :) [odpowiedz]
  6. photo szopa @13marcin - "szybko, mamy dziesięć minut na napisanie algorytmu, w przeciwnym razie wybuchnie bomba! i musi działać liniowo, bo jak będzie kwadratowo to nie zdążymy wszystkich ładunków rozbroić!" - póki co nie miałem zbyt wiele takich sytuacji w swojej (niezbyt długiej, co prawda) karierze :P A tak bardziej na poważnie, to jest jeden ficzer dzięki któremu użyteczność codility wzrosłaby dla mnie bardzo mocno, mianowicie zadania postaci: "ten kod miał robić to i to. niestety, nie działa poprawnie. popraw go tak aby działał dobrze" - to już dużo bardziej sprawdza kryteria na podstawie których oceniłbym potencjalnego pracownika. oczywiście, takie zadania bardzo trudno przygotować i mierzenie wyników uczestników może być trudne (bo prędkość działania jest nieistotna). [odpowiedz]
  7. photo 13marcin @szopa - ciekawy pomysł, i chyba nawet wykonalny - zgłębimy temat, dzięki :) [odpowiedz]
  8. photo jakacki @szopa - dzięki za feedback; ciekawy jest pomysł na ficzer "to i tamto nie działa, popraw by działało", będziemy na pewno kombinować w tym kierunku. W pewnym zakresie już go realizujemy podając (a) wynik kompilacji (dzięki czemu masz pewność, że nie zaliczysz wpadki na takiej głupocie jak zgubiony średnik) oraz (b) poprawność działania na teście przykładowym (żeby ograniczyć szanse wpadki np. na zapomnianym "return", mylnym zrozumeniu treści itp.). [odpowiedz]
  9. photo Mekk Mechanizmy testowania kodu (przynajmniej wyniku i czasu) ma pl.spoj.pl inne wpisy na ten temat
    Wyforkowali ostatnio też cuś, czego jeszcze nie obejrzałem - scarky.com inne wpisy na ten temat  [odpowiedz]
  10. photo szopa @jwr - jeśli rekrutacja programisty jest ciężkim kawałkiem chleba, to rekrutowanie tech leada (i w ogóle na jakiekolwiek stanowisko kierownicze) wydaje się być o rząd wielkości trudniejsze. jedyne, co mi przychodzi do głowy to długie rozmowy, referencje wspólnych znajomych, czytanie starego kodu z projektów open source: czyli same rzeczy, które są kosztowne i czasochłonne. i zapewne zupełnie nie skalują się przy firmie takiej jak #Google. [odpowiedz]
  11.  
  • Promuj wpis:
  • Zobacz inne wpisy otagowane: #codility