„Wiem, że potrzebuję LeetCode, system design”. Tak odpowiedział mi 11 listopada programista na poziomie seniora, z którym pracuję jako mentor, kiedy omawialiśmy jego najbliższą rekrutację. Nazwijmy go Pavel.
Rozmowa rekrutacyjna na stanowisko AI product engineer sprawdza, czy potrafisz kierować agentami AI, które piszą kod, i udowodnić, że to, co dowożą, jest poprawne. LeetCode to dziś niewielka część tej godziny.
Przeczytaj ogłoszenie FTMO na stanowisko Product Engineer (AI Native) w Pradze: „Większość kodu piszą agenci, a my spędzamy czas na specyfikowaniu, weryfikowaniu i odpowiadaniu za to, co trafia na produkcję”. I dalej: „Pokaż nam swoje środowisko agentów. Konfiguracje agentów, pliki CLAUDE.md / AGENTS.md, ewaluacje, pętle testowe, integracje MCP albo repozytoria. Poprosimy o pokazanie”.
Kiedy ogłoszenie brzmi w ten sposób, przynieś swoje środowisko agentów, a nie swój GitHub. Ogłoszenie wymienia też repozytoria, jako jedno z miejsc, w których takie środowisko może żyć, ale repozytorium z kodem pokazuje, co agent potrafi napisać. Środowisko pokazuje, czego agentowi nie pozwalasz zrobić, i właśnie za to płaci się seniorowi.
Jest haczyk, o którym ogłoszenie nie wspomina. Środowisko łatwo skopiować. Z AGENTS.md korzysta ponad 60 tys. projektów open source, a wyselekcjonowana lista konfiguracji i skilli (zapisanych zestawów instrukcji dla AI) do Claude Code ma w tym tygodniu 57 674 gwiazdki na GitHubie. Gdybym siedział naprzeciwko Ciebie, pominąłbym sam plik i zapytał, po co jest w nim każda zasada.
Konfigurację da się skopiować. Twoich blizn nie.
Rok temu Pavel oblał rekrutację do big techu na etapie system designu, a jego plan to więcej tego samego przygotowania. Opowiedziałem mu o praskiej firmie, która właśnie stworzyła stanowiska product buildera. Na rozmowie proszą tam o pokazanie Twojego CLAUDE.md.
Jego pierwsza odpowiedź brzmiała: „Poprosiłbym o skille”. To dobry instynkt, tylko że nie stoi za nim jeszcze żadna historia. Na następnej sesji robimy próbną rozmowę rekrutacyjną, a dziesięć pytań poniżej to te, które mu zadam.
W Mews rozbudowałem zespoły product engineeringu z 8 do 80 osób, więc siedziałem po drugiej stronie tego stołu. Dziś prowadzę swój biznes na własnym środowisku: plik instrukcji na 206 linii i do tego 16 hooków, stan na listopad 2026.
Najlepsza historia o nim, jaką mam na rozmowę, to porażka. Alerty, które zbudowałem, żeby wyłapywać ciche awarie, same przez pięć dni po cichu nie działały, a jeden agent pogorszył sprawę, zanim inny agent znalazł przyczynę. To pytanie 5.
Ogłoszenie już mówi, co sprawdzi rozmowa
Ogłoszenie o pracę czytam jak scenariusz rozmowy. Każda linijka z sekcji „What you’ll do” i „What you bring” w ogłoszeniu FTMO zamienia się w pytanie na rozmowie.
| Obszar | Ogłoszenie mówi | Pytanie, którego się spodziewam | Co przynieść |
|---|---|---|---|
| Środowisko agentów | „Pokaż nam swoje środowisko agentów” | Pokaż mi je krok po kroku | Pliki i powód istnienia każdej zasady |
| Weryfikacja | „zwłaszcza tam, gdzie płyną pieniądze” | Jak sprawdzasz kod agenta na ścieżce płatności? | Test, którego agent nie może edytować |
| Przejęty kod | „Poznaj go szybko ze swoimi agentami, a potem zrób go swoim” | Co robi agent w pierwszym tygodniu? | Plan, który zaczyna się od czytania |
| Produkcja | „monitoring, incydenty i poprawki” | Opowiedz o incydencie krok po kroku | Jeden prawdziwy incydent, krok po kroku |
| Dostawcy | „dostawcy płatności i KYC” | Dostawca zwraca sukces, a dane się nie zgadzają | Kontrola, która to wyłapała |
| Narzędzia zespołu | „Twoje środowisko agentów, pętle testowe i konwencje stają się wspólne dla zespołu” | Co byś zmienił w naszym środowisku? | Jedna zasada do dodania i jej uzasadnienie |
Źródło: FTMO, Product Engineer (AI Native), stan na 10 listopada 2026.
Żaden z sześciu wierszy nie każe Ci odwracać listy jednokierunkowej. Stack (TypeScript, NestJS, React, Google Cloud, Kafka) dostaje w ogłoszeniu jedną linijkę. Mews nazywa to samo stanowisko product builder, a portale z ofertami pracy: product engineer.
FTMO prosi o pokazanie środowiska. Elicit i Canva patrzą, jak go używasz
FTMO to jedyna firma, jaką znalazłem, która wpisuje to do ogłoszenia. Inne sprawdzają tę samą umiejętność na żywo. W Elicit kandydaci pracują na własnym komputerze, „z dowolnymi narzędziami, z którymi czują się swobodnie”, a prowadzący rozmowę oceniają „sterowanie, a nie samo promptowanie” i „dostrzeganie ryzyka”: „Kiedy można bezpiecznie coś założyć? Kiedy trzeba się zatrzymać i sprawdzić?”
Canva pozwala kandydatom korzystać z AI i twardo sprawdza jedno: „Czy potrafią znaleźć i naprawić problemy w kodzie wygenerowanym przez AI?”
Najmocniejszy głos przeciw pochodzi od firmy, która robi Claude Code. Anthropic mówi kandydatom przed rozmowami na żywo: „Tu liczysz się tylko Ty, bez pomocy AI, chyba że zaznaczymy inaczej”. To uczciwe stanowisko. Jeśli nie potrafisz rozumować bez agenta, nie potrafisz ocenić agenta.
W jednym procesie rekrutacyjnym pewnie trafisz na oba rodzaje etapów, a środowisko pomaga Ci także w tym bez AI. Wybierz jedną zasadę ze swojego środowiska i wyjaśnij, bez agenta, co się zepsuje, jeśli ją usuniesz. Jeśli zrobisz to dla pięciu zasad, etap bez AI jest tą samą rozmową, tylko przy tablicy.
Twoje środowisko należy do pracodawcy. Pokaż zasady, nie repozytorium
Większość roku pracy z agentami dzieje się w kodzie pracodawcy, a tego repozytorium nie otworzysz na rozmowie w innej firmie. Nie musisz.
Prywatna kopia zasad
Skopiuj plik instrukcji i listę hooków do prywatnego repozytorium, usuwając szczegóły klientów. Zasady i ich daty są Twoje, kod, który chronią, już nie. Znajomy Team Lead zbudował pętlę, która dopisuje nowe zasady do plików instrukcji jego zespołu, w całości w repozytoriach pracodawcy. Poradziłem mu, żeby opublikował tę pętlę jako publiczny skill, który nie wskazuje na żadne z nich.
Dziennik zmian zasad
Jedna linijka na każdą zmianę zasady: data, co się zepsuło, co dodałeś. To najbardziej przekonująca strona, jaką możesz przynieść, i nie ma w niej ani linijki kodu pracodawcy.
Jedna zasada odtworzona na żywo
Zaproponuj, że na rozmowie odtworzysz od zera jeden hook albo jeden test. Zajmuje to dziesięć minut i dowodzi, że zasada siedzi w Twojej głowie, a nie tylko w pliku.
10 pytań rekrutacyjnych na stanowisko AI product engineer i co pokazuje mocna odpowiedź
Każde pytanie odpowiada jednej linijce ogłoszenia. Przy każdym: po co o to pytają, jak brzmi mocna odpowiedź i jaka czerwona flaga kosztuje Cię ofertę.
1. Pokaż mi krok po kroku swoje środowisko agentów
Napisali „Pokaż nam swoje środowisko agentów”, więc otwórz pliki, zamiast je opisywać. Pokaż plik instrukcji, co w nim jest i co z niego usunąłeś. Długi plik, którego agent słucha w połowie, jest gorszy niż krótki, którego słucha w całości.
Potem pokaż historię, bo tej części nie da się skopiować. Większość zasad w moim pliku ma datę i incydent, który za nią stoi, od certyfikatów Pythona w sierpniu po zasadę o Chrome w trybie headless w październiku.
We wrześniowej próbnej rozmowie kandydat, z którym pracuję jako mentor, nie umiał odpowiedzieć na pytanie o AI: jakich modeli używa jego zespół i jak śledzą ich użycie i ruch. Nazwijmy go Marek. W jego własnych notatkach z tej sesji jest zapisane: „nie udało się odpowiedzieć”. Poradziłem mu, żeby nazwał narzędzia, telemetrię i to, co sprawdza sam.
Czerwona flaga: Twój plik wygląda jak szablon i nie potrafisz powiedzieć, która zasada wzięła się z którego błędu.
2. Którą zasadę przeniosłeś z pliku instrukcji do hooka?
Mam na to linijkę w swoim pliku: „Linijki w CLAUDE.md to prośby, hooki to zasady”. Agent czyta plik i zwykle się do niego stosuje. Hook uruchamia się przed wywołaniem narzędzia i blokuje je, cokolwiek agent postanowił.
U mnie stało się to w dwóch krokach. W sierpniu 2026 przeniosłem pliki firmy z Google Drive na dysk lokalny, a razem z nimi zniknął kosz Drive’a, więc hook pyta teraz przed każdym rm ze wzorcem glob albo zmienną. 17 września 2026 okazało się, że konektor Gmaila przepisuje każdy link w moich szkicach na śledzące przekierowanie przez google.com. Tego samego dnia powstał z tego hook, który blokuje narzędzia Gmaila do zapisu.
Czerwona flaga: każda zasada żyje w zwykłym tekście, a Ty ufasz, że agent ją przeczyta.
3. Czego Twój agent nigdy nie robi bez Ciebie?
Elicit opisuje odwrotność: kandydatów, którzy „na yolo odpalają claude --dangerously-skip-permissions” i akceptują każdą sugestię bez czytania diffa. Mocna odpowiedź to krótka lista z uzasadnieniem przy każdym punkcie.
Moja: żadnego usuwania poza folderami tymczasowymi bez pytania mnie, żadnych wdrożeń folderów klientów, żadnych maili przez konektor, żadnego merge’a wpisu na bloga. Mój pipeline zatrzymuje się na pull requeście, a merge robię sam. W repozytorium produktu ta sama lista wygląda zwykle tak: migracje bazy danych, konfiguracja płatności, sekrety i wdrożenia na produkcję.
Czerwona flaga: klikasz „tak” przy każdym pytaniu o uprawnienia, nie czytając go.
4. Jak weryfikujesz kod napisany przez agenta tam, gdzie płyną pieniądze?
Najlepiej ujmuje to Stripe w tekście o integracjach płatności budowanych przez AI: „Implementacja PaymentIntent tanieje. Trafne odczytanie intencji biznesowej, która za nią stoi, to teraz cała praca”.
Nie wdrożyłem z agentami żadnej ścieżki płatności, więc nie będę udawał, że mam tu bliznę. Kształt mocnej odpowiedzi i tak jest jasny: oddziela tego, kto sprawdza, od tego, kto pisze. Przypadki biznesowe piszesz sam (zwrot wypłacony dwa razy, niezgodna waluta, webhook, który przychodzi w złej kolejności), a agent nie może edytować tych testów, żeby przeszły.
Czerwona flaga: „Testy też napisał agent i są zielone”.
5. Opowiedz o sytuacji, w której Twoje kontrole przechodziły, a system nie działał
Moja: przez pięć dni w sierpniu 2026 moje alerty o awariach nie działały, a ja o tym nie wiedziałem.
Zaczęło się od odwrotnego błędu. Do 16 sierpnia każde z moich dziewięciu zaplanowanych zadań zgłaszało sukces, nawet kiedy się wywalało, bo ostatnią linijką każdego skryptu był wpis do logu, a ten zawsze się udawał.
Razem z agentem dodaliśmy więc alerty na Slacku do wszystkich dziewięciu. Agent napisał skrypt pomocniczy, a żeby zepsuty alert nie mógł położyć zadania, ten połykał każdy błąd. Zatwierdziłem to. Wyglądało na ostrożne.
Python na moim Macu nigdy nie dostał swojego pakietu certyfikatów, więc każde jego wywołanie https padało, po cichu. curl korzysta z certyfikatów systemowych, więc wszystko inne działało i nic nie wyglądało na zepsute.
21 sierpnia jedna sesja agenta trafiła na ten błąd certyfikatu, obeszła go inną biblioteką i poszła dalej. Druga sesja, która tego samego popołudnia budowała nowy health check, poszła do źródła problemu i odkryła, że skrypt od alertów był martwy od dnia, w którym powstał. Moja notatka z tamtego dnia: mechanizm zbudowany, żeby skończyć z cichymi awariami, sam po cichu nie działał.
Nigdy się nie dowiedziałem, czy w tych pięciu dniach któreś zadanie padło. Odpowiedź, na którą czekają, to poprawka. Sprawdzaj na starcie, nie obchodź problemu po cichu: zadanie, które potrzebuje sieci, najpierw sprawdza, czy pakiet certyfikatów jest na miejscu, i kończy się kodem różnym od zera, jeśli go brakuje. I naprawiaj maszynę, a nie jeden skrypt, bo obejście zostawia uzbrojoną pułapkę na każdy inny skrypt.
Czerwona flaga: nigdy Ci się to nie zdarzyło. Po roku kierowania agentami „nigdy” zwykle znaczy, że nie patrzyłeś.
6. Przejmujesz działający kod zbudowany przez zewnętrznego partnera. Co agent robi w pierwszym tygodniu?
To prawdziwa sytuacja FTMO: „Pierwsza wersja działa na produkcji z prawdziwymi użytkownikami i powstała razem z zewnętrznym partnerem”. Poradnik rekrutacyjny jobsbyculture nazywa tę umiejętność wprost: „potrafią utrzymać w głowie cudzy kod na tyle długo, żeby wnieść coś użytecznego. To większość tej pracy”.
W pierwszym tygodniu agent czyta, a Ty robisz notatki. Zmapuj ścieżki, którymi płyną pieniądze, wywołania dostawców i miejsca bez testów, a potem z tego, co znalazłeś, napisz plik instrukcji dla tego kodu. Twój pierwszy commit to test.
Czerwona flaga: „Poprosiłbym agenta o refaktoryzację”.
7. Napisz specyfikację, zanim agent napisze choć linijkę
Specyfikowanie to pierwszy czasownik w zdaniu FTMO. Prowadzący rozmowy w Elicit zauważyli, jak rzadko się to zdarza: „Myślenie, które zaczyna się od planu, jest rzadsze, niż się spodziewaliśmy”.
Marek opisał mi w październiku drogę swojego zespołu. Najpierw kod pisali agenci. Potem doszło code review robione przez AI, a po nim człowiek. Potem wąskim gardłem stały się testy.
„Wtedy cofamy się aż do generowania specyfikacji … musimy mieć dobrą specyfikację”. Skończyli tam, gdzie zaczyna się zdanie FTMO.
Mocna odpowiedź to pół strony, które piszesz na miejscu: kim jest użytkownik, co się dla niego zmienia, co nie może się wydarzyć (przypadki z pieniędzmi) i skąd będziesz wiedzieć, że zadziałało.
Czerwona flaga: otwierasz agenta w pierwszej minucie.
8. Coś się zepsuło na produkcji. Opowiedz, co robisz przez następną godzinę
Ogłoszenie odpowiada na pytanie o odpowiedzialność, zanim zrobisz to Ty: „Odpowiadasz za swoje funkcje na produkcji: monitoring, incydenty i poprawki, bez przekazywania ich komuś innemu”.
Mój incydent pochodzi z 25 października 2026. Wdrożyłem na tę stronę trzy nowe podstrony, sprawdziłem je, wszystkie zwracały 200. Mniej więcej godzinę później wszystkie trzy zwracały 404. Lista wdrożeń pokazała dwa, których nie robiłem: inna sesja agenta w tym samym repozytorium wgrała starszą kopię strony na moją.
Mój własny push też nie dotarł na serwer, a moja kontrola twierdziła, że dotarł, bo obie porównywane kopie były stare. Poprawka jest teraz zasadą: najpierw push, potem potwierdzenie, że commit jest na głównej gałęzi, wdrożenie stamtąd i ponowne sprawdzenie nowych podstron 30 do 60 minut później, kiedy działają inne sesje.
Czerwona flaga: „Tę część napisał agent”.
9. Wywołanie dostawcy się wywala, a wszystko dalej pokazuje OK. Jak się o tym dowiadujesz?
Lista FTMO to silnik transakcyjny, dane rynkowe, płatności i KYC, więc cicha awaria u dostawcy kosztuje pieniądze. Mocna odpowiedź to historia, w której dostawca powiedział „nie”, a Twój system powiedział „tak”.
Moja pochodzi z 30 sierpnia 2026. Attio, mój CRM, odrzuca cały rekord, jeśli nie zna nazwy choćby jednego pola. Po zmianie nazwy jednego pola i dodaniu czterech nowych zapisy z mojego pipeline’u mentoringowego zaczęły wracać z kodem 400, a integracja łapała tylko błędy sieciowe, więc niczego nie zalogowała i odpowiadała narzędziu do rezerwacji „ok”. Lista nowych zapytań stała na zerze, a maile z ofertą wychodziły bez zarzutu.
Teraz każdy zapis przechodzi przez jedną funkcję pomocniczą, która sprawdza kod statusu i loguje błąd, a codzienny health check wysyła mi alert o tym błędzie.
Czerwona flaga: „Ufamy ich SLA”.
10. Skąd wiesz, że Twoje środowisko agentów jest coraz lepsze?
Ogłoszenie pyta o ewaluacje i pętle testowe. Najlepszą odpowiedź, jaką słyszałem, dał Team Lead z pętlą do zasad. Nazwijmy go Ondřej.
Jego pętla czyta sesje agentów jego zespołu i code review w pull requestach. Kiedy ktoś w review zostawia ten sam komentarz w pięciu pull requestach z rzędu, pętla proponuje zasadę i otwiera pull request do pliku instrukcji. Ondřej puścił ją na sześciu miesiącach historii review.
Każdy z tych pull requestów nadal przegląda człowiek. A raz na miesiąc albo dwa zespół czyta plik „świeżym okiem” i tnie, bo plik nie może rosnąć w nieskończoność. Tak wygląda środowisko, które jest coraz lepsze, z dowodami w historii gita.
Czerwona flaga: „Mam wrażenie, że jest szybciej”.
Przygotuj 15-minutowy pokaz przed rozmową
Zaplanuj 15 minut, po trzy na każdą część. Wypełnij prawą kolumnę swoim środowiskiem, a potem raz opowiedz to na głos bez agenta.
| Część (po 3 min) | Co pokazać | Moje, jako przykład |
|---|---|---|
| Pliki | Plik instrukcji, skille, konfiguracje | Jeden globalny plik na 206 linii plus jeden na każdy projekt |
| Lista zakazów | Które zasady są hookami i dlaczego | Strażnik rm i hook blokujący Gmaila |
| Pętla | Jak zmiana jest sprawdzana, zanim trafi na produkcję | Build pada przy brakującym obrazku, wpisie bez FAQ albo złym kluczu analityki |
| Jedna awaria | Wyłapana albo przepuszczona, z datą | Pięć dni martwych alertów, sierpień 2026 |
| Co dalej | Jedna luka, o której wiesz | Moje zadania dalej chodzą na jednym Macu, więc padnięty laptop to padnięty pipeline |
Jeśli Twoje środowisko jest skromne, masz siedem dni
Używaj dat z błędów, które naprawdę popełniłeś. Rozmówca zapyta, co się wtedy stało.
| Dni | Co zrobić |
|---|---|
| 1-2 | Napisz plik instrukcji na podstawie trzech ostatnich błędów z agentem, każda zasada z datą |
| 3 | Zamień najdroższy z nich w hook |
| 4-5 | Napisz jeden test, którego agent nie może edytować, na ścieżce, na której ucierpiałyby pieniądze albo użytkownicy |
| 6 | Opisz jedną awarię z datą i tym, co zmieniłeś |
| 7 | Przejdź przez całość na głos, bez agenta, na czas |
Działa to też w drugą stronę. Inny mentee, nazwijmy go Radek, sprawdza pracodawców, zanim wyśle aplikację, i ma w notatkach jedno pytanie: „Czy będę mógł używać AI jako codziennej dźwigni w pracy?” Poproś ich, żeby też pokazali Ci swoje środowisko.
Pavel ma swój tydzień. Jeśli chcesz przećwiczyć tę godzinę, zanim zacznie się liczyć, robimy to w mentoringu dla Staff Engineerów: razem otwieramy Twoje środowisko, a ja zadaję Ci te dziesięć pytań.
To jak: gdybyś jutro musiał otworzyć swoje środowisko przed rozmówcą, który plik zamknąłbyś najpierw?
