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 wypełnij uporządkowaną kartę oceny, 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 wpisuje ten sam prompt w 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 do domu. 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

W puli kandydatów jest coraz więcej 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 o poziom wcześniej, 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 inżynier w realnej robocie. 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 około 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ę.

Szefowie zespołów inżynierskich już czują, że ten pomiar się sypie. Raport Karat 2025–2026 AI Workforce Transformation Report, oparty na odpowiedziach 400 szefów zespołów 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, a wśród pracodawców z Nowego Jorku odsetek ten sięga blisko 25% i ma rosnąć 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 rekrutacyjnych do domu ponad podwoiło się: z 15% w czerwcu 2025 do 35% w grudniu 2025. Współczesne narzędzia rozwiązują standardowe zadania do domu 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 szefowie zespołów 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 zbrojeń w renderowaniu 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. 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 przechodzi 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 cykl rozmów 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 ważne, 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ą ukierunkowane 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 nie da się obejść zależnością od AI, bo ta praca polega 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, odpowiadając przy tym za 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 zaplanowałbyś tu cache, 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.

Karta oceny: pięć kryteriów wartych punktowania

Niech karta oceny 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 ukierunkowane 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, odpowiada za wynik.

Dlaczego próbki pracy przewyższają dyplomy i LeetCode

Pokazana próbka pracy to jeden z najtrafniejszych sygnałów rekrutacyjnych, jaki kiedykolwiek zmierzono. Trzyma się od 25 lat. Klasyczna metaanaliza Schmidta i Huntera (1998) z psychologii pracy wycenia trafność próbki pracy na około 0,54, a trafność ustrukturyzowanej rozmowy na 0,51, przy czym połączenie ogólnych zdolności umysłowych z próbką 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 do domu — 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 prowadzącej rozmowy techniczne ani dostawcy zdalnego nadzoru, żeby to uruchomić. Potrzebujesz dwóch etapów, skonfigurowanych raz: zadania programistycznego z dozwolonym AI zbudowanego wokół weryfikacji oraz ustrukturyzowanego omówienia na żywo z prawdziwą kartą oceny. 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 system ATS od podstaw oparty na 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 „znajdź błąd w tej bazie kodu / rozwiń ten niepełny system”, czyli kształt zadania, który nagradza weryfikację, a nie generowanie. Kit obsługuje 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 kartę oceny, 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 karty oceny, 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 karta oceny, która punktuje to, jak kandydat kieruje asystentem, weryfikuje go i poprawia. 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 w rundzie kodowania?

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 wykryjesz tego zdalnym nadzorem, bo 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 kartą oceny, która wyżej ceni rozumowanie niż wynik. Próbki pracy mają najwyższą trafność predykcyjną w literaturze o doborze pracowników (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.