Zadania rekrutacyjne i sposob ich oceniania

Odpowiedz Nowy wątek
2020-03-19 17:27

Rejestracja: 8 miesięcy temu

Ostatnio: 3 godziny temu

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.

Pozostało 580 znaków

2020-03-19 17:40

Rejestracja: 6 lat temu

Ostatnio: 5 godzin temu

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).

edytowany 1x, ostatnio: wiciu, 2020-03-19 17:42

Pozostało 580 znaków

2020-03-19 17:43

Rejestracja: 12 lat temu

Ostatnio: 6 godzin temu

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.


Ivory Tower Architect
edytowany 1x, ostatnio: Charles_Ray, 2020-03-19 17:44
Poruszyłem temat, gdyż jestem w takiej sytuacji. Dosłownie przed chwilą wykryłem lekkiego buga w zadaniu, który notabene nie wpływa na końcowy wynik, lecz w przypadku catch'a mógłby wpłynąć. Poprawiłem go i nie omieszkałem poinformować o tym osoby rekrutującej. - ledi12 2020-03-19 17:47
No to prawidłowo - Charles_Ray 2020-03-19 18:18

Pozostało 580 znaków

var
2020-03-19 18:41
var

Rejestracja: 2 lata temu

Ostatnio: 5 godzin temu

Lokalizacja: Wrocław

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.

no można jeszcze źle robić weganizm ;) - Miang 2020-03-19 22:31
"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ą." - podobną właściwość ma jeszcze programowanie obiektowe. - Troll anty OOP 2020-03-22 15:11

Pozostało 580 znaków

2020-03-19 18:45

Rejestracja: 10 miesięcy temu

Ostatnio: 5 godzin temu

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.


"Ktoś sobie uświadomił, że pisał pod pseudonimem rzeczy, które lepiej żeby w firmie nie wypatrzyli :-)"

"- Ledwo na studiach 3 tydzień się kończy i już ciężko?
- Niestety prowadzący jest dziwny i robi kartkówki"
edytowany 1x, ostatnio: BraVolt, 2020-03-19 18:58
Bez sensu ten komentarz, chyba ze żart :) - Charles_Ray 2020-03-19 19:53
Jeśli jesteś filozofem a nie programistą, to rzeczywiście zadanie programistyczne to "przeczołganie". Ja z kolei jako "przeczołganie" postrzegam rekrutacje polegające głównie na gadaniu - które to, wg ogłoszenia, wcale nie ma być moim głównym zadaniem w pracy - a zupełne pominięcie tego, co ponoć pracownik ma robić, czyli programowanie. - Troll anty OOP 2020-03-22 15:27
Dokładnie, programista jest od programowania, a nie od komunikacji - Charles_Ray 2020-03-22 15:31

Pozostało 580 znaków

2020-03-20 02:39

Rejestracja: 1 rok temu

Ostatnio: 5 godzin temu

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

Pozostało 580 znaków

2020-03-20 06:31

Rejestracja: 7 lat temu

Ostatnio: 1 tydzień temu

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.

Pozostało 580 znaków

2020-03-22 14:48

Rejestracja: 7 miesięcy temu

Ostatnio: 4 godziny temu

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.

Pozostało 580 znaków

2020-03-22 15:23

Rejestracja: 2 lata temu

Ostatnio: 2 dni temu

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ę.

Jakość kodu jest równie ważna - nie chciałbym pracować z z fanatykiem spaghetti czy innym miłośnikiem curry, którego kod jest nieutrzymywalny, nie dający się rozwijać albo nawet sprawnie debugować. - var 2020-03-22 15:43
mnie interesowało spełnienie założeń, miało być obiektowo, a zrobił spaghetti ;( - Miang 2020-03-22 16:08
@var: problem utrzymywania pojawia się przy projektach większych i uważam, że projektem na kilka godzin nie da się zweryfikować, czy w przypadku większego projektu, ktoś będzie umiał to zrobić w sposób utrzymywalny. Dlatego nie widzę sensu wnikania w cokolwiek innego niż czy w ogóle działa. - Troll anty OOP 2020-03-22 20:26

Pozostało 580 znaków

2020-03-22 15:59

Rejestracja: 1 rok temu

Ostatnio: 1 dzień temu

Lokalizacja: Dubaj, UAE

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

Pozostało 580 znaków

2020-03-22 17:30

Rejestracja: 4 lata temu

Ostatnio: 1 tydzień temu

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.


Lubię agrest. I malinowe chruśniaki.
Leser. Zdolny, ale leser.

Pozostało 580 znaków

Odpowiedz

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