Kandydat, którego trudno ocenić

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?

Wiedziałeś, że jestem też obecny w serwisie YouTube gdzie również znajdziesz treści związane z programowaniem? Nie?

W takim razie warto to zmienić! Odkryj i zasubskrybuj mój kanał dostępny pod adresem https://www.youtube.com/user/zajacmarekcom

Szukasz książek dla programistów i jednocześnie chcesz wesprzeć tego bloga? Sprawdź ofertę wydawnictwa Helion klikając w TEN LINK.

2 thoughts on “Kandydat, którego trudno ocenić”

    1. Chodziło o to, że korzystając z foreach nie można modyfikować kolekcji, po której się iteruje (nie można np. usunąć elementu), nie ma dostępu do indeksu kolejnych elementów i utrudnione jest porównywanie kolejnych elementów. Szczególnie nie można porównać bieżącego elementu z kolejnym, co jest możliwe np. w pętli for, bo wtedy wystarczy zrobić list[i] == list[i+1].

Dodaj komentarz

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