Nie tylko kod. Dlaczego autoprezentacja i kompetencje komunikacyjne coraz częściej decydują o zatrudnieniu developera?

Kompetencje miękkie nie są już dodatkiem

Raport Pracuj.pl i theprotocol.it pokazuje, że 64% rekruterów uważa znaczenie kompetencji miękkich w IT za większe, niż się powszechnie sądzi. W przypadku każdego stanowiska uwzględnionego w badaniu ponad 2/3 rekruterów uznało je za istotne lub bardzo istotne.

Wśród najczęściej poszukiwanych cech znalazły się:

• krytyczne myślenie,
• rozwiązywanie problemów,
• odporność na stres,
• zarządzanie czasem,
• komunikacja w zespole
• umiejętność tłumaczenia trudnych kwestii prostym językiem.

Jednocześnie tylko 33% respondentów uznało komunikatywność za cechę dobrze rozwiniętą wśród specjalistów IT.

To pokazuje, że kandydaci zwykle wiedzą, jak ważna jest komunikacja, ale nie zawsze potrafią zaprezentować ją podczas rozmowy.

Dlaczego dobry kod nie wystarcza?

Kod jest odpowiedzią na problem użytkownika lub potrzebę biznesową. Nawet dobre technicznie rozwiązanie może być nietrafione, gdy developer nie upewni się, że właściwie rozumie cel zadania.

W codziennej pracy trzeba zadawać pytania, zgłaszać ryzyka, przedstawiać warianty rozwiązania, przyjmować feedback i przekazywać wiedzę. W projektach dla klientów dochodzi jeszcze umiejętność wyjaśnienia konsekwencji technicznych osobom bez specjalistycznej wiedzy.

W projektach realizowanych przez Mood Up developerzy współpracują z klientami z różnych krajów i branż, między innymi przy aplikacjach mobilnych, webowych, IoT i streamingowych. W takim środowisku liczy się nie tylko poprawność kodu, ale też odpowiedzialność, decyzyjność i jasna komunikacja.

Developer nie musi być zawodowym mówcą. Musi jednak potrafić przekazywać swoją wiedzę w sposób zrozumiały dla wszystkich.

Autoprezentacja to nie przechwalanie się

Dobra autoprezentacja nie polega na tworzeniu sztucznego wizerunku. Chodzi o uporządkowane pokazanie własnego doświadczenia.

Kandydat powinien umieć wyjaśnić, przy jakim produkcie pracował, jaki problem rozwiązywał, za co odpowiadał, jakie działania podjął i jaki rezultat przyniosła jego praca.

Rekruter nie zna całej historii zawodowej kandydata. Ocenia ją na podstawie CV i ograniczonej czasowo rozmowy. Nawet bardzo dobry specjalista może wypaść słabo, jeśli odpowiada chaotycznie, używa ogólników albo nie potrafi nazwać własnego wkładu.

Autoprezentacja nie zastępuje kompetencji. Pozwala je zauważyć i właściwie ocenić.

Sama deklaracja nie wystarczy

Aż 70% rekruterów uważa, że specjaliści IT mają trudności z realistyczną oceną własnych kompetencji miękkich. Dlatego zdanie „dobrze pracuję w zespole” nie jest wystarczającym argumentem.

Zamiast deklarować dobrą komunikację, warto przywołać konkretną sytuację:

Klient chciał wdrożyć funkcję w terminie, który nie uwzględniał zależności po stronie backendu. Przygotowałem dwa warianty realizacji, przedstawiłem ich wpływ na czas i ryzyko, a następnie omówiłem je z klientem. Wybraliśmy rozwiązanie etapowe i dostarczyliśmy najważniejszą część funkcji zgodnie z terminem.

Taka odpowiedź pokazuje komunikację, analizę ryzyka, odpowiedzialność i rozumienie biznesu.

Jak opowiadać o doświadczeniu technicznym?

Samo wymienienie technologii nie pokazuje poziomu samodzielności. Zamiast mówić „Mam doświadczenie z React, TypeScript czy Node.js”, lepiej wyjaśnić, do czego zostały wykorzystane i jaki problem udało się dzięki nim rozwiązać.

Odpowiedź można uporządkować według czterech elementów:

1. Kontekst - jaki był cel produktu i kto z niego korzystał?
2. Problem - co wymagało rozwiązania?
3. Działanie - za co odpowiadał kandydat i jaką decyzję podjął?
4. Rezultat - co zmieniło się dzięki jego pracy?

Taka konstrukcja pozwala połączyć wiedzę techniczną z odpowiedzialnością i komunikacją.

Najczęstsze błędy podczas rozmowy

Kandydaci często odpowiadają bez konkretnego przykładu, mówią wyłącznie o pracy całego zespołu, używają nadmiernie technicznego języka albo próbują ukryć brak wiedzy.

Lepszym podejściem jest przygotowanie przykładów trudnych sytuacji, jasne wskazanie własnej odpowiedzialności, dopasowanie języka do rozmówcy oraz otwarte przyznanie, czego jeszcze się nie wie.

Szczególnie istotna jest umiejętność tłumaczenia złożonych tematów. Osoba biznesowa nie musi znać szczegółów technicznych, ale powinna rozumieć wpływ decyzji na budżet, termin, bezpieczeństwo lub działanie produktu.

Uproszczenie języka nie oznacza upraszczania problemu. Oznacza przedstawienie go tak, aby odbiorca go zrozumiał i mógł podjąć właściwą decyzję.

Jak przygotować się do rozmowy?

Przed spotkaniem warto przeanalizować wymagania stanowiska i przygotować kilka historii pokazujących współpracę, rozwiązywanie problemów, reagowanie na zmianę oraz kontakt z klientem.

Pomaga także krótka prezentacja zawodowa odpowiadająca na cztery pytania:

1. W czym się specjalizuję?
2. Przy jakich produktach pracowałem?
3. Za co odpowiadałem?
4. Jakiego rodzaju wyzwań obecnie szukam?

W firmach realizujących projekty dla zewnętrznych organizacji spotkanie z klientem może być częścią rekrutacji. W przypadku rozbudowy zespołów technologicznych z Mood Up developerzy stają się częścią środowiska projektowego klienta. Muszą więc sprawnie funkcjonować nie tylko w kodzie, lecz także w komunikacji, procesach i strukturze odpowiedzialności.

Kod otwiera drzwi, ale komunikacja pomaga przez nie przejść

Wiedza techniczna pozostaje podstawą pracy developera. Kompetencje komunikacyjne nie zastępują znajomości technologii ani umiejętności tworzenia dobrego kodu.

Mogą jednak zdecydować o tym, czy wiedza kandydata zostanie właściwie zauważona i czy będzie można skutecznie wykorzystać ją w projekcie.

Rekrutacja nie sprawdza już wyłącznie, czy kandydat potrafi napisać kod. Sprawdza również, czy potrafi współpracować przy tworzeniu produktu.

Developer, który jasno opowiada o doświadczeniu, uzasadnia decyzje, przyznaje się do niewiedzy i tłumaczy złożone zagadnienia w zrozumiały sposób, pokazuje nie tylko swoje kompetencje. Pokazuje także, jak będzie funkcjonował w zespole.

[artykuł sponsorowany]