#16 Jak Zostać Programistą: Jak wygląda rozmowa kwalifikacyjna?

You are currently viewing #16 Jak Zostać Programistą: Jak wygląda rozmowa kwalifikacyjna?

Kiedy nareszcie udało Ci się zakwalifikować na rozmowę rekrutacyjną

Po wysłaniu CV do kilkunastu firm nadchodzi w końcu ten moment, gdy jakaś firma odpowie i zaprosi Cię na rozmowę kwalifikacyjną. Jest to wtedy pierwszy mały sukces starając się o swoją pierwsza pracę jako programista. Tylko nadal trzeba pamiętać, że jeszcze to nie jest gwarancja zatrudnienia. Na razie jest to pierwszy krok do osiągnięcia sukcesu i to dopiero następne etapy będą tymi kluczowymi. Dlatego idąc na rozmowę rekrutacyjną trzeba się jak najlepiej do niej przygotować i dać z siebie 100%!

W tym celu właśnie powstał ten wpis. Chce Ci w nim pokazać jak wygląda przebieg takiej rozmowy rekrutacyjnej. Co robić, żeby jak najlepiej wypaść oraz pokażę Ci na co najlepiej zwrócić uwagę przygotowując się do takiej rozmowy.

Przebieg rozmowy kwalifikacyjnej

W tym punkcie przedstawię Ci najważniejsze etapy rozmowy kwalifikacyjnej. Podzieliłem je na takie główne sekcje jakie mogą wystąpić. Oczywiście nie wszystkie z nich mogą się pojawić, ale jak będziesz przygotowywał się, to warto być gotowym na każdą z nich. Dodatkowo też nie sugeruj się kolejnością, bo każda firma może mieć ułożony przebieg rozmowy trochę inaczej. Nie ma na to jakieś konkretnej zasady czy reguły.

Przedstawienie firmy

Na początku rozmowy, po krótkim przywitaniu, firma opowie dlaczego Cię zaprosiła na rozmowę. Wspomną o twoim CV, umiejętnościach oraz o stanowisku, na które aplikujesz. Następnie opowiedzą krótko o swojej firmie, czym się zajmują, ich największe osiągnięcia oraz podadzą więcej informacji na temat zespołu do jakiego miałbyś/miałabyś trafić.

Opowiedzenie o sobie

Kolejnym krokiem może być poproszenie przez firmę, żebyś teraz Ty się po krótko przedstawił. Wystarczy opowiedzieć jakieś podstawowe informację np. studia, szkoła, poprzednia praca (jeśli jest warta uwagi), technologię w jakich chce się rozwijać.

Rozmowa o aspektach miękkich, HR

Rozmowa o aspektach miękkich ma na celu ocenę czy nadajesz się do zespołu, do którego zostaniesz przydzielony. Chcą w ten sposób sprawdzić czy będziesz wstanie dogadać się z zespołem. Oczywiście działa to w dwie strony. Zarówno czy oni będą wstanie mieć z Tobą wspólny język, ale też czy ty będziesz miał z nimi. Ciężko potem się pracuje zespołowo z ludźmi, z którymi nie będziesz wstanie złapać jakiegokolwiek kontaktu.

Poniżej spisałem kilka przykładowych pytań:

  • Dlaczego chcesz akurat do nas aplikować?
  • Dlaczego chcesz zmienić pracę?
  • Co najbardziej fascynuje Cię w pracy jako programista?
  • Jakie są dla Ciebie kluczowe umiejętności podczas pracy?
  • Czy uważasz, że umiesz pracować zespołowo? Podaj przykład.
  • Wolisz pracować w grupie czy osobno?
  • Jak napotkasz problem w pracy to w jaki sposób będziesz szukał rozwiązania?
  • Jak się uczysz? Skąd czerpiesz wiedze?
  • Jakich narzędzi i technik używasz do organizacji swojej pracy?

Rozmowa techniczna

Jest to najważniejsza i najdłuższa część rozmowy. Na tym etapie są sprawdzane umiejętności techniczne. Zadawane są pytania z języków programowania oraz technologii podanych w CV. Można też spodziewać się pytań sprawdzających konkretne umiejętności wymagane do pracy na ubiegane stanowisko.

Sama wiedza praktyczna może być często niewystarczająca do tej części rozmowy i trzeba też się mocno przygotować z wiedzy teoretycznej. To czego warto się nauczyć jest zależne mocno od stanowiska na jakie rekrutujesz. Jednak najważniejsza będzie wiedza z Twojego głównego języka programowania i to na nim poświęciłbym najwięcej czasu na naukę.

Kodowanie na żywo

Może się zdarzyć, że oprócz pytań z samej teorii, dostaniesz zadania praktyczne do rozwiązania. Rekruter daję Ci polecenie do zrobienia, laptopa (lub zdarza się, że zamiast laptopa dostaje się kartkę) i patrzy jak je rozwiązujesz. Poza samym wykonaniem zadania, rekruter sprawdza też tutaj jak podchodzisz do problemu oraz jak postępujesz w sytuacji (jak sobie z nimi radzisz), gdy nie umiesz wykonać jakieś części zadania.

Rozmowa po angielsku (lub w innych językach obcych)

Dość często na rozmowie rekrutacyjnej występuje rozmowa po angielsku, a wręcz na pewno trzeba się jej spodziewać jak firma ma klientów zagranicznych i na co dzień trzeba używać tego języka. Firma w ten sposób chce sprawdzić czy sobie poradzisz w sytuacji, gdzie będziesz musiał z kimś porozmawiać w tym języku. Na rozmowach, w których ja brałem udział nigdy nie była to jakaś skomplikowana rozmowa. Często dotyczyła mojego hobby, pracy lub opowiedzenia czegoś o sobie.

Jeśli dawno nie rozmawiałeś po angielsku to warto chociaż cokolwiek sobie przypomnieć (chociaż najprostsze zwroty i słówka). Dzięki temu zawsze można trochę lepiej wypaść podczas rozmowy. Ale wiadomo jak to w życiu bywa z językami obcymi, umiesz albo nie :). Niestety w parę dni przed rozmową nie da się tego nauczyć. Zawsze polecam dokształcać się w tym języku w miarę możliwości jak najczęściej, niezależnie od tego czy masz akurat rozmowę o pracę.

Pytania od kandydata

W pierwszej części rozmowy firma zadaje Tobie pytania, ale też jest druga część, gdzie ty możesz im zadać jakieś. Mogli czegoś nie dopowiedzieć, a jest coś co Ciebie jeszcze interesuje, to warto pytać. Z miłą chęcią powinni odpowiedzieć na wszystkie nurtujące Cię kwestie.

Natomiast może być sytuacja, w której wszystko już wiesz i nie potrzebujesz o nic dopytywać firmy, to mimo tego myślę, że warto tutaj zadać chociaż to jedno pytanie. W ten sposób można pokazać, że nie przyszło się tutaj przez przypadek i faktycznie interesuję Ciebie to stanowisko i firma. Oczywiście jeśli naprawdę nie masz żadnego pytania to nie ma co na siłę jakiegoś wymyślać 🙂

Zakończenie

Po przejściu przez wszystkie etapy, rekruterzy informują Cię o tym, że to wszystko co mieli przygotowane na rozmowę, dziękują Ci za Twój poświęcony czas i mówią kiedy można spodziewać się odpowiedzi od nich oraz w jakiej formie (telefon czy e-mail).

Czasem na koniec rozmowy jeszcze mogą Cię spytać w ilu procesach rekrutacyjnych bierzesz udział lub czy jeśli dostaniesz odpowiedzieć dopiero za tydzień to czy będzie dla Ciebie w porządku. Rekruterzy chcą w ten sposób podpytać ile mniej więcej mają czasu, żeby dać Ci odpowiedź. Potrzebują tego w sytuacji, gdy aplikujesz jeszcze do innych firm. W przypadku, gdy będą chcieli Ci zaoferować pracę to chcą uniknąć sytuacji, w której zdążysz wybrać ofertę pracy konkurencji. Oczywiście działa to też w drugą stronę. Gdybyś chciał iść do nich, ale konkurencyjna firma szybciej wysłała Ci ofertę pracy i przyjąłeś ją. Tylko dlatego, żeby nie ryzykować i mieć już gwarancję pracy. Dlatego uważam, że warto na to pytanie odpowiedzieć w miarę szczerze. Nie musisz dokładnie odpowiadać w ilu procesach rekrutacyjnych bierzesz udział. Wystarczy dać do informacji, że prowadzisz rozmowy z innymi firmami i zależy Ci na w miarę szybkiej odpowiedzi. W przypadku, gdy firma będzie miała jasno powiedziane, że aplikujesz również do innych firma to może dać Ci szybciej odpowiedzieć.

Innym częstym pytaniem na koniec rozmowy jest pytanie o oczekiwania finansowe. Ciężko mi doradzić w jakikolwiek sposób jak można na to pytanie odpowiedzieć. Myślę, że każdy powinien do tego podejść indywidualnie i wycenić swoje umiejętności. Warto spojrzeć ile mniej więcej powinno się zarabiać na aplikowanym przez Ciebie stanowisku. Niestety w ogłoszeniu nie zawsze podane są widełki płacowe. Pamiętaj, żeby przed rozmową przemyśleć sobie to pytanie, żeby już podczas rozmowy móc na nie w łatwy sposób odpowiedzieć.

Co warto powtórzyć do rozmowy technicznej?

Największy stres przed rozmową kwalifikacyjną jest prawdopodobnie dla Ciebie część techniczna. Zastanawiasz się o co mogą Cię zapytać albo co najlepiej powtórzyć. Według mojego doświadczenia najlepiej zacząć od tego co było w ogłoszeniu i na podstawie technologii tam wymienionych powtórzyć sobie materiał. Jeśli są jakieś technologię w ogłoszeniu, których nie znasz to nie ma sensu chwilę przed rozmową ich się uczyć. Po prostu może na to nie starczyć czasu i można sobie tylko bardziej namieszać w głowie. Ewentualnie da się podejść tak, że jeśli dana nazwa nic Ci nie mówi, to można tylko orientacyjnie dowiedzieć co się pod nią kryje. Można przeczytać jakiś ogólny opis i zobaczyć do czego jest wykorzystywana dane technologia (nie zagłębiając się w szczegóły). Zawsze w ten sposób można pokazać podczas rozmowy, że mimo nieznania danej technologii w praktyce, orientować się chociaż w teorii czym jest.

Według mnie najlepiej przed rozmową skupić się na powtórzeniu sobie materiału z głównego swojego języka programowania. Do tego wziąłbym jeden lub dwa najważniejszych dla niego Frameworki oraz ewentualnie jakąś bazę danych. Jako przykład, dla ubiegania się na stanowisko Junior Java Developera skupiłbym się na powtórce z Javy, Springa, Hibernate i SQL.

Rekturerzy najbardziej skupiają się na tym czy rozumiesz dany język programowania i specyficzne dla niego Frameworki oraz czy znasz je bardziej szczegółowo, nie tylko w praktyce, ale też w teorii. Pozostałe umiejętności i technologię liczą się trochę mniej (oczywiście mowa tutaj o stanowiskach juniorskich), ale nadal warto je umieć. W końcu mogą się zawsze przydać w pracy. Natomiast osoby rekrutujące nie poświęcają tym technologią tak dużo czasu jak językowi programowania czy Frameworką, więc raczej nie powinieneś dla nich dostać szczegółowych pytań (ale to nie znaczy, że jakieś się nie może trafić 🙂 ).

Jak ubrać się na rozmową kwalifikacyjną?

Nie trzeba na rozmowę rekrutacyjną jakoś specjalnie się stroić. Według mnie koszula powinna w zupełności wystarczyć. Byleby nie przychodzić na rozmowę w dresach. Chyba, że rozmowa jest zdalna to może być wyjątek :). Oczywiście nie można też w drugą stronę przesadzać, żeby nie przyjść zbyt elegancko 🙂

Na co warto być jeszcze gotowym?

Rozmowa rekrutacyjna jest czymś czego nie da się uniknąć starając się o pracę. Natomiast część firm oprócz samej rozmowy kwalifikacyjnej czasem robi dodatkowe etapy rekrutacji, tak żeby odsiać część kandydatów na starcie i zaprosić na rozmowę tylko wybranych, którzy sobie poradzili z dodatkowym zadaniem.

Najczęściej spotykałem się z dwoma typami wstępnych rekrutacji. Pierwszą z nich było napisanie samodzielnie aplikacji na podstawie treści zadania. A drugą zrobienie Code Review na podstawie aplikacji wysłanej przez firmę. Sprawdzenie zmian w kodzie, wykrycie potencjalnych błędów, złych praktyk programowania oraz zaproponowanie ulepszeń.

Napisanie samodzielnie aplikacji

Napisanie aplikacji samodzielnie w domu może wydawać się prostym zadaniem, natomiast nie do końca takie jest. Co prawda dostajesz od firmy zadanie z listą rzeczy jakie powinny się znaleźć w aplikacji oraz jak powinna działać, ale jest to tylko jedna z części jaką firma będzie sprawdzać. Może być tak, że mimo zrobienia całej aplikacji zgodnie z tym co było w zadaniu, będzie to wystarczające, żeby przejść ten etap rekrutacji.

No dobra, ale co takiego jeszcze firma sprawdza? Poniżej spisałem kluczowe elementy na które warto zwrócić uwagę, poza wykonaniem tego co było napisane w treści zadania.

  • Zadbać o wysoką jakość kodu – stosować dobre praktyki programowania (np. SOLID), wykorzystać wzorce projektowe itp.
  • Pomyśleć nad architekturą aplikacji – oczywiście ważne jest aby zadanie działało, ale warto też w tym zadbać o architekturę aplikacji. Podczas pisania trzeba na to spojrzeć nie jak na zadanie, ale bardziej na coś co chciałoby się w przyszłości rozwijać.
  • Napisać jakieś podstawowe testy jednostkowe i integracyjne nawet jeśli nie były wymagane w zadaniu!
  • Jeśli w zadaniu wystawiasz usługi np. RESTowe to warto zadbać o ich dobrą dokumentację z użyciem Swaggera (w tym artykule wyjaśniałem czym jest Swagger) lub Postmana (w tym artykule wyjaśniałem czym jest Postman).
  • Sposób przekazania wykonanego zadania – najlepiej zrobić to za pomocą repozytorium na jednej z trzech najpopularniejszych platform: GitHub, Bitbucket lub Gitlab. Niektórzy wysyłają archiwum ZIP na e-maila, ale to nie jest zbyt profesjonalne podejście (chyba, że firma sobie tak zażyczyła).
  • Jeśli już wysyłasz linka do repozytorium to warto zadbać o najważniejsze rzeczy w nim. Pierwszym istotnym elementem jest dobrze opisany plik README (w tym artykule opisywałem jak je dobrze napisać). Natomiast drugim ważnym elementem jest odpowiedni opis Commitów (warto zadbać, żeby były dobrze opisane, a nie w jakiś dziwny sposób).
  • (opcjonalne) Jeśli znasz Dockera (co to jest Docker?) to można pokusić się o dodanie pliku DockerFile do swojej aplikacji (ewentualnie plik docker-compose.yml jeśli Twoja aplikacji ma więcej serwisów np. Frontend, Backend i bazę danych) mimo, że nie było takiego wymagania. Zawsze można w ten sposób zwiększyć swoje szansę.

Code review

Wygląda to tak, że dostajesz od firmy linka do ich repozytorium dla którego musisz zrobić sobie ’forka’ (fork – jest to zrobienie kopi repozytorium, żeby móc sobie pracować na nim niezależnie u siebie na gicie). Następnie musisz zrobić ’code review’ na podstawie instrukcji jaką dostaniesz. Powinni wysłać Ci ją na e-maila albo będzie w pliku README w otrzymanym repozytorium. Prawdopodobnie dostaniesz w instrukcji informacje jakiego ’brancha’ masz sprawdzić, w jaki sposób (np. stworzyć ’Pull Request’ i tam dopiero opisywać komentarze) i na co w szczególności zwrócić uwagę podczas sprawdzania.

Pamiętaj, żeby podczas takiego sprawdzania kodu skupić się na kilku istotnych elementach:

  • Ogólne błędy w kodzie – czyli coś zostało źle zrobione np. dany fragment kodu jest zły i może powodować błędy.
  • Brak 'czystego kodu’ w aplikacji. Warto spojrzeć czy ktoś nie zrobił jakiś podstawowych błędów np. w nazewnictwie metod, pól lub klas, złe sformatował kod itp. Po prostu trzeba sprawdzić czy kod aplikacji jest czytelny czy jednak wymagana jest jakaś poprawa czytelności w nim.
  • Czy da się coś lepiej w kodzie zrobić . Warto sprawdzić czy zaprezentowany kod jest dobry, czy dałoby się to lepiej zrobić np. wykorzystać jakiś wzorzec projektowy lub skorzystać z innego podejścia.
  • W przypadku bardziej ogólnych uwag np. architektury czy ogólnie wykonanego zadania, warto to opisać szczegółowo w osobnym komentarzu. Będzie to lepiej wyglądać i będzie tak bardziej czytelne niż odnoszenie się do konkretnego miejsca w kodzie.
  • Jeśli jakiś fragment kodu został napisany bardzo dobrze to warto pochwalić w komentarzu. Można w ten sposób, przy okazji, pokazać, że wie się coś więcej w danym temacie. Tylko mowa tu o naprawdę dobrych niekonwencjonalnych rzeczach, a nie o jakiś drobnych czy podstawowych. Warto to robić tylko w sytuacji jeśli jest się tego pewnym, bo może mieć odwrotny skutek do zamierzonego 🙂

Po zakończeniu robienia zadania informujesz o tym firmę. Z reguły jest tak, że udostępniasz im repozytorium, żeby mogli sobie sprawdzić jak Ci poszło (w skopiowanym repozytorium, w ustawieniach dajesz im dostęp na podstawie e-maila – powinni napisać na jaki e-mail udostępnić to).

Podsumowanie

Mam nadzieje, że przybliżyłem Ci chociaż trochę jak wygląda rozmowa kwalifikacyjna na programistę i czego można oczekiwać. Może dzięki temu będzie Ci choć trochę łatwiej się przygotować do takiej rozmowy i pozwoli zwiększyć szanse na zdobycie pracy.

Subscribe
Powiadom o
guest
0 komentarzy
Inline Feedbacks
View all comments