Jak stworzyć test programistyczny

What you'll need

• Przestrzeń robocza w SkillCort (albo demo)
• Prawdziwy przykład kodu, który pisze Twój zespół — błąd, mała funkcjonalność, refaktor
• Starszy inżynier, który zdefiniuje zadanie i rubrykę
• Decyzja, które języki będziecie akceptować

Step 1: Wybierz realistyczne zadanie zamiast zagadki algorytmicznej

Spójrz na swój ostatni miesiąc pull requestów i wybierz zadanie w kształcie tych, które się powtarzają: napraw błąd przy zadanym błędnym zachowaniu, rozszerz małą funkcję o nowy przypadek, zrefaktoruj zabałaganiony blok albo napisz transformację danych. Te rzeczy przewidują codzienną skuteczność znacznie lepiej niż odwracanie drzewa binarnego.

Skroj je na 30–45 minut skupionej pracy kompetentnej osoby. Zagadka nagradza tego, kto ją przećwiczył; realistyczne małe zadanie nagradza tego, kto potrafi odczytać istniejącą intencję, wprowadzić rozsądną zmianę i zachować zrozumiałość kodu — a to właśnie zatrudniasz.

Usuń wiedzę specyficzną dla frameworka i dla firmy, chyba że rola naprawdę tego wymaga, a cały kontekst potrzebny zadaniu podaj wewnątrz samego briefu. Mocny inżynier, który nigdy nie dotykał Waszego stosu, wciąż powinien móc pokazać Ci rozsądny osąd. Testuj umiejętność, a nie znajomość ciekawostek Waszej bazy kodu.

• Powtarza się w Waszej prawdziwej bazie kodu, a nie w podręcznikach do rozmów rekrutacyjnych
• Ma więcej niż jedno rozsądne rozwiązanie
• Mieści się w 30–45 minutach bez bohaterstwa
• Możliwe do przeczytania przez oceniającego w mniej niż dziesięć minut

Step 2: Utwórz pytanie z kodem w banku pytań

Zrób folder dla roli — na przykład Inżynier backendu — z tagami obszaru umiejętności i trudności, a potem utwórz pytanie, używając typu pytania z kodem. Kandydaci piszą i edytują kod bezpośrednio w obszarze odpowiedzi, a oceniający później przeglądają go na miejscu.

Zasil pytanie kodem startowym zamiast pustym edytorem. Krótka funkcja z opisanym błędem albo zaślepka z jasnym kontraktem kotwiczy każdego kandydata w tym samym punkcie wyjścia i sprawia, że ich zmiany są wprost porównywalne. Prawdziwa praca prawie nigdy nie zaczyna się od pustego pliku i test też nie powinien.

Step 3: Napisz brief obok edytora

Użyj układu z materiałem obok siebie: brief, wymagania oraz przykładowe wejścia i wyjścia po jednej stronie, a obok edytor kodu. Kandydat nigdy nie odjeżdża od specyfikacji, żeby napisać rozwiązanie — ten sam kształt co praca ze zgłoszeniem w IDE.

Napisz brief tak, jak czyta się dobre zgłoszenie: obecne zachowanie, oczekiwane zachowanie, ograniczenia i dwa–trzy konkretne przykłady. Powiedz wprost, na czym Ci zależy — „najpierw działający kod; czytamy też pod kątem czytelności” — żeby kandydaci optymalizowali pod to, co faktycznie będziesz punktować. Niejednoznaczność w briefie zamienia się w szum w wynikach.

Step 4: Zbuduj rubrykę punktującą coś więcej niż poprawność

Poprawne wyjście jest konieczne, ale niewystarczające. Zbuduj rubrykę macierzową opartą na poziomach z trzema albo czterema kryteriami — zwykle poprawność, czytelność i podejście, opcjonalnie obsługa przypadków brzegowych — z których każde ma kotwiczące opisy tego, jak wygląda kod mocny, akceptowalny i słaby. „Nazwy ujawniają intencję, brak martwego kodu” da się punktować; „czysty kod” nie.

Zważ poprawność najmocniej, ale nie rób z pozostałych kryteriów ozdobnika: ledwo działające rozwiązanie, którego nikt nie utrzyma, nie jest mocnym sygnałem rekrutacyjnym. Gdy podpinasz rubrykę, zamraża się ona w migawkę, więc każdy kandydat w tym przebiegu jest przeglądany według identycznego standardu, nawet jeśli wersja w banku później się zmieni.

Step 5: Złóż i ustaw czas w kreatorze

Utwórz assessment jako sekcje, strony i bloki i zaimportuj pytanie z kodem przez selektor. Wiele zespołów dodaje krótką pierwszą sekcję z szybkimi pytaniami o osąd — odczytanie diffa, wskazanie błędu we fragmencie, szybko wklejone jako jednokrotny wybór — a zadanie programistyczne umieszcza w osobnej sekcji.

Ustaw całkowity limit czasu z zapasem na czytanie i myślenie, a na stronie z kodem użyj limitu na stronę, żeby zadanie nie połknęło całego podejścia. Zważ sekcję programistyczną najmocniej (na przykład ×3), żeby dopasowanie do roli na Decision Board odzwierciedlało pracę, a nie rozgrzewkę. Napisz instrukcje, które nazywają dozwolone języki i mówią, co się stanie, gdy skończy się czas.

Step 6: Zrób podgląd, wyczyść listę kontrolną i opublikuj

Użyj Preview as candidate i sam spróbuj wykonać zadanie, a jeszcze lepiej — poproś inżyniera, który go nie pisał, żeby podszedł do niego na zimno. Jeśli skończy w dziesięć minut, jest za łatwe; jeśli nie skończy w limicie, poluzuj zakres albo zegar. Popraw brief wszędzie tam, gdzie się zawahał.

Potem zaspokój listę kontrolną publikacji — blokuje ona Publish, dopóki punktacja, czas i instrukcje nie są kompletne. Test programistyczny z brakującą rubryką albo nieprzetestowanym limitem czasu nigdy nie powinien dotrzeć do kandydata, a lista kontrolna pilnuje, żeby nie mógł.

Step 7: Ustaw kontrole wiarygodności proporcjonalnie do stawki

Utwórz przeprowadzenie z nazwą i oknem czasowym, a potem świadomie wybierz przełączniki bezpieczeństwa. Przy standardowym przesiewie rekrutacyjnym blokowanie kopiowania i wklejania oraz tryb Lockdown na pełnym ekranie z sensownym limitem naruszeń zwykle wystarczą. Nagrywanie z kamery, nagrywanie ekranu, wykrywanie drugiego ekranu i sprawdzenie tożsamości istnieją dla przebiegów o naprawdę wysokiej stawce — certyfikacji, ostatnich rund — a nie jako ustawienia domyślne.

Wszystko, co włączysz, jest ujawnione na bramce zgody i sprawdzenia wstępnego, zanim kandydat zacznie. Sygnały wiarygodności są flagami do przejrzenia przez człowieka w kontekście, nigdy podstawą do automatycznego odrzucenia — wyjście z pełnego ekranu może być powiadomieniem, a nie oszustwem. Proporcjonalność sprawia, że mocni kandydaci nie odchodzą od sieci inwigilacji.

Step 8: Przeglądaj kod z rubryką, z AI jako wsparciem

Oceniający przeglądają każde rozwiązanie względem wspólnej rubryki, klikając kartę poziomu pasującą do kodu w każdym kryterium — poprawność, czytelność, podejście. Postawienie dwojga przeglądających przy przypadkach granicznych albo o wysokiej stawce utrzymuje standard uczciwym, a ponieważ wszyscy punktują względem tej samej zamrożonej migawki rubryki, spory wychodzą jako konkretne różnice w kryteriach, a nie jako mgliste różnice w przeczuciu.

AI może naszkicować podsumowanie rozwiązania i zaproponować wyniki na poziomie kryteriów — przy kodzie to naprawdę przydatne pierwsze przejście, z modelem i wersją zapisanymi do protokołu. Ale wskazany z nazwiska inżynier potwierdza albo zmienia każdy wynik. AI jest wsparciem decyzji — nigdy decydentem: odpowiedzialny osąd o kodzie kandydata zawsze należy do człowieka.