Czego nie mówić podczas rozmowy kwalifikacyjnej na stanowisko programisty
Bycie programistą ma swoje plusy i minusy. Plusem jest to, że pracy na rynku jest naprawdę sporo, a minusem to, że jest spora konkurencja. Jeśli jakaś firma jest znana z tego, że dba o swoich pracowników, to wielu developerów będzie chciało w niej pracować. Szukanie pracy jako programista nie polega tylko na posiadaniu odpowiednich umiejętności - trzeba też zrobić pierwsze dobre wrażenie na rozmowie kwalifikacyjnej. A to oznacza niemówienie rzeczy, które są aroganckie i zdradzające ignorancję oraz brak szacunku.
Jako engineering manager, hiring manager oraz osoba, która przeprowadziła rozmowy kwalifikacyjne z ponad setką developerów w ciągu dwóch poprzednich lat, chciałabym przedstawić rzeczy, które sprawiają, że jakiś programista staje się mniej atrakcyjny jako potencjalny pracownik - nawet jeśli ich CV wygląda dobrze, a na rozmowie całkiem nieźle poradzili sobie w testach technicznych i koderskich.
Pamiętajcie, żeby tych rzeczy unikać - pozwoli Wam to dobrze wypaść na następnej rozmowie kwalifikacyjnej, niezależnie od tego, czy będzie zdalna, czy na miejscu.
Rzeczy związane z kodowaniem
To strasznie głupi framework/technologia/język. Dlaczego ktoś miałby go jeszcze używać
Wszystko ma swój powód. A technologia rozwija się szybko, więc rzeczy i trendy też się intensywnie zmieniają. Czasem zdarzy się i tak, że w jakiejś firmie jest legacy code - zwłaszcza w dużych organizacjach. Swoją opinię na ten temat można wyrazić w sposób dyplomatyczny, a nie arogancki i zdradzający brak szacunku. Nie patrz też z góry na ludzi, którzy nadal używają starszych technologii.
No, chyba że jesteś w stanie przepisać cały legacy kod i dokonać jego refaktoryzacji w ciągu tygodnia. Wtedy możemy porozmawiać.
Code review to strata czasu. Wszyscy od razu powinni pisać dobry kod
Po pierwsze, code review to coś zdecydowanie dobrego. Jeśli nigdy wcześniej nie miałeś komercyjnego doświadczenia z code review, bo np. jesteś świeżo po studiach, albo nie praktykowano tego w Twoich poprzednich firmach, to jak najbardziej możesz o tym powiedzieć.
Niemniej jednak powinieneś chociaż rozumieć, dlaczego coś takiego w ogóle istnieje. I nie jest to tylko po to, żeby wykrywać gorsze momenty w kodzie.
Code review jest po to, abyśmy wszyscy mogli dzielić się wiedzą i upewniać się, że wszyscy stosują się do ustalonych standardów i wymagań pisania kodu.
Wolę napisać nową funkcję od zera, niż naprawiać błędy innych
O wiele za dużo razy zdarzyło mi się to usłyszeć. Tacy kandydaci to często wykonawcy pracujący na zlecenie, którzy odchodzą w momencie dostarczenia pierwszej produkcyjnej wersji.
Rozumiem, że wielu developerów chce budować rzeczy od nowa, i to do tego przy użyciu najnowszych technologii - nie oznacza to jednak, że są lepsi od innych.
Możesz się wiele nauczyć, naprawiając błędy (niezależnie od tego, czy chodzi o Twoje własne, czy innych) oraz optymalizując i skalując istniejące systemy.
Rzeczy związane z zachowaniem na rozmowie
Testy? QA i testerzy zrobią to za mnie
Kiedy ktoś zapyta Cię, jak podchodzisz do testów, staraj się nie dawać do zrozumienia, że testy to nie Twoja broszka. Jesteś programistą. Rozwijasz funkcje i tworzysz rzeczy. Musisz to wszystko też testować.
Twoje podejście do testów może się znacznie różnić od podejścia innych. Możesz nie korzystać z Test-Driven Development (TDD), możesz nie znać najnowszego narzędzia do testowania na rynku - ale na pewno testowałeś kiedyś swój kod.
Jeśli nie testowałeś, to nie jesteś prawdziwym developerem. Jesteś po prostu kimś, kto klepie kod.
Nie będę kwestionować wyborów mojego tech leada/development managera - wszystko mi jedno
Osoba prowadząca rozmowę kwalifikacyjną może Cię zapytać, w jakiej sytuacji wybrałbyś daną technologię, narzędzie, czy framework, które zostały wspomniane w Twoim CV, a dlaczego zrezygnowałbyś z innych.
Ponieważ powiedziałeś, że ich używałeś, to osoby prowadzące rozmowę będą oczekiwały, że będziesz znać ich zalety i wady. Warto również podzielić się swoją na ich temat opinią.
Jeśli odpowiesz, że wszystko Ci jedno, będzie to prawdopodobnie oznaczało, że albo nie masz opinii, albo Ci na tym nie zależy. Albo, co gorsza, że skłamałeś na CV i tak naprawdę nic o nich nie wiesz.
Nie poświęcam czasu na naukę poza pracą. Po prostu uczę się rzeczy w pracy
Jeśli chodzi o technologię, to zawsze musisz się uczyć i interesować się aktualnymi rzeczami. Kiedy mówisz, że nie masz czasu na naukę, oznacza to, że nie interesujesz się tym, co robisz.
Sugerujesz wtedy osobie prowadzącej rozmowę, że bycie developerem to jedynie sposób na zarobienie pieniędzy, a nie Twoja prawdziwa kariera.
Nigdy nie będę używał (danego oprogramowania/technologii itd.)
Kiedy osoba prowadząca rozmowę zapyta Cię o jakąś technologię, aplikację, software, czy wzorzec projektowy, to oznacza to zazwyczaj, że jest to ważne dla stanowiska, na które aplikujesz.
Powiedzmy, że pracujesz na frontendzie, a osoba prowadząca rozmowę prosi Cię o opinię na temat Internet Explorera. Wydaje mi się, że może się domyślać, iż większość developerów nie przepada za IE, ale chce znać Twoją opinię na temat jej używania, budowania, oraz niektórych udziwnień i tak dalej.
Dlaczego? Może to być akurat przeglądarka, która jest wspierana przez Twoją firmę. Co więcej, mogą z niej też korzystać jej klienci. Jeśli powiesz, że nigdy, przenigdy jej nie użyjesz, to będzie to oznaczało, że nie będziesz pasować do tej roli.
Rzeczy związane z szerszą perspektywą
Nigdy nie korzystałem z Waszych produktów
Jest to niezwykle istotna sprawa, zwłaszcza jeśli chcesz rozwijać jakąś technologię, lub pracować dla firmy, która tworzy konkretne produkty. Kiedy idziesz na rozmowę do takiej firmy, osoby, które będą ją z Wami przeprowadzały pewnie będą Cię pytać o Twoją opinię na temat ich produktów - może to być feedback, lub podzielenie się doświadczeniem z używania.
To, że nigdy nie używałeś ich produktów, może Ci nie ujść na sucho.
Na pewno rozczarujesz osobę prowadzącą rozmowę, jeśli powiesz, że nigdy nie korzystałeś z platformy, którą rozwijają (niech to np. będzie LinkedIn). Nawet jeśli nie używałeś ich produktu regularnie, to zrobienie researchu na pewno nie zaszkodzi. Spróbuj go poużywać, poczytaj o nim, postaraj się go zrozumieć, spróbuj zobaczyć, z jakich technologii korzysta itd.
To jest w moim CV. Widzieliście, prawda?
Tak, osoba prowadząca rozmowa widziała Twoje CV. Co więcej, to mogło być idealne CV, co było powodem zaproszenia Cię na rozmowę.
Osoby rekrutujące przeczytały wzmiankę o Twoim doświadczeniu z jakąś technologią lub projektem i chcą dowiedzieć się więcej. Być może chcą usłyszeć o tym coś więcej i to bezpośrednio od Ciebie. Może być też tak, że pominęli to, czytając Twoje CV za pierwszym razem i zauważyli to dopiero na rozmowie.
Niezależnie od sytuacji, Twoim zadaniem jest udzielenie odpowiedzi spójnej z tym, co widać w Twoim CV. Nie mów osobie prowadzącej rozmowę, żeby sobie przeczytała Twoje CV. A mówiąc “spójna odpowiedź” nie mam na myśli mówienia słowo w słowo to, co jest tam napisane.
Co mam na myśli to to, że jeśli napisało się na CV, że używałeś Spring MVC w swojej poprzedniej pracy, i dostaniesz pytanie o zdradzenie szczegółów, to nie możesz powiedzieć “Właściwie to tego nie używałem”.
Nie mam żadnych pytań. Jaki jest następny etap rekrutacji?
Jest to jedna z tych rzeczy, które stawiają Cię w złym świetle na koniec rozmowy - i to niezależnie od tego, jak ta rozmowa poszła. Osoby prowadzące rozmowę zazwyczaj kończą ją następującym pytaniem: “Czy masz jakieś pytania dotyczące stanowiska, firmy, lub czegokolwiek innego”.
Rozmowa rekrutacyjna to ruch dwukierunkowy - musisz wiedzieć o firmie tyle, ile od Ciebie wymagają. Kiedy nie masz żadnych pytań na koniec rozmowy (albo, co gorsza, nie możesz się doczekać wyjścia) będzie to oznaczać, że straciłeś zainteresowanie stanowiskiem lub firmą.
Tak, pewnie, że możesz sobie po prostu pójść, a zwiększysz szanse na to, że Cię już nigdy do siebie nie zaproszą.
Podsumowanie
Mam nadzieję, że powyższy artykuł pomoże Wam wypaść lepiej na następnej rozmowie rekrutacyjnej na stanowisko programistyczne.
Pamiętaj, że to, co mówisz, ma znaczenie, a Twoje milczenie też wiele mówi.
Oryginał tekstu w języku angielskim możesz przeczytać tutaj.