• O WordPressie
    • WordPress.org
    • Dokumentacja
    • Naucz się WordPressa
    • Pomoc techniczna
    • Uwagi
  • Zaloguj się
Marek Zając Marek Zając
  • contact@zajacmarek.com Zapraszam do kontaktu
  • Strona główna
  • O mnie
  • Kursy
  • Konsultacje
  • Kanał Youtube
  • 23 stycznia 2019
  • Marek Zając
  • 2 Comments

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?

Related Posts
  • Nie lubię TEGO projektu! 15 stycznia 2020
  • Pierwsze portfolio na GitHubie – Przewodnik 14 stycznia 2020
  • Pozory porządku – Historie z placu boju 13 stycznia 2020
2 komentarze
  1. Reply
    jarzej 23 stycznia 2019

    Jaka odpowiedź o foreach byłaby satysfakcjonująca bo jestem ciekaw?

    • Reply
      Marek Zając 23 stycznia 2019

      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].

Leave a Comment Cancel Comment

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Copyright 2020 Bizix, All rights reserved.
  • POLITYKA PRYWATNOŚCI I PLIKÓW COOKIES