Blog

Junior, Rozmowa, Tips&Tricks

Przygotowanie do rozmowy kwalifikacyjnej – pułapki

06 Paź 2018

Kolejny artykuł z cyklu co robić, jak żyć, jak przygotować się do rozmowy kwalifikacyjnej.

Wprawdzie już w innym wpisie opisałem przygotowanie do rozmowy kwalifikacyjnej, jednakże dziś chciałbym skupić się na tym, jakie są najczęstsze błędy popełniane podczas rozmowy kwalifikacyjnej. Temat zdaje się być totalnie błahy, jednak coraz to nowsze anegdoty co to kandydat wyczyniał na rozmowie nie biorą się znikąd. I co gorsze, pojawia się ich coraz więcej.

Lekcesobieważenie rozmówców

Jesteś osobą techniczną. Masz w planach pisać ogromne aplikacje, tworzyć perfekcyjnie skalowalną architekturę. Wyciskać z C++ ostatnie soki. Niczym Yoda Darth Vader (ciemna strona była zawsze bardziej interesująca…) rozwiązywać problemy przepełnienia stosu. Jasne, wszystko rozumiem – sam ciągle mam takie plany na przyszłość. Ale im prędzej zrozumiesz podstawową prawdę życiową IT, że poza kompilatorem istnieją jeszcze inne istoty zaangażowane w Twoją pracę, tym lepiej dla Ciebie.

Nader często będziesz mieć do czynienia z osobami nietechnicznymi (bądź osobami technicznymi, ale z innych obszarów specjalizacji), którym musisz wytłumaczyć ten, bądź inny fenomen w prostych słowach, niekoniecznie posługując się slangiem IT. Często będą to osoby odpowiedzialne stricte HRowo za proces rekrutacji, który – uwierzcie – nie należy do najłatwiejszych zadań (z tego miejsca bardzo serdecznie pozdrawiamy Dziewczyny z The Hidden Heroes).

Bardzo częstym problemem z jakim mierzyliśmy się całą załogą DorwijNerda, było obcesowe traktowanie osób nietechnicznych. Uznawanie, że ot taki tam misiu Yogi niczego nie ogarnia. Że gdzie mi tam jakaś babka z rekrutacji będzie duby smalone bredzić o tym, jak rozwiązuję problemy w zespole. Przeca jestę programistom, gdzie mnie z tymi rencoma! [pisownia oczywiście zamierzona] – hm, jak to ująć: jesteś na straconej pozycji. Nawet bardzo dobrze rokujący technicznie kandydaci odpadali właśnie przez niestosowne zachowanie.

Reasumując – nawet jeżeli masz interfejs z gatunku ciężkich, postaraj się z całych sił to w sobie zdusić. Bądź kulturalny i traktuj wszystkich z należnym im poszanowaniem – wszak my, osoby ze świata IT, nie jesteśmy Prometeuszami XXI wieku. A szkoda… Chociaż jakby się zastanowić głębiej, to przynajmniej nie będziemy wystawieni na pastwę niezbyt przyjaźnie nastawionych ptaków.

Niepochlebna opinia o poprzednim pracodawcy

… eufemistycznie ujmując.

To będzie krótki akapit, bo można go podsumować krótkim zdaniem. Ale ono będzie za moment. Stawianie poprzedniego pracodawcy w złym świetle to niestety dość często spotykana cecha, mająca najczęściej postać wywlekania wewnętrznych spraw na światło dziennie. Nie chodzi tu o stwierdzenie faktów, że zmieniam pracę po to, aby działać z nowszymi standardami języka, albo że potrzebuję nowych wyzwań technicznych – chodzi raczej o mówienie wprost, że poprzednia/inna firma jest kiepska. Jak jest źle zarządzana. Jak podejmowane decyzje były głupie i bezsensowne. Nawet jeśli miałaś/miałeś nieszczęście trafić na firmę z takimi przywarami – to nic z powyższych nie powinno paść podczas oficjalnej rozmowie. Skąd Twój potencjalny przyszły pracodawca ma mieć pewność, że kiedyś nie powiesz tego samego o nim? I tu właśnie padnie obiecane krótkie zdanie: nigdy nie upubliczniaj brudów z poprzedniego miejsca pracy/innej firmy na rozmowie kwalifikacyjnej. To świadczy źle, tylko i wyłącznie, o Tobie.

Opowiadanie bajek

Ach, temat rzeka. Ileż to razy kandydaci, nie zgłębiwszy odpowiednio danego zagadnienia, określali siebie mianem eksperta z danej dziedziny. A potem przychodzi rekruter i udowadnia im, że są w błędzie. Pół biedy, jeśli wobec logicznych argumentów kandydat zrozumie swoją pomyłkę (bądź rekruter – to wcale nie jest taka rzadka sytuacja) i się wycofa ze swojej niewiedzy. Jednakże, gdy wykonanie poniższego kawałku kodu (zakładamy brak optymalizacji kompilatora, undefined/unspecified/implementation-defined behaviour etc.)

int a = 2;
int b = 2;
int c = a + b;

zdaniem kandydata jest zależne od kompilatora, no to… Tak naprawdę, w takim momencie rozmowę można przerwać, wzajemnie podziękować za poświęcony czas i się pożegnać. W sytuacji, gdy rekruter stwierdza, że nie masz racji, a sam nie jesteś pewien w 100% swojej wiedzy, to wtedy zastanów się dwa razy zanim wdasz się w dalszą dysputę.

Może lekko rozwinę moją myśl: w przypadku, gdy jesteś całkowicie pewien tego co wiesz, nie przejmuj się tym, że rekruter ma inną opinię. Możliwe, że to druga strona się pomyliła. Jednakże, gdy wiesz, że masz luki w swojej wiedzy, to po prostu lepiej się do tego przyznaj. A na pewno nie idź w kierunku swoich błędnych tez. Ludzką rzeczą jest błądzić i nie ma nic złego w tym, że się przyznasz do niewiedzy. Natomiast trwanie w dziwnych i często nielogicznych założeniach z reguły stanowi czerwony alarm dla rekrutera. Natomiast dla Ciebie – drogi czytelniku – dość poważną przeszkodę w otrzymaniu oferty od potencjalnego pracodawcy.

Zdradzanie tajemnic

Zanim powiecie, że piszemy poradnik dla agentów w służbie jej królewskiej mości zastanówcie się w jaki sposób opowiadacie o poprzednich projektach realizowanych dla różnorakich klientów. Zastanówcie się, czy projekt ów ujrzał już światło dzienne. Pomyślcie przez chwilę, czy nie obejmuje Was (jeszcze) jakaś konkretna NDA. Problem, który nader często obserwowaliśmy był bardzo prozaiczny – opowiadanie o przeszłych projektach z podaniem konkretnych nazw klientów, dla których owi kandydaci pracowali. O ile nie działacie w projektach, o których można otwarcie opowiadać (w razie wątpliwości zapytajcie przełożonego), to generalna reguła jest taka, że lepiej wstrzymać się z pochwaleniem „projekt, jaki realizuję będzie dostarczony dla XXX”. Dochodzi tutaj kwestia całej drabinki (pod)wykonawców, gdzie reguły nie są już aż tak restrykcyjne, jednakże pracując np. w super tajnym projekcie dostarczanym dla znanej oraz poważanej firmy DorwijNerda podczas rozmowy lepiej pochwalić się wykorzystywanymi technologiami oraz tym, co się faktycznie wykonywało. A klienta nazywać po prostu klientem.

Cała reszta

Bardzo opisowe, bardzo pomocne. Wow.

No cóż, nie chciałem pisać o gadaniu głupot już na poziomie nagłówka, dlatego też nie obędzie się bez przeczytania kilku następnych zdań. Wybaczcie. Problem, jaki niestety często zauważaliśmy jest bardzo prosty – kandydaci nie zdają sobie sprawy, z tego, że jednym zdaniem można się skutecznie kopnąć w głowę. Albo postrzelić się trzydzieści razy w plecy. No bo jak inaczej ując rzucanie mięchem przy tablicy, chwalenie się że policja w Niemczech mnie poszukuje, dlatego też wyjazdy służbowe mogą być trochę utrudnione czy też mówienie wprost, że postawione zadanie jest głupie, a jego rozwiązanie to strata czasu. Ok, jeśli jesteś pewien, że konkretni rekruterzy podchodzą do rozmowy bardzo nieformalnie – to oczywiste jest, że rzucenie dowcipem, odejście od sztywnych zasad jest jak najbardziej w porządku (sami forsujemy oraz cenimy bardzo nieformalne rozmowy). Natomiast jeśli wypalasz jednym z powyższych tekstów, bądź czymś o jeszcze cięższym kalibrze, to nie dziw się, że odpowiedź po procesie rekrutacyjnym może być negatywna. Albo możesz jej nie otrzymać.

Reasumując – błędy podczas rozmowy kwalifikacyjnej mogą zdarzyć się każdemu. Jednakże odpowiednie przygotowanie powinno znacząco zniwelować ryzyko ich wystąpienia. Skupienie się nad tym, czego nie mówić jest równie ważne jak to co powinniśmy podkreślać. Bo o ile będąc pewnym siebie, znając odpowiedzi na pytania stawiane przez rekruterów zaskarbiamy sobie sympatię osób, które nas przepytują tak niestety wykonując jednego sprawnego kopa we własną głowę, możemy pogrzebać szanse na udaną rekrutację. A jestem pewien, że nie jest to Waszym celem.

Stanisław Kubiak

Software Engineer, który zdążył już złapać kilka siwych włosów od debugowania. Psuje kod zawodowo, potem zawodowo musi go naprawiać – najczęściej pracuje z C++. Zajmował się projektami z głębokiego backendu, jak i tymi tkwiącymi stricte we frontendzie. Rekrutacją zajmuje się od kilku lat.

@Stanisław Kubiak
Referencja kontra Wskaźnik

__init__(self) a klasa bazowa

Rozmowa kwalifikacyjna – porady

Angielski (4)
C++ (7)
Junior (12)
Python (3)
Regular (6)
ReverseEngineering (1)
Rozmowa (7)
Różne (6)
Senior (1)
Tips&Tricks (10)
angielski c++ junior python regular rozmowa rozmowa kwalifikacyjna