Żeby przetestować instrukcję zadania rekrutacyjnego do wykonania w domu, poproś osobę, która jej nie zna, o przejście przez te same kroki przygotowania i oddania pracy, które otrzyma kandydat. Obserwuj, kiedy potrzebuje pomocy, zapisz niezamierzone przeszkody, popraw materiały i powtórz próbę z kolejną osobą. Przez cały czas pamiętaj, jakie umiejętności ma sprawdzać zadanie.

11 października Terence Eden opisał, jak [zapłacił ludziom za próbę wykonania poleceń z jego README](https://shkspr.mobi/blog/2026/10/i-paid-people-to-try-and-follow-my-readme/). Oferował 25 € za godzinę, obserwował udostępniane ekrany i prosił uczestników o głośne opisywanie swoich myśli. Między spotkaniami poprawiał dokument. Według jego relacji wydał łącznie około 150 €. Eksperyment ujawnił błędny link do demonstracji, niejasne operacje na plikach, niewyjaśnione terminy i niepraktyczną kolejność sekcji.

[Dyskusja na Hacker News](https://news.ycombinator.com/item?id=50042219) dotyczy dokumentacji oprogramowania. Eden nie badał rekrutacji. Zespół rekrutujący może jednak wykorzystać ten pomysł, żeby przećwiczyć własne instrukcje, zanim zacznie oceniać pracę kandydatów. Nawet starannie napisana treść zadania może ukrywać brak uprawnień albo niejasny ostatni krok.

## Co tak naprawdę sprawdzają instrukcje zadania?

**Zapisz, jaką umiejętność chcesz ocenić, zanim zorganizujesz próbę.** Ten punkt odniesienia pozwoli rozstrzygnąć, czy trudność jest częścią oceny, czy wynika z błędu w organizacji zadania, który da się usunąć.

Rozważmy fikcyjne zadanie backendowe: dodanie filtra do niewielkiego API i zabezpieczenie dotychczasowego działania testami. Można w nim oceniać rozumienie kodu, wybór sposobu zmiany, obsługę przypadków brzegowych i uzasadnienie decyzji. To sensowne cele, jeśli odpowiadają pracy na danym stanowisku.

Amerykański Office of Personnel Management opisuje [próbki pracy i symulacje](https://www.opm.gov/policy-data-oversight/assessment-and-selection/other-assessment-methods/work-samples-and-simulations/) jako zadania przypominające rzeczywiste obowiązki zawodowe. Jego wytyczne rozróżniają też kompetencje potrzebne już przy zatrudnieniu i te, których pracodawca zamierza nauczyć. Dlatego przy każdym wymaganiu wstępnym warto zapytać: czy na tym stanowisku trzeba spełniać je od pierwszego dnia?

Czytanie nieznanego kodu może do nich należeć. Znajomość nieopublikowanej konfiguracji firmowej bazy danych nie wynika jednak z tego celu. Wyszukiwanie błędów również może być przedmiotem oceny, ale trzeba zdecydować, czy uszkodzone środowisko startowe jest właśnie zadaniem do naprawienia. Ukryta usterka zmienia to, co uczestnicy mają wykazać.

Umieść odpowiedź obok kryteriów oceny. Dla fikcyjnego zadania z API można napisać: „Oceniamy poprawność, zachowanie dotychczasowego działania, trafność testów oraz wyjaśnienie kompromisów”. Jeśli interpretowanie niepełnego wymagania jest celowe, wyjaśnij, jak będą oceniane założenia przyjęte przez kandydatów.

Próba sprawdza, czy materiały pozwalają przeprowadzić zamierzoną ocenę. Udany przebieg nie dowodzi, że zadanie przewiduje późniejszą efektywność w pracy. Szersze zasady projektowania zadań opisuje osobny poradnik o [strukturze zadań programistycznych](/blog/how-to-structure-code-assignments).

## Daj nowej osobie rzeczywiste materiały dla kandydata

**Przećwicz razem zaproszenie, dostęp, instrukcję i sposób oddania pracy.** Wysłanie współpracownikowi samego repozytorium pomija przejścia między etapami, przy których kandydat może stracić orientację.

Wybierz osobę z umiejętnościami wymaganymi przy zatrudnieniu, która nie pisała ani nie sprawdzała zadania. Może to być programista z innego projektu. Osoba zupełnie nowa w programowaniu może ujawnić problem z tekstem. Jej trudności z instalacją środowiska wykonawczego trzeba jednak inaczej interpretować w kontekście stanowiska dla doświadczonego inżyniera.

Przed rozpoczęciem wyjaśnij cel: testujesz materiały do zadania. Jeśli zapraszasz kogoś specjalnie na tę sesję, uzgodnij zakres pracy i wynagrodzenie. Budżet Edena opisuje jego eksperyment; nie wyznacza standardowej stawki ani zalecanej liczby uczestników. Nie wykorzystuj obecnego kandydata jako bezpłatnego uczestnika testu użyteczności bez jego wiedzy.

Przekaż tej osobie te same materiały i uprawnienia, które planujesz udostępnić kandydatom:

- Zaproszenie i ewentualne instrukcje przygotowania.
- Podsumowanie zadania, szczegółową instrukcję i kryteria oceny.
- Dostęp do repozytorium, dostarczone dane i potrzebne dane uwierzytelniające.
- Oczekiwany nakład pracy, termin oraz zdarzenie rozpoczynające odliczanie czasu.
- Zasady korzystania z dokumentacji, wyszukiwania, współpracy i pomocy AI.
- Rzeczywisty sposób oddania pracy oraz kontakt do pytań.

Użyj konta testowego i danych odpowiednich do sesji. Jeśli zadanie wymaga konkretnego środowiska, udostępnij je wprost. Jeżeli kandydaci mogą korzystać z własnych komputerów, wypróbuj opisany sposób przygotowania w dozwolonym środowisku bez wcześniej zainstalowanych zależności twojego zespołu.

Przed dalszą pracą poproś uczestnika o opisanie oczekiwanego rezultatu. Zapisz tę wypowiedź jako obserwację. Odmienna interpretacja może ujawnić niejasne wymaganie, ale może też być rozsądnym wyborem zawodowym w granicach zamierzonej swobody.

Przy zadaniu programistycznym poproś o przejście na tyle daleko, by uruchomić wersję wyjściową, wprowadzić niewielką dozwoloną zmianę i oddać pracę. Uzgodnij ten zakres wcześniej. Chodzi o obserwację praktycznych kroków, bez niejawnego żądania pełnego rozwiązania za darmo.

## Obserwuj, gdzie instrukcja przestaje pomagać

**Zapisz, co się wydarzyło, zanim wyjaśnisz swoją intencję.** Podpowiedź może być konieczna, ale sama potrzeba jej udzielenia jest częścią zebranych informacji.

Poproś uczestnika, żeby podczas pracy mówił, którą instrukcję wykonuje, czego oczekuje po danym poleceniu i gdzie szuka następnego kroku. Nie objaśniaj mu na bieżąco całej strony. Gdy się zatrzyma, pozwól mu najpierw wyjaśnić powód, zamiast od razu uznawać to za problem.

Przerwa na rozważenie znaczenia filtrów może ujawnić wartościowe rozumowanie. Przerwa spowodowana tym, że link „Repozytorium startowe” otwiera niedostępną stronę, wskazuje na problem organizacyjny. Rozróżniaj takie obserwacje w notatkach, zamiast ujmować je w jednym czasie ukończenia zadania.

Prowadź krótki rejestr przeszkód. Poniższe wpisy to wymyślone przykłady dla zadania z API, a nie wyniki rzeczywistego badania rekrutacji:

| Instrukcja lub miejsce | Zaobserwowana przeszkoda | Proponowana poprawka | Obserwacja z ponownego testu |
|---|---|---|---|
| „Uruchom aplikację” | Uczestnik szuka wersji środowiska wykonawczego w trzech plikach | Wskazać wspieraną wersję i podać link do poleceń przygotowania | Zapisać, czy kolejna osoba zaczyna bez podpowiedzi |
| Zaproszenie do repozytorium | Uczestnik nie może otworzyć prywatnego repozytorium | Sprawdzić zaproszenie i konto otrzymujące dostęp | Potwierdzić dostęp tą samą drogą, z której korzysta kandydat |
| „Dodaj filtrowanie” | Uczestnik nie wie, czy dwa filtry mają się łączyć | Określić wymagane połączenie albo wyjaśnić, że ten wybór podlega ocenie | Zapisać interpretację uczestnika |
| „Wyślij rozwiązanie” | Uczestnik wysyła link mailem, ale pomija czynność w portalu | Wskazać ostatni krok oddania pracy | Sprawdzić, czy pojawia się oczekiwane potwierdzenie |

Dodaj polecenie, błąd lub sformułowanie potrzebne do odtworzenia problemu. „Przygotowanie było niejasne” niewiele mówi. „Polecenie przygotowania wymaga nazwy bazy danych, której brakuje w przykładzie konfiguracji środowiska” daje osobie odpowiedzialnej konkretny punkt zaczepienia.

Jeśli interweniujesz, zapisz udzieloną pomoc. Inaczej wynik końcowy może sugerować, że materiały są zrozumiałe, choć sesja zależała od twojego wyjaśnienia. Głośne opisywanie myśli pomaga diagnozować problemy. Obserwacja i mówienie na głos mogą jednak zmieniać sposób pracy, więc nie służą do szacowania zwykłej efektywności kandydatów.

## Popraw treść zadania i przetestuj zmiany

**Usuń konkretną przyczynę problemu, ograniczając zmianę do niezbędnego zakresu, a poprawiony przebieg sprawdź z osobą, która nie zna wypracowanego obejścia.** Pierwszy uczestnik wie już rzeczy, których następny kandydat nie będzie wiedział.

Pierwotne materiały do fikcyjnego zadania z API mówią: „Uruchom aplikację, dodaj filtrowanie i wyślij rozwiązanie”. Poprawiona wersja może zawierać wspierane środowisko wykonawcze, dokładne polecenia instalacji, polecenie uruchomienia testów wersji wyjściowej, przykładowe dane i oczekiwane działanie filtrów. Powinna też wskazywać miejsce oddania pracy oraz kryteria oceny.

Powiąż poprawki z obserwacjami. Jeśli uczestnik nie potrafi zainstalować zależności, dodatkowy akapit o kulturze firmy nie rozwiąże problemu. Jeśli testy przechodzą, ale uczestnik nie może znaleźć sposobu oddania pracy, poprawka jest potrzebna właśnie w tym miejscu.

Przed kolejną obserwowaną sesją samodzielnie sprawdź polecenia. Wykonaj je po kolei na świeżo pobranej kopii repozytorium, w opisanym środowisku. Usuń przypadkowe zależności od lokalnych danych uwierzytelniających, danych z pamięci podręcznej albo nieopublikowanej konfiguracji. Automatyczne testy mogą wykrywać niedziałające linki i polecenia. Nie pokażą jednak, jak człowiek rozumie „Wyślij rozwiązanie”.

Sformułuj konkretne pytanie na następny test. Na przykład: czy uczestnik może uruchomić wersję wyjściową wyłącznie na podstawie materiałów i wyjaśnić, kiedy praca jest formalnie oddana? Zapisz obserwację w tym samym rejestrze, zamiast uznawać całe zadanie za „zwalidowane”.

Po usunięciu przeszkody, która uniemożliwiała dalsze kroki, sprawdź ponownie cały przebieg. Poprawione zaproszenie do repozytorium może ujawnić problem z przygotowaniem środowiska, do którego pierwsza osoba nawet nie dotarła. Zakończ próby, gdy zbierzesz dość informacji, by usunąć znalezione konkretne przeszkody. Uwzględnij przy tym ograniczenia wynikające z liczby osób i środowisk objętych testem.

## Zachowaj spójne warunki i wyjaśnienia dla kandydatów

**Ustal materiały przed zaproszeniem grupy kandydatów i przekazuj istotne poprawki wszystkim zainteresowanym na tych samych zasadach.** Zmiana wymagań bez komunikatu może sprawić, że recenzenci porównują prace powstałe w różnych warunkach.

Zachowaj zaproszenie, instrukcje, wersję startową i kartę oceny razem, w dokumencie lub repozytorium, którego zespół już używa. Zapisz, którą wersję otrzymał każdy kandydat. To propozycja praktyki organizacyjnej, a nie twierdzenie, że samo wersjonowanie czyni ocenę sprawiedliwą.

[Wytyczne amerykańskiej EEOC dotyczące testów rekrutacyjnych i metod selekcji kandydatów](https://www.eeoc.gov/laws/guidance/employment-tests-and-selection-procedures) obejmują właściwy cel, sposób przeprowadzenia, ocenianie i walidację. Próba z osobą nieznającą materiałów jest pojedynczym sprawdzeniem organizacji procesu. Nie spełnia wszystkich tych obowiązków ani nie dowodzi zgodności z prawem.

Załóżmy, że kandydat zgłasza problem z wczytaniem dostarczonych danych. Potwierdź usterkę, poinformuj pozostałe osoby, których dotyczy, co się zmieniło, i rozważ przesunięcie ich terminów. Jeśli błąd uniemożliwił przygotowanie pracy do oceny, zbadaj jego wpływ, zanim uznasz brak wyniku za brak umiejętności.

Oddziel wyjaśnienia organizacyjne od podpowiadania rozwiązania. Informację „Plik prześlij na tej stronie” można przekazać wszystkim. Rozmowa dostarczająca sposobu rozwiązania głównego problemu zmienia zakres otrzymanej pomocy i powinna być odnotowana dla recenzentów.

Po oddaniu pracy zachowaj powiązanie między materiałami otrzymanymi przez kandydata a oceną. Recenzent powinien znać przekazane kryteria, w tym każdą celowo pozostawioną niejednoznaczność. Pytania zadawane później, podczas rozmowy o poprawnym rozwiązaniu, należą do osobnego etapu; zobacz [rozmowę o rozwiązaniu, które przechodzi testy](/blog/coding-interview-after-solution-passes).

## Zadbaj o dostępność instrukcji

**Uwzględnij w próbie sposób czytania materiałów i poruszania się po nich.** Poprawne polecenie nadal może być trudne do wykorzystania, jeśli znajduje się wyłącznie na zrzucie ekranu albo pod niezwiązaną z nim nazwą sekcji.

[Poradnik W3C WAI o nagłówkach](https://www.w3.org/WAI/tutorials/page-structure/headings/) wyjaśnia, jak znaczące nagłówki i ich struktura ułatwiają nawigację oraz zrozumienie. W zadaniu sekcje takie jak „Przygotowanie”, „Wymagane działanie” i „Oddanie pracy” pomagają znaleźć potrzebne informacje. Sprawdź dokument w rzeczywistej postaci, również PDF lub stronę repozytorium, które udostępniasz.

Udostępniaj polecenia jako tekst, który da się zaznaczyć i skopiować. Nadawaj linkom nazwy wskazujące ich cel. Sprawdź, czy ważne instrukcje pozostają czytelne na wspieranych urządzeniach i w używanych formatach dokumentów. Jeśli strona oddania pracy zawiera elementy sterujące, uwzględnij ich obsługę klawiaturą w próbie. Samo przeczytanie zadania nie obejmuje całego doświadczenia.

Zapewnij kontakt jeszcze przed rozpoczęciem zadania. W amerykańskich wytycznych dotyczących [kandydatów do pracy i ustawy ADA](https://www.eeoc.gov/laws/guidance/job-applicants-and-ada) EEOC wyjaśnia, że pracodawca może opisać proces rekrutacji i zapytać, czy kandydat potrzebuje dostosowania tego procesu. Obsługuj takie prośby odpowiednim prywatnym kanałem. Informacji o diagnozach medycznych nie umieszczaj we wspólnych notatkach z oceny.

Przejście przez zadanie z jedną osobą pokazuje jej doświadczenie. Nie dowodzi dostępności dla każdego użytkownika ani pełnej zgodności z WCAG. Wcześniejszy poradnik o [jasnych instrukcjach dla kandydatów](/blog/clear-candidate-instructions-cognitive-accessibility) omawia oczekiwania, terminy i potwierdzenia. Opisana tu próba dostarcza dodatkowych informacji o tym, czy ktoś rzeczywiście potrafi przejść przez skonfigurowany proces.

## Zachowaj przetestowane instrukcje przy zadaniu w Kit

**Do ostatniej próby użyj rzeczywistej ścieżki kandydata.** Pola i podglądy pomagają przygotować materiały. Dopiero przejście całej ścieżki pokazuje, co ustawienia oznaczają w praktyce.

W [Kit Hiring](/hiring) zadanie programistyczne może korzystać z prywatnego repozytorium GitHub utworzonego z twojego szablonu. Konfiguracja obejmuje instrukcje, szacowany nakład pracy i ustawienia czasu. Kandydat łączy konto GitHub i otrzymuje zaproszenie do repozytorium. Przyjęcie tego zaproszenia rozpoczyna odliczanie czasu na wykonanie zadania. Strona kandydata pokazuje następnie instrukcje i możliwość oddania pracy; po upływie późniejszego nieprzekraczalnego terminu praca zostaje oddana automatycznie, a czas na rozwiązanie się kończy.

Zadanie próbne ma inny moment rozpoczęcia. Kandydat może najpierw przeczytać podsumowanie, a potem nacisnąć **Rozpocznij zadanie**, żeby odsłonić prywatną treść zadania i rozpocząć odliczanie. Przesyła wynik i otrzymuje potwierdzenie oddania pracy. Podczas próby własnego zadania wyraźnie uwzględnij te różnice; [dokumentacja doświadczenia kandydata](/docs/the-candidate-experience) opisuje obie ścieżki.

Kit zapewnia obsługę kolejnych kroków zadania. Twój zespół organizuje sesję z osobą, która nie zna materiałów, zapisuje przeszkody i decyduje, które poprawki zachowują cel oceny. Przekaż tej osobie planowane zaproszenie, obserwuj przygotowanie i oddanie pracy, a potem popraw i ponownie sprawdź przeszkody, które da się odtworzyć. Zrób to, zanim pierwszy kandydat będzie musiał odkryć je za ciebie.