Review projektu w rekrutacji seniora: gotowy scenariusz

Review projektu technicznego w rekrutacji seniora polega na ocenie dostarczonej propozycji, ustaleniu kolejności potrzebnych zmian i wyjaśnieniu, jak dalej pracować nad rozwiązaniem. Każdy kandydat dostaje te same wymagania, a jego rozumowanie ocenia się według jawnych kryteriów. Liczy się to, jak łączy decyzję z jej konsekwencjami.

Ten format odpowiada konkretnemu obowiązkowi: sprawdzeniu propozycji innego inżyniera, zanim zespół zdecyduje się ją zrealizować. Daje podstawę do rzeczowej rozmowy. Kandydat nie musi wymyślać całego systemu ani przynosić poufnych dokumentów poprzedniego pracodawcy.

Poradnik Michaela Lyncha o pisaniu przydatnej dokumentacji projektu technicznego wywołał w tym tygodniu nową dyskusję na Hacker News. W artykule z czerwca 2026 roku autor przekonuje, że taka dokumentacja powinna skupiać uwagę na decyzjach o istotnych konsekwencjach, a nakład pracy odpowiadać zadaniu. To podsuwa pytanie do rozmowy rekrutacyjnej: czy kandydat potrafi rozpoznać, którymi decyzjami trzeba zająć się najpierw?

Poniższe zadanie to autorski, fikcyjny przykład do dostosowania. Czas, założenia i zasady oceny są propozycjami redakcyjnymi, a nie zwalidowanym testem rekrutacyjnym. Nie przypisujemy mu określonej trafności przewidywania ani wpływu na wyniki rekrutacji.

Zacznij od odpowiedzialności przewidzianej na stanowisku

Wykorzystaj review projektu, jeśli ocena takich propozycji należy do rzeczywistych obowiązków. Sam tytuł seniora nie mówi, czy dana osoba będzie sprawdzać kontrolę dostępu, przetwarzanie danych, interakcje we frontendzie czy zmiany infrastruktury.

Ustal z osobą prowadzącą rekrutację jedno zdanie: „Ten inżynier będzie oceniał proponowane zmiany w backendzie obsługującym klientów i pomagał zespołowi decydować, co można wdrożyć”. Następnie określ, jakie decyzje musi umieć podejmować od początku, a co może poznać już w pracy.

Wytyczne dotyczące analizy stanowiska amerykańskiego Office of Personnel Management łączą decyzje rekrutacyjne z rzeczywistymi zadaniami i potrzebnymi kompetencjami. Stosuj tę zasadę do konkretnej roli. Jeśli stanowisko dotyczy głównie rozwoju produktu we frontendzie, zadanie o eksporcie z backendu trzeba zastąpić innym, nawet gdy prowadzący rozmowy lubią dyskutować o kolejkach.

Podobnie wytyczne OPM dotyczące próbek pracy wskazują na kompetencje wymagane już w momencie zatrudnienia. Znajomość wewnętrznej konwencji nie powinna być ukrytym warunkiem zaliczenia, jeśli zamierzasz nauczyć jej nową osobę po przyjęciu do zespołu.

Jeszcze przed wysłaniem zaproszeń przełóż obowiązki na zachowania, które da się zaobserwować. Pomoże w tym poradnik tworzenia profilu idealnego kandydata. Zawęź zadanie tak, by recenzent potrafił wyjaśnić, jakiej części ogłoszonego stanowiska dotyczy każde kryterium.

Przekaż kandydatom komplet materiałów

Dostarcz kontekst potrzebny do uzasadnienia odpowiedzi. Materiały powinny zawierać cel, ograniczenia operacyjne, proponowane rozwiązanie, oczekiwaną formę odpowiedzi i warunki pracy.

Na pierwszy pilotaż można zaproponować 30 minut przygotowania i 30 minut rozmowy. To wartości do sprawdzenia z kolegami, nie zmierzony czas wykonania. Jeśli materiałów nie da się przeanalizować w zapowiedzianym czasie, skróć je przed użyciem w rekrutacji.

Powiedz kandydatom, że wystarczą krótkie notatki i że nie oceniasz wyglądu slajdów, stylistycznego dopracowania tekstu ani liczby komentarzy. Udostępnij dostępną cyfrowo wersję tekstową. Wyjaśnij, jak poprosić o zmianę formatu lub czasu, i podaj kontakt do pytań.

Określ zasady korzystania z dokumentacji, wyszukiwarki, pomocy AI i współpracy z innymi. Jeśli wymagane jest konkretne narzędzie, zapewnij dostęp. Rozmowa może pokazać więcej z toku rozumowania kandydata, ale nie potwierdza autorstwa i nie wyklucza pomocy z zewnątrz.

Użyj danych syntetycznych i fikcyjnego projektu. Nie proś o wewnętrzne dokumenty poprzedniego pracodawcy ani nie wykorzystuj zadania do rozwiązania aktualnego problemu produkcyjnego. Kwestie nakładu pracy, wynagrodzenia i komunikacji omawia poradnik przygotowywania zadań programistycznych.

Wypróbuj fikcyjny projekt eksportu danych klienta

Poproś o ocenę ograniczonej propozycji, zamiast zlecać projektowanie platformy eksportowej od zera. Wszystko w tej sekcji powinno znaleźć się w materiałach dla kandydata, łącznie z ograniczeniami, przy których różne odpowiedzi mogą mieć sens.

Kontekst przekazany kandydatowi

Fikcyjna firma prowadzi aplikację biznesową. Każda organizacja klienta ma własne rekordy. Uprawnieni administratorzy po stronie klienta chcą eksportować rekordy swojej organizacji do pliku CSV, czyli formatu tekstowego otwieranego w arkuszu kalkulacyjnym.

Pierwsza wersja ma następujące wymagania i ograniczenia:

• Administrator może zamówić eksport rekordów swojej organizacji.
• Plik zawiera prywatne informacje klienta. Samo zalogowanie nie uprawnia do dostępu do danych każdej organizacji.
• Największy obecny klient ma 200 000 rekordów. Nie zmierzono czasu generowania eksportu ani szczytowego zużycia pamięci.
• Klienci mogą czekać na gotowy plik do dziesięciu minut. W pierwszej wersji nie potrzebują eksportów według harmonogramu.
• Aplikacja ma już procesy wykonujące zadania w tle i prywatny magazyn plików.
• Dwóch inżynierów ma tydzień na pierwszą wersję. Mogą ograniczyć początkowy zakres, jeśli wyjaśnią skutki dla klientów.
• Zespół nie ustalił jeszcze okresu przechowywania plików ani zachowania systemu, gdy administrator straci dostęp po zamówieniu eksportu.

Te liczby określają wymyślony scenariusz. Nie są zaleceniami dotyczącymi wielkości aplikacji, terminów realizacji ani obsady zespołu.

Propozycja do oceny

Dodaj przycisk Eksport do panelu klienta. Przeglądarka wysyła identyfikator organizacji do nowego endpointu. Endpoint sprawdza, czy osoba wysyłająca żądanie jest zalogowana, pobiera rekordy organizacji, tworzy CSV i zapisuje plik w magazynie. Następnie zwraca URL do pobrania.

Zapisz URL w profilu użytkownika, aby panel mógł pokazywać jego ostatni eksport. URL pozostaje ważny bezterminowo. Po przekroczeniu czasu żądania wyświetl błąd i poproś użytkownika o ponowne kliknięcie przycisku Eksport.

Uwzględnij wszystkie dostępne pola, aby uniknąć późniejszych próśb o uzupełnienia. Dodaj test pokazujący, że zalogowany użytkownik otrzymuje link do pobrania. Po wdrożeniu dodaj cykliczne eksporty i konfigurowalny kreator eksportu.

Propozycja jest celowo niepełna. Powiedz to wprost. Kandydat ma ją poprawić, a nie zgadywać, czy prowadzący rozmowę potajemnie uważa ją już za poprawną.

Oczekiwana odpowiedź

Poproś o cztery rzeczy:

1. Wskaż trzy zmiany, które potraktujesz priorytetowo przed pierwszym wdrożeniem. Wyjaśnij, jakim konsekwencjom zapobiega każda z nich.
2. Zaproponuj sposób wdrożenia zgodny z podanymi ograniczeniami. Określ, co pominiesz.
3. Wymień jedno otwarte pytanie, którego odpowiedź mogłaby zmienić twoją rekomendację.
4. Opisz, jakich dowodów potrzebujesz przed zatwierdzeniem zmiany, w tym testów lub pomiarów.

Implementacja nie jest wymagana. Kandydaci mogą przygotować szkic, listę punktów albo krótki dokument. Mogą jawnie wskazywać założenia, ale nie powinni zmieniać podanego wymagania bez zaznaczenia tego, by dopasować je do ulubionej architektury.

Szukaj priorytetów wynikających z propozycji

Przydatne review odróżnia problem blokujący wdrożenie od pytania, usprawnienia i pracy na później. Dwanaście uwag nie daje automatycznie lepszej odpowiedzi niż trzy istotne problemy i spójny sposób ich rozwiązania.

W tym zadaniu dostęp stanowi konkretny problem. Propozycja ufa identyfikatorowi organizacji przesłanemu przez przeglądarkę i opisuje jedynie sprawdzenie logowania. Kandydat powinien powiązać tę lukę z wymaganiem dostępu administratorów wyłącznie do rekordów własnej organizacji. „Dodać zabezpieczenia” mówi mniej niż wyjaśnienie, gdzie trzeba sprawdzać uprawnienia.

Generowanie pliku w ramach żądania HTTP również wymaga analizy. Podana liczba rekordów i brak pomiarów nie dowodzą, że synchroniczne generowanie się nie powiedzie. Oznaczają jednak, że propozycja nie wykazuje jeszcze, czy operacja będzie niezawodnie kończyć się w granicach czasu i zasobów żądania. Zwróć uwagę, czy kandydat odróżnia zaobserwowany problem od ryzyka wymagającego sprawdzenia.

Bezterminowy link i nieustalone zachowanie po utracie dostępu ujawniają brak decyzji produktowej. Dobre review może postawić pytanie, kto i jak długo powinien móc pobierać gotowy plik. Nie powinno wymyślać okresu przechowywania i przedstawiać tej preferencji jako wymagania podanego w materiałach.

Wytyczne Google dotyczące code review wskazują na projekt, działanie, przypadki brzegowe i złożoność, w tym zbędną pracę nad hipotetycznymi przyszłymi potrzebami. To przydatne obszary oceny również tutaj. Wytyczne dotyczą jednak review technicznego, nie trafności tego zadania rekrutacyjnego.

W tym przypadku konfigurowalny kreator eksportu może poczekać, bo pierwsza wersja go nie wymaga. Jeśli kandydat poświęca review na jego projektowanie, powinien wyjaśnić, dlaczego zasługuje ono na czas przed rozstrzygnięciem opisanych kwestii dostępu i dostarczenia pliku.

Dopuść więcej niż jeden uzasadniony plan wdrożenia

Oceniaj zgodność planu z ograniczeniami, a nie z ulubioną implementacją recenzenta. Zapisz sensowne alternatywy przed rozmowami, by niewypowiedziana preferencja nie stała się wymaganiem.

Jeden kandydat może zaproponować generowanie w tle przy użyciu istniejących procesów, zapis każdego żądania eksportu, prywatny magazyn i ścieżkę pobierania z kontrolą uprawnień. Może wyjaśnić obsługę powtórzonych żądań, informowanie użytkownika o gotowości lub błędzie oraz pomiary potwierdzające osiągnięcie celu dziesięciu minut.

Inny może zacząć od mniejszej wersji dla klientów poniżej jasno określonego limitu wielkości danych. Najpierw zmierzy generowanie, a potem zdecyduje, ile pracy przenieść do zadania w tle. Takiej odpowiedzi musi towarzyszyć wyraźne zastrzeżenie: największy klient nie będzie jeszcze obsługiwany. Kandydat powinien uzyskać zgodę na ograniczenie zakresu, zamiast twierdzić, że pierwotne wymaganie zostało spełnione.

Oba plany nadal wymagają odpowiednich kontroli uprawnień i jawnej decyzji o dostępie do pliku wraz z upływem czasu. Prostsza implementacja nie usprawiedliwia pominiętych wymagań. Bardziej rozbudowana nie zasługuje na dodatkowe punkty tylko dlatego, że ma więcej komponentów.

Porównaj uzasadnienia. Czy kandydat wyjaśnia, co może zawieść, kto to zauważy i jakie dowody zmienią decyzję? Czy wskazuje koszt własnej rekomendacji? Takie obserwacje są bardziej przydatne niż liczenie terminów architektonicznych.

Można też zapisać uzasadniony sprzeciw. Jeśli kandydat kwestionuje cel dziesięciu minut albo tygodniowy termin, zapytaj, co powie osobie odpowiedzialnej za produkt i jaką zaproponuje alternatywę. Podważenie ograniczenia to co innego niż przeoczenie go.

Zadawaj te same główne pytania uzupełniające

Zaplanuj rozmowę przed przeczytaniem odpowiedzi kandydata. Główne pytania powinny być jednakowe, a pytania doprecyzowujące służyć zrozumieniu przedstawionego rozumowania.

Wytyczne OPM dotyczące rozmów ustrukturyzowanych opisują pytania ustalone z wyprzedzeniem i wspólne standardy oceniania. W tym zadaniu można zastosować tę zasadę przez krótki scenariusz rozmowy:

• Który problem rozwiążesz najpierw i dlaczego przed pozostałymi?
• Co skłoniłoby cię do wybrania innego sposobu wdrożenia?
• W których miejscach plan zależy od informacji, których nie podaliśmy?
• O sprawdzenie czego poprosisz innego specjalistę?

Następnie przekaż każdemu kandydatowi ten sam dodatkowy fakt: „Zespół produktowy potwierdza, że administratorzy tracący dostęp nie mogą już pobierać wcześniej wygenerowanych eksportów”. Zapytaj, co zmienia to w planie i co trzeba przetestować.

Uprzedź kandydatów, że podczas rozmowy pojawi się dodatkowe wymaganie. Ma to dać okazję do zmiany decyzji, a nie zaskoczyć zadaniem sprawdzającym reakcję pod presją. Zapisz, czy kandydat wyjaśnia zmianę, wskazuje istniejące zabezpieczenie czy potrzebuje dalszych informacji.

Nie wymyślaj coraz trudniejszych scenariuszy dla osób, które robią dobre wrażenie. Jeśli jedna dostaje awarię regionalną, a druga zmianę tekstu, ich oceny dotyczą różnych zadań.

Opieraj oceny na konkretnych obserwacjach

Ustal znaczenie każdej oceny przed wspólnym omówieniem. Kryterium powinno prowadzić do notatki, którą inny recenzent może przeanalizować, a nie etykiety w rodzaju „sprawia wrażenie seniora”.

Poniższa tabela to proponowany punkt wyjścia. Dostosuj obszary do stanowiska i sprawdź opisy ocen w pilotażu. Odpowiedź „za mało danych do oceny” powinna pozostać dostępna, gdy zadanie lub rozmowa nie pozwoliły zaobserwować wystarczająco dużo.

Notatka z obserwacją może brzmieć: „Wskazał potrzebę sprawdzania uprawnień do organizacji; poprosił o test z administratorem innej organizacji”. Inna: „Zalecił kolejkę, ale nie powiązał jej z czasem żądania ani nie wyjaśnił obsługi błędów”.

Oddziel te obserwacje od końcowej decyzji o zatrudnieniu. Jedno zadanie sprawdza fragment obowiązków. Nie rozstrzyga o umiejętności programowania, wszystkich kompetencjach współpracy ani gotowości do podjęcia wszystkich obowiązków na poziomie seniora. Poradnik o ustrukturyzowanych kartach oceny opisuje, jak uporządkować kryteria w całym procesie.

Uzgodnij sposób oceniania przed użyciem zadania

Sprawdź, czy recenzenci rozumieją materiały i tak samo stosują opisy ocen. Poproś kolegów o wykonanie zadania i zanotuj faktyczny nakład pracy. Niech recenzenci ocenią odpowiedzi niezależnie, zanim wspólnie je omówią.

Gdy recenzenci się nie zgadzają, ustal przyczynę. Czy ktoś nagradza wymienienie konkretnej usługi? Czy inna osoba zakłada wymaganie nieobecne w materiałach? Czy odpowiedź była niejednoznaczna, czy opis oceny zbyt szeroki? Popraw zadanie lub instrukcję, zanim kandydaci napotkają ten sam problem.

Przy każdej ocenie zachowaj wersję materiałów i scenariusza rozmowy. Jeśli zmieniasz wymagania między rozmowami, zapisz zmianę i rozważ, czy wcześniejsze oceny nadal można porównywać. Nie poprawiaj instrukcji bez odnotowania tego w połowie naboru.

Zapytaj uczestników pilotażu, gdzie zabrakło kontekstu i które polecenia niepotrzebnie zabierały czas. Usuń pracę, która nie służy żadnemu jawnemu kryterium. Pilotaż pomaga usprawnić organizację zadania; nie dowodzi jego trafności prognostycznej ani braku stronniczości.

Wybierz recenzentów rozumiejących oceniane decyzje. Jeśli zadanie zamienia się w specjalistyczny sprawdzian bezpieczeństwa, zaangażuj kompetentnego recenzenta i jasno określ to wymaganie albo zawęź zadanie. Osoba prowadząca rekrutację odpowiada za zgodność stanowiska, ćwiczenia i składu komisji.

Zorganizuj etap review projektu w Kit

Powiąż opis zadania, kryteria i obserwacje recenzentów z etapem kandydata. Zespół rekrutujący nadal musi przygotować odpowiednie ćwiczenie i zdecydować, jakie wnioski wynikają z zebranych dowodów.

W Kit umieść dostarczony dokument w prywatnym opisie zadania próbnego i zbierz pisemną ocenę propozycji przygotowaną przez kandydata, w postaci pliku lub linku do odpowiedzi. Przypisz recenzentów i kryteria, a potem zaplanuj omówienie jako rozmowę na żywo. Kryteria mogą mieć opisy, wagi i skale; zasady oceniania przygotowuje twój zespół.

W trakcie aktywnej rundy oceny recenzenci najpierw przesyłają własną ocenę, a dopiero potem widzą ukończone oceny pozostałych osób. Wspiera to ustaloną kolejność pracy, ale nie dowodzi bezstronności ani poprawności. Kit nie dostarcza zwalidowanego testu review projektu ani nie ocenia automatycznie architektury.

Ustal ostateczny opis i zasady oceny zadania próbnego przed zaproszeniem kandydatów: warunki oceny zostają zablokowane, gdy pierwszy kandydat trafia do etapu. Jeśli skonfigurujesz wynagrodzenie, Kit rejestruje zlecenie wypłaty; pieniądze wysyła twój zespół.

Zacznij od jednego obowiązku, jednej dostarczonej propozycji i krótkiej listy decyzji, które kandydat powinien umieć wyjaśnić. Przeprowadź pilotaż z recenzentami, usuń niejasności i powiedz kandydatom dokładnie, jakiej pracy oczekujesz.