Jak sprawdzać realne umiejętności inżynierów w erze AI

Żeby sprawdzić realne umiejętności inżyniera w czasach, gdy AI potrafi podstawić gotowe odpowiedzi, pozwól na AI w zadaniu i oceniaj to, jak kandydat nim kieruje, jak weryfikuje i poprawia jego wyniki. Daj zadanie typu „znajdź błąd i rozwiń” na kodzie, którego sam nie pisał, a potem przejdź przez uporządkowaną rubrykę, która wyżej punktuje rozumowanie, walidację wyniku i myślenie o kompromisach niż samą poprawność kodu. Wąskie gardło tej pracy przesunęło się z pisania kodu na jego weryfikację, więc Twoja rozmowa rekrutacyjna powinna mierzyć właśnie weryfikację.

Po samych zgłoszeniach nie odróżnisz już dwóch kandydatów. Jeden kieruje asystentem AI z osądem, wyłapuje jego błędy i dostarcza coś solidnego. Drugi promptuje ten sam model, dostaje kod, który wygląda na działający, i nie ma pojęcia, że jest błędny. Obaj zaliczą zadanie domowe. Różnica wychodzi dopiero później — na produkcji, w kolejce do code review i w zaufaniu, które traci Twój zespół. To problem projektowania rekrutacji i da się go rozwiązać bez zakazywania AI i bez bawienia się w detektywa. Szerszy obraz rynkowej zmiany, która za tym stoi, opisaliśmy w tekście o załamaniu wartości dyplomów.

Problem z podażą, który zespoły rekrutacyjne właśnie odziedziczyły

Pula kandydatów jest coraz pełniejsza inżynierów, którzy potrafią dowieźć kod z asystentem, ale nie potrafią rozumować bez niego. Najczytelniejszy dowód płynie z uczelni, które ich kształcą — tam liczba ocen niedostatecznych wystrzeliła, a wykładowcy otwarcie wskazują nadużywanie AI jako przyczynę.

Wiosną 2026 roku odsetek niezaliczeń na kursie CS 10 na UC Berkeley sięgnął 35,3% — wobec mniej niż 10% zarówno wiosną 2024, jak i wiosną 2025, według danych o ocenach podanych przez Daily Californian. Na CS 61A odnotowano 10,6% ocen niedostatecznych, a na EECS 127 — 16,8%. Średnia ocen w semestrze spadła do mniej więcej C+ (2,3 GPA), znacznie poniżej zalecanego przez wydział przedziału 2,8–3,3.

Wykładowca Dan Garcia przypisał ten upadek „ogromnemu wzrostowi nieuczciwości akademickiej” wynikającemu z korzystania z dużych modeli językowych, wskazując na blisko 30 studentów przyłapanych na ściąganiu przy egzaminach domowych z samego CS 10. Profesor Gireeja Ranade zauważyła, że studenci nie radzą sobie z wymaganą wcześniej algebrą liniową; jeden z nich wyznał, że na jego kursie algebry liniowej obowiązywała „polityka otwartego internetu i otwartego AI” przy pracach domowych i egzaminach. Od tego czasu ponad 1300 wykładowców UC podpisało petycję o przywrócenie egzaminów SAT i ACT przy rekrutacji na kierunki STEM.

Ten kurs algebry liniowej z „polityką otwartego AI” to cały problem w pigułce. AI nie pomogło studentom po prostu oszukać na egzaminie z informatyki. Zamaskowało braki w fundamentach jedno piętro wyżej, tak że student potrafi zaliczyć kurs, którego wymagań nigdy naprawdę nie opanował. Zanim taka osoba trafi do Twojego procesu rekrutacyjnego, luka jest na papierze niewidoczna i wychodzi na jaw dopiero wtedy, gdy coś się psuje, a asystent się myli.

Dlaczego zakaz AI na rozmowie mierzy nie tę pracę

Zakaz AI na rozmowie technicznej testuje sposób pracy, którego nie używa już żaden praktykujący inżynier. Optymalizuje Twoje zadanie pod umiejętność, której praca już sama w sobie nie nagradza — a do tego takiego zakazu i tak nie da się wyegzekwować.

AI wrosło dziś w normalne wytwarzanie oprogramowania. Badanie firmy Sonar State of Code Developer Survey 2026, oparte na ponad 1100 programistach, wykazało, że 42% commitowanego kodu jest już generowane lub wspomagane przez AI, z prognozą wzrostu do 65% w 2027 roku. W Google CEO Sundar Pichai poinformował w aktualizacji z kwietnia 2026, że mniej więcej 75% nowego kodu powstaje z udziałem AI i jest recenzowane przez inżynierów — wobec 50% poprzedniej jesieni (wg relacji Exponent i Tekedii o wewnętrznym programie). Skoro trzy czwarte nowego kodu w czołowej organizacji inżynierskiej zaczyna się od asystenta, to rozmowa, która tego asystenta zakazuje, mierzy fikcję.

Liderzy inżynierscy już czują, że ten pomiar się sypie. Raport Karat 2025–2026 AI Workforce Transformation Report, oparty na 400 liderach inżynierskich z USA, Indii i Chin, pokazał, że 71% uważa, iż AI utrudnia ocenę umiejętności technicznych. Ten sam raport zwraca uwagę, że silni inżynierowie są dziś wyceniani na trzykrotność (lub więcej) swojego całkowitego wynagrodzenia, co podnosi koszt pomyłki na etapie selekcji. Odpowiedź branży to dopuszczenie AI, a nie zakaz: według analizy IEEE-USA z kwietnia 2026 około 38% organizacji pozwala już na AI w rozmowach technicznych, przy adopcji wśród pracodawców z Nowego Jorku na poziomie blisko 25% i prognozie wzrostu w kierunku 50%. Pozwalają na to już m.in. Canva, Rippling, Red Hat, Meta i Shopify.

Dlaczego „złap oszusta” to przegrany wyścig zbrojeń

Próba przyłapywania na korzystaniu z AI to walka, którą będziesz przegrywać raz za razem. Narzędzia do wykrywania są o krok za narzędziami do oszukiwania, a dystans się powiększa — więc każda strategia oparta na „zakaż i przyłap” psuje się w chwili, gdy ją wdrożysz.

Liczby są bezlitosne. Według Fabric, który przeanalizował ponad 50 000 kandydatów, ściąganie z pomocą AI przy zadaniach domowych ponad podwoiło się — z 15% w czerwcu 2025 do 35% w grudniu 2025. Współczesne narzędzia rozwiązują standardowe zadania domowe w niecałe pięć minut i wyświetlają odpowiedzi przez niewidoczne nakładki GPU, które nigdy nie pojawiają się przy współdzieleniu ekranu. Fabric podaje, że 59% menedżerów rekrutujących już podejrzewa kandydatów o używanie AI w zadaniach, a liderzy z badania Karat szacują, że ponad połowa kandydatów korzysta z AI nawet wtedy, gdy się tego zakazuje. Patrząc dalej w przyszłość, Gartner przewiduje, że do 2028 roku jeden na cztery profile kandydatów będzie fałszywy — sklecony z syntetycznego tekstu, głosu lub deepfake’ów (cyt. za Fabric).

Nie wygrasz wyścigu o renderowanie z oprogramowaniem, które ukrywa się przed ekranem. Więc przestań próbować. Porażka wykrywania to nie powód do rozpaczy — to argument za zmianą tego, co mierzysz. Skoro nie da się rzetelnie stwierdzić, czy użyto AI, zaprojektuj zadanie tak, by to nie miało znaczenia — bo dobre korzystanie z AI to dokładnie ta rzecz, którą chcesz zaobserwować.

Prawdziwy sygnał przesunął się z generowania na weryfikację

Deficytowa umiejętność to już nie wytwarzanie kodu. To ocena, czy kod wyprodukowany przez asystenta jest faktycznie poprawny — i naprawienie go, gdy nie jest. Sonar nazywa to wprost: efektem netto AI jest „wąskie gardło weryfikacji”, a nie czysty wzrost produktywności.

Dane stojące za tym sformułowaniem dają do myślenia. W badaniu Sonara 96% programistów nie ufa w pełni kodowi generowanemu przez AI, a mimo to tylko 48% zawsze weryfikuje go przed commitem, zaś 38% przyznaje, że recenzja kodu AI kosztuje więcej wysiłku niż recenzja kodu człowieka. Ten koszt weryfikacji nie znika też na bramce QA. Raport Lightrun 2026 State of AI-Powered Engineering wykazał, że 43% zmian w kodzie generowanym przez AI wymaga ręcznego debugowania na produkcji już po przejściu QA i środowiska staging (wg relacji VentureBeat).

Zestaw te dwa fakty razem. Duża i rosnąca część kodu jest generowana przez AI, a duża jej część jest subtelnie błędna w sposób, który przeżywa automatyczne kontrole i trafia na produkcję. Inżynier, który tworzy wartość w takim świecie, to ten, kto czyta wynik krytycznie, buduje minimalną reprodukcję, sprawdza logi i udowadnia poprawkę, zamiast ufać modelowi. To właśnie tę zdolność musi obnażyć Twoja rozmowa. Skoro wąskim gardłem pracy jest weryfikacja, to zadanie powinno mierzyć weryfikację.

Co naprawdę warto mierzyć: kieruje, weryfikuje, poprawia

Przestań punktować to, czy kandydat napisał poprawną funkcję. Zacznij oceniać to, jak kieruje asystentem, jak weryfikuje jego wynik i jak wychodzi z opresji, gdy ten się myli. To model, który czołowe programy już przyjęły, i dobrze się przekłada na pętlę w rozmiarze startupu.

Opisywany pilotaż Google z asystentem AI pozwala na zatwierdzonego asystenta w rundzie kodowania dla stanowisk junior i mid w USA i ocenia „biegłość w AI, w tym prompt engineering, walidację wyniku i umiejętności debugowania”. Co kluczowe, kandydaci, którzy „mocno opierają się na AI, nie pokazując własnego zrozumienia”, dostają negatywną ocenę. Ten jeden wybór projektowy to cała teza: biegłość daje punkty, zależność je odbiera. DoorDash poszedł dalej i zastąpił klasyczną rundę kodowania 60-minutową sesją roboczą z udziałem AI na realistycznym projekcie, ocenianą pod kątem „użycia narzędzi, podejścia do debugowania, osądu i komunikacji w warunkach realnych ograniczeń”. Zespół inżynierski DoorDash mówi wprost, że „prawdziwym wyróżnikiem są decyzje, rozumowanie na poziomie systemu i poczucie odpowiedzialności”.

Materiały rekrutacyjne programów takich jak Formation i Sierra zbiegają się w tym samym języku walidacji: silni kandydaci „tworzą minimalną reprodukcję, czytają logi i piszą celowane testy, by udowodnić, że poprawka działa, zamiast ślepo ufać wynikowi AI”. Dwa formaty zadań pokazują to najlepiej.

Zadanie „znajdź błąd i rozwiń” na kodzie, którego kandydat nie pisał

Najbardziej diagnostyczne ćwiczenie to czytanie i naprawianie kodu, którego kandydat nie napisał. „Czy potrafisz przeczytać cudzy kod, znaleźć, co jest nie tak, i to naprawić?” to pytanie, którego zależność od AI nie udźwignie — bo to praca polegająca na weryfikacji, a nie na generowaniu. Daj kandydatowi małą, częściowo działającą bazę kodu z podłożonym błędem logicznym — takim, który wygląda poprawnie i przechodzi naiwny test. Potem poproś, żeby go znalazł, naprawił i rozwinął system o jedną realistyczną funkcję.

AI jest wprost dozwolone. Patrzysz na to, jak kandydat orientuje się w nieznanym kodzie, czy reprodukuje błąd, zanim go „naprawi”, czy ufa pierwszej podpowiedzi asystenta, czy ją sprawdza, i jak reaguje, gdy model z pełnym przekonaniem proponuje coś błędnego. Kandydat zależny wkleja błąd do prompta i dostarcza to, co wróci. Biegły używa asystenta, żeby działać szybciej, biorąc na siebie każdą decyzję.

Rozmowa o projekcie systemu, która wymusza kompromisy

Połącz zadanie debugowania z rozmową o projekcie systemu, która wymusza jawne rozważanie kompromisów. Nie „zaprojektuj Twittera”, ale wąsko zakrojona, konkretna decyzja: jak byś to cache’ował, gdzie to pęka pod obciążeniem, co tracisz, wybierając prostszą opcję? AI potrafi naszkicować diagram architektury. Nie potrafi za to, w żywej wymianie zdań, obronić wyboru, który podważasz, ani skorygować go, gdy dorzucasz ograniczenie. Rozmowa pokazuje, czy rozumowanie należy do kandydata, czy do modelu.

Rubryka: pięć kryteriów wartych punktowania

Niech rubryka będzie krótka, behawioralna i przechylona ku osądowi kosztem samego wyniku. Oceniaj każdego kandydata według tych samych pięciu kryteriów, żeby sygnał był porównywalny w całym procesie.

1. Dobrze kieruje AI. Klarowne, celowe prompty; wie, o co i po co pyta, zamiast wklejać cały problem w nadziei, że się uda.
2. Weryfikuje wynik. Reprodukuje, czyta logi, pisze celowane testy; nie commituje na wiarę.
3. Poprawia błędy AI. Wyłapuje podpowiedź, która brzmi sensownie, ale jest błędna, i wyjaśnia, dlaczego jest błędna.
4. Rozumuje o kompromisach. Broni decyzji, waży alternatywy, koryguje się przy nowych ograniczeniach.
5. Komunikuje się i bierze odpowiedzialność. Opowiada tok myślenia, panuje nad zakresem, bierze na siebie wynik.

Dlaczego próbki pracy biją na głowę dyplomy i LeetCode

Pokazana próbka pracy to jeden z najtrafniejszych sygnałów rekrutacyjnych, jaki kiedykolwiek zmierzono — i trzyma się od 25 lat. Klasyczna metaanaliza Schmidta i Huntera (1998) z psychologii personelu wycenia trafność próbki pracy na około 0,54, a trafność ustrukturyzowanej rozmowy na 0,51, przy czym kompozyt „ogólne zdolności umysłowe plus próbka pracy” sięga blisko 0,63. Późniejsza rewizja autorstwa Rotha, Bobki i McFarland (2005) ustawia próbki pracy bliżej 0,33 — wciąż wysoko ponad słabymi wskaźnikami zastępczymi.

Słabe wskaźniki zastępcze to dokładnie te, które AI właśnie psuje. CV, lata doświadczenia i niezweryfikowane dyplomy plasują się przy dnie tabel trafności, a sygnał płynący z dyplomu degraduje się na żywo, co pokazują oceny z Berkeley. Łamigłówki z wyuczonych algorytmów nie wypadają lepiej: runda LeetCode na żywo jest tak samo łatwa do podrobienia z AI i tak samo nietrafna jak zadanie domowe — dlatego właśnie selekcja w stylu LeetCode staje się przeżytkiem. Wniosek z badań i z rynku jest spójny. Obserwuj, jak człowiek wykonuje realistyczną pracę i jak o niej rozumuje. Nie ufaj, że dyplom wykona tę robotę za Ciebie.

Jest też premia za sprawiedliwość. DoorDash podaje, że formaty z udziałem AI pozwalają „naprawdę zabłysnąć inżynierom o nietypowej ścieżce”, bo asystent domyka lukę w wykonaniu, a runda mierzy osąd — który przenosi się z matematyki, fizyki czy samodzielnej nauki. Dopuszczenie AI to nie ustępstwo wobec oszustów. To poszerzenie lejka o ludzi, którzy dobrze rozumują, choć nie przeszli standardowej ścieżki informatycznej.

Jak zbudować to we własnym procesie

Nie potrzebujesz zewnętrznej firmy rekrutacyjnej ani dostawcy proctoringu, żeby to uruchomić. Potrzebujesz dwóch etapów, skonfigurowanych raz: zadania programistycznego z dozwolonym AI zbudowanego wokół weryfikacji oraz ustrukturyzowanego, żywego omówienia z prawdziwą rubryką. To właśnie tę lukę Kit wypełnia dla zespołów w rozmiarze startupu. Przy rekrutacji juniorów oba te etapy dostajesz już skonfigurowane w szablonie Junior Engineer Pipeline.

Kit to ATS natywny dla AI z konfigurowalnym, etapowym procesem, a dwa istniejące typy etapów mapują się wprost na ten projekt. Etap zadania programistycznego opiera się na szablonie GitHub, więc zamiast prompta typu „zbuduj X” od zera dajesz szablon zdebuguj-tę-bazę-kodu / rozwiń-ten-niepełny-system — kształt zadania, który nagradza weryfikację nad generowaniem. Kit ogarnia założenie repozytorium, instrukcje, automatyczne zgłoszenie po terminie i archiwizację. W instrukcjach możesz napisać wprost: „AI jest dozwolone; poprosimy Cię, żebyś przeprowadził nas przez to, jak nim kierowałeś i jak weryfikowałeś jego wynik”. Następnie etap rozmowy na żywo niesie rubrykę — z przypisaniem recenzentów i ustrukturyzowaną oceną zespołu — tak by te pięć kryteriów było punktowane jednakowo dla każdego kandydata i pozostawało porównywalne w całym lejku.

Jedno uczciwe zastrzeżenie. Żadne narzędzie, Kit włącznie, nie wykrywa rzetelnie korzystania z AI — dane o niewidocznych nakładkach mówią to jasno. To ograniczenie jest dokładnie powodem, dla którego odpowiedzią jest projektowanie zadania i rubryki, a nie wykrywanie. Rolą Kita jest sprawić, by właściwy projekt łatwo było wdrożyć i ustandaryzować, a nie grać w kotka i myszkę z narzędziami do oszukiwania. Powiązany artykuł o samym zadaniu znajdziesz pod adresem jak ułożyć zadania programistyczne, których kandydaci nie znienawidzą.

Zmianę da się ująć prosto, a opór przed nią jest większy, niż powinien. Przestań zakazywać AI, bo praca z niego korzysta. Przestań wykrywać AI, bo tego wyścigu nie wygrasz. Zamiast tego zaprojektuj zadanie, w którym dobre korzystanie z AI jest widoczną umiejętnością: zadanie „znajdź błąd i rozwiń” na nieznanym kodzie, rozmowa o kompromisach, której AI nie napisze za kandydata, i rubryka, która punktuje to, jak kieruje, weryfikuje i poprawia asystenta. Tak odróżnisz inżyniera, który dowodzi AI, od tego, który jest od niego zwyczajnie zależny — i na tym polega różnica między osobą, która dowozi, a tą, która zapycha Twoją kolejkę do code review.

Najczęściej zadawane pytania

Czy powinienem pozwalać kandydatom korzystać z AI na rozmowie kodowej?

Tak — w tych rundach, w których chcesz zmierzyć, jak pracują. Praca mocno korzysta z AI (42% commitowanego kodu jest już wspomagane przez AI wg Sonara), więc runda bez AI testuje sposób pracy, którego nikt nie używa. Trzymaj użycie AI w ryzach poszczególnych rund: DoorDash na przykład pozwala na nie w sesji roboczej z AI, ale nie w każdej rundzie. Oceniaj to, jak kandydat kieruje asystentem i jak go weryfikuje, a nie to, czy w pojedynkę napisał poprawną funkcję.

Jak wykryć, że kandydat jest zbyt zależny od AI?

Nie wykrywasz tego przez proctoring — dane pokazują, że to przegrany wyścig zbrojeń. Wydobywasz to przez projekt zadania. Daj zadanie „znajdź błąd i rozwiń” na nieznanym kodzie z podłożonym błędem logicznym i obserwuj, czy kandydat weryfikuje wynik asystenta, czy ufa mu ślepo. Zależność ujawnia się w chwili, gdy model jest pewny siebie i błędny, a kandydat nie potrafi tego rozpoznać.

Jaki jest najlepszy format rozmowy technicznej w 2026 roku?

Próbka pracy typu „znajdź błąd i rozwiń” na kodzie, którego kandydat nie pisał, w parze z wąsko zakrojoną rozmową o projekcie systemu — w obu z dozwolonym AI i z rubryką, która wyżej ceni rozumowanie niż wynik. Próbki pracy mają najwyższą trafność predykcyjną w literaturze o selekcji personelu (od około 0,33 do 0,54 wg Schmidta i Huntera oraz późniejszych rewizji), znacznie ponad CV, lata doświadczenia czy łamigłówki z wyuczonych algorytmów.

Czy dopuszczenie AI stawia w gorszej sytuacji kandydatów o nietypowej ścieżce?

Wręcz przeciwnie. DoorDash podaje, że formaty z udziałem AI pozwalają zabłysnąć inżynierom o nietypowej ścieżce, bo asystent domyka lukę w wykonaniu, a runda mierzy osąd — który przenosi się z dziedzin takich jak matematyka i fizyka. Dopuszczenie AI poszerza lejek o silnych w rozumowaniu, którzy nie przeszli standardowej ścieżki informatycznej.