Zadania rekrutacyjne i sposob ich oceniania

2

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

4

Kandydaci robią projekty domowe minimalistycznie, albo im się nie chce i dziękują.
A firmy udają, że robią feedback, albo nie robią go wcale (zapadają się pod ziemię i nie odpisują na pocztę).

I nie, stwierdzenie w mailu "rozwiązanie nie jest satysfakcjonując" nie jest feedbackiem :D

Więc rzekłbym, że oby dwie strony są sobie kwita.

3
dzika_kuna napisał(a):

Kandydaci robią projekty domowe minimalistycznie, albo im się nie chce i dziękują.
A firmy udają, że robią feedback, albo nie robią go wcale (zapadają się pod ziemię i nie odpisują na pocztę).

A zadania są z terminem dwa tygodnie z w pełni zaangażowaną robotą na tydzień.

Zadanie na max 2 godzinki to nie zadanie na 2 tygodnie.
Takie przytłoczenie, ja to dalej nazywam przeczołganiem, to stosowana częściej lub rzadziej praktyka rekrutacyjna (info przekazane, zawodowe), gdy firma szuka określonego profilu psychologicznego kandydata. Wyników nikt dokładniej nie sprawdza bo liczy się czy ktoś się zaangażował prawie bez reszty w sytuacji niewielkiej szansy powodzenia.

1

Ja ostatnio miałem rekrutacje w finansowym korpo na Sysadmina/devopsa:
Część teoretyczną - sprawdzali mój zakres wiedzy w działce do której startowałem, chodziło czy rozumiem tematy które były w profilu o prace
Część praktyczna:
3 zadania na które miałem 2h:
1 zadanie ze ściągnięciem plików i porównaniu danych - dowolny jezyk wysokiego poziomu.
2 zadanie wywalona jakaś usługa na Linuksie, musiałem ja przywrócić było parę pułapek
3 zadanie miałem znaleźć duplikaty w folderze.
Wszystko było na ich maszynie zdalnej i byłem na screen sharingu. Mogłem korzystać ze wszystkiego oprócz pomocy osób trzecich, chcieli sprawdzić jak rozwiązuje problemy.
Plus jest taki że do pierwszego zadania mogłem uzyć własnego IDE
Ogólnie że mam syndrom tablicy to zawsze głupieje jak coś mam pokazywać i robić więc: za każdym razem jak zaczynałem zadanie mówiłem jak widzę problem, jak chcę to rozwiązać. Więc trochę mówienia na temat mojego toku myślenia miałem, ew. dopytywałem o szczegóły które wydawały mi się nie jasne.
ostatecznie przez stres zrobiłem 2.75 zadania :D ale zanim skończył mi się czas powiedziałem jak mam dokończyć zadanie 2.
Myślałem że poszło mi tragicznie ale firma była bardzo zadowolona z rezultatów.

2

Na stronie firmy, na którą dziś klnie pewnie co trzecia Polka (i Polak), w ścieżce kariery IT (mid, senior PHP) proces rekrutacji ma 3 etapy:

  1. Koszyk Zadań
  2. Spotkanie z rekruterem
  3. Decyzja o zatrudnieniu

Cały koszyk zadań, dopiero po nim spotkanie z rekruterem.

Dziś ich system przy pierwszej "próbie bojowej" wyzionął ducha.

0

Ja raz robiłem zadanie programistyczne (mini aplikacje webowa z bazą danych) które łącznie zajeło z kilkanaście godzin, oddałem je i dostałem obszerny feedback w postaci kilkudziesięciu komentarzy na githubie, i nie nie były to komentarze typu "po co dwie puste linie". Ja się przyłożyłem i osoba robiąca review się przyłożyła...

3

Jak ja to lubie :D Firma podobno znalazla innego kandydata, "ktory" lepiej wpasowuje sie w standardy firmy a dwa dni pozniej ogloszenie znowu laduje na nfj ^^

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