rekrutacja-programisty

Rekrutacja programisty okiem eksperta – cz. 2

Jak wygląda rekrutacja na programistę w praktyce? Jeżeli braliście już udział w procesie rekrutacyjnym i otrzymaliście do wykonania zadanie, to mogę powiedzieć, że mieliście dużo szczęścia. Moim zdaniem to najlepszy sposób na weryfikację umiejętności zarówno dla kandydata, jak i pracodawcy. Jeżeli takie zadanie dopiero przed Wami, to wierzę, że dzisiejszy wpis pozwoli Wam się dobrze przygotować. Czas na drugą część wpisu – rekrutacja programisty okiem eksperta. Tym razem rozmawiam z Sandrą, doświadczoną programistką, która opowie Wam, czego można się spodziewać na tym etapie rekrutacji.

Dla przypomnienia: w pierwszej części wpisu rozmawiałam z Anią, specjalistką ds. rekrutacji,  która opowiadała o tym, jak wygląda proces rekrutacyjny od momentu wysłania CV do zaproszenia kandydata do rozmowy technicznej.

Poprosiłam Cię o rozmowę, ponieważ jako doświadczona programistka przygotowywałaś i sprawdzałaś zadania rekrutacyjne kandydatów na stanowisko Junior Front-end Developera, w tym moje. 😉 Czy możesz krótko opowiedzieć, jaki był główny cel zadania?

W zadaniu rekrutacyjnym, które skomponowałam, najważniejsza była umiejętność poradzenia sobie z nim. Nie było to trudne zadanie, wykonywane w domowym zaciszu, więc nie sprawdzało wiedzy teoretycznej. Kandydaci mieli dostęp do wszelkich pomocy naukowych, jakie były w ich zasięgu. Mieli wykazać się umiejętnością wykorzystania dostępnej wiedzy do wykonania praktycznego zadania. Oczywiście nie chodziło o bezmyślne kopiowanie cudzej pracy, fragmentów kodu z Internetu.

Jakie kryteria były dla Ciebie kluczowe, aby pozytywnie ocenić pracę kandydata? Na co zwracałaś szczególną uwagę?

Zadanie składało się z kilku elementów składowych, które odnosiły do różnych obszarów programowania stron. CSS, poprawność struktury HTML, JS i jQuery, RWD mogą wyznaczać te obszary. W każdym z nich zwracałam uwagę szczególnie na to, czy ktoś podjął się próby i to już dawało pierwszy plus. Następnie analizowałam, na ile zaprezentowane rozwiązanie jest samodzielne, przedstawianie cudzego kodu jako własnego jest niewskazane. Dopiero wówczas oceniałam skuteczność rozwiązania i elegancję kodu. Wszystko to jest oczywiście bardzo ważne w pracy Front-end Developera, ale metod i narzędzi człowiek może się nauczyć, a chęci do nauki po prostu ma lub nie.

Co w sytuacji, gdy kandydat odesłał niepełne zadanie, bo np. nie zdążył albo nie potrafił wykonać wszystkich poleceń? Czy taka osoba miała mniejsze szanse niż ktoś, kto wykonał zadanie w 100%?

W przypadku rekrutacji nie oceniamy wyłącznie wiedzy i umiejętności, ważną kwestią są bowiem rokowania. Oczywiście patrząc bardzo sucho na to wszystko, może się wydawać, że ten kto wykonał 100% zawsze będzie przed tym, który nie potrafił, ale nie do końca to tak działa. Osobiście bardzo cenię uczciwość. Jeżeli otrzymam od kandydata informację, że nie zdąży wykonać całego zadania to dam mu nieco więcej czasu, żeby miał szansę dokończyć. Przyznanie, że się nie potrafiło czegoś zrobić nie skreśla, ponieważ wychodzę z założenia, iż może się tego nauczyć ode mnie. Bardzo ważne jest też, że kandydat ma świadomość, czego jeszcze nie umie – otwiera mu to drogę do czerpania nowej wiedzy.

Czy lepiej odesłać niepełne zadanie, ale w terminie czy wykonane w 100%, ale po czasie?

Najlepiej zgłosić brak czasu i poprosić o wydłużenie terminu. Oczywiście w granicach rozsądku, ale jak jesteśmy pewni, że damy radę skończyć zadanie to nie bójmy się zapytać o jeden czy dwa dni dłużej. Jednak jeśli nie jesteście pewni czy w ogóle skończycie, to lepiej wysłać niepełne w terminie. Ewentualnie można przyznać, że sobie z czymś nie radzicie, ale chcielibyście mieć jeszcze chwilę na przemyślenie problematycznego zagadnienia. Otwartość, zaangażowanie, komunikacja to niezwykle wartościowe i pożądane cechy, które dobry pracodawca z pewnością doceni.

Czy warto pisać komentarze do napisanego kodu? Czy wystarczy, żeby strona/aplikacja z zadania działała?

Zawsze, po prostu zawsze, cokolwiek się programuje warto komentować kod. Komentarze pokazują, czy rozumiemy to, co robimy, dają dodatkową informację o nas, naszym zaangażowaniu, wiedzy, metodologii pracy. Jak już wspomniałam wcześniej, nie sprawdzamy wiedzy teoretycznej, wykutej na pamięć, bo to nie ma zbyt wielkiego znaczenia. Najważniejsze jest to, czy kandydat będzie potrafił ją zastosować. Każdy powinien mieć na uwadze to, że nie sprawdzamy wyłącznie wizualnie, czy wszystko działa. Przeglądamy kod i dopiero na tej podstawie możemy ocenić wykonaną pracę. Co więcej, czytanie cudzego kodu zazwyczaj jest nieprzyjemne, ponieważ każdy programista ma swoje nawyki, struktury, rozwiązania. Bez komentarzy sprawdzający może początkowo widzieć wyłącznie bałagan, szczególnie jeśli przyjdzie mu do przeglądania niechlujny kod.

W tym miejscu warto też dodać jedną, dość istotną rzecz, o której wielu zapomina. Nie tylko komentarze są ważne, ale również estetyka. Nie bójcie się używać wcięć w strukturze, odstępów, bowiem one właśnie sprawiają, że wszystko staje się znacznie bardziej czytelne.

W jaki sposób weryfikowałaś, czy kandydat samodzielnie rozwiązał zadanie?

Jeżeli ktoś rozwiązał zadanie mocno niesamodzielnie, a właściwie zrzucił tylko przykłady znalezione w sieci, to uwierzcie: nie potrzeba do tego wielkiej analizy. Taki kod wydaje się krzyczeć każdą swoją linijką, że został po prostu przepisany z jakiegoś innego źródła. To, że nie sprawdzamy wiedzy teoretycznej a umiejętności posługiwania się dostępną wiedzą, sprawia, że znacznie łatwiej jest wyczuć, kiedy ktoś nie rozumiał nawet tego, co kopiuje. Zazwyczaj oczywiście występują w tym kodzie błędy, nieścisłości. Dodatkowo pomaga „wujek Google”. My również korzystamy z tej wyszukiwarki i może nawet znamy kilka tricków, które pozwalają znaleźć dość szybko prawdziwe źródło kodu. Najgorszą pracą jaką otrzymałam od kandydatów, była bezczelna kopia strony, którą sama tworzyłam. Bezczelna i niestety też bezmyślna. Kopiując źródło strony kandydat pozostawił nawet moje własne komentarze oraz szereg danych, które bezpośrednio wskazywały skąd zaczerpnął tej „inspiracji”. Nigdy tak nie róbcie, taka osoba zostaje od razu skreślona.

Bazując na swoim doświadczeniu, jakie rady dałabyś osobom podchodzącym do zadań rekrutacyjnych?

Podstawowa rada to: spróbuj. Kolejna: nie bój się, rekruter nie gryzie.

Myślę, że warto skupić się na tym, by rzeczywiście zaangażować się w to zadanie. Usiąść, przemyśleć, zaplanować i wykonać krok po kroku. Jeśli zatniesz się na jakimś elemencie, to zostaw, wróć do niego później, bo czasami trzeba odświeżyć głowę, zapomnieć o problemie i zacząć od nowa. To oczywiście nie dotyczy tylko kandydatów na Juniorów, to dotyczy wszystkich, także mnie, bo czasami zatnę się na czymś banalnym.

Może warto podejść do tego zadania nie jak do obowiązku, przymusu, a bardziej jak do swego rodzaju zabawy edukacyjnej. Wierzę, że wysyłając CV, naprawdę chcecie to właśnie robić, uczyć się i rozwijać właśnie w tej dziedzinie, więc niech to zadanie będzie przyjemnym sprawdzeniem własnych sił. Pamiętajcie, że osoby na tym stanowisku mają się dopiero uczyć od bardziej doświadczonych w zespole, nie musicie być alfą i omegą na starcie.

Jeśli macie jakiekolwiek pytania do Sandry, zadawajcie je śmiało w komentarzach. 🙂


sandra-rosaSANDRA ROSA
Software developer z 8-letnim doświadczeniem w zawodzie.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.