Przed Tobą poszukiwanie pierwszej pracy jako junior developer? Zastanawiasz się, jak najlepiej to ogarnąć? A może by tak zmienić podejście i feedback w procesie rekrutacyjnym uczynić głównym celem poszukiwania pracy?
Zdaję sobie sprawę, iż to może wydać się dziwne. W końcu proces rekrutacyjny ma nam dać pracę, a nie feedback. Nie czarujmy się jednak. Kiedy myślimy o zmianie branży i zaczynamy szukać pierwszej pracy, warto nastawić się na samym początku nie na dostanie pracy, ale na otrzymanie feedbacku. Jak już kiedyś pisałam na blogu, uważam, iż warto wcześnie zacząć wysyłać CV i brać udział w procesach rekrutacyjnych. To da nam pojęcie, na jakim etapie nauki jesteśmy, czy nasza wiedza w ogóle jest wystarczająca i co powinniśmy robić dalej.
Nie oznacza to zupełnie, iż zakładam, iż nie uda się znaleźć pracy podczas jednej z pierwszych rekrutacji. Oczywiście, to jest możliwe. Uważam jednak, iż zniesienie presji z konieczności dostania pracy i uczynienie jej poszukiwania sposobem na ulepszanie swojej wiedzy, jest fajniejszym rozwiązaniem. Dzięki temu każde zadanie rekrutacyjne czy rozmowę, traktuje się jako szansę nauczenia się czegoś nowego.
Żeby uściślić – nie namawiam do aplikowania o pierwszą prace po zrobieniu jednego kursu online. To logiczne, iż wtedy nasza wiedza pozostało w powijakach. Jednak kiedy uczymy się już jakiś czas i mamy na koncie małe projekty, warto potraktować proces rekrutacyjny jako proces zdobywania feedbacku.
Zakładając, iż naszym celem jest feedback, zdejmujemy z siebie część presji. Otrzymanie pracy jest tu w takim przypadku bonusem. To ważne szczególnie jeżeli zmieniamy branżę zupełnie i nigdy nie mieliśmy do czynienia z zadaniami technicznymi podczas rekrutacji.
Załóżmy więc, iż wysłaliśmy CV w parę miejsc i dostaliśmy w odpowiedzi zadania rekrutacyjne. Zrobiliśmy zadania, poświęciliśmy swój czas, a tu przychodzi odpowiedź, iż niestety, nie o taki poziom rozwiązań im chodziło i dziękujemy. Tu warto się zatrzymać i zamiast po prostu zamknąć maila i uznać, iż ponieśliliśmy porażkę, wyciągnąć lekcję z tego, co się właśnie stało.
Skoro podstawą oceny było zadanie techniczne, istnieją na pewno techniczne powody, przez które nie dostaliśmy się do kolejnego etapu. Jeśli rekruter nie udzielił nam tej informacji, koniecznie o nią zapytajmy. To nie będzie źle odebrane! Co więcej, słyszałam nie raz historie, gdy kandydat, który dopytywał o feedback dostawał dosłownie listę rzeczy do nauki i poprawienia z informacją, iż jak ogarnie podany materiał, może ponownie wziąć udział w rekrutacji na to stanowisko.
Nie zdarzyło mi się jeszcze, abym nie otrzymała feedbacku od rekrutera, gdy o niego prosiłam. Czasem było to jedno czy dwa zdania, a czasem bardzo szczegółowa analiza mojego kodu. Na początku niezwykle mi to pomogło, choć przyznam, iż trochę zajęło mi nauczenie się, jak traktować taki feedback jako coś pozytywnego. Naszą pierwszą reakcją jest “ale ten ktoś się czepia, przecież to działa!”. Ale warto zdać sobie sprawę, iż osoba, która oceniała nasze techniczne zadanie ma o wiele więcej doświadczenia od nas. Dlatego jej słowa mogą być niezwykle cenne i stanowić dla nas podstawę do ustalenia dalszego planu nauki.
Jak najlepiej przygotować się do feedbacku, który dostajemy podczas procesu rekrutacyjnego? Po pierwsze, pamiętajmy, iż prosząc o feedback, chcemy uzyskać informacje o tym, co było dobrze, a co poszło nie tak. Dzięki temu będziemy mogli ustalić plan dalszej nauki. Nie chodzi o to, aby wykłócac się z rekruterem, czy przerzucać mailami. Za otrzymany feedback wystarczy po prostu podziękować i wziąć się do działania.
Załóżmy, iż po rozmowie rekrutacyjnej dostaliśmy informację, iż widać, iż znamy podstawy JavaScriptu, jednak ewidetnie pojawił się problem w zadaniu, w którym trzeba było debugować istniejący kod. To daje nam wyraźny znak, aby więcej poćwiczyć z napisanym już kodem. Na sam początek to moga być nasze starsze projekty (sprawdzanie swojego kodu to naprawdę ciężkie zadanie!). Możemy także poszukać projektów na Githubie czy Codepen i poczytać kod innych. Gdy czytamy kod, warto zastanowić się, co autor miał na myśli stosując takie a nie inne podejście. Fajną opcją jest też robienie zadań na Codewars, gdzie po ukończeniu danego zadania mamy dostęp do rozwiązań innych osób.
Zdaję sobie sprawę, iż to, co dzisiaj proponuję w tekście, jest dość przewrotne. W końcu w momencie zostania odrzuconym w procesie rekrutacyjnym, często mamy ochotę zwyczajnie wszystko rzucić i już nie wracać do tematu. Ale… gdy szukamy pierwszej programistycznej pracy, warto się nastawić, iż poszukiwania trochę potrwają. I warto wyciągąć z każdego procesu rekrutacyjnego jak najwięcej! Często to będzie pierwszy kontakt z innymi programistami (jeśli uczymy się sami), a feedback, jaki dostaniemy co do naszego kodu, to najcenniejsza rzecz, jaką możemy wynieść z rozmów kwalifikacyjnych!
Złota zasada jest jedna: nie bój się i pytaj! Dowiedz się, co było nie tak, czy coś im się podobało, co możesz poprawić, czy gdzieś dałoby się coś ulepszyć. A później zaktualizuj swój plan nauki w oparciu o otrzymane wskazówki. Na pewno czeka Cię sporo pracy, ale powrócisz w kolejnym procesie rekrutacyjnym
A gdy już otrzymasz pierwszą pracę, zajrzyj do tego wpisu, gdzie znajdziesz informacje, jak nauczyć się przyjmować feedback otrzymywany podczas code review. Tak, tak, praca programisty to ciągłe otrzymywanie i dawanie feedbacku! Warto się nauczyć, jak robić to dobrze.
Masz przemyślenia w temacie? Chcesz coś dodać? Napisz komentarz pod tym wpisem albo maila na joanna@wakeupandcode.pl. Obserwuj mnie także na
, tam dzielę się migawkami mojej codzienności.
