Miał być post na Facebooku ale wyszło tego więcej niż myślałem. Dlatego dostaniecie wpis na blogu ;)

Byłem dzisiaj na rozmowie rekrutacyjnej. Ponownie w roli osoby, która zadaje pytania (chociaż pamiętajcie, że kandydat też może i powinien zadawać pytania!). Całość trwała niecałe dwie godziny. A trafił nam się kandydat, którego szczerze mówiąc ciężko mi ocenić. Dlaczego?

Teoretyczna praktyka

Dlatego, że jego odpowiedzi zahaczały o skrajności. Przykładowo miał problem żeby odpowiedzieć jakie są ograniczenia pętli foreach w języku C# albo kiedy lepiej użyć interfejsu, a kiedy klasy abstrakcyjnej. Z drugiej zaś strony całkiem sprawnie radził sobie trochę bardziej złożonych zagadnień jak np. obiekty niemutowane czy zastosowanie kompozycji w kontekście chociażby reguły Open-Closed. Widać było, że chłopak coś robił w kierunku czystego kodu. Wie po co i jak dbać o jakość kodu. Nawet w trakcie rozmowy wspomniał, że jest w trakcie przerabiania książki „Czysty kod” Wujka Boba. A mimo to wykazywał braki jeżeli chodzi o bardziej techniczne zagadnienia.

Przed rozmową, kiedy dostaliśmy CV, kolega mnie zapytał dlaczego kandydat ocenił znajomość TypeScriptu trochę ponad średnią skoro wg CV pracuje w nim kilka lat. Jak dużo można jeszcze nie wiedzieć robiąc tylko to przez taki czas. Jednak w trakcie rozmowy okazało się, że pracuje 4 lata, ale samym Angularem i TypeScriptem zajmuje się od ok. roku. Nie bez powodu wspominam tutaj TypeScript, a nic nie mówię o JavaScripcie. Bo kiedy zadałem pierwsze pytanie o JSa usłyszałem, że JSa to on nie zna bo programuje tylko w TypeScripcie właśnie. A jest to poważny błąd. Bo TS jest ostatecznie kompilowany do JSa i o wszystkich mechanizmach obecnych w JSie trzeba pamiętać pisząc w TSie. Inaczej można spędzić długie godziny albo dni szukając błędu, który przecież nie mógł wystąpić.

Chciał dobrze

W tym momencie sprawa mogłaby być prosta. Mamy do czynienia z osobą, która nie ma praktyki, coś przeczytała i tyle. Ale nie. Bo mimo, że wykazywał takie braki to jednocześnie płynnie i długo opowiadał o rozwiązaniach jakie używali w pracy czy o problemach z jakimi się spotkali. Tak więc coś robił i w coś był zaangażowany. Jednak jak sam stwierdził w obecnej pracy wszystko miało być na już, nieważne jak zrobione. Stąd też moje przypuszczenie, że chłopak rozwija się na własną rękę, ale nie może tego wykorzystać w codziennej pracy, a przez to trudno mu trafić na problemy i ich rozwiązania, które by wynikały z prób implementowania tego czego się nauczył.

Jest nadzieja

Ostatecznie wydałem decyzję, że na jakieś niższe stanowisko możemy go przyjąć, bo widzę potencjał i zaangażowanie. Ale takich osób nie możemy mieć za dużo, bo wymagają więcej naszego czasu i uwagi. Jednak przez to, że jest świadomy swoich braków i nie kręcił przy odpowiedziach uznałem, że będzie z czego szlifować wiedzę. Jednocześnie widzę, że zmarnował sporo czasu w obecnej pracy, bo będąc na początku drogi pracował w projekcie, który rozwijał go bardzo wolno albo wręcz w ogóle.

Dlatego jeżeli w pracy czujecie, że coś jest robione byle jak i nie rozwijacie przez to swojej biegłości w pisaniu kodu to może warto się zastanowić czy to praca dla Was? Z drugiej strony czytając o czymś dobrze jest próbować to zastosować do rozwiązania realnego problemu, nawet na własną rękę, w domowym projekcie. Bo co z tego, że znacie mnóstwo wzorców projektowych, skoro widzieliście je tylko w odizolowanych przykładach. Albo że nauczyliście się wszystkich zasad czystego kodu, skoro ani razu nie musieliście męczyć się żeby je zastosować w projekcie średniej jakości?

A czy Ty drogi czytelniku zaryzykowałbyś wzięcie takiej osoby do zespołu?