Dlaczego rekrutacja techniczna w IT zawodzi — tylko nie od razu

Jednym z najmniej oczywistych, a jednocześnie najbardziej kosztownych ograniczeń klasycznych rozmów technicznych jest to, że koncentrują się one na poprawności odpowiedzi, a nie na sposobie dochodzenia do decyzji. Proces rekrutacyjny bardzo często zakłada, że jeśli kandydat potrafi wskazać właściwe rozwiązanie, to potrafi również podejmować dobre decyzje w realnym systemie. W praktyce są to dwie zupełnie różne kompetencje.****

Różnica pomiędzy „znam rozwiązanie” a „rozumiem problem, jego kontekst i konsekwencje” wydaje się subtelna, dopóki nie zacznie się analizować projektów, które po kilku miesiącach zaczęły tracić spójność, elastyczność lub tempo rozwoju. Wtedy okazuje się, że poprawne odpowiedzi udzielone na rozmowie nie miały większego znaczenia, ponieważ nie przełożyły się na jakość decyzji podejmowanych w czasie.****

Rekrutacje techniczne bardzo często premiują wiedzę deklaratywną. Kandydaci uczą się schematów pytań, zapamiętują wzorce odpowiedzi i ćwiczą sposób ich prezentacji, wiedząc, że rozmowa będzie miała określoną strukturę i przewidywalny przebieg. Z czasem cały proces zaczyna przypominać egzamin z przygotowania do rekrutacji, a nie próbę zrozumienia, jak dana osoba faktycznie myśli i działa w warunkach projektowych.****

Problem polega na tym, że codzienna praca inżynierska niemal nigdy nie wygląda jak rozmowa rekrutacyjna. Problemy rzadko są kompletne, wymagania zmieniają się w trakcie, a decyzje trzeba podejmować bez pełnej informacji i bez gwarancji, że będzie czas na ich bezkosztowe cofnięcie. Co więcej, konsekwencje tych decyzji bardzo rzadko są widoczne od razu. Często ujawniają się dopiero po tygodniach lub miesiącach, kiedy system zaczyna rosnąć, a wcześniejsze wybory zaczynają się kumulować.****

W takim środowisku kluczowe nie jest to, czy ktoś zna „właściwą” odpowiedź, ale jak radzi sobie z niejednoznacznością, jak formułuje założenia, jakie ryzyka potrafi nazwać i w jaki sposób bierze odpowiedzialność za konsekwencje swoich decyzji. Tego nie da się ocenić na podstawie pojedynczego pytania ani nawet serii pytań technicznych, ponieważ nie chodzi o sam rezultat, lecz o proces myślowy, który do niego prowadzi.****

Poprawna odpowiedź na rozmowie technicznej mówi bardzo niewiele o tym, jak dana osoba będzie funkcjonować pod presją, w warunkach niepełnych danych i realnego kosztu błędu. Może świadczyć o przygotowaniu do procesu, ale niekoniecznie o zdolności do podejmowania decyzji, które będą miały sens w dłuższym horyzoncie. A to właśnie te decyzje, podejmowane codziennie i często bez spektakularnych sygnałów ostrzegawczych, decydują o tym, czy system zachowa zdolność do rozwoju, czy zacznie stopniowo generować coraz większe koszty.****

Drugim obszarem, który standardowe procesy rekrutacyjne omijają niemal całkowicie, są długofalowe skutki decyzji technicznych. Rozmowy techniczne z natury skupiają się na tym, co da się ocenić w krótkim czasie: czy kandydat zna dany wzorzec, czy potrafi zaproponować rozwiązanie „na teraz”, czy umie logicznie uzasadnić wybór technologii. Wszystko to daje poczucie, że decyzja została podjęta w sposób racjonalny i ustrukturyzowany.****

Znacznie rzadziej pojawia się jednak pytanie o to, co dzieje się z tą decyzją później. O koszt jej zmiany, o wpływ na utrzymanie systemu, o to, jak będzie się zachowywać w miarę wzrostu skali i złożoności. Architektura bardzo często traktowana jest jako jednorazowy wybór, który albo jest „dobry”, albo „zły”, zamiast jako proces ciągłych kompromisów, których konsekwencje ujawniają się dopiero w czasie.****

W praktyce wiele problemów projektowych nie wynika z decyzji oczywiście błędnych. Przeciwnie są one efektem decyzji, które w momencie podjęcia wydawały się rozsądne, eleganckie i dobrze uargumentowane. To rozwiązania, które świetnie brzmią w rozmowie, bez trudu przechodzą code review i nie budzą sprzeciwu zespołu, ponieważ lokalnie optymalizują konkretny fragment systemu.****

Dopiero po kilku miesiącach zaczyna się okazywać, że te same decyzje wprowadzają sztywność, wzmacniają sprzężenia i stopniowo podnoszą koszt każdej kolejnej zmiany. System traci zdolność do adaptacji nie w wyniku jednego spektakularnego błędu, ale na skutek kumulacji drobnych wyborów, które nigdy nie zostały ocenione pod kątem długofalowych konsekwencji.****

I właśnie ten mechanizm sprawia, że problemy architektoniczne tak często zaskakują zespoły. Nie dlatego, że ktoś popełnił oczywisty błąd, ale dlatego, że proces rekrutacyjny nigdy nie sprawdził, jak dana osoba myśli o decyzjach w perspektywie czasu, a jedynie jak potrafi je uzasadnić w perspektywie rozmowy.

Jednym z najbardziej systemowych zniekształceń w rekrutacji technicznej jest rozdźwięk pomiędzy tym, jak wygląda rozmowa, a tym, jak wygląda realna praca po jej zakończeniu. Zdecydowana większość projektów software’owych funkcjonuje w środowisku, które jest dalekie od idealnych warunków startowych. Systemy mają swoją historię, narosłe kompromisy, dług techniczny oraz zależności organizacyjne, których nie da się usunąć jedną decyzją architektoniczną.**

Mimo to rozmowy rekrutacyjne bardzo często zakładają scenariusz, który z rzeczywistością ma niewiele wspólnego. Pytania koncentrują się na projektowaniu od zera, swobodnym wyborze technologii i budowaniu „idealnego” rozwiązania w próżni. Kandydat funkcjonuje w świecie, w którym nie istnieją wcześniejsze decyzje, zobowiązania wobec klientów ani konsekwencje organizacyjne, a jedynym kryterium jakości jest spójność koncepcji.**

Taki format rozmowy naturalnie premiuje osoby, które potrafią tworzyć czyste, eleganckie wizje systemów. Problem polega na tym, że zdolność do projektowania greenfieldu nie jest tym samym, co zdolność do rozwijania systemu, który już działa, obsługuje użytkowników i stanowi element większego ekosystemu biznesowego. W praktyce są to dwie różne kompetencje, wymagające innego zestawu doświadczeń i innego sposobu oceny ryzyka.**

Praca z istniejącym systemem rzadko polega na budowaniu czegoś „od nowa”. Znacznie częściej oznacza konieczność poruszania się w ramach ograniczeń, rozumienia cudzych decyzji oraz podejmowania zmian, które muszą współgrać z tym, co już istnieje. To praca, w której nie chodzi o znalezienie najlepszego możliwego rozwiązania, lecz o wybór rozwiązania najmniej ryzykownego w danym kontekście.**

Doświadczenie oparte głównie na greenfieldach bywa w tym środowisku zwodnicze. Uczy myślenia w warunkach, które występują rzadko i przez krótki czas, a jednocześnie nie przygotowuje do pracy z systemem, w którym każda decyzja musi uwzględniać historię projektu, ograniczenia zespołu i realia biznesowe. To, co na rozmowie wygląda jak odwaga technologiczna, w praktyce bywa brakiem wrażliwości na koszt zmian i konsekwencje długoterminowe.**

**Standardowe procesy rekrutacyjne bardzo rzadko próbują sprawdzić, jak kandydat odnajduje się właśnie w takiej rzeczywistości nie dlatego, że jest to obszar mniej istotny, ale dlatego, że znacznie trudniej go zasymulować w trakcie rozmowy. Efektem jest sytuacja, w której decyzje rekrutacyjne są podejmowane na podstawie umiejętności projektowania świata idealnego, a nie funkcjonowania w świecie, który już istnieje.

Jednym z najrzadziej poruszanych, a jednocześnie najbardziej decydujących czynników w pracy inżynierskiej jest sposób funkcjonowania w warunkach niejednoznaczności. W projektach bardzo rzadko istnieje moment, w którym wszystkie informacje są kompletne, wymagania zamknięte, a konsekwencje decyzji w pełni przewidywalne. Zamiast tego dominują sytuacje graniczne: niepełne dane, sprzeczne oczekiwania interesariuszy, presja czasu i konieczność działania „tu i teraz”, bez komfortu idealnej analizy.****

Tego rodzaju środowisko nie jest wyjątkiem, lecz normą w dojrzałych organizacjach. Im większy system, im większa skala odpowiedzialności i im bliżej core’u biznesowego, tym mniej jednoznacznych odpowiedzi, a więcej decyzji podejmowanych na podstawie najlepszej dostępnej oceny ryzyka. I właśnie w takich momentach ujawnia się realna dojrzałość inżynierska nie w tym, czy ktoś zna poprawne rozwiązanie, lecz w tym, jak zachowuje się, gdy poprawne rozwiązanie po prostu nie istnieje.****

Klasyczne procesy rekrutacyjne próbują tę niejednoznaczność eliminować. Pytania są precyzyjne, zakres jasno określony, a odpowiedź da się ocenić jako „dobra” lub „zła”. Kandydat funkcjonuje w bezpiecznym środowisku, w którym brak odpowiedzi bywa traktowany jako słabość, a przyznanie się do wątpliwości jako brak kompetencji. W efekcie rozmowa techniczna nagradza pewność siebie i klarowność wypowiedzi, a nie zdolność do świadomego zarządzania niepewnością.****

Tymczasem w rzeczywistej pracy inżynierskiej brak jednoznaczności jest często sygnałem, a nie problemem. Wymaga on umiejętności formułowania założeń, komunikowania ryzyk, podejmowania decyzji z pełną świadomością ich nieodwracalności oraz gotowości do ponoszenia konsekwencji. Różnica pomiędzy osobą, która mówi „czekam na specyfikację”, a osobą, która potrafi powiedzieć „na podstawie tego, co wiemy, zrobiłbym X, bo Y, a ryzykiem jest Z”, jest różnicą o ogromnym znaczeniu systemowym.****

Dla osób decyzyjnych ten aspekt ma szczególną wagę. Każda decyzja rekrutacyjna w obszarze technicznym oznacza wprowadzenie do organizacji nowego „węzła decyzyjnego” osoby, która w praktyce będzie podejmować dziesiątki mikrodecyzji dziennie, często bez bezpośredniego nadzoru, często w sytuacjach niejednoznacznych. To nie są decyzje widoczne w raportach ani łatwe do audytowania, ale to one w długim okresie kształtują architekturę systemu, tempo pracy zespołu i poziom ryzyka operacyjnego.****

Problem polega na tym, że dojrzałość w pracy z niejednoznacznością bardzo rzadko ujawnia się na rozmowie rekrutacyjnej. Nie dlatego, że kandydaci ją ukrywają, lecz dlatego, że sam proces nie stwarza warunków, w których można by ją zaobserwować. Brak realnej odpowiedzialności, brak presji czasu i brak kosztu błędu sprawiają, że rozmowa testuje deklaracje, a nie zachowania.****

W efekcie organizacje często zatrudniają osoby, które świetnie radzą sobie w warunkach pełnej kontroli, ale tracą orientację wtedy, gdy muszą samodzielnie ocenić ryzyko i podjąć decyzję bez pełnego obrazu sytuacji. To nie jest problem kompetencyjny w klasycznym sensie. To problem dopasowania do realiów systemu, w którym decyzje rzadko są czarno-białe, a odpowiedzialność nie zawsze da się rozłożyć na wiele osób.****

Z perspektywy systemowej właśnie ten obszar reakcji na niejednoznaczność jest jednym z najsilniejszych predyktorów tego, czy decyzje podejmowane przez nową osobę będą w długim horyzoncie stabilizować system, czy stopniowo zwiększać jego kruchość. I właśnie dlatego pomijanie go w procesie rekrutacyjnym sprawia, że ryzyko ujawnia się dopiero po czasie, kiedy koszt korekty staje się znacznie wyższy niż na etapie podejmowania decyzji.

Złe decyzje rekrutacyjne bardzo rzadko niszczą projekt w sposób natychmiastowy i jednoznaczny. Nie ma momentu, w którym system „przestaje działać”, a zespół może wskazać konkretną datę, osobę lub decyzję jako źródło problemu. Zamiast tego negatywne skutki ujawniają się stopniowo, w sposób rozproszony i trudny do jednoznacznego zidentyfikowania.****

Na etapie rozmowy rekrutacyjnej wszystko zazwyczaj wygląda poprawnie. Kandydat dobrze odpowiada na pytania, rozumie technologię, potrafi logicznie uzasadnić swoje wybory. Pierwsze tygodnie współpracy również nie budzą większych zastrzeżeń. Zadania są dowożone, zespół zakłada, że nowa osoba „wchodzi w projekt”, a ewentualne tarcia traktowane są jako naturalny element onboardingu.****

Problem pojawia się dopiero później, gdy pojedyncze decyzje zaczynają się kumulować, a system stopniowo traci zdolność do elastycznego reagowania na zmiany. Rozwiązania, które początkowo wydawały się rozsądne, zaczynają ograniczać rozwój. Koszt cofnięcia wcześniejszych wyborów rośnie, a każda kolejna modyfikacja wymaga coraz więcej pracy, koordynacji i kompromisów.****

W tym momencie trudno już wskazać jeden punkt zapalny. Zespół nie widzi jednego błędu, który można naprawić, ani jednej decyzji, którą da się łatwo odwrócić. Zamiast tego pojawia się poczucie, że projekt stał się bardziej skomplikowany, cięższy w utrzymaniu i mniej przewidywalny niż wcześniej.****

Dlatego zespoły niemal nigdy nie opisują tej sytuacji jako rezultat błędnej decyzji rekrutacyjnej. Znacznie częściej padają sformułowania mówiące o tym, że „projekt się rozrósł”, „architektura się skomplikowała” albo że „z czasem pojawiło się więcej zależności”. Problem zostaje nazwany językiem systemu, a nie decyzji, mimo że jego źródło leżało znacznie wcześniej w momencie, gdy nie było jeszcze żadnych wyraźnych sygnałów ostrzegawczych.****

Problemy opisane wcześniej rzadko pozostają niewidoczne dlatego, że są drugorzędne lub mało istotne. W większości organizacji znikają z pola widzenia z zupełnie innego powodu: standardowe procesy rekrutacyjne nigdy nie zostały zaprojektowane po to, by je wychwytywać.****

Rekrutacja skupiona na wiedzy i poprawności odpowiedzi działa dobrze wtedy, gdy celem jest szybka selekcja kompetencji technicznych. Przestaje jednak działać w momencie, gdy stawką stają się decyzje podejmowane w czasie, konsekwencje architektoniczne i wpływ pojedynczej osoby na cały system pracy zespołu. Tych obszarów nie da się łatwo zaobserwować w trakcie rozmowy, dlatego bardzo często pozostają poza procesem aż do momentu, w którym zaczynają generować realny koszt.****

W praktyce oznacza to, że wiele organizacji uświadamia sobie istnienie ryzyka dopiero wtedy, gdy jest ono już rozproszone po całym systemie. Zamiast jednego wyraźnego sygnału pojawiają się opóźnienia, napięcia w zespole, rosnący dług techniczny i spadek elastyczności projektu. Na tym etapie łatwo pomylić problem systemowy z personalnym i próbować reagować punktowo, naprawiając objawy zamiast przyczyn.****

To właśnie dlatego decyzje rekrutacyjne tak rzadko są kwestionowane w odpowiednim momencie. Nie dlatego, że były oczywiście błędne, ale dlatego, że nie istniał mechanizm, który pozwoliłby wcześniej zauważyć ich długofalowe konsekwencje.****

Jeżeli chcesz przyjrzeć się temu głębiej zrozumieć, jakie obszary standardowa rekrutacja konsekwentnie pomija, dlaczego zespoły dostrzegają problemy dopiero po czasie i w jaki sposób realnie zmniejszyć ryzyko złych decyzji bez poszukiwania nieistniejących „idealnych ludzi” przygotowaliśmy osobny dokument oparty na pracy z rzeczywistymi zespołami i projektami, w których koszt tych decyzji stał się namacalny.****