Cześć.
Zabranie się do tego tematu zajęło mi trochę czasu. Bo sam pomysł pojawił się jakoś pod koniec lata 2020. A mamy luty. Cóż, lepiej późno niż później.
Zaczynajmy.
Kilka rekrutacji za mną
Ilość rekrutacji, które przeprowadziłem w swojej karierze można liczyć w grubych setkach. Spotkałem naprawdę ogromny przekrój ludzi, od juniorów, którzy powinni być regularami, po seniorów, których umiejętności są na poziomie juniora. Jeszcze tylko junior, który po rozmowie „awansował” na seniora, się nie trafił. Albo po prostu ja go nie wyłapałem.
Czas spędzony na tych spotkaniach pozwolił mi wypracować swój własny sposób ich prowadzenia, nauczyłem się jakich pytań unikać, na co przymykać oko, a na co zwracać większą uwagę.
Rozmowa z kandydatem to nie tylko ocena jego umiejętności technicznych, ale również sposobu rozmowy, prezencji, elokwencji, a także takich bardziej ulotnych rzeczy, jak próba określenia czy kandydat będzie pasował do firmy lub czy jego plany na przyszłość są do zrealizowania w organizacji, do której się rekrutuje.
Ale dziś zamkniemy się w jednym, konkretnym temacie – rekrutacji Junior Python Developera i wymagań technicznych, jakie stawiam takim osobom.
Seniority
Ogólnie seniority (poziom wtajemniczenia – junior, senior itp) to etykieta, którą próbuje się określić jak dobry jesteś. Ale nikt nigdy nie sprecyzował i pewnie szybko nie sprecyzuje konkretnych, uniwersalnych wymagań, które muszą być spełnione, aby wskoczyć na wyższy poziom. Kariera programisty najczęściej wygląda tak:
Gdzie po ekspercie są już twory bardziej wyspecjalizowane lub bliższe biznesowi. Mam tu na myśli pozycje typu TechLead, Architekt, TeamLeader itp. Powszechną praktyką jest tworzenie zespołów wokół seniorów/ekspertów, co tylko przyśpiesza ewentualne poziome awanse. Muszę jeszcze dodać, że wiele firm upraszcza tę drogę, pomijając pośrednie poziomy typu regular+. Ma to swoje wady i zalety.
Czekaj, stop!
Podoba Ci się to co tworzę? Jeśli tak to zapraszam Cię do zapisania się na newsletter:Jeśli to Cię interesuje to zapraszam również na swoje social media.
Jak i do ewentualnego postawienia mi kawy :)
Brak uniwersalnych wymagań
Każda firma będzie mieć inne wymagania co do nowych osób. I ciężko się temu dziwić, bo firmy korzystają z różnych technologii i jasne jest, że będą faworyzować osoby, które są bliższe im pod tym względem. Ta faworyzacja (jak i jeszcze kilka innych elementów) sprawia, że możesz w jednej firmie zostać juniorem, a w drugiej regularem. Albo na odwrót. Jeśli myślisz o zmianie pracy, to dobrą praktyką jest porzucenie na chwilę tych etykiet.
O ile nie porwałbym się nigdy na określenie wymagań, co do osób startujących na stanowiska regular i wyżej, tak o juniorach można powiedzieć już znacznie więcej.
Wymagania techniczne wobec Junior Python Developera
To co napiszę tutaj jest subiektywnym zbiorem wymagań, który nie koniecznie musi pokrywać się z wymaganiami innych rekruterów. Jest jednak wynikiem mojego doświadczenia i myślę, że zazębia się z wymaganiami rynku. Ogólnie można zauważyć, ze sytuacje, kiedy bierze się do pracy każdego, kto umiał trzymać klawiaturę, występują coraz rzadziej. Tak czy siak, zaczynajmy.
A nie, jeszcze chce dodać, że kolejność nie określa ważności. No, teraz możemy zaczynać.
Podstawy języka
Nikt, kto ma stanowisko developera, obojętnie od poziomu, nie powinien mieć problemów ze składnią języka. Jeśli korzystając z PyCharm’a brak dwukropka po warunkach w ifie sprawia, że człowiek szuka rozwiązania przez 30 minut, to jest to sygnał, że coś jest nie tak.
Kandydat musi bez problemów rozróżniać specyficzne dla Pythona elementy takie jak generatory, dekoratory itp – jednym słowem, musi znać język, ale również jego najbliższy ekosystem, tj narzędzia typu pip czy venv.
Biblioteka standardowa
Dla wielu osób siłą Pythona jest jego biblioteka standardowa. I ciężko nie przyznać im choćby częściowej racji, bo znajdziemy w niej naprawdę wiele przydatnych rzeczy. Podstawowe elementy z stdliba junior musi po prostu znać i umieć wykorzystać. Oczywiście nie mówię, żeby recytował z pamięci argumenty funkcji, ale żeby wiedział że istnieją i gdzie mniej więcej ich szukać.
Pisząc „podstawowe elementy stdliba” mam na myśli np:
- random
- json
- datetime
- os
- re
- logging
itp…
Natomiast nie będę wymagał znajomości bibliotek np. przeprowadzających operacje na kopcach.
Programowanie obiektowe
Znajomość programowania obiektowego na poziomie co najmniej dobrym jest konieczna, a w związku z tym kandydat powinien swobodnie poruszać się w zagadnieniach takich jak jest dziedziczenie, polimorfizm, kompozycja czy hermetyzacja. Do tego dodałbym jeszcze klasy abstrakcyjne i znajomość podstawowych metod magicznych. Jeśli to wszystko udekorujemy rozumieniem tego paradygmatu, to jest naprawdę fajnie.
Testy
Junior powinien umieć napisać poprawnie proste testy w dowolnym z frameworków. Dobrze by było jakby wiedział czym są mocki (atrapy) i jak z nich korzystać. Powinien znać termin „pokrycie testami” i mieć ogólną wiedzę wystarczającą do rozmowy na temat tego, czy ta metryka jest miarodajna i co dokładnie ona przedstawia.
Typy danych
Konieczna jest znajomość podstawowych typów danych, zarówno prostych jak int czy string, ale też bardziej złożonych jak lista, zbiór, słownik czy tupla. Kandydat powinien swobodnie czuć się w używaniu metod, jakie dostarczają te klasy oraz poradzić sobie z ewentualną konwersją.
Generatory, dekoratory i managery kontekstu
Prosty dekorator nie powinien stanowić problemu, podobnie ma się sprawa z generatorami i managerami kontekstu. Kandydat powinien znać mocne i słabe strony tych rozwiązań i umieć wybrać najlepsze do konkretnego problemu.
List/dict/set comprehension
Tutaj nie oczekuję cudów, po prostu chciałbym żeby taki zapis był czytelny dla kandydata i żeby był on w stanie, w skończonym czasie, napisać podobne wyrażenie samodzielnie.
Algebra boolowska
Pełna płynność w ewaluacji wyrażeń jest wymagana. Przykładowym zadaniem mogłoby być np.:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | def first(): print(1) return True def second(): print(2) return False def third(): print(3) return False first() and second() and third() |
gdzie pytanie brzmiałoby: co ten kod wypisze i dlaczego?
Wyjątki
Junior powinien umieć rzucać, łapać i przede wszystkim rozumieć mechanizm wyjątków. Ten ostatni wymóg pozwoli mu na łatwe przyswojenie tworzenia wyjątków, ich hierarchii i ich ogólnego znaczenia w programowaniu.
Myślenie
Czasem zdarza mi się dać zadanie, w którym jest użyta jakaś mniej znana funkcja. Gdy kandydat mówi, że nie spotkał się z nią, to opisuję mechanizm jej działania i liczę, że wspólnie określimy rezultat przedstawionych programów. Tego typu zadania nie zawsze zdają egzamin. Szczególnie, jeśli ktoś jest zestresowany. Więc tutaj trzeba uważać, żeby nie wyciągnąć zbyt szybko zbyt pochopnych wniosków. Ale to już problem rekruterów.
Bazy danych
Przynajmniej jedna baza relacyjna powinna być opanowana w stopniu podstawowym, tj.:
- selecty (w tym kolejność, agregacja itp)
- joiny
- inserty
- delete’y
- update’y
Wymagań odnośnie baz nierelacyjnych nie mam.
Docker
Ta technologia jest tak wygodna i tak powszechnie używana, że aż ciężko, żeby nie pojawiła się na liście wymagań. I oczywiście, byłoby super, gdyby kandydat umiał korzystać z Dockera, a najlepiej, żeby jeszcze umiał pisać Dockerfile’a i ubierać je w docker-compose’a, ale…
Ale jest to tylko „nice to have”. Doszedłem do wniosku, że już dużo pracy trzeba poświęcić, by umieć rzeczy o których wspomniałem wyżej, że dokładanie kolejnej, która wszak nie wpływa na samą umiejętność programowania, nie ma sensu.
GIT
Bezbłędne poruszanie się w podstawach, tj push/pull/commit/checkout itp. Rzadko zdarza się ktoś kto w ogóle nie korzystał z GITa.
Współbieżność/asynchroniczność
Dobrze by było znać teoretyczne podstawy i na tym się zamykam. Chyba, że widzę potencjał, to zawsze warto więcej porozmawiać. Pisząc „teoretyczne podstawy” mam na myśli różnicę miedzy wątkami i procesami i sposób użycia ich w Pythonie.
Linux
Nie przywiązuję do tego jakiejś wielkiej uwagi, bo wychodzę z założenia, że pracując na Linuxie 8h dziennie, szybko załapie wymagane podstawy.
Czy to są wysokie wymagania?
Ciężko mi na ten temat jednoznacznie odpowiedzieć. To, co jest tu ważne, to fakt, że braki w jednym elemencie mogą być zrekompensowane w innych. Jednym słowem: czasem zakłada się, że część kompetencji kandydat zdobędzie już podczas pracy i onboarding układa się tak, by zdobył je możliwie najszybciej. Inną techniką jest po prostu zakontraktowanie, że nim umowa wejdzie w życie, kandydat przejrzy te zagadnienia, które są koniecznie do płynniejszego wejścia w stos technologiczny firmy do której aplikuje. Wszystko zależy od sytuacji. Ogólnie cel rekrutacji jest jeden: znaleźć osoby które dobrze rokują i dać im możliwość rozwijania się.
Co z szukaniem regularów i seniorów?
Tutaj sprawa jest znacznie trudniejsza. Zazwyczaj jedna rozmowa nie wystarcza by podjąć decyzję. Czasem stosuje się rekrutację kilku etapową, czyli po pierwszej rozmowie jest kilka kolejnych. Ewentualnie prosi się kandydata o live-coding lub o realizację konkretnego programu i podesłanie linka do GitHuba. Sposobów zbadania, czy dany kandydat to na pewno osoba, której poszukujemy, jest wiele. Jest w tym również korzyść dla kandydata – im więcej kontaktu z firmą, tym większa szansa, że uda mu się odpowiedzieć na podobne pytanie: czy firma z którą rozmawiam jest tą, której szuka.
Oczywiście tutaj również działa zasada, że braki w jednym zakresie mogą być rekompensowane wiedzą w innych. I ma to te same konsekwencje, co w przypadku juniorów.
Zmierzając do brzegu
Rekrutacja to proces w którym wygrać mają obie strony – tylko wtedy praca jest satysfakcjonująca i efektywna. Jako rekruter zawsze staram się podchodzić do kandydatów z uśmiechem, tak by poczuli się swobodnie, bo od tego już prosta droga do zamiany stresującej rekrutacji w luźną rozmowę o kodzie. Oczywiście na tyle, na ile to możliwe. Zawsze jestem szczery, otwarty i chętny do pomocy. Tego samego oczekuję od kandydatów.
Mateusz Mazurek
Wartościowy artykuł Mateuszu, skłania do przemyśleń – także mnie, również od jakiegoś czas parającego się rekrutowaniem.
Dodałbym, że nieodłącznym elementem (wspominanym tu między wierszami) jest zadanie praktyczne. W jego trakcie naprawdę wychodzi wiele rzeczy, jakie by ono nie było – ja np. szczególnie zwracam uwagę na proces rozumowania (do dzielenia którym zachęcam kandydata) czy zwykła umiejętność suchego kodowania. To, o co uzupełniłbym Twoją listę to umiejętności komunikacyjne. Po pierwsze, sprawdzane już podczas luźnej rozmowy (np. precyzyjne odpowiadanie na pytania). Po drugie, oceniane w trakcie zadania praktycznego (proste informowanie co robię, jeśli się zaciąłem – to mówię o tym itd).
Tak, podpisuję się pod tym co napisałeś. Dodałbym może, to co w sumie napisałem w artykule, że praktyka na rozmowie rekrutacyjnej to miecz obosieczny – jeśli kandydat zacznie się stresować (co nie jest takie rzadkie), bo ktoś mu patrzy na ręce, to możliwe że mimo genialnej wiedzy – utknie na pozornie błahych problemach i wypadnie w samej rozmowie słabo. Ale tak czy siak, zawsze warto popatrzeć na kod:)
Czytam to z perspektywy osoby 50+ muszącej zmienić zawód na jakiś nowy. Myślałem o spróbowaniu szczęścia w IT. Przy czym nie zależy mi na legendarnym hajsie, który zarabia się w tej dziedzinie. Po prostu szukam nowej, ciekawej pracy, dającej normalne gwarancje finansowe. Jestem po 3-miesięcznym, stacjonarnym kursie Pythona. Większość z rzeczy które opisujesz, mogę znaleźć na Stackoverflow czy ogólnie gdzieś w Googlach, ale sam ich z palca nie napiszę. Co do przykładu z algebrą boolowską, to ten kod chyba nic nie zwróci. Ogólnie wrażenia dołujące po przeczytaniu Twojego artykułu. Tzn. sam artykuł jest ciekawy, ale wymagania na juniora są dołujące… Czytaj więcej »
Przykro mi, że artykuł nie podniósł Cię na duchu :( liczyłem, że pokazując jakie są/mogą być wymagania na juniora pozwolę kandydatom „poznać wroga” a tym samym właśnie motywację zwiększyć. Tak czy siak, trzymam kciuki, żeby Ci się udało!