Jak może wyglądać cała rekrutacja? Jak sprawdzane są umiejętności techniczne? O tym właśnie postaramy się opowiedzieć w dzisiejszym wpisie.
W skrócie: rekrutacja na stanowisko programisty jest zazwyczaj podzielona i obejmuje weryfikację techniczną oraz rozmowę z działem HR. Do tego gdzieś doklejone jest sprawdzenie języka angielskiego. Postaramy się przybliżyć Wam możliwe sposoby sprawdzenia Waszej wiedzy.
Weryfikacja techniczna
Może przybierać różne formy, poniżej zestawione te najbardziej popularne.
Rozmowa
W najprostszej wersji to po prostu rozmowa z doświadczonym programistą, której celem jest weryfikacja twojej wiedzy, umiejętności i doświadczenia. Powinny na niej więc paść pytania o studia, praktyki, staże, własne projekty IT, a także pytania stricte techniczne dotyczące programowania.
Warto wspomnieć, że weryfikacja techniczna ma często strategię do “któregoś” nie wiem, co oznacza, że nawet jeśli jesteś juniorem, będziesz dostawać pytania przekraczające Twoją wiedzę — rekruterzy chcą mieć po prostu dobry obraz Twojej wiedzy i stąd mogą zadawać trudne pytania na które nie odpowiesz. Oczywiście nie jest to może najbardziej komfortowe, gdy po każdej rozmowie masz w głowie ile razy czegoś nie wiedziałaś, jednak taka specyfika branży, że wszystkiego wiedzieć po prostu nie możemy i nawet szukając nowej posady na stanowisku seniorskim to nie wiem będzie się pojawiać w Twoich odpowiedziach.
Może się też pojawić fragment kodu z zapytaniem: co się stanie jeśli …, albo możesz zostać poproszona o napisanie na kartce jakiegoś fragmentu kodu, zapytania SQL czy narysowanie jakiegoś schematu. Warto przećwiczyć takie pisanie w domu, bo czasem długopis może …sparaliżować.
Programowanie podczas rozmowy
To co też może Was spotkać to programowanie podczas rozmowy. Rekruter może poprosić o napisanie jakichś prostych klas na zasadzie sklep i lista zakupów i wykonania na nich prostych operacji. Takie zadanie jest z reguły proste, jego rozwiązanie powinno zająć góra kilkanaście minut, a rekruter będzie Cię podczas niego uważnie obserwował, by zobaczyć chciażby w jaki sposób używasz środowiska.
Możesz też dostać do wykonania coś bardziej złożonego i w dłuższym (np. godzinnym czasie pracy) zostać poproszonym o wykonanie tego zadania. W tym czasie powinnaś mieć też zapewnione komfortowe warunki do pracy. W przypadku takiego zadania warto pamiętać o tworzeniu java-docsów, czy nawet zwykłym komentowaniu by lepiej pokazać koncepcje, oraz o TODO, którym można oznaczyć rzeczy do napisania na przyszłość np. walidacje.
Kolejnym sposobem weryfikacji jest pair-programing, który jest trochę miksem wcześniej przedstawionych — będziesz programowała sama, ale z podglądem dla rekrutera, który będzie mógł na bieżąco zadawać pytania do konkretnych rozwiązań i linijek kodu.
Zadanie do wykonania w domu
Tutaj możecie spotkać się z dwoma typami zadań. Po pierwsze możecie dostać jakiś problem opisany w sposób biznesowy, do rozwiązania z użyciem np. dowolnych technologii. Jako, że masz więcej czasu to i jakość Twojego kodu powinna być lepsza ;) Ważnym jest by opisać w jakimś dokumencie założenia jakie przyjęłaś na taką aplikacje w tym, jak ona działa, jakie są jej ograniczenia. Bez tego brak np. sprawdzenia czy dodany mail istnieje w bazie może zostać uznane za błąd, a jeśli zawrzesz to w takiej dokumentacji to będzie wiadomo, że miałaś tego świadomość.
Drugim typem zadania, może być stworzenie czegoś prostego ale z użyciem technologii narzuconej przez firmę, np. frameworku, którego oni używają, a ty go nie znasz, albo specjalnej konwencji czy narzędzi jakich używają do tworzenia swojego oprogramowania. Tutaj oprócz rozwiązania musisz znaleźć czas na naukę narzędzi niezbędnych do tego wykonania. Ważna uwaga! To też weryfikacja dla Ciebie i tego, czy chcesz pracować w danej technologii i warto ją wykorzystać. Z drugiej strony, może tak jak ja na jednej rozmowie dostaniesz naprawdę kilo dokumentacji związanej z pisaniem i edycją wtyczek do aplikacji, której ilość zniechęci do podjęcia wyzwania (nie uważam, że wdrożenie w technologie naprawdę specyficzną do projektu powinno być po stronie aplikującego, a do tego powinno dokonywać się już po rekrutacji:/) i podobnie jak ja, uznasz, że czegoś nie zrobisz, bo wiedza w ten sposób zdobyta do niczego innego się nie przyda.
Testy
Często są rozdawane podczas rozmów, czasami też jest to forma weryfikacji online. Testy wielokrotnego wyboru sprawdzające Waszą wiedzę. Niestety, nierzadko ich zawartość pozostawia wiele do życzenia (ja mam wtedy przed oczami taką szafę pancerną, do której ktoś kiedyś upchał wydrukowane testy, a po kilku latach ktoś inny uznał, że skoro wydrukowaliśmy, to je wykorzystajmy), bo pojawiają się w nich pytania o stare technologie, czy rzeczy zupełnie niezwiązane z daną rekrutacją.
Codility
Narzędzie, które część firm uwielbia, a część nienawidzi — podobnie, jak myślę, podzieleni są programiści. Rekrutacja z jego wykorzystaniem to 3 zadania, w których oprócz działającego rozwiązania jest oceniana jego złożoność obliczeniowa.
My nie do końca lubimy to narzędzie, a dlaczego, to dokładniej opowie Wam Kuba: “W kwestii Codility nie do końca się zgadzam z tym, że jest wartościowe narzędzie rekrutacyjne. Problemem tego typu narzędzi jest to, że nie do końca wiadomo co one sprawdzają. Gdyby ktoś mnie zapytał odpowiedziałbym, że jest to umiejętność budowania abstrakcyjnych algorytmów w bardzo krótkim czasie. I ocenianie nie działa prawidłowo. Zdziwiona?
Mogę podać przykład z jednego z testów, który rozwiązywałem — pytanie dotyczyło sprawdzenia, czy określona liczba występuje z określoną częstotliwością w zbiorze. Warunki zadania (złożoność obliczeniowa / pamięciowa) jak mi się wydawało były niemożliwe do spełnienia (później znalazłem, że jednak jest algorytm, który wprawdzie złożoność teoretyczną ma większą, ale w praktyce działa w założonym czasie), a jako że było to zadanie jedno z 3 do rozwiązania w godzinę, zaimplementowałem algorytm, który nie spełniał kryterium złożoności obliczeniowej. Tzn nie spełniał, ale wg systemu już tak, ponieważ kalkulacja złożoności opiera się o pomiar czasu działania (złożoność została opracowana po to, żeby takich pomiarów czasu unikać!!). Jak to się ma do rzeczywistości? Ano nijak, w całej swojej karierze nie spotkałem się z problemem który wymagałby podobnego podejścia czy nawet szerzej — sposobu myślenia. Bo czy naprawdę chce, aby programista w mojej firmie był w stanie w np. godzinę wymyślić algorytm? Nie, ja chcę, żeby był w stanie zaimplementować opisane rozwiązanie (junior), zastosować powszechnie znane rozwiązanie/technologię do problemu (deweloper) lub rozbił problem na takie mniejsze, które zostały już rozwiązane (senior). Które z tych kompetencji sprawdzają tego typu testy? Moim zdaniem żadne. Znam osoby, które są w stanie rozwiązać (prawie) każde tego typu zadanie, których nie chciałbym mieć w zespole za żadne skarby. Są też takie, które prawdopodobnie nie zaliczyłyby tego testu, a którym gdybym tylko mógł zapłaciłbym każdą sumę, żeby mieć ich w zespole.
To nie znaczy jednak że są one całkowicie beznadziejne. Polecam przeczytać dyskusję tutaj: http://qr.ae/7CErKn — prawie wszystkie zalety testów ‘na algorytmy’, o których mowa, nie mają przełożenia na ich ‘automatyczną’ wersję. Tego typu testy mogą być przydatnym DODATKOWYM źródłem informacji o kompetencjach osoby, ale nie mogą być jedynym. W praktyce często są one stosowane jako pewnego rodzaju sito do dalszych etapów rekrutacji. Jeśli napotkacie na swojej drodze firmę, która tak robi, powinna Wam się zapalić czerwona lampka, bo najprawdopodobniej wynika to z podejścia do rekrutacji ‘najniższym kosztem’. Niestety doświadczenie uczy, że najczęściej przekłada się to na identyczne podejście do pracowników i projektów.”
Narzekać można, ale co, gdy trafi Ci się takie zadanie? Po pierwsze, na stronie codility, możesz przejść tutoriale, które uczą jak podchodzić do różnych problemów. Dzięki temu nauczycie się nie tylko jak działa platforma, ale też jak podchodzić do zadań, które mogą się pojawić. Po kilku(nastu) zadaniach zobaczycie same, że wszystko opiera się na znalezieniu odpowiedniego algorytmu i późniejszej implementacji. Słowem, jest to absolutnie do przejścia, tyle, że wymaga trochę przygotowania. Ja np. miałam 3 zadania, w których 2 były oparte na tak naprawdę takim samym algorytmie i różniły się naprawdę niuansami.
Zakres materiału
Jeśli chodzi o pokrycie tematów, które powinny być Ci znane to ciągle pracujemy nad kolejnymi odcinkami #NiezbędnikaJuniora więc polecamy śledzić te wpisy na naszym blogu i zapoznawać się z rzeczami, które często pojawiają się na takich rozmowach. Zazwyczaj pytania krążą wokół Javy SE, EE, Springa, podstaw baz danych i SQLa, wzorce projektowe, pojawia się też HTML, CSS, Javascript(i jego framworki np. Angular), często pytają też o testy i ich tworzenie, korzystanie z repozytorium, dobre praktyki programistyczne, protokół HTTP. Te wszystkie tematy będziemy rozszerzać właśnie w serii #NiezbędnikaJuniora, na ten moment wyszukajcie konkretną lekcje z naszego kursu i sięgnijcie do literatury dodatkowej.
Co firma to obyczaj (bo i o technologie okienkowe mogą pytać, w szczególności jeśli robią w nich jakieś projekty), zdarzyło mi się usłyszeć na rozmowie: fajnie, że masz już pierwszą aplikacje na koncie jak i: wolałbym żeby nie znała Pani nic ze Springa, a dobrze poruszała się w Javie. No cóż, znalezienie pierwszej pracy nie jest może najłatwiejsze, ale ściskam kciuki za poszerzanie Waszej wiedzy i znalezienie pracodawcy, który postawi przede wszystkim na Wasz potencjał!
Weryfikacja języka
Raz przeprowadzana podczas rozmowy HRowej, raz technicznej — sprowadza się (jeśli aplikujesz do polskiej firmy) do naprawdę krótkiej rozmowy. Zakładam, że jeśli mówisz na poziomie B1 to bez problemu sobie z nią poradzisz. Jeśli nie, to hm, będzie trudno w codziennej pracy, bo przecież dokumentacja, tutoriale itp., są głownie w języku angielskim.
Rozmowa z osobą z działu HR
Te pytania może też zadać teamleader czy po prostu rekrutujący Cię programista. Chodzi tu głównie o warunki zatrudnienia, od kiedy możesz zacząć, stawkę, stanowisko, sprzęt na jakim pracujesz, ogólne opowiedzenie o projekcie i firmie do jakiej aplikujesz.
Mamy nadzieję, że zebrane przez nas informacje zaspokoją Twoją ciekawość i ułatwią przygotowanie do rozmów!
PS. do rekrutera
Chodziliśmy z Kubą na różne rozmowy rekrutacyjne. Znamy też doświadczenia naszych znajomych, dlatego chcemy przekazać Ci informację zwrotną.
Jeśli rekrutujesz w swojej firmie mam do Ciebie jedną wiadomość: weź odpowiedzialność za przebieg rozmowy technicznej. Ja wiem, że czasem możecie mieć w firmie bazę pytań z odpowiedziami i fajnie, że macie się na czym podpierać — ale jeśli już z nich korzystasz, to proszę Cię sprawdź, czy odpowiedzi z jakimi porównujesz kandydata są poprawne, a jeśli będziesz pytał o coś z czym nie masz doświadczenia, to proszę idź do swojego kolegi i dopytaj, czy dana odpowiedź jest dobra.
Sprawdź testy, zadania jakie dajecie kandydatom. Czy nie ma tam błędów, niejasności albo rzeczy, których się już dawno nie stosuje. Nie bój się porozmawiać ze swoim szefem o ich aktualizacji.
Zastanów się też, czego warto wymagać od programisty: czy to o co pytasz, to faktycznie wiedza niezbędna czy może teoria, która była wymagana na studiach, która nie przydaje się w praktyce.
Nie bój się też juniorów, którzy nie znają jeszcze całego słownictwa i czasem dość opisowo opowiadają na pytania wspierając się przykładami z życia. Jeśli ktoś jest Ci w stanie wytłumaczyć programowanie na przykładzie szkoły i klasy, to znaczy, że rozumie temat (a czasem rozumie znacznie lepiej niż ten, co odpowie wyuczoną regułką).
Na koniec, nie bój się ludzi takich jak ja, którzy nie mają wykształcenia IT, ale mają ogromną pasję do tego co robią. Pomyśl ile determinacji wymaga nauczenie się programowania samemu, a dodatkowo ile motywacji samo zdecydowanie się na tak krok. Taki pracownik aż pali się do pracy, a jeśli sam zrobił swoją pierwszą aplikacje (a dowiesz się tego z jego CV, więc naprawdę fajnie jakbyś na nie spojrzał wcześniej niż na samej rozmowie) to pomyśl jak szybko nauczy się programować z pomocą doświadczonych współpracowników.
To był post z cyklu #PierwszaPraca, który publikujemy co dwa tygodnie: