Przez długi czas uważałem, że rozmowy techniczne są źle prowadzone. Skoro mam publiczny kod open source, myślałem, to powinno wystarczyć, żeby pokazać, co potrafię. Nie mówię o repozytorium założonym w niedzielę wieczorem z trzema commitami o nazwie "fix", ale o latach projektów, issue, pull requestów, bibliotek używanych przez prawdziwych ludzi i błędów naprawianych o drugiej w nocy, podczas gdy ktoś otwiera issue zawierające wyłącznie "not work".
Idealna rozmowa w mojej głowie była prosta: techniczna osoba przeglądała mój GitHub, wybierała projekt i pytała, dlaczego użyłem takiej struktury, czemu odrzuciłem inne rozwiązanie i który błąd zmusił mnie do przepisania wszystkiego we wtorkowe popołudnie. Wyjaśniałem swoje wybory, druga strona rozumiała mój sposób myślenia, a potem przychodziła oferta.
Rzeczywistość wyglądała trochę inaczej. Seria technicznych pytań, zagadki logiczne, quizy z LeetCode, drzewa binarne do odwracania na tablicy i tablice do sortowania bez zaglądania do internetu. Wszystko po to, żeby przygotować cię do prawdziwej pracy, w której poniedziałek spędzisz na wyśrodkowaniu przycisku, a wtorek na rozmowie o tym, czy nazwać go button-primary, czy primary-button.
Potem pojawiły się pierwsze chatboty w 2022 roku, agenci w 2025 i nagle ChatGPT przestał być kartą dyskretnie otwartą w przeglądarce, a stał się aplikacją o nazwie Codex, stale otwartą i pracującą na twoim MacBooku. Został wydajnym stażystą: nie bierze urlopu, nie obraża się, gdy prosisz go o sześciokrotne przepisanie tej samej funkcji, a przede wszystkim nigdy nie mówi: "Tę część zrobił poprzedni kolega, który już nie pracuje w firmie".
Natrafiłem na wpis antireza "Control the ideas, not the code". Nie chodzi w nim o to, że kompetencje przestały być potrzebne ani że wystarczy napisać "zrób mi Redis, tylko ładniejszy" i pójść na obiad. Autor opisuje implementowanie z AI złożonych części DwarfStar, silnika inferencji dla LLM, przy jednoczesnym skupieniu się na architekturze, projekcie, wydajności, weryfikacji i QA zamiast czytania każdej funkcji wiersz po wierszu.
Nie przestał programować. Przeniósł pracę piętro wyżej.
Jeśli developer może dziś prowadzić agenta cel po celu, zbudować ogromny system i kontrolować jego jakość oraz kierunek bez napisania każdej linijki kodu (ale przede wszystkim, i to właśnie uderzyło mnie najbardziej, bez jej przeczytania), o co powinniśmy pytać podczas rozmów? "Zaimplementuj mi bubble sort w C": praktycznie zaczyna mieć to taką samą wartość jak poproszenie architekta, żeby na naszych oczach wyprodukował cegłę. Właściwie zatrudniłbym go, gdyby mu się udało.
Tymczasem Apple pozwało OpenAI, oskarżając firmę między innymi o zabieganie o poufne informacje podczas rekrutowania pracowników Apple, a nawet o proszenie kandydatów, by przynosili na rozmowy komponenty sprzętowe. Zarzuty nie zostały jeszcze udowodnione, ale scena jest wspaniała: przez dwadzieścia lat kazano nam przynosić CV. W 2026 roku najwyraźniej wystarczy prototypowa płyta główna w kieszeni marynarki. Jeśli uruchomisz alarm przy wyjściu, prawdopodobnie przeszedłeś pierwszy etap.
Co w takim razie mam przynieść? Historię promptów? Rozmowy, w których prowadziłem agenta aż do rozwiązania? Listę wewnętrznych procesów, które zautomatyzowałem? Firmowe sekrety, może uporządkowane według ważności w pliku Excela?
Być może rozmowa w 2026 roku powinna przypominać pracę w 2026 roku. Dajcie kandydatowi mały, ale niejednoznaczny problem i pozwólcie mu używać narzędzi, z których naprawdę korzystałby w pracy, łącznie z AI. Zobaczcie, jakie pytania zadaje przed rozpoczęciem, jak dzieli pracę, jaki kontekst przekazuje agentowi, jak rozpoznaje wiarygodnie brzmiącą, lecz błędną odpowiedź i jakie testy wymyśla, żeby spróbować ją zniszczyć.
Zapytajcie, dlaczego wybrał taką architekturę, co się stanie, gdy model zacznie halucynować, ile kosztuje rozwiązanie, jak wycofa wadliwe wdrożenie i której części nigdy nie powierzyłby AI. Poproście go o wyjaśnienie porażki. Udane projekty dowodzą, że raz wszystko poszło dobrze, ale dobrze wyjaśnione porażki pokazują, że następnym razem może pójść lepiej. Kod open source nadal jest przydatny, być może bardziej niż wcześniej, ale teraz liczy się historia stojąca za tym repozytorium, a nie sam kod.
W 2026 roku nie chcę być oceniany wyłącznie za to, jak szybko sortuję tablicę. Chcę być oceniany za umiejętność zrozumienia, czy ta tablica wymagała sortowania, czy mogliśmy w ogóle jej nie tworzyć, czy agent AI, który ją posortował, właśnie nie skasował produkcyjnej bazy danych i ile czasu zajęło mi zauważenie tego.
Nasze życie jako developerów trzeba napisać od nowa: staliśmy się kodem legacy, który należy wycofać, i musimy wdrożyć na produkcję nową wersję samych siebie.