Jak przygotować zadanie programistyczne, które szanuje czas kandydata

Zadanie programistyczne pozwala zobaczyć, jak kandydat rozwiązuje problem podobny do tych, z którymi spotka się w pracy. Jego wartość zależy od treści, warunków i sposobu oceny. Samo zastąpienie rozmowy przy tablicy projektem do domu nie poprawia rekrutacji, zwłaszcza jeśli deklarowane trzy godziny pracy zajmują cały weekend.

Metaanaliza Schmidta i Huntera z 1998 roku, opublikowana w Psychological Bulletin, podawała korelację 0,54 między wynikiem próbki pracy a wynikami zawodowymi. To historyczny szacunek dla szerokiej kategorii metod, a nie wynik badania zadań na GitHubie. Nie dowodzi też, że połączenie dowolnego zadania z rozmową daje trafność 0,63. Ta wartość dotyczyła połączenia próbki pracy z testem ogólnych zdolności poznawczych.

Rozmowa na żywo czy zadanie do domu?

Podczas rozmowy z kodowaniem rekruter widzi tok rozumowania kandydata i może dopytać o decyzje. Obserwacja i presja czasu mogą jednak utrudniać pracę. Zadanie do domu pozwala wybrać dogodną porę i własne narzędzia, ale wymaga dodatkowego czasu poza rozmową.

Wybierz format pasujący do sprawdzanych umiejętności. Jeśli zespół potrzebuje osoby, która będzie debugować istniejącą aplikację, przygotuj błąd do znalezienia. Jeśli ważna jest współpraca przy kodzie, zaplanuj wspólne omówienie rozwiązania. Nie zakładaj, że jeden format będzie najlepszy dla każdego stanowiska i kandydata.

Co zniechęca kandydatów

Zaniżony szacunek czasu

Polecenie „zbuduj aplikację full-stack” może oznaczać dwie godziny albo dwa dni pracy. Kandydat powinien wiedzieć, jakie minimum wystarczy i czego nie trzeba robić. Sprawdź czas na osobie z zespołu, która nie zna rozwiązania, a potem uwzględnij czas na poznanie repozytorium.

Niejasny zakres

Bez kryteriów kandydaci zgadują, czy warto dopisać testy, skonfigurować Dockera albo dopracować interfejs. Zaznacz, które elementy oceniasz. Napisz też wprost, że dodatkowe funkcje nie dają punktów, jeśli nie są częścią zadania.

Brak odpowiedzi po oddaniu kodu

Po kilku godzinach pracy kandydat oczekuje decyzji i wyjaśnienia. Ustal termin odpowiedzi, przypisz osobę do oceny i zarezerwuj jej czas przed wysłaniem zadania. Jeśli termin się przesuwa, poinformuj o tym kandydata.

Uwzględnij różne warunki pracy

Rodzice, opiekunowie i osoby pracujące na kilku etatach mogą nie mieć wolnego weekendu. Kandydat może też potrzebować dostosowania czasu lub narzędzi ze względu na niepełnosprawność. Nie wyciągaj z dostępności czasowej wniosków o zaangażowaniu ani umiejętnościach.

Rozróżnij przewidywany nakład pracy od terminu oddania. Zadanie na trzy godziny może mieć tygodniowy termin, żeby kandydat znalazł dogodny moment. Sam termin nie ogranicza liczby przepracowanych godzin. Ogranicz zakres i zaproponuj alternatywną formę oceny, gdy jest potrzebna.

Siedem zasad przygotowania zadania

1. Zaplanuj dwie do czterech godzin pracy

Potraktuj ten zakres jako cel przy projektowaniu krótkiego zadania, nie uniwersalny wymóg. Poproś kandydata, by po wskazanym czasie oddał również niepełne rozwiązanie i opisał dalsze kroki. Oceniaj zgodnie z tą zasadą, zamiast nagradzać dodatkowe godziny.

Ustal też sposób zgłaszania potrzebnych dostosowań czasu lub warunków pracy. Rozpatruj je przed rozpoczęciem zadania.

2. Przygotuj repozytorium startowe

Dodaj instrukcję uruchomienia, zależności, dane przykładowe i testy, jeśli ich konfiguracja nie jest przedmiotem oceny. Uruchom projekt na czystym środowisku, żeby sprawdzić instrukcję.

Jeśli rekrutujesz do istniejącej aplikacji, praca na przygotowanym fragmencie kodu zwykle lepiej oddaje warunki stanowiska niż budowanie całego projektu od zera.

3. Wybierz problem podobny do codziennych zadań

Może to być mała funkcja, błąd do naprawienia albo integracja z API. Nie wykorzystuj zadania jako bezpłatnej pracy nad produktem. Przygotuj samodzielny przykład bez danych klientów i dostępu do produkcji.

Przykład: „Dodaj do tego API endpoint wyszukujący rekordy i napisz testy dla opisanych przypadków”. Takie polecenie określa oczekiwany zakres rozwiązania.

4. Opublikuj kryteria oceny

Przed rozpoczęciem zadania podaj, co sprawdzą oceniający:

• Czytelność kodu i nazewnictwo.
• Obsługę błędów i przypadków brzegowych.
• Jakość testów, w tym dobór sprawdzanych zachowań.
• Podział odpowiedzialności i uzasadnienie decyzji.
• Historię zmian w Git, jeśli jest istotna dla zadania.

Określ zasady korzystania z AI, dokumentacji i pomocy innych osób. Nie oceniaj według wymagań, których kandydat wcześniej nie poznał.

5. Przekaż konkretną informację zwrotną

Zaplanuj odpowiedź do każdego oddanego rozwiązania. Nie musi to być pełny przegląd kodu. Kilka uwag odnoszących się do kryteriów pozwoli wyjaśnić decyzję: co działało, czego zabrakło i dlaczego miało to znaczenie.

Nie obiecuj terminu, którego zespół nie jest w stanie dotrzymać. Czas potrzebny na ocenę sprawdź podczas wewnętrznej próby zadania.

6. Dopuść inne sposoby pokazania umiejętności

Zależnie od stanowiska możesz zaproponować:

• Omówienie wcześniejszego wkładu w projekt open source.
• Wspólne programowanie nad podobnym problemem.
• Prezentację wcześniejszego projektu i decyzji technicznych.

Zachowaj porównywalne kryteria. Nie wymagaj publicznego portfolio od osoby, której dotychczasowa praca była poufna.

7. Płać za rozbudowane projekty

Jeśli potrzebujesz kilku dni pracy, uzgodnij wynagrodzenie, zakres, zasady wykorzystania kodu i termin. Płatny projekt próbny jest większym zobowiązaniem niż krótkie ćwiczenie rekrutacyjne. Kandydat powinien znać warunki przed podjęciem decyzji.

Co daje praca z repozytorium GitHub

Kandydat może sklonować repozytorium i pracować we własnym edytorze. Zespół zobaczy kod i historię commitów, a przy pracy przez pull request także komentarze przy konkretnych liniach. Warto wykorzystać narzędzia podobne do tych, których używa zespół.

Historia zmian może pomóc w rozmowie o rozwiązaniu. Nie traktuj liczby commitów jako miary umiejętności. Kandydat mógł porządkować historię albo pracować w inny sposób niż oceniający.

Co rzeczywiście wynika z badania trafności

Historyczne szacunki z metaanalizy opublikowanej w Psychological Bulletin. Nie są gwarancją trafności konkretnego zadania ani miarą odsetka poprawnych decyzji.

Zadanie i rozmowa o kodzie mogą dostarczyć różnych informacji. Warto sprawdzać, czy oceny w waszym procesie mają związek z późniejszymi wynikami pracy, zamiast przypisywać własnemu zadaniu współczynnik z metaanalizy.

Jak oceniać rozwiązania

Oddziel własne preferencje od wymagań

Inna biblioteka lub styl kodowania nie oznaczają gorszego rozwiązania. Oceniaj poprawność i kryteria podane w poleceniu. Jeśli określona technologia jest wymagana, powiedz o tym wcześniej.

Uzasadniaj ocenę przykładami

Zamiast „dobry kod” napisz, które zachowanie działa poprawnie i gdzie to widać. Zamiast „słaba architektura” wskaż, jakie odpowiedzialności są ze sobą pomieszane i jaki problem to powoduje. Takie uwagi można sprawdzić i omówić z innymi oceniającymi.

Omów kod z kandydatem

Zapytaj o wybraną bibliotekę, obsługę większego ruchu i zmiany, które kandydat wprowadziłby przy dłuższym czasie. Pozwól wyjaśnić kompromisy. Oceń odpowiedzi według tych samych kryteriów, które stosujesz do kodu.

Jak Kit obsługuje zadania programistyczne

Prywatne repozytorium z szablonu pracodawcy

Kit tworzy prywatne repozytorium GitHub na podstawie szablonu przygotowanego przez pracodawcę i zaprasza kandydata. To zespół dodaje instrukcję, zależności i testy do szablonu. Kandydat klonuje repozytorium i uruchamia je u siebie.

Termin oddania i przedłużenia

Termin biegnie od przyjęcia zaproszenia do repozytorium. W konfiguracji określasz liczbę dni na zadanie oraz dodatkowy okres na spóźnione oddanie. Po upływie obu okresów Kit automatycznie oznacza nieoddane rozwiązanie jako oddane. Nie mierzy aktywnego czasu programowania, więc tygodniowy termin nie narzuca trzygodzinnego limitu pracy.

Rekruter może przedłużyć termin. Jeśli pozwala na to konfiguracja, kandydat może również sam skorzystać z jednorazowego przedłużenia przed terminem. Archiwizacja repozytorium zależy od ukończenia etapu. Sam upływ terminu nie zamraża kodu automatycznie.

Dostęp dla oceniających

Po oddaniu rozwiązania Kit powiadamia oceniających i zaprasza do repozytorium tych, którzy mają połączone konto GitHub. Zespół może przeglądać kod i historię zmian na GitHubie. Jeśli zadanie wymaga pull requesta, uwzględnij jego utworzenie w instrukcji dla kandydata. Kit nie tworzy go automatycznie.

Kolejny etap rekrutacji

Zadanie jest częścią procesu rekrutacyjnego. Przejście dalej zależy od warunków ukończenia etapu i konfiguracji procesu. Samo oddanie kodu nie oznacza, że kandydat otrzyma pozytywną ocenę lub bezwarunkowo przejdzie do kolejnej rozmowy.

Przed wysłaniem pierwszego zadania

Przeprowadź próbę w zespole. Sprawdź instrukcję, rzeczywisty czas pracy i kryteria oceny. Wyznacz osobę, która przeczyta kod i odpowie kandydatowi. Dopiero wtedy uruchom zadanie w rekrutacji.

Rozpocznij bezpłatny okres próbny, jeśli chcesz obsługiwać repozytoria, terminy i oceny w Kit.