Dlaczego rekrutacja techniczna w IT zawodzi — tylko nie od razu

Większość procesów rekrutacyjnych w IT opiera się na jednym, z pozoru rozsądnym założeniu: jeśli uda się rzetelnie sprawdzić wiedzę techniczną kandydata, ryzyko złej decyzji znacząco spadnie. W praktyce oznacza to skupienie się na tym, co da się szybko nazwać, porównać i ocenić w trakcie rozmowy znajomości technologii, rozumieniu wzorców czy poprawności odpowiedzi na konkretne pytania.

To podejście daje poczucie kontroli. Wiedza jest mierzalna, możliwa do zestawienia pomiędzy kandydatami i relatywnie łatwa do ocenienia w ograniczonym czasie. Pozwala uporządkować proces, „odhaczyć” kompetencje i przejść dalej. Na papierze wszystko wygląda spójnie i logicznie.

Trudności pojawiają się dopiero wtedy, gdy spojrzymy na to, gdzie w rzeczywistości powstają największe koszty w projektach software’owych. Z perspektywy zespołów, które rozwijają systemy przez lata, bardzo szybko okazuje się, że problemy rzadko mają związek z brakiem wiedzy technicznej. Porażki projektowe niemal nigdy nie wynikają z tego, że ktoś „nie znał technologii” lub nie opanował określonego frameworka.

Znacznie częściej są one konsekwencją decyzji podejmowanych w dobrej wierze, pod presją czasu, przy niepełnych informacjach i w określonym kontekście organizacyjnym. Są to decyzje, które w momencie podjęcia wydają się rozsądne, które dobrze brzmią w rozmowie, przechodzą code review i nie budzą większych zastrzeżeń. Ich skutki ujawniają się dopiero po miesiącach, gdy system zaczyna rosnąć, a wcześniejsze wybory zaczynają się ze sobą kumulować.

To właśnie te decyzje a nie brak znajomości konkretnego narzędzia czy wzorca w największym stopniu decydują o tym, czy system będzie się rozwijał w sposób przewidywalny, czy zacznie stopniowo tracić elastyczność, zwiększać koszt zmian i ograniczać tempo pracy zespołu.

W tym miejscu ujawnia się fundamentalne ograniczenie standardowych procesów rekrutacyjnych. Nie są one zaprojektowane do obserwowania jakości decyzji w czasie. Nie dlatego, że ten obszar jest mniej istotny, ale dlatego, że bardzo trudno uchwycić go w formacie klasycznej rozmowy.

Decyzje systemowe nie objawiają się jedną, poprawną odpowiedzią. Ujawniają się w sposobie myślenia, w reakcji na niejednoznaczność, w rozumieniu konsekwencji własnych wyborów oraz w gotowości do ponoszenia ich kosztu. Tych elementów nie widać w CV i nie da się ich zweryfikować listą pytań. I właśnie dlatego tak często umykają aż do momentu, w którym koszt przestaje być abstrakcyjny, a staje się realnym problemem dla zespołu i organizacji.