Poza LeetCode: jak oceniać pracę inżynierów korzystających z AI

Poprawne rozwiązanie zadania z LeetCode nie wystarcza do oceny pracy inżyniera. Jeśli na stanowisku liczy się utrzymanie systemu i weryfikowanie kodu AI, sprawdź również te umiejętności.

Badanie North Carolina State University i Microsoft z 2020 roku objęło 48 studentów informatyki. Osoby rozwiązujące zadanie przy obserwującym rozmówcy uzyskały gorsze wyniki niż osoby pracujące samodzielnie. Badanie wskazuje na wpływ warunków oceny, ale nie dowodzi, że każda rozmowa techniczna mierzy wyłącznie stres.

Czego nie rozstrzyga zadanie algorytmiczne

Zadanie algorytmiczne może sprawdzić znajomość struktur danych i sposób rozwiązywania problemu. Wynik zależy jednak także od przygotowania do formatu, presji czasu i dostępu do narzędzi. Nie traktuj go jako pełnej oceny umiejętności zawodowych.

Łamigłówka rekrutacyjna, zadanie algorytmiczne i przegląd kodu sprawdzają różne rzeczy. Nie przenoś wniosków o jednym formacie na wszystkie pozostałe.

Wpływ stresu i czasu na przygotowanie

Stres może utrudnić pokazanie umiejętności. Sam odsetek osób zgłaszających zdenerwowanie nie mówi jednak, ile z nich nie potrafi ukończyć zadania ani jak silny jest ten wpływ.

Doświadczona osoba może poświęcać więcej czasu na rozważenie ograniczeń produkcyjnych, a osoba dobrze przygotowana do LeetCode szybciej rozpoznać schemat zadania. Rozmowa powinna pozwolić sprawdzić tok rozumowania obu osób.

Czas na przygotowania też nie jest równomiernie dostępny. Długie zadania mogą ograniczać udział rodziców, opiekunów i osób łączących rekrutację z pracą. Podaj zakres, czas i zasady oceny z wyprzedzeniem.

Co AI zmieniło w produktywności inżynierskiej

Jeśli zespół korzysta z AI, ocena techniczna powinna obejmować także pracę z jego wynikami.

Kontrolowany eksperyment dotyczący GitHub Copilot wykazał, że programiści ukończyli zadanie z serwerem HTTP 55,8% szybciej z pomocą AI. Dalsze badania pokazują, że 73% programistów deklaruje łatwiejsze utrzymanie skupienia przy narzędziach AI, a 87% mniejszy wysiłek psychiczny przy powtarzalnych zadaniach. To samoocena; wynik eksperymentu z serwerem HTTP dotyczy jednego zadania i nie gwarantuje takiego przyspieszenia w każdym projekcie.

Weryfikacja wygenerowanego kodu wymaga umiejętności szerszych niż pisanie składni:

• Architektura systemów: projektowanie odpornych na awarie systemów rozproszonych, które obsługują przewidywany wzrost obciążenia
• Przegląd kodu: wyłapywanie sytuacji, gdy kod wygenerowany przez AI jest subtelnie, ale katastrofalnie wadliwy
• Rozumowanie o trybach awarii: przewidywanie kaskadowych awarii, lawiny ponownych prób, wyścigów i przypadków brzegowych, które AI może pominąć
• Komunikacja techniczna: tłumaczenie kompromisów architektonicznych osobom nietechnicznym i mentoring młodszych inżynierów

Umiejętność kandydata odwrócenia drzewa binarnego z pamięci nie wystarcza do ustalenia, czy potrafi zabezpieczyć rozproszoną bazę danych, zaprojektować idempotentną kolejkę czy odrzucić pewnie sformułowany, ale błędny pull request od asystenta AI.

Problem rezygnacji z własnego osądu

Powierzenie AI rutynowego zadania nie zwalnia z przeglądu wyniku. Rozważ przykład: asystent przygotowuje migrację bazy danych, a zespół zatwierdza ją po pobieżnym przeglądzie. Trzy tygodnie później brak indeksu okazuje się przyczyną stukrotnego spowolnienia zapytania przy większej liczbie danych. To hipotetyczny scenariusz ilustrujący koszt nieweryfikowania założeń, a nie udokumentowana codzienna awaria.

LLM to systemy probabilistyczne. Mogą wymyślić nieistniejące API, użyć przestarzałej metody lub wygenerować czytelny kod z błędem logicznym. Proces rekrutacji musi testować, czy kandydat będzie ślepo ufał wynikowi maszyny, czy ma wiedzę potrzebną, by sprawdzać, poprawiać i bezpiecznie wdrażać wygenerowany kod.

Cztery sposoby oceny technicznej przy pracy z AI

Dobierz metody do obowiązków. Metaanaliza Schmidta i Huntera z 1998 roku, podsumowująca 85 lat badań, podawała trafność 0,63 dla połączenia próbki pracy z testem ogólnych zdolności poznawczych. Nie jest to wynik połączenia zadania domowego z rozmową ustrukturyzowaną ani walidacja poniższego procesu rekrutacji programistów.

1. Przegląd repozytorium

Zamiast pisania kodu bez kontekstu, kandydaci prezentują swoją faktyczną pracę inżynierską. Oceniający analizują historię commitów, dyskusje w pull requestach, konfiguracje CI/CD i zapisy decyzji architektonicznych.

To ujawnia nawyki, które mają znaczenie od pierwszego dnia. Czy piszą testy przed wdrożeniem? Czy zajmują się długiem technicznym przyrostowo, zamiast pozwalać mu narastać? Czy dokumentują decyzje projektowe dla inżyniera, który będzie utrzymywał ten kod za dwa lata? Czy dają konstruktywne, konkretne code review, czy stemplują wszystko „LGTM”?

Pułapka do uniknięcia: portfolio generowane przez AI. Kandydaci mogą teraz generować nienagannie wyglądające pliki README, konwencjonalne opisy commitów i przeinżynierowane projekty poboczne, które wyglądają imponująco, ale nie ujawniają niczego. Prawdziwy sygnał jest w nieuporządkowanych częściach: dyskusjach w issue trackerze, rozwiązywaniu konfliktów merge, obsłudze przestarzałych zależności i głęboko zagnieżdżonych wątkach PR.

Dla kandydatów, których praca jest objęta poufnością (często w finansach, obronności, ochronie zdrowia), zaproponuj alternatywy: wyselekcjonowane niepoufne próbki kodu, pisemne zapisy decyzji architektonicznych lub możliwość wykonania zadania programistycznego.

2. Ocena biegłości w AI

Sprawdź, czy kandydat weryfikuje i poprawia kod wygenerowany przez AI. Sama umiejętność napisania polecenia nie odpowiada na to pytanie.

Przedstaw kandydatom realistyczny pull request wygenerowany przez AI, może 500-2000 linii funkcjonalnego, ale wadliwego kodu. Kod wygląda czysto, ale zawiera subtelne problemy: niezindeksowane zapytanie bazodanowe, które spowolni przy większej liczbie danych, wyhalucynowany endpoint API, wyciek pamięci ukryty za rozsądnie wyglądającą logiką.

Silni kandydaci:

• Sprawdzą testy przed zatwierdzeniem zmian
• Porównają założenia AI z dokumentacją
• Zidentyfikują przypadki brzegowe, które model pominął
• Wyjaśnią koszty utrzymania proponowanego kodu

Takie zadanie pozwala obserwować odpowiedzialność za kod przy pracy z AI.

3. Kontekstowe projektowanie systemów

Porzuć podpowiedzi typu „zaprojektuj Twittera”, które kandydaci zapamiętują z poradników przygotowawczych. Zamiast tego przedstaw problemy ograniczone przez rzeczywiste warunki operacyjne firmy: konkretne wymagania latencji, budżety kosztów infrastruktury, wymagania prawne dotyczące danych.

Na przykład zamiast „zaprojektuj skracacz URL” zapytaj: „Nasz pipeline analityczny przetwarza 50 mln zdarzeń dziennie z wymaganiem opóźnienia P99 na poziomie 200 ms. Musimy dodać wykrywanie anomalii w czasie rzeczywistym bez przekraczania obecnego budżetu infrastrukturalnego 30 tys. zł miesięcznie. Opowiedz o swoim podejściu.” Poproś o uzasadnienie kompromisów, a następnie zmień jedno z ograniczeń i sprawdź, jak kandydat dostosuje rozwiązanie.

Badaj rozumowanie o trybach awarii: Jak system degraduje się podczas awarii centrum danych? Jak nie dopuszczasz do tego, by lawiny ponownych prób w systemie rozproszonym położyły usługi zależne? Co się dzieje, gdy ruch skacze 10-krotnie w trakcie premiery produktu?

To testuje również komunikację. Czy kandydat potrafi uzasadnić decyzje o kompromisach osobie nietechnicznej? Czy potrafi dyskutować o alternatywach bez postawy obronnej? Czy potrafi wyjaśnić złożoną architekturę bez chowania się za żargonem? Najlepsi architekci potrafią przełożyć ograniczenia techniczne na język biznesowy.

4. Płatne zadania programistyczne

Zastąp rundę kodowania na żywo płatnym zadaniem zbliżonym do pracy na stanowisku. Daj kandydatom faktyczną (bezpiecznie zmniejszoną) bazę kodu z realnymi wadami operacyjnymi, złożoną logiką biznesową i celowo niejednoznacznymi wymaganiami. Pozwól im korzystać z własnego IDE, własnych narzędzi AI i własnego procesu pracy, dokładnie tak jak pierwszego dnia w pracy.

Oceniaj prace według wspólnej karty oceny obejmującej trwałość architektury, kompletność testów, czytelność dokumentacji i jakość kodu. Praca we własnym środowisku może ograniczyć część stresu, ale nie usuwa wszystkich barier udziału.

Przy zadaniu na 4–6 godzin ustal wynagrodzenie odpowiednie do zakresu. Kwotę kilkuset złotych traktuj jako przykład budżetu, nie uniwersalną stawkę. Popularny szacunek kosztu błędnego zatrudnienia wynosi co najmniej 30% rocznej pensji. Dla inżyniera z wynagrodzeniem 220–340 tys. zł rocznie koszty rekrutacji, wdrożenia, opóźnień i utraconej produktywności mogą być znaczne, ale nie wynikają automatycznie z tego mnożnika. Więcej o takich kosztach w analizie błędów rekrutacyjnych startupów.

Szczegółowy opis, jak określić zakres i strukturę tych projektów, znajdziesz w naszym poradniku o tym, jak przygotować zadania programistyczne o rozsądnym zakresie.

Porównanie metod oceny

Nie ma jednego rankingu, który określa jakość każdego zadania domowego i każdej rozmowy. Zestaw metody według tego, co pozwalają obserwować, oraz ich ograniczeń.

Zmiana kulturowa, której to wymaga

Zmiana formatu wymaga przygotowania prowadzących rozmowy. Omówcie, co obecne zadania sprawdzają dobrze, a jakich umiejętności nie pozwalają ocenić. Przygotujcie nową kartę na przykładzie rozwiązania.

Przy zmianie procesu zaplanuj:

• Szkolenie: oceniający muszą nauczyć się symulować realne środowiska inżynierskie i badać tok rozumowania, nie wyuczone odpowiedzi
• Kalibrację: oceny muszą odnosić się do konkretnych obserwacji (czy kandydat samodzielnie wyłapał wyhalucynowaną metodę w testowym PR?)
• Czas na ocenę: przeglądanie repozytoriów i ocenianie projektów domowych zajmuje więcej czasu niż obserwowanie kogoś zmagającego się z tablicą

Porównaj koszt prowadzenia procesu, rezygnacje kandydatów i późniejsze wyniki zatrudnionych osób. Nie zakładaj, że zmiana formatu sama zapewni niższą rotację. Zapytaj też kandydatów, czy zadania odpowiadały opisanej pracy.

Jak Kit wspiera ocenę techniczną

Kit pozwala połączyć zadania i ocenę zespołową w jednym procesie. Więcej o sposobie pracy z AI w artykule o systemie ATS opartym na AI.

Zadania programistyczne są zintegrowane bezpośrednio z pipeline rekrutacyjnym: tworzenie repozytoriów GitHub z szablonów, automatyczne zaproszenia kandydatów, zarządzanie terminami i dostęp dla recenzentów, z obsługą pracy w GitHubie. Kandydaci uwierzytelniają się za pomocą linku z e-maila i przesyłają pracę przez portal kandydata.

Ocena zespołu i głosowanie pozwalają wielu prowadzącym rozmowy oceniać kandydatów według wspólnych kart oceny niezależnie od siebie, zanim zobaczą oceny pozostałych, redukując myślenie grupowe i efekt zakotwiczenia.

Informacje o etapach i zgłoszeniach są dostępne zgodnie z uprawnieniami zespołu. Wyznacz osoby odpowiedzialne za przegląd i kolejny kontakt.