Zadania rekrutacyjne i sposob ich oceniania

0

Hej,
Pytanie kieruje głównie do osób doświadczonych a szczególnie takich, które być może sprawdzają takie zadania. Czy takowe zadanie musi być w 100% dobrze zrobione, wręcz idealne, żeby pracodawca zdecydował się na współpracę ? Czy może jednak liczy się sposób myślenia kandydata i ew małe błędy, które mogły wyniknąć np. z pośpiechu bądź przeczenia nie będą miały aż tak drastycznego wpływu na decyzje ? Nie spotkałem się jeszcze z takim pytaniem na tym forum a wydaję mi się, że temat jest dosyć ciekawy.

1

Nie wiem, co Ci mam powiedzieć. To zależy od oceniającego. Gdybym ja oceniał, to nie czepiałbym się wszystkiego, tylko jakichś ewidentnych błędów lub nie spełnienia wymagań podanych w zadaniu. Ewentualnie odpałował kogoś za jakieś drobiazgi jeśli miałbym 2 kandydatów i jeden zrobił zadanie idealnie, a drugi popełnił jakieś drobne błędy. Surowiej powinien być też oceniany kandydat na senior developera, niż na junior developera.

Sam brałem udział w takich rekrutacjach i niektóre przechodziłem, a czasami ktoś się czepiał o jakieś drobiazgi, albo podawał niekonkretny feedback (np. rozwiązanie jest "zbyt skomplikowane", ale bez konkretnej informacji, co dokładnie jest zbyt skomplikowane).

1

Powiem tak, im lepiej wykonane zadanie, tym większa szansa :) zwykle sam proces code review i dyskusji w komentarzach daje bardzo dużo, poprawki i iteracje są normalne (jak w życiu). Zwykle samo zadanie jednak dostarcza zbyt mało informacji, coś musiałoby być koncertowo skopane, żeby zakończyć proces na tym etapie.

3

Ideały nie istnieją. No może poza komunizmem i scrumem, które to zawsze są "źle wdrażane" natomiast same w sobie wad nie posiadają.

To zależy czego dotyczy te zadanie. Jeśli to jakieś byle co, typu aplikacja z jednym kontrolerem i jedną metodą pobierająca coś z zewnętrznego API to niekoniecznie. Natomiast jeśli w grę wchodzi coś poważniejszego to jak najbardziej czepialstwo może być bardzo na miejscu. To też oczywiście zależy od poziomu umiejętności osoby rekrutowanej i stanowiska na jakie aplikuje. Juniorowi można np. odpuścić problem synchronizacji wątków, natomiast od seniora można wymagać zadbania np. o to, żeby wykonanie kodu jak najmniej obciążało Garbage Collector (o ile język w jakim pisze wykorzystuje taki twór).

Osobiście nie lubię takich zadań bo to nie pokazuje wartości kandydata. Zdarza się, że jak wspomniał już @wiciu, osoba techniczna podchodzi do danego rozwiązania w sposób bardzo subiektywny nie potrafiąc jednocześnie uzasadnić wyższości swojego rozwiązania nad tym, które zaproponował kandydat. Spotkałem się z czymś takim niestety, było to całkiem zabawne w momencie kiedy siedząc przed "komisją" stwierdziłem że nie zamierzam tam pracować i zacząłem zadawać masę niewygodnych pytań :D
Oprócz tego zajmują one mnóstwo czasu, za który nikt nie płaci. To nie jest nigdy zadanie na 2 godziny. Tak więc jeśli słyszę, że ktoś chciałby żebym szybciutko mu coś zakodował wieczorkiem to ja równie szybciutko sobie odpuszczam udział w rekrutacji.

5
var napisał(a):

Oprócz tego zajmują one mnóstwo czasu, za który nikt nie płaci. To nie jest nigdy zadanie na 2 godziny. Tak więc jeśli słyszę, że ktoś chciałby żebym szybciutko mu coś zakodował wieczorkiem to ja równie szybciutko sobie odpuszczam udział w rekrutacji.

Bo takie zadania na wstępnym etapie rekrutacji mają nie testować umiejętności technicznych ale miękkie, podatność kandydata na - już na etapie rekrutacji - przeczołganie, gotowość do siedzenia po godzinach bez wynagrodzenia itp.

1

zadanie w domu to zrobienia to tylko pierwszy krok. Ja np zrobilam zadania i dzieki temu zaprosili mnie na rozmowe, ale rozmowa nie poszla

1

Odpowiedź brzmi: nie. To znaczy - istnieją pracodawcy, którzy robią testy "pod klucz", zwłaszcza przy pierwszym odsiewie. Ale jeśli zamiast "&&" dasz gdzieś "&" czy też nazwa klasy będzie zawierała literówkę to zdecydowana większość na takie coś machnie ręką.

Z drugiej strony czasem małe błędy mogą być tymi ważnymi. Jeśli np. masz przelecieć po liście po indeksach od 0 do 5, a warunek stopu będzie "i < 5" to taki drobny błąd może świadczyć o niezrozumieniu zadania.

0

Jak pisali ludzie wyżej, z mojego doświadczenia też zależy to głównie od osoby oceniającej. Miałem przypadki, w których oceniający patrzyli niemal wyłącznie na to, czy kod robi, co powinien i nie przywiązywali szczególnej uwagi do innych rzeczy. Miałem też przypadki, w których oceniający oczekiwali kodu na poziomie porównywalnym z produkcją, więc dostałem bęcki za brak Dependency Injection oraz testów integracyjnych.

0

Kila razy w życiu miałem w ramach rekrutacji testowe zadanie do zrobienia. Za każdym razem robiłem je minimalistycznie, bez zawracania sobie głowy, czy jest to w dobrym stylu - byle działało - choć być może wprost błędów tam nie było. W każdym z tych przypadków byli skłonni mnie zatrudnić (w odróżnieniu od rekrutacji, w których zadania testowego nie było, a których miałem znacznie więcej - gdzie w ani jednym przypadku mnie zatrudnić nie chcieli).

Raz w życiu przygotowywałem zadanie rekrutacyjne i je później oceniałem. Interesowało mnie wyłącznie to, czy działa. Gdyby coś nie działało i uznałbym, że to prawdopodobnie przeoczenie, poprosiłbym kandydata o poprawienie. Rzeczy niewymienione w zadaniu, czyli jakieś tam testy, czy wyrafinowana struktura kodu nie interesowały mnie ani odrobinę.

0

Done is better than perfect :D
Jeśli problem do rozwiązania jest bardziej skomplikowany niż fizzbuzz, np. jest to napisanie jakiejś prostej aplikacji, to nie ma sensu starać się być perfekcjonistą - ważne jest żeby to działało i było napisane tak, żeby czytanie kodu nie równało się z wykrzykiwaniem WTF co 30 sekund.

Nie jestem fanem za dużej ilości komentarzy:) ale akurat w tym przypadku działają świetnie, bo możemy napisać mniej kodu a jednocześnie przekazać swoje intencje gdy skończył się nam ustalony czas. Np:
// TODO: obsłużyć tu wyjątek który może polecieć w sytuacji X
albo
// TODO: naiwna metoda generowania hasła. zamienić ją na Y

oczywiście nie można ich nadużywać, ale są jak najbardziej OK zamiast różnych trywialnych rzeczy które wymagają sporo kodu a mało myślenia

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