Co zadanie ma sprawdzić
Zanim ułożysz treść, odpowiedz sobie na jedno pytanie: jaką decyzję ma ułatwić wynik. Jeśli chcesz sprawdzić, czy kandydat potrafi napisać czytelny kod w wybranej technologii, zadanie będzie inne niż wtedy, gdy interesuje Cię jego sposób projektowania systemu albo debugowania. Zadanie nie służy do sprawdzenia wszystkiego naraz. Im węższy cel, tym bardziej wiarygodny wynik.
Zadanie nie zastępuje rozmowy. To materiał do rozmowy. Kod kandydata jest dobrym punktem wyjścia do pytań: dlaczego wybrał takie rozwiązanie, co zmieniłby przy większym ruchu, jak przetestowałby brzegowe przypadki.
Kiedy zadanie jest dobrym pomysłem
Zadanie ma sens przy stanowiskach, na których praktyczna umiejętność jest kluczowa i trudna do oceny z samego CV. Nie ma sensu wymagać go od każdego kandydata na każdym etapie. Doświadczone osoby z publicznym dorobkiem albo bogatym opisem projektów często wolą rozmowę o rzeczywistych decyzjach. Warto rozważyć, czy dla seniorów nie zamienić zadania na rozmowę projektową.
Najczęstsze formy zadań
- Krótkie zadanie na platformie lub w edytorze, wykonywane w czasie rozmowy na żywo.
- Zadanie domowe, rozwiązywane we własnym środowisku i oddawane w ustalonym terminie.
- Przegląd kodu (code review), w którym kandydat ocenia gotowy fragment kodu i wskazuje problemy.
- Zadanie projektowe, w którym kandydat opisuje i broni architektury prostego systemu.
- Debugowanie, czyli odnalezienie błędu w przygotowanym programie.
Każda z tych form mierzy co innego. Zadanie na żywo pokazuje sposób myślenia i komunikację, ale przy części osób powoduje stres, który zaburza wynik. Zadanie domowe daje spokojniejsze warunki, ale łatwo przeciągnąć je ponad rozsądną miarę. Code review dobrze sprawdza doświadczenie, bo wymaga rozpoznawania wzorców i ryzyk.
Dobór do stanowiska i poziomu
Dla juniora zadanie powinno sprawdzać podstawy i sposób uczenia się: prosta logika, praca z danymi, czytelność. Dla mida lepiej sprawdza się zadanie z kilkoma decyzjami projektowymi i potrzebą testów. Senior może dostać problem, w którym nie ma jednej poprawnej odpowiedzi, a liczy się uzasadnienie. Dopasuj też technologię do stanowiska, ale nie wymagaj tej samej wersji frameworka, którą masz w projekcie.
Ile czasu poświęcić
Zadanie domowe powinno mieścić się w ramach, które respektują czas kandydata. Dla większości stanowisk rozsądnie jest zakładać od jednej do dwóch godzin pracy, a dla bardziej złożonych przypadków maksymalnie kilka. Kandydaci często pracują zawodowo i oddają zadanie wieczorem, a dłuższy wysiłek bez gwarancji kolejnych kroków uznają za brak szacunku. Podaj czas wprost i wskaż, że nie oczekujesz dopracowania ponad ustalony zakres.
Dodaj termin oddania z zapasem. Kilka dni to zwykle uczciwa miara. Zapewnij też jasne instrukcje uruchomienia, dane wejściowe i oczekiwany format wyniku.
Jak napisać treść
Dobra treść zadania zawiera cztery elementy. Opis problemu w języku biznesowym. Konkretne wymagania funkcjonalne. Wyraźnie oznaczone to, co jest poza zakresem. Informację o tym, jak będzie oceniane rozwiązanie. Jeśli kandydat musi zgadywać, co ma zrobić, mierzysz jego zdolność do domyślania się, a nie umiejętności.
Kryteria oceny ustalone przed pierwszym rozwiązaniem
Najważniejsza zasada brzmi tak: kryteria spisz, zanim zobaczysz jakiekolwiek rozwiązanie. Inaczej będziesz oceniał pod wpływem tego, co przyszło jako pierwsze. Lista kryteriów może obejmować poprawność działania, czytelność i strukturę kodu, obsługę błędów i przypadków brzegowych, testy, uzasadnienie decyzji w opisie oraz zgodność z zakresem.
Dla każdego kryterium ustal prostą skalę i opis tego, co oznacza dany poziom. Każde rozwiązanie warto ocenić dwukrotnie: jedną ocenę wystawia lider techniczny, drugą inny programista, a potem porównują wyniki. Rozbieżności są najcenniejsze, bo zwykle pokazują niejasne kryteria.
Co oceniać, a czego nie
- Oceniaj to, co zadanie ma sprawdzać. Jeśli celem była logika biznesowa, nie obniżaj wyniku za brak ozdobnego interfejsu.
- Nie karz za wybór innego, uzasadnionego rozwiązania niż Twoje.
- Nie porównuj stylu z własnymi preferencjami, jeśli nie jest częścią zasad zespołu.
- Zwracaj uwagę na opis i komentarze, bo pokazują, jak kandydat komunikuje decyzje.
Wynik zadania jest sygnałem, nie wyrokiem. Przy granicznych ocenach zadaj kandydatowi kilka dodatkowych pytań na rozmowie. AI może pomagać przy tworzeniu i porządkowaniu kryteriów, ale nie powinno samodzielnie odrzucać kandydatów. Ostateczną decyzję podejmuje rekruter razem z zespołem.
Doświadczenie kandydata
Poinformuj o zadaniu na początku procesu, a nie po trzech rozmowach. Wyjaśnij, co się stanie z kodem po jego oddaniu, i zapewnij, że nie będzie używany w produkcie ani publikowany. Odpowiedz na wszystkie pytania doprecyzowujące, bo to część uczciwej oceny. Po ocenie przekaż informację zwrotną, nawet krótką. To jeden z najskuteczniejszych sposobów budowania opinii dobrego pracodawcy.
Najczęstsze błędy
- Zbyt długie zadanie bez zapowiedzi czasu.
- Zadanie będące w istocie prawdziwą pracą dla firmy.
- Niejasne kryteria, które każdy ocenia inaczej.
- Brak informacji zwrotnej po oddaniu rozwiązania.
- Taki sam test dla wszystkich stanowisk i poziomów.
- Przechowywanie rozwiązań bez zasady. Zajrzyj do artykułu RODO w rekrutacji IT.