Jeśli w ciągu ostatnich miesięcy przeglądałeś CV developerów, wiesz, jak wygląda ta sytuacja. „ChatGPT”, „Prompt Engineering”, „AI tools” – w sekcji umiejętności niemal każdego kandydata. Problem w tym, że dodanie tych słów do CV nic nie kosztuje. I nic nie mówi o tym, jak ta osoba naprawdę pracuje.
Większość kandydatów deklarujących znajomość AI to użytkownicy, sięga po ChatGPT kiedy sobie przypomną, korzystają z Copilota gdy IDE zaproponuje. AI-native developer to ktoś zupełnie inny: ktoś, kto zaczyna od AI i cofa się do ręcznej pracy tylko gdy musi. Ktoś, dla kogo praca bez asystentów AI byłaby dziś realnym utrudnieniem.
Standardowa rozmowa kwalifikacyjna tej różnicy nie wyciągnie. Do tego potrzeba innych pytań, takich, które testują nawyki i sposób myślenia, nie znajomość nazw narzędzi.
Ten artykuł daje Ci gotowy protokół: 10 pytań z wyjaśnieniem, czego szukać w odpowiedziach i jakie sygnały powinny zapalić czerwoną lampkę.
Zanim zaczniesz pytać
Jedno zdanie, które zmienia perspektywę całej rozmowy: nie szukasz kogoś, kto zna AI. Szukasz kogoś, kogo AI zmieniła.
To fundamentalna różnica. Developer, który „zna ChatGPT”, potrafi odpowiedzieć na każde pytanie o narzędzia — i nie powiedzieć przy tym nic istotnego. Developer AI-native opowie Ci o konkretnym problemie, konkretnym workflow, konkretnym błędzie modelu, który go nauczył czegoś nowego.
Dlatego pytania w tym protokole są podzielone na trzy kategorie:
- Workflow — jak AI wchodzi w codzienną pracę
- Myślenie o problemie — jak kandydat podejmuje decyzje z AI i bez niej
- Uczenie się — jak kandydat śledzi i adaptuje się do zmieniającego się rynku narzędzi
W każdej kategorii szukasz konkretów, nie deklaracji. „Używam AI regularnie” to nie odpowiedź. „Zbudowałem sobie skrypt, który generuje testy jednostkowe z opisu funkcji i uruchamia je automatycznie po każdym commicie” — to jest odpowiedź.
10 pytań do AI-native developera
Kategoria A — Codzienny workflow
Pytanie 1 Opisz, jak wygląda Twój typowy dzień pracy — gdzie konkretnie pojawia się AI?
Czego szukasz: Dobra odpowiedź jest szczegółowa i osadzona w konkretnych zadaniach: „rano zaczynam od przeglądu PR-ów, do code review używam Claude’a, potem zazwyczaj mam nowe zadanie — zanim zacznę kodować, opisuję problem modelowi i sprawdzam, czy moje podejście ma sens”. Kluczowe jest to, że AI pojawia się w wielu momentach dnia, nie tylko przy „trudnych” zadaniach.
Czerwona flaga: Odpowiedź ogólna i niezakotwiczona w konkretach — „używam AI do różnych rzeczy, głównie do generowania kodu”. Brak przykładów z ostatnich tygodni. Wrażenie, że kandydat opisuje, jak powinien używać AI, nie jak faktycznie to robi.
Pytanie 2 Pokaż mi jedno narzędzie lub workflow, które sam zbudowałeś albo skonfigurowałeś z pomocą AI w ciągu ostatnich trzech miesięcy.
Czego szukasz: Pytanie celowo prosi o „zbudowane” lub „skonfigurowane” — nie „używane”. AI-native developer nie tylko korzysta z gotowych rozwiązań, ale aktywnie składa narzędzia pod swoje potrzeby. Może to być custom prompt systemowy w IDE, skrypt automatyzujący część pipeline’u, własny agent do konkretnego zadania. Ważne, że kandydat potrafi wyjaśnić, co ten workflow robi i dlaczego tak go skonstruował.
Czerwona flaga: Kandydat nie ma żadnego przykładu lub podaje przykład z „dawnych czasów”. Opisuje narzędzia, których używa, ale żadnego, które sam zbudował lub dostosował. To sygnał, że AI jest dla niego czymś zewnętrznym — narzędziem do sięgnięcia, nie częścią warsztatu.
Pytanie 3 Kiedy ostatnio AI zawiodła Cię podczas pracy nad kodem? Co się stało i co zrobiłeś?
Czego szukasz: Każdy, kto naprawdę używa AI w codziennej pracy, ma dziesiątki takich historii — model zwrócił kod, który nie działał, zasugerował podejście, które nie skaluje się, halucynował nazwę biblioteki. Dobra odpowiedź jest konkretna i pokazuje, jak kandydat zareagował: zweryfikował output, zrozumiał błąd, wyciągnął wnioski. Bonus: kandydat opisuje, jak zmienił swój workflow po tym doświadczeniu.
Czerwona flaga: Kandydat nie ma żadnego przykładu albo odpowiada ogólnie: „czasem AI robi błędy, trzeba weryfikować”. To może oznaczać, że nie używa AI wystarczająco intensywnie, żeby napotkać jej ograniczenia — albo że nie zauważa błędów, bo nie weryfikuje outputów.
Kategoria B — Myślenie o problemie
Pytanie 4 Dostajesz nowy feature do wdrożenia. Jaki jest Twój pierwszy krok — i gdzie w tym procesie sięgasz po AI?
Czego szukasz: To pytanie testuje, czy AI jest wbudowana w proces myślenia, czy tylko w proces pisania kodu. Developer AI-native często używa modelu już na etapie planowania — do weryfikacji podejścia, generowania alternatywnych rozwiązań, sprawdzenia edge case’ów — zanim napisze pierwszą linię. Ciekawe są też momenty, w których kandydat świadomie nie sięga po AI (patrz pytanie 6).
Czerwona flaga: AI pojawia się wyłącznie na etapie generowania kodu lub debugowania. Kandydat traktuje AI jako narzędzie do przyspieszenia pisania, nie jako partnera do myślenia o problemie. To nie dyskwalifikuje kandydata, ale sugeruje, że nie jest głęboko AI-native.
Pytanie 5 Jak oceniasz, czy output modelu jest wystarczająco dobry, żeby go użyć?
Czego szukasz: To pytanie weryfikuje krytyczne myślenie i dojrzałość w używaniu AI. Dobra odpowiedź zawiera konkretny proces walidacji: „czytam kod i sprawdzam, czy rozumiem każdą linię”, „uruchamiam testy”, „sprawdzam edge case’y, których model mógł nie uwzględnić”, „porównuję z dokumentacją, jeśli chodzi o API”. Kandydat rozumie, że odpowiedzialność za output zawsze leży po jego stronie.
Czerwona flaga: „Zazwyczaj działa” lub „sprawdzam czy się kompiluje”. Brak świadomości, że model może generować kod poprawny składniowo, ale błędny logicznie lub niebezpieczny. Kandydat, który ślepo ufa outputom AI, jest potencjalnym ryzykiem dla kodu produkcyjnego.
Pytanie 6 Które zadania developerskie celowo robisz bez AI i dlaczego?
Czego szukasz: Paradoksalnie to jedno z najlepszych pytań do weryfikacji AI-native mindset. Developer, który naprawdę rozumie AI, wie też, kiedy jej nie używać. Może to być architektura systemu wymagająca głębokiego rozumienia kontekstu biznesowego, code review, gdzie chce wyrobić własną opinię, albo nauka nowej technologii, gdzie generowanie kodu zablokowałoby mu zrozumienie. Świadoma decyzja „nie tu” jest oznaką dojrzałości.
Czerwona flaga: „Zawsze używam AI” — brak refleksji nad ograniczeniami. Albo odwrotnie: „wolę robić większość rzeczy sam” — co sugeruje, że AI nie jest faktycznie wbudowana w codzienny workflow.
Pytanie 7 Jak reagujesz, gdy AI generuje kod, który działa, ale nie rozumiesz, co robi?
Czego szukasz: To pytanie o wartości zawodowe, nie umiejętności techniczne. Developer AI-native powinien rozumieć każdą linię kodu, którą wypuszcza na produkcję — niezależnie od tego, kto lub co ją napisało. Dobra odpowiedź: „pytam model o wyjaśnienie, rozkładam na części, przepisuję samodzielnie jeśli muszę zrozumieć”. To też pytanie o responsibility — czy kandydat czuje się właścicielem outputu AI.
Czerwona flaga: „Jeśli testy przechodzą, to zostawiam” lub „ufam, że model wie co robi”. To poważny sygnał ryzyka, szczególnie przy pracy z kodem produkcyjnym, systemami bezpieczeństwa lub wrażliwymi danymi.
Kategoria C — Uczenie się i świadomość
Pytanie 8 Jakie modele lub narzędzia AI aktywnie używasz i czym różnią się dla Ciebie w praktyce?
Czego szukasz: Nie chodzi o wymienienie nazw — chodzi o to, czy kandydat świadomie dobiera narzędzie do zadania. „Do code review używam Claude’a, bo lepiej tłumaczy decyzje. Do szybkiego generowania boilerplate’u używam Copilota w IDE, bo nie muszę przełączać kontekstu. Do research’u nowych bibliotek wolę Perplexity, bo cytuje źródła” — taka odpowiedź pokazuje, że kandydat rozumie różnice między modelami i ma własne zdanie.
Czerwona flaga: Kandydat używa wyłącznie jednego narzędzia do wszystkiego, bez refleksji nad tym, czy to optymalne. Albo wymienia narzędzia, ale nie potrafi powiedzieć, czym się różnią w praktyce. To sugeruje użytkownika, nie praktyka.
Pytanie 9 Co zmieniło się w Twoim podejściu do pracy w ciągu ostatniego roku przez AI?
Czego szukasz: To pytanie o trajektorię, nie o stan obecny. Developer AI-native powinien być w stanie opisać konkretną ewolucję: „rok temu używałem AI głównie do autocomplete, teraz zaczynam każde zadanie od rozmowy z modelem o architekturze”, „zmieniłem podejście do dokumentacji — piszę ją w dialogu z AI”, „zacząłem pisać więcej testów, bo generowanie ich z AI jest szybkie, więc nie ma wymówki”. Zmiana powinna być konkretna i mierzalna.
Czerwona flaga: Brak wyraźnej zmiany lub bardzo ogólna odpowiedź („wszystko jest teraz szybsze”). Jeśli rok temu i dziś kandydat pracuje tak samo, tylko z AI w tle — nie jest AI-native, jest AI-user.
Pytanie 10 Jak wyglądałoby Twoje idealne środowisko pracy, gdybyś miał je zbudować od zera dziś?
Czego szukasz: To pytanie otwarte, które daje kandydatowi przestrzeń do pokazania, jak myśli o przyszłości pracy z AI. Dobra odpowiedź ujawnia konkretną wizję: jakie modele, jakie integracje, jaki poziom automatyzacji, jakie granice. Kandidat AI-native ma na ten temat przemyślane zdanie — bo aktywnie eksperymentuje i śledzi co się dzieje w ekosystemie.
Czerwona flaga: Odpowiedź skupiona wyłącznie na klasycznych narzędziach (IDE, CI/CD) bez refleksji nad rolą AI. Albo odpowiedź na tyle ogólna, że mogłaby paść dwa lata temu — brak zakorzenienia w tym, co jest możliwe dziś.
Zadanie live — opcjonalne uzupełnienie
Pytania to teoria. Jeśli masz czas i pozwala na to format rozmowy, warto dodać 10–15 minutowe zadanie live.
Formuła jest prosta: daj kandydatowi konkretny, nietrywialny problem techniczny i powiedz: „Masz 10–15 minut. Możesz użyć dowolnych narzędzi, w tym AI.”
Nie oceniaj rozwiązania — oceniaj proces. Zwróć uwagę na:
- Czy kandydat od razu sięga po AI, czy najpierw próbuje sam? Ani jedna, ani druga odpowiedź nie jest z góry lepsza — ale daje sygnał o nawykach.
- Jak formułuje prompt? Czy zadaje modelowi kontekst, czy wrzuca surowe pytanie?
- Jak reaguje na błędny output? Czy weryfikuje, pyta doprecyzowująco, czy przyjmuje pierwszy wynik?
- Czy rozumie to, co dostał? Poproś o wyjaśnienie dowolnej części rozwiązania.
Więcej o weryfikacji kompetencji AI-native w praktyce — w artykule Jak zweryfikować, czy kandydat naprawdę pracuje z AI?
O co nie pytać
Kilka pytań, które brzmią sensownie, ale w praktyce niczego nie weryfikują:
„Czy znasz ChatGPT / Copilota / Claude’a?” Tak pyta każdy. Każdy odpowie tak. Znajomość nazwy narzędzia nie mówi nic o tym, jak ktoś z nim pracuje.
„Jak oceniasz swoje umiejętności AI w skali 1–10?” Samoocena w tej dziedzinie jest wyjątkowo myląca. Kandydaci, którzy używają AI powierzchownie, często oceniają się wysoko, bo nie wiedzą, czego nie wiedzą. Praktycy bywają bardziej sceptyczni wobec własnych umiejętności.
„Jak AI zmieni branżę IT w ciągu 5 lat?” To pytanie do felietonisty, nie do developera. Dostaniesz dobrze brzmiącą odpowiedź, która nic nie mówi o tym, jak kandydat pracuje dziś.
„Czy boisz się, że AI zastąpi programistów?” Weryfikuje poglądy, nie kompetencje. Nieistotne z punktu widzenia rekrutacji.
Podsumowanie
AI-native developer to nie ten, kto zna wszystkie narzędzia. To ten, kto zmienił sposób myślenia o pracy — i może Ci to pokazać na konkretnych przykładach z ostatnich tygodni.
Dobre pytania rekrutacyjne nie pytają o wiedzę. Pytają o nawyki, decyzje i refleksję. Kandydat, który potrafi opisać, kiedy AI go zawiodła, jak zmienił workflow po tym doświadczeniu i dlaczego do pewnych zadań celowo nie używa modeli — to kandydat, który naprawdę pracuje z AI, a nie obok niej.
Protokół z tego artykułu możesz wdrożyć od razu na następnej rozmowie. Jeśli jednak nie masz czasu prowadzić tych weryfikacji samodzielnie — lub szukasz kandydatów, zanim trafią na rynek — porozmawiajmy. Talent Place przeprowadza weryfikację AI-native kompetencji w ramach każdego projektu rekrutacyjnego.
A jeśli dopiero planujesz, gdzie szukać takich kandydatów — przeczytaj też: Gdzie szukać talentów AI-native poza LinkedIn?
