8 pytań, które Ty powinieneś zadać rekruterowi

Dlaczego warto zadać właściwe pytania ?

Powodów jest wiele. Paradoksalnie dobrze zadane pytanie może nawet zaważyć na tym czy zostaniesz zatrudniony. Pamiętajmy, że rozmowa kwalifikacyjna często jest jedynym momentem kiedy twój potencjalny przyszły pracodawca ma możliwość poznania Cię jako osoby, a nie tylko punktów z CV. Czasy gdy programista utożsamiany był z mrukiem siedzącym w piwnicy dawno już minęły. Międzynarodowe projekty wymuszają dużą ilość interakcji korzystając z jeszcze większej ilości kanałów komunikacji. Pracodawcy zależy zatem na zatrudnieniu osoby komunikatywnej i otwartej. Zatem jeśli zadasz rekruterowi odpowiednie pytania zostaniesz potraktowany jako pracownik umiejący pozyskać potrzebne mu informacje oraz wykażesz zainteresowanie projektem. Wszyscy potrzebują ludzi zmotywowanych do pracy.

Aspekt psychologiczny.

Innym aspektem jest to, że zdając pytania przejmujesz kontrolę nad rozmową. Możesz zatem skierować ją na tematy wygodne dla ciebie, gdzie będzie łatwiej podkreślić swoje kompetencje. Przykładowo jeśli czujesz się mocny z testów jednostkowych możesz zapytać jakiego frameworka oni używają w projekcie. Wiem, że wydaje się to tak racjonalne, że nawet nie warto o tym wspominać, ale w ogniu pytań rekrutacyjnych można o tym zapomnieć. Pamiętajmy również, że rozmowa kwalifikacyjna powinna służyć obu stronom. Pracodawca sprawdza, czy chce cię zatrudnić, ale i ty masz za zadanie zdecydować, czy rzeczywiście pasujesz do tej firmy i tego stanowiska.

Oto lista pytań, które ja zawsze zadaje na takich rozmowach w raz z korzyściami jakie z nimi idą.

1. Czy pracujecie w scrumie

Scrum i inne zwinne metodyki oprogramowania stały się już standardem w branży IT. Czy jest on poprawnie implementowany w danej firmie to już inna sprawa. Zainteresowaniem procesem wytwarzania oprogramowania na pewno będzie działało na nasza korzyść. Warto dopytać jak wyglądają standupy, w jaki sposób szacują taski oraz jakiego narzędzia używają do zarządzania zadaniami. Pamiętajmy jednak, że dobrze działający waterfall jest dużo lepszy niż źle zaimplementowany agile. Najgorsze co może nas spotkać.

Korzyści:

• Pokazujemy, że mamy już jakieś doświadczanie w pracy przy użyciu zwinnych metodyk oprogramowania
• Pokazujemy, że interesujemy się nie tylko technicznym aspektem projektu
• Mamy miły temat do rozmowy by oderwać się od pytań o aspekty techniczne
• Dowiemy się na jakim poziomie jest bałagan w projekcie

2. Czy używacie Jenkinsa

Oczywiście Jenkins jest tu tylko przykładem. Naszym celem jest sprawdzenie, czy w danym projekcie istnieje jakiś automatyczny system budujący. Jeśli czegoś takiego nie ma i nie jest to dopiero startujące przedsięwzięcie radził bym się zastanowić czy warto wchodzić do takiego projektu. Chyba ,że wdrożenie takiego rozwiązania jest w planach, a ty masz ambicje się tym zająć. W takim wypadku śmiało do boju. Radził bym jednak unikać projektów w których panuje podejście: „Testy nie potrzebne bo przecież piszemy od razu dobrze”.

Korzyści:

• Wykazujemy, że dbamy o jakość produktu
• Pokazujemy, że znamy dobre praktyki tworzenia oprogramowania
• Badamy stan projektu jeśli już trwa
• Analizując sposób budowania aplikacji można sprawdzić, czy nasze kompetencje są potrzebne w tym projekcie

3. Czy są testy jednostkowe? Jaki framework do testów jest w użyciu

Zwykle tak zwane quality w aplikacji zaczyna wprowadzać się od testów jednostkowych. Najpierw testy jednostkowe potem automatyczne budowanie oraz testy funkcjonalne i systemowe. Oczywiście nie zawsze to tak wygląda jednak nie zmienia to faktu, że testy jednostkowe być muszą. Jeśli ich nie ma i nie jest to dopiero powstający produkt jest to informacja, że coś tu nie do końca jest zgodne ze sztuką. Oczywiście może być tak, że z premedytacją zgłaszasz się do projektu w nie najlepszej kondycji z myślą, że to właśnie ty wjedziesz tam na białym koniu i wprowadzisz ład i porządek. Ważne, żeby była to twoja świadoma decyzja.

Korzyści:

• Wykazujemy, że dbamy o jakość produktu
• Pokazujemy, że znamy dobre praktyki tworzenia oprogramowania
• Ludzie kładący nacisk na testy są potrzebni w każdym projekcie
• Dostajemy informacje o stanie projektu
• Sprawdzamy jakiego framework używają do testowania
• Dowiemy się czy nasza praca nie będzie polegała jedynie na tworzeniu testów

4. Jaki standard języka jest u używany

Z reguły z samego ogłoszenia wynika jakie języki programowania są używane w danym projekcie. Niestety rzadko kiedy jasno określona jest wersja danego języka programowania. W świecie IT czas pędzi niezwykle szybko i praca w starych technologiach może znacząco wpłynąć na nasz rozwój zawodowy. Oczywiście nie namawiam do wybierania tylko ofert w najnowszych czy też najmodniejszych technologiach. Takie podejście znacząco uszczupliło by ilość dostępnych ofert. Warto by się jednak zastanowić, czy świadomie podejmując pracę w technologi mniej lubianej przez programistów nie powinniśmy zażądać wyższej pensji. Nie namawiam tu do pieniężnej rekompensaty pracy w starej wersji danego języka. Na rynku ofert pracy tak samo jak wszędzie indziej działa prawo podaży i popytu. Jeśli dany projekt jest mniej ciekawy to oznacza, że będzie mniej chętnych do pracy w nim, a więc pensje powinny być wyższe.

Kopyści:

• Dowiemy się w jakiej technologi będziemy pracować
• Zorientujemy się jak długo trwa już projekt
• Sprawdzimy czy praca w tym projekcie będzie dla nas rozwojowa

  5. Jaki jest system kontroli wersji

Nie będziemy się tu długo rozwodzić. Git jest już standardem. Jeśli w projekcie do którego masz dołączyć używane jest coś innego warto by się tym zainteresować. Dodatkowo jeśli używane jest jakieś starodawne rozwiązanie może to oznaczać mało rozwojowe utrzymywanie starej aplikacji.

Korzyści:

• Badamy dojrzałość projektu
• Sprawdzamy czy nasza nowa praca sprosta naszym oczekiwaniom

6. Czy są testy funkcjonalne

W zasadzie to należało by rozszerzyć to pytanie o to czy testy są i kto je pisze i wykonuje. W obecnych realiach pracy w wielo funkcyjnych zespołach (cross-functional teams) pozacierały się już granice pomiędzy testerami, a programistami. Często tworzenie całej infrastruktury CI (continuous integration) leży w kompetencjach zespołu. Dla mnie osobiście taka sytuacja okazała się bardzo korzystna. Ty sam musisz sobie odpowiedzieć  jak odnajdziesz się w takich realiach. Jeśli twoim celem jest nabranie kompetencji w jednym wąskim obszarze np. programowania w danym języku to nie będziesz zadowolony z rozpraszania się testami funkcjonalnymi. Z drugiej strony wejście w temat testów jednostkowych może być ciekawym, alternatywnym kierunkiem rozwoju.

Korzyści:

• Sprawdzamy czy dany projekt jest dla nas atrakcyjny
• Sprawdzamy w jakiej kondycji jest projekt
• Badamy alternatywne ścieżki rozwoju

7. Jak długo trwa projekt

To jest chyba najważniejsze pytanie ze wszystkich. W różnej fazie życia projektu różne aktywności muszą być podjęte. Wielu programistów marzy o zaczęciu projektu totalnie od zera. Daje to dużo zabawy z planowaniem architektury nowej aplikacji. Starsze projekty zapewne będą wymagały więcej aktywności związanych z refaktorowaniem kodu. Znam również paru programistów, którzy świetnie czują się w starszych projektach. Charakteryzują się one większą stabilnością i jeśli były prowadzone poprawnie, większym porządkiem.

Korzyści:

• Dowiemy się na czym tak naprawdę będzie polegała nasza praca
• Dowiemy się czy dany projekt będzie dla nas ciekawy
• Dostaniemy informacje jak stabilny jest projekt, do którego mamy dołączyć

8. Widełki

Miałem nie poruszać tu tematu finansów, ale pytanie dotyczące widełek jest dość ważne. Wszystkie większe firmy i sporo mniejszych ma jasno ustalone widełki. Także do sprawdzenia są trzy rzeczy:

1. Sprawdź czy widełki płacowe są
2. Czy są jawne
3. Czy rozpiętość widełek nie jest zbyt duża

Jeśli w firmie nie ma jasno zdefiniowanych widełek płacowych oznacza to, że nie ma też jasnego systemu awansów. Może to spowodować, że ugrzęźniesz na tym samym stanowisku na lata. Dodatkowo w takiej sytuacji łatwo o uznaniowość w awansowaniu pracowników.

Natomiast zbyt duża rozpiętość widełek powinna wzbudzić twoją czujność. Bo dlaczego za te same kompetencje na tym samym poziomie pracodawca ma płacić np. 70% więcej ? Może tak na serio nikt nie ma tej górnej granicy i jest to raczej chwyt marketingowy mający na celu zainteresowanie potencjalnych pracowników. Wiele portali internetowych z ogłoszeniami o pracę informuje już o możliwym wynagrodzeniu. Bez wątpienia jest to dobry trend.

Korzyści:

• Zorientujemy się jak zorganizowany jest system płacowy
• Przy odrobinie szczęścia dowiemy się jak atrakcyjni jesteśmy dla naszego nowego pracodawcy
• Będziemy mieli lepszą pozycję negocjacyjną

Na koniec jeszcze raz zachęcam. Rozmawiajcie z rekruterami. Zadawajcie im pytania. Z doświadczenia wiem, że wyjdzie to wam na dobre. Rekruterzy to tacy sami programiści jak wy.  Z chęcią odpowiedzą na wasze pytania, a jeśli nie to i tak nie chcieli byście pracować w takiej firmie. Na koniec najważniejsza rada dotycząca rozmów o pracę. Jeśli się nie spóźnisz to potem już jest z górki 🙂