Okiem programisty. Czy kandydat powinien przejmować inicjatywę na rozmowie rekrutacyjnej? Wywiad z Bartłomiejem Kurasem

Większości kandydatów na wakat w firmie towarzyszy lekki stres i niepewność, o co może zapytać go rekruter podczas rozmowy. A gdyby tak odwrócić tę sytuację o 180 stopni i postawić rekrutera w pozycji osoby, której to kandydat zadaje pytania? W rozmowie z Bartłomiejem Kurasem zapytaliśmy o wady i zalety przejmowania inicjatywy podczas rozmowy rekrutacyjnej oraz dotychczasowe reakcje na tak rzadko spotykany ruch.

Czy przejmowanie pałeczki podczas rozmów rekrutacyjnych to była Twoja inicjatywa? Czy jakaś sytuacja po prostu Cię do tego skłoniła?

Można powiedzieć, że była to moja inicjatywa, nie pamiętam konkretnej sytuacji, która by takie podejście spowodowała. Zwyczajnie zbyt dużo razy zdarzyło mi się zostać wprowadzonym w błąd w trakcie rozmowy rekrutacyjnej, żeby godzić się dołączać do kolejnego idealnego projektu, który okaże się identyczny z poprzednim.

Co sądzisz o możliwości stawiania żądań czy też zadawania nie do końca wygodnych pytań rekruterom? Czy jest to dla ciebie obowiązkowy element każdej rozmowy? Czy jednak nie zawsze jest na to miejsce?

Na pewno nie ma takiej rzeczy, na którą miejsce jest zawsze — mocne słowa i skrajności są na ogół mało uniwersalne. Jeśli na przykład jako całkowity junior aplikujemy na swoją pierwszą pozycję, zgrywając eksperta, możemy wyjść raczej zabawnie i stracić szansę na wejście na rynek — żeby być w pozycji osoby, która może zadawać niewygodne pytania, musimy być gotowi na to, jak po różnej odpowiedzi na takie pytanie zareagować i co w ogóle z niego wynieść.

Idąc dalej — nawet aplikując na pozycję architekta, warto mieć wyczucie komu, jakie pytania zadajemy. I tak być może nie warto w pierwszej rozmowie z osobą z HR (być może nawet z agencji związanej z firmą tylko krótką umową) zadawać niewygodnych pytań dotyczących organizacji pracy w projekcie — spowoduje to sprowadzenie rozmowy na nerwowy tor od początku, co wcale nie musi być korzystne.

Także jestem zdania, że od pytań lepszy jest zawsze research. Cała nasza rozmowa zaczęła się od tego, że zdarza mi się powiedzieć, że lubię prosić potencjalnego klienta o dostęp do kodu przed podjęciem ostatecznej decyzji. Jeśli rozmawiam z firmą, która zdecydowaną większość swojej pracy publikuje jako OpenSource, to podobna prośba będzie jasnym sygnałem dla klienta – „kandydat nie jest zainteresowany ofertą na tyle, żeby przeprowadzić podstawowy research”.

Natomiast są pewne sprawy, które staram się wyjaśnić z firmą zawsze, zanim podejmę z nią współpracę. Część z tych rzeczy jest niewygodna. Jeśli nie jestem w stanie wyciągnąć interesujących mnie informacji z innych źródeł (być może researchem publicznych informacji, być może mam w docelowym projekcie kolegę), zadam trudne pytania w procesie rekrutacji.

Oferty pracy z

Jakie były dotychczasowe reakcje, z jakimi spotkałeś się podczas przejmowania inicjatywy podczas rekrutacji? Jest to odbierane pozytywnie, czy pojawiły się również mniej przychylne opinie? 

Poważni (z mojego punktu widzenia) klienci odbierają taki ruch raczej pozytywnie. Z racji swojego doświadczenia i miejsca na rynku, aplikuję raczej na pozycje z większym zakresem odpowiedzialności niż szeregowy developer korporacyjny. Na takich stanowiskach racjonalny manager ceni sobie proaktywność, pewność siebie, transparentność i jasność poglądów.

Reakcje negatywne wynikają przede wszystkim z dwóch sytuacji: mocno szablonowego procesu rekrutacji lub świadomości, że ma się coś do ukrycia. Przykłady (oba celowo przekoloryzowane nieinspirowane konkretnymi klientami):

Przykład pierwszy — jeśli jest duża korporacja, ze stosunkowo rozmytą odpowiedzialnością, bardzo sztywnymi procesami, będzie niekiedy trudno znaleźć osobę, która w ogóle na moje pytanie może odpowiedzieć, a co dopiero zmienić proces rekrutacyjny pod konkretnego kandydata. Reakcją w podobnych przypadkach najczęściej jest nie tyle niechęć współpracy ile zakłopotanie i ostateczna rezygnacja z mojej strony (niechętnie pracuję w miejscach o wysokim poziomie „korporacyjności” i biurokracji).

Przykład drugi — mały startup, odpalili się trzy miesiące temu. Rozmawiamy o roli lidera technicznego. Na pytanie, czy kod jest testowany, dowiaduję się, że oczywiście, każdy fragment. Jednak kiedy zaczynam dociekać, pytając o to, jak wygląda proces testowania, zaczyna się lawirowanie, a prośba o pokazanie przykładowych testów automatycznych jest ignorowana. Po zaakceptowaniu oferty okazuje się, że kod testowany faktycznie jest — ale manualnie przez pana testera przed wrzuceniem na produkcję i nie ma chęci zmiany tego stanu rzeczy.

I teraz co ciekawe — problem drugiego przykładu nie polega na tym, że firma źle testuje. Problem polega na niechęci zmiany stanu rzeczy. Gdyby firma wiedziała, że w galopie dostarczania POC zignorowała aspekt testów, ale była gotowa o tym szczerze rozmawiać, mogłaby wyniknąć z tego bardzo ciekawa rozmowa na temat tego, jak ten stan rzeczy można naprawić i jaka moja — jako tech leada — byłaby tutaj rola. Klient dowiedziałby się w ten sposób więcej na temat moich kompetencji i preferencji niż z jakiegokolwiek testu, jaki próbuje na mnie przeprowadzić.

Ostatecznie uważam, że większość negatywnych reakcji wynika z przeświadczenia, że odpowiedzi na trudne pytania są złe lub dobre. Prawda jest jednak taka, że są tylko odpowiedzi prawdziwie lub fałszywe, i dopiero umieszczone w szerszym kontekście kształtują decyzję o dalszej współpracy lub jej zaniechaniu.

Jakie są plusy i minusy stawiania jasnych żądań oraz zadawania mało wygodnych pytań na rekrutacji?

Plusy tego podejścia widzę trzy. Jeden jest oczywisty, więc tylko o nim wspomnę — mamy szanse uzyskać odpowiedzi, a więc podjąć decyzję o współpracy lepiej doinformowani.

Drugim plusem jest natychmiastowe zaprezentowanie istotnych umiejętności miękkich — umiejętność przejęcia inicjatywy, gotowość do podjęcia trudnej dyskusji, pewności siebie i tym podobnych. Z reguły są to umiejętności często pożądane. I ten plus ma drugie dno — czasem klient wręcz podobnych cech nie pożąda, a szuka posłusznego pracownika realizującego jego agendę, którą odgórnie narzuci. Takie pytania szybko rekrutację zakończą, co jest na ogół oszczędnością czasu obu stron.

Ostatnim plusem, o którym należałoby wspomnieć, jest fakt, że z trudnych pytań mogą wyniknąć ciekawe rozmowy — jak w przykładzie, jaki poprzednio podałem.

Wad takiego podejścia zasadniczo nie widzę, natomiast jest to związane z tym jaki jest mój cel uczestniczenia w rekrutacji — nie jest nim znalezienie pracy, a dowiedzeniem się, czy chcę z danym klientem współpracować. Natomiast jest oczywiste, że trudne pytania zmniejszają nasze szanse na ostateczną współpracę — bo klient może być wobec nich nieprzychylny. Jeśli wiec zamierzamy zaakceptować ofertę zupełnie niezależnie od odpowiedzi, a inicjatywę przejmujemy wyłącznie celem „pokazania się”, to być może nie warto.

Wszystko, o czym za mało mówi się w branży IT.

Prosto na Twoją skrzynkę.

Oświadczam, że zapoznałem/am się z Polityką Prywatności oraz akceptuję jej treść.

Leave this field empty if you’re human:

Jakie żądania powinno się wręcz przekazać na rozmowie, a jakich tematów lepiej unikać? Jakich pytań nie warto bać się zadawać (bo mogą mieć duże znaczenie dla przyszłości kandydata)?

Powinno się pytać o wszystko, co jest z naszego punktu widzenia istotne. Natomiast jest to bardzo uzależnione od pozycji, na którą aplikujemy i etapu rozwoju zawodowego, na którym się znajdujemy. Ja na przykład mam bardzo silne i ugruntowane poglądy na temat tego, jak i w jakim zakresie należy testować oprogramowanie i ten temat prawie zawsze pojawi się na rozmowach, w których biorę udział (niezależnie od strony biurka, po której siedzę). Podobnie np. mam silne i niekoniecznie popularne poglądy na temat znaczenia używanej technologii w projektach i znaczeniu biegłości w samym stacku i też chętnie o tym rozmawiam. Zadając takie pytania, jestem w stanie zagwarantować sobie, że trafię do projektu, gdzie cenione są wartości podobne do moich i będzie mi w nim raczej dobrze, a nawet jeśli nie — jestem przynajmniej od początku świadom, na jakie ustępstwa muszę pójść.

Jednak nie mogę powiedzieć, że należy zawsze pytać o to, jakie jest pokrycie testami systemu. Jeśli nie mamy doświadczenia, nie potrafimy na ten temat pociągnąć dyskusji, a reakcja na pytanie będzie na zasadzie “poniżej 60% nie biorę, bo kolega mówił, że tak musi być” to jest to bardzo zły pomysł. Pytania, szczególnie te trudne powinny wynikać z naszego doświadczenia — jeśli wiemy, że konkretne aspekty w projekcie nas wyjątkowo denerwują i chcemy ich uniknąć, konstruujemy pytania, które pozwolą nam te aspekty wykryć.

Na pewno jednak warto pytać o rzeczy związane z warunkami pracy. Za co jesteśmy rozliczani? Jak wygląda raportowanie pracy? Jakie są typowe spotkania w tygodniu, w których będzie trzeba uczestniczyć? Jak wygląda proces onboardingu? Jaka jest rotacja pracownicza? Jak wygląda rozwój finansowy w firmie? Czy mogę porozmawiać z szeregowym mid-developerem w ramach rekrutacji? Szczególnie ta ostatnia prośba może być cenna — firma może się na nią zgodzić, bo wygląda bardzo niewinnie, ale taki mid, który nie bierze na co dzień udziału w rekrutacjach, może przypadkiem dać nam całkiem dobry pogląd na to, co działa lub nie działa w firmie.

Sama rekrutacja bywa stresująca, do tego często jesteśmy zbyt nieśmiali, żeby walczyć o swoje. Jakie masz sposoby na przełamanie tej bariery i znalezienie pewności siebie, aby zacząć stawiać warunki firmom?

Nie mam sposobów. Jestem na rynku ponad dekadę, pracowałem przy kilkunastu projektach w kilku różnych firmach, widziałem projekty odnoszące sukcesy i takie, które nie trafiły na produkcje, a w międzyczasie odbyłem dziesiątki (kto wie, czy nie setki) rozmów rekrutacyjnych zarówno jako kandydat, jak i rekruter. Od kilku lat współorganizuje we Wrocławiu regularny Meetup, brałem udział w organizacji konferencji — to wszystko kształtuje umiejętności miękkie.

Pewność siebie wynika ze znajomości swojej wartości na rynku i zrozumienia, że jeśli nie ten klient to następny. Ważniejsze jest znaleźć projekt, w którym będę chciał zostać długo, a nie projekt, który znajdę szybko.

Natomiast to nie przychodzi samo z siebie. Pierwszy projekt, w którym byłem to miejsce, w którym spędziłem 3 lata, pomimo że byłem tam bardzo nieszczęśliwy i odejść chciałem po pierwszym roku — trzymał mnie jednak strach przed tym, że mógłbym nie utrzymać się w innym projekcie, a tu mam pewną posadę. Prawdopodobnie pracowałbym tam dużo dłużej (a może i do dzisiaj — firma trzyma się dobrze), gdyby mnie moja (jeszcze wtedy przyszła) żona do zmiany pracy niemal nie zmusiła. Najlepszym rozwiązaniem jest więc chyba dobry ożenek/zamążpójście.

---

Bartłomiej Kuras. Maintainer ekosystemu CosmWasm, pomysłodawca i autor Sylvia Framework. Współorganizator Rust Wrocław Meetup, zaangażowany w organizację Rusty Days. Współtwórca CosmWasm Academy, autor The CosmWasm book. W przeszłości programista C++, dzisiaj cały swój wysiłek wkłada w promowanie idiomów Rustowych i samego języka. Żywo zainteresowany poznawaniem nowych technologii twierdzi, żę nowy jezyk zawsze warto poznać choćby po to, żeby zobaczyć inny punkt widzenia.

---

Zdjęcie główne pochodzi z unsplash.com

Katarzyna Kozieł

Redaktor współpracująca

Od trzech lat pracuje jako copywriterka, aktualnie zajmuje się tworzeniem treści dla branży IT oraz militarnej. Miłośniczka robienia szczegółowego researchu.