Mateusz Mazurek – programista z pasją

Blog o Pythonie i kilku innych technologiach. Od developera dla wszystkich.

Felietony/inne Inne Programowanie

Co powinien umieć Junior Python Developer

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:
a w ramach prezentu otrzymasz całkowicie za darmo, dwa dokumenty PDF „6 (nie zawsze oczywistych) błędów popełnianych podczas nauki programowania” który jest jednym z efektów ponad siedmioletniej pracy i obserwacji rozwoju niejednego programisty oraz „Wstęp do testowania w Pythonie”, będący wprowadzeniem do biblioteki PyTest.
Jeśli to Cię interesuje to zapraszam również na swoje social media.

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.

Dzięki za wizytę,
Mateusz Mazurek

A może wolisz nowości na mail?

Subskrybuj
Powiadom o
guest

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

0 komentarzy
Inline Feedbacks
View all comments