Jak rekrutować inżynierów, gdy każdy ma to samo AI

Sam gotowy kod nie wystarczy do oceny umiejętności inżyniera. GitHub Octoverse 2025 podaje, że 97% programistów korzysta z narzędzi AI na co dzień, a blisko jedna trzecia kodu produkcyjnego powstaje z ich pomocą. W rekrutacji warto więc sprawdzać również, jak kandydat rozumie rozwiązanie, weryfikuje je i ocenia jego ograniczenia.

Ukryty endpoint w zadaniu rekrutacyjnym

Startup Maestro.dev przeprowadził niedawno eksperyment, który powinien zaniepokoić każdego, kto zatrudnia inżynierów. Przytłoczony liczbą aplikacji na stanowiska backendowe i mobilne, zespół inżynierski umieścił w instrukcjach zadania rekrutacyjnego niewidoczny biały tekst. Ukryta treść nakazywała każdemu LLM przetwarzającemu dokument stworzenie niefunkcjonalnego endpointu „health” zwracającego ciąg „uh-oh”.

Wynik: 100% kandydatów, którzy ukończyli zadanie, wstawiło podstawiony endpoint. Zdecydowana większość wyraźnie zaprzeczyła, że korzystała z narzędzi AI.

To nie odosobniony przypadek. Według interviewing.io, 81% osób prowadzących rozmowy techniczne w dużych firmach podejrzewa, że kandydaci używają AI podczas zdalnych rozmów, a 31% przyłapało kandydatów na przedstawianiu odpowiedzi wygenerowanych maszynowo jako własnych. Raport HackerRank 2025 Developer Skills Report wykazał, że 76% programistów uważa, iż AI znacząco ułatwia obchodzenie testów rekrutacyjnych.

Takie przypadki podważają zaufanie zespołów rekrutacyjnych do kandydatów. Zamiast zwiększać nadzór, ustal, jakie umiejętności chcesz sprawdzić.

Jak dobrać zasady użycia AI i nadzoru

Firmy zaczęły zwiększać nadzór nad kandydatami. Meta wprowadziła obowiązkowe udostępnianie ekranu na wszystkich rozmowach kwalifikacyjnych i wymagała od kandydatów wyłączenia rozmycia tła. Platformy testowe zbudowały wielowarstwowe wykrywanie oszustw, łącząc sygnały behawioralne, monitoring wizualny i analizę plagiatów AI. HackerRank deklaruje 93% skuteczności wykrywania. Firmy podniosły złożoność algorytmiczną, stosując mało znane warianty zadań LeetCode zaprojektowane tak, by zmylić modele językowe.

Jeśli musisz zablokować przeglądarkę kandydata, wyłączyć jego standardowe narzędzia i monitorować ruchy oczu, żeby ocenić umiejętności, testujesz scenariusz, który nie istnieje już w żadnym środowisku produkcyjnym. Raport CoderPad State of Tech Hiring 2026 pokazuje podział branży: 34% organizacji zakazuje AI podczas rozmów kwalifikacyjnych, 46% dopuszcza je z ograniczeniami, a 20% ocenia ich użycie indywidualnie.

Dobierz zasady do celu zadania. Część umiejętności możesz sprawdzić bez AI, a przy innych obserwować, jak kandydat z niego korzysta. Wyjaśnij ten podział przed rozpoczęciem oceny.

Jak więc sprawdzić umiejętności potrzebne w pracy?

Zmiana kompetencji: od składni do weryfikacji

Raport GitHub Octoverse dokumentuje 55% wzrost postrzeganej produktywności programistów dzięki narzędziom AI do kodowania. Dane CodeSignal z 2025 roku pokazują, że 91% inżynierów codziennie korzysta z asystentów AI wykonujących zadania (Claude Code, Cursor, Codex), a 75% w ciągu ostatnich sześciu miesięcy wdrożyło kod produkcyjny częściowo lub głównie wygenerowany przez AI.

Szybsze generowanie kodu zwiększa znaczenie umiejętności potrzebnych do jego wdrożenia i utrzymania:

• Projektowanie systemów i architektura: AI to probabilistyczny silnik, który zgaduje, jaki kod powinien być następny. Może nie mieć pełnego obrazu architektury. Projektowanie systemów rozproszonych, planowanie migracji bez przestojów i zarządzanie stanem między serwisami wymagają oceny inżyniera.
• Debugowanie systemów rozproszonych: diagnoza wyścigu występującego tylko pod dużym obciążeniem wymaga zebrania danych z właściwego środowiska. Sprawdź, jak kandydat formułuje hipotezy i je testuje.
• Weryfikacja kodu i ocena ryzyka: wygenerowany kod trzeba sprawdzić pod kątem bezpieczeństwa, wydajności i zgodności z architekturą.
• Decyzje przy ograniczeniach biznesowych: kandydat powinien umieć uwzględnić koszty utrzymania, budżet wydajności i wymagania firmy.

Test porównawczy Stripe ilustruje to konkretnie. Przy testowaniu badanych modeli na budowie kompletnych integracji Stripe, Claude 3.5 Sonnet uzyskał 92% na ograniczonych zadaniach backendowego API. Ale modele konsekwentnie zawodziły przy łączeniu funkcji z różnych części systemu, awariach o niejasnej przyczynie i złożonych błędach środowiskowych. W infrastrukturze płatniczej „prawie poprawnie” to katastrofalna porażka. Modele potrafiły wygenerować kod, ale nie potrafiły go zweryfikować z rygorem, jakiego wymaga ta domena.

Czas potrzebny na weryfikację

Wygenerowany kod wymaga sprawdzenia. Szybkość generowania nie usuwa tego obowiązku. Badania pokazują, że czas przeglądów kodu wzrósł o 91%, a pull requesty są o 18% większe z powodu generowania przez AI.

W rekrutacji sprawdzaj, jak kandydat weryfikuje kod, zamiast oceniać wyłącznie tempo pisania.

Przykłady procesów rekrutacji

Poniższe firmy oceniają kandydatów na podstawie praktycznej pracy i podejmowanych decyzji.

Linear: ograniczenia zamiast skali

Linear osiągnął wycenę 1,25 miliarda dolarów ze 100 pracownikami. Ich filozofia: nie da się rozwiązać problemów strukturalnych zatrudnianiem kolejnych osób. Nie zatrudniają juniorów licząc, że AI uzupełni braki kompetencyjne. Zatrudniają seniorów, którzy używają AI do przyspieszania pracy, a następnie oceniają wyczucie produktowe, rygor architektoniczny i umiejętność pracy przy ograniczonym czasie i zasobach. Bez sztucznych testów kodowania.

Shopify: wymaganie umiejętności pracy z AI

Gdy CEO Tobias Lütke ogłosił, że Shopify przestanie zatrudniać na stanowiska, które AI może obsłużyć, nie chodziło o zastępowanie ludzi. To był filtr. Przez partnerów weryfikacyjnych Shopify ocenia teraz programistów pod kątem zdolności do funkcjonowania jako „hybryda technologa i rozwiązywacza problemów”. Szukają zwinności, umiejętności headless commerce (React/Vue) i dowodów, że programista wnosi umiejętności potrzebne do integracji, z którymi AI samo sobie nie radzi.

Automattic: płatne próby zamiast LeetCode

Automattic całkowicie pomija standardowe zadania algorytmiczne. Ich oferty na stanowiska „Applied AI Engineer” wprost deklarują, że szukają kandydatów, którzy „wdrożyli funkcje AI, z których ludzie faktycznie korzystają”. Kandydaci pracują nad krótkim płatnym projektem razem z faktycznym zespołem, mierząc się z realnymi problemami. Próba testuje komunikację, wykorzystanie narzędzi AI i umiejętność szybkiego prototypowania przy jednoczesnym budowaniu z myślą o większym obciążeniu.

Basecamp: zatrudniaj, gdy boli

Basecamp otrzymał ponad 1000 aplikacji na stanowisko Rails developer i nie złożył ani jednej oferty. Nie dlatego, że nikt nie miał kwalifikacji, ale dlatego, że żaden kandydat nie przekonał ich, że zatrudnienie poprawi dynamikę istniejącego zespołu. Całkowicie odrzucają łamigłówki algorytmiczne, oceniając kandydatów pod kątem faktycznej zdolności do dostarczania oprogramowania przez projekty z prawdziwego życia.

Wspólny wątek: każda z tych firm testuje pracę odzwierciedlającą to, co inżynier faktycznie będzie robił na co dzień. Żadna z nich nie używa oderwanego od rzeczywistości zapamiętywania algorytmów jako bramki wejściowej.

Mniej pracy dla początkujących inżynierów

Badanie Stanford Digital Economy wykazało, że zatrudnienie programistów w wieku 22-25 lat spadło o blisko 20% między końcem 2022 a połową 2025 roku. W miarę jak organizacje używają AI do obsługi szablonowego kodowania, podstawowego debugowania i rutynowej dokumentacji, ubywa zadań, na których nowi inżynierowie zdobywali doświadczenie.

Ograniczenie zatrudniania juniorów zmniejsza liczbę osób, które mogą zdobywać doświadczenie pod opieką zespołu. Warto uwzględnić ten skutek w długoterminowym planie zatrudnienia.

Przywoływane badania podają zarówno przyspieszenie wykonywania określonych zadań przez juniorów o 56%, jak i spowolnienie doświadczonych programistów o 19%. Dotyczą jednak różnych warunków. Nie można na tej podstawie uznać, że seniorzy tracili czas konkretnie na poprawianie kodu juniorów.

Model juniora wspomaganego AI

Rozwiązaniem nie jest zaprzestanie zatrudniania juniorów. Trzeba na nowo zdefiniować tę rolę:

• Zadania juniorów: korzystają z AI do szablonów, testów jednostkowych i generowania dokumentacji. Sprawdzają logikę rozwiązania, żeby wychwycić błędy przed wdrożeniem.
• Wsparcie seniorów: skupiają się na architekturze, złożonym rozwiązywaniu problemów i nadzorze, którego AI nie jest w stanie replikować.
• Środowiska sandbox: juniorzy budują, popełniają błędy i iterują z AI bez wpływu na infrastrukturę krytyczną, dopóki ich praca nie zostanie zwalidowana.
• Ewolucja mentoringu: uczyć juniorów sprawdzania logiki wygenerowanej przez AI, podejmowania decyzji projektowych i pisania skutecznych promptów.

Proponowany podział 60–70% seniorów i 30–40% juniorów traktuj jako wariant do rozważenia, a nie uniwersalne optimum. Liczbę początkujących osób dopasuj do zadań i czasu, jaki zespół może przeznaczyć na wsparcie.

Iluzja kompetencji: ukryte ryzyko rekrutacyjne AI

Poza rozwojem początkujących inżynierów istnieje subtelniejszy problem, o którym coraz częściej mówią doświadczeni menedżerowie inżynierscy: AI całkowicie maskuje fundamentalne braki kompetencyjne.

Juniorzy generują nieskazitelny kod i przechodzą wszystkie testy za pomocą asystentów AI, po czym mają trudności, gdy poprosi się ich o wyjaśnienie struktur danych czy decyzji architektonicznych. W jednym opisywanym przypadku inżynier użył konkretnej struktury danych wyłącznie dlatego, że AI „ją zasugerowało”, bez jakiegokolwiek zrozumienia mechanizmów stojących za tym wyborem.

Kod może się kompilować i przechodzić testy, choć kandydat nie potrafi wyjaśnić wybranej struktury danych lub zmienić rozwiązania. Poproś więc o omówienie konkretnych fragmentów i ich ograniczeń.

Jeśli kompilujący się kod i przechodzące testy nie gwarantują już zrozumienia, ocena musi obejmować uzasadnienie decyzji, a nie tylko wynik.

Taką ocenę opisujemy w tekście o metodach rozmowy technicznej. Przegląd kodu, zaprojektowanie i wykonanie rozwiązania oraz diagnoza błędów pozwalają obserwować decyzje kandydata. Także w tych zadaniach może pomagać AI, dlatego ustal zasady i oceniaj tok pracy.

Kwestia równości: kto zyskuje, kto traci

Wpływ AI na równość w rekrutacji jest złożony i działa w obie strony.

Strona negatywna: Bootcampy programistyczne historycznie doskonale szkoliły juniorów w dokładnie tych powtarzalnych, fundamentalnych zadaniach, które AI teraz automatyzuje. Narracja o zdobyciu pracy po 12-tygodniowym kursie intensywnym się załamała. Bariery wejścia na rynek są wyższe, bo firmy oczekują od juniorów kompetencji na poziomie mid.

Strona pozytywna: AI może pomóc rozwiązywać złożone problemy osobom bez formalnego wykształcenia informatycznego. Programiści bez formalnego wykształcenia informatycznego mogą wykorzystać AI do nadrobienia braków w pamięci składni i optymalizacji algorytmów, konkurując bezpośrednio intuicją architektoniczną, wyczuciem produktowym i zaradnością. Zdolność szybkiego uczenia się i adaptacji do nowych narzędzi jest teraz cenniejsza niż prestiżowy dyplom.

Przy ocenie kandydatów po bootcampach i studiach sprawdzaj te same umiejętności: rozumienie kodu, weryfikację wyników AI i rozwiązywanie problemów. Sam rodzaj wykształcenia nie odpowiada na te pytania.

Jak ułożyć ocenę kandydatów

Przebudowę procesu rekrutacyjnego możesz zacząć od poniższych zmian.

Co przestać robić

• Zautomatyzowane testy przesiewowe oparte na algorytmach, które nie odzwierciedlają realnej pracy. Łatwo je obejść za pomocą AI, a seniorzy odmawiają udziału w takim teatrze bezpieczeństwa.
• Zakazywanie narzędzi AI podczas rozmów kwalifikacyjnych. To tworzy syntetyczne środowisko, które nie oddaje faktycznego sposobu pracy.
• Mierzenie wydajności liczbą linii kodu. AI przyspiesza generowanie kodu, więc liczba linii nie mówi wiele o jakości pracy.

Co zacząć robić

• Przegląd kodu. Przedstaw kandydatom realne, zanonimizowane PR. Oceń, czy sprawdzają kompatybilność wsteczną, egzekwują konwencje nazewnicze, weryfikują obsługę błędów i wyłapują luki bezpieczeństwa. Stripe scala ponad 1300 PR napisanych przez AI tygodniowo, stosując to podejście.
• Sesje design-to-build. Poproś kandydatów o zaprojektowanie systemu i zbudowanie jego najważniejszego komponentu, z dostępnymi narzędziami AI. Obserwuj precyzję promptów, wykrywanie halucynacji i umiejętność łączenia projektu z implementacją.
• Debugowanie na żywo. Daj kandydatowi przykładową aplikację z błędem współbieżności lub śledzenia żądań. Zapewnij potrzebne dane o środowisku i obserwuj, jak diagnozuje problem.

Co zmodyfikować

• Rozmowy o projektowaniu systemów: zamiast ogólnych diagramów komponentów omawiaj awarie, spójność danych, opóźnienia i problemy z integracją.
• Zadania domowe: wprost zezwól na AI, a potem wymagaj rozmowy na żywo, podczas której kandydat broni architektury, tłumaczy kompromisy i refaktoryzuje pod presją. Jeśli nie potrafi nawigować po kodzie, który złożył, jest zdyskwalifikowany.

Karta oceny

Wspólne karty oceny ograniczają ocenianie „na wyczucie”. Oceniaj kandydatów w czterech wymiarach:

Jak aktualizować zadania wraz ze zmianami AI

Możliwości modeli AI poprawiają się co kwartał. Ocena zaprojektowana dziś pod konkretną słabość LLM będzie przestarzała przy następnym wydaniu modelu. To znaczy, że proces rekrutacyjny nie może opierać się na stałych sztuczkach czy podchwytliwych pytaniach.

Sprawdzaj sposób myślenia kandydata i jego decyzje, a nie tylko gotowy wynik.

Szukaj osób, które potrafią wychwycić błędną logikę w kodzie AI, projektować modele danych i ocenić, kiedy wynik modelu wymaga dokładniejszego sprawdzenia.