Projekt do portfolio

Wiele z was aby dostać się do branży myśli o projekcie do portfolio, który można umieścić w repozytorium np. na githubie i podzielić się nim w CV. Dzisiejszy wpis jest właśnie o takim projekcie – czy w ogóle warto, a jeżeli tak to jak taki projekt powinien wyglądać.

Czy projekt w CV to must have?

Nie. Czasami się przydaje, ale zdecydowanie rzadziej niż wydaje się kandydatom. Jeżeli aplikujecie do korpo lub firmy z dość ustrukturyzowanym procesem rekrutacyjnym to prawdopodobnie nikt nawet nie spojrzy do waszego repozytorium, ponieważ każda osoba ma z góry narzucone rzeczy/zadania/pytania które musi sprawdzić i to na tej podstawie podejmie decyzje. Rekruter przeglądający CV nie otworzy waszego projektu bo nie ma na to czasu i zazwyczaj nie jest osobą techniczną, a osoba techniczna oceni was na podstawie wcześniej ustalonych zadań. Znam osoby, które przeprowadzały rozmowy techniczne i wręcz specjalnie nie otwierały nawet CV kandydata żeby się nie sugerować tym co tam jest napisane.

Podstawą większości procesów rekrutacyjnych jest porównanie kandydatów między sobą – ciężko jest stwierdzić czy ktoś jest dobry tylko na podstawie jego własnego projektu, kiedy nie zna się dogłębnie danych, problemu i nie wiadomo ile czasu kandydat poświęcił na ten projekt. Dużo prościej ocenić poziom techniczny potencjalnego pracownika na podstawie hometasku, gdzie każdy dostaje takie same zadanie do zrobienia w tym samym czasie. Dokładne sprawdzenie techniczne tym bardziej się tyczy osób wchodzących do branży, które nie mają doświadczenia zawodowego jasno potwierdzającego co potrafią zrobić.

Oczywiście są firmy, które mogą bardziej polegać na projektach kandydatów, np. startupy które być może nie mają czasu i sprecyzowanych kroków rekrutacyjnych. Moim zdaniem jednak jest to rzadkość.

Czy ja bym dołączyła link do repozytorium do CV?

Nie. Nigdy tego nie robiłam. Moim zdaniem jest to zbędne i nikt na to nie patrzy.

Czy zatem nie robić projektów?

Robić, ale DLA SIEBIE, żeby się jak najwięcej nauczyć. Projekty są podstawą nauki, przede wszystkim w przypadku nauki MLa i gdy aplikuje się na DSa. Jeżeli jest to dla was bardziej motywujące i bardziej się postaracie, to róbcie projekt nawet do tego repozytorium, żeby umieścić link w CV. Po prostu nie oczekujcie, że dramatycznie zmieni on waszą sytuację rekrutacyjną, albo że jest on wymagany przez pracodawców.

Moim zdaniem lepszą opcją niż dodanie linka do repozytorium będzie wspomnienie o prywatnym projekcie już w CV i wytłumaczeniem na czym projekt polegał – aczkolwiek ma to sens tylko w przypadku, gdy jest o czym wspominać, czyli gdy projekt był na tyle rozbudowany, że zasługuje na odrębne miejsce w CV.

Mimo wszystko chcę zrobić projekt do CV

Analityk Danych

Jeżeli aplikujesz na juniorską pozycję analityka danych i celujesz w stanowisko związane z SQL i programem do wizualizacji to moim zdaniem projekt jest już całkowicie zbędny.

Repozytorium githuba to jest repozytorium kodu. Nie da się tam wrzucić dashboardu, który jest finalnym produktem tworzonym przez program do wizualizacji. Jasne, wiele takich programów opiera się na kodzie więc można by się uprzeć i wrzucić tam ten kod, ale oglądanie takiego czystego kodu bez wglądu do końcowego efektu jest… tutaj jest miejsce na jakąś trafną metaforę, która akurat nie przychodzi mi na myśl… po prostu jest bez sensu. To tak jakbyście się specjalizowali w robieniu stron internetowych i w portfolio mieli kod na zrobienie strony, zamiast pokazać właśnie tę stronę.

To samo z SQL – ciężko ocenić czysty kod SQL bez wiedzy jak wygląda baza danych. Diabeł tkwi w szczegółach, szczególnie w przypadku SQL gdzie czasami jeden warunek w WHERE albo specyficzny JOIN robi całą robotę. Można by sprawdzić czy ktoś ma dobre nawyki – pisze czysty kod lub używa CTE, ale ciężko będzie stwierdzić czy kod rzeczywiście jest poprawny np. że logika obliczeń jest prawidłowa bo żadna z tabel nie zawiera duplikatów.

Data Scientist

W przypadku data scientista historia jest trochę inna, ponieważ stanowisko to opiera się głównie na pythonie za pomocą którego możemy stworzyć pełnoprawny projekt w Jupyterze Notebooku. Jupyter jest środowiskiem pythonowym, które umożliwia sekwencyjne wykonywanie kodu wraz z pokazywaniem jego wyniku włączając w to wizualizacje. Za jego pomocą możemy stworzyć całą historię analizy – pokazać dane, zwizualizować je i przejść przez wszystkie potrzebne kroki. Dodatkowo możemy dodawać tekst, który pozwoli nam opisać co robimy i dlaczego. Notebook to taki raport tekstowo-kodowy, dlatego jest idealnym narzędziem do stworzenia projektu.

Btw, przykład jupytera notebooka został wysłany do odbiorców newslettera, dlatego zachęcam do dołączenia do grona odbiorców:

Cel projektu

Wiele osób błędnie zakłada, że projekt ma tylko udowodnić, że potraficie pisać kod. Albo że potraficie zbudować model MLa. Nie. Jeżeli już macie projekt, to można was ocenić na wielu płaszczyznach sprawdzając umiejętności:

  • pisania kodu
  • analizy danych, data science czy machine learningu
  • logicznego myślenia, wyciągania wniosków i stawiania rekomendacji
  • streszczania i wyciągania najważniejszych informacji
  • omówienia projektu i prezentacji

Jeżeli zatem coś w waszym projekcie leży to możecie więcej stracić niż zyskać. Niektórzy wychodzą z założenia, że jakikolwiek kod jest lepszy niż brak kodu, CO JEST ABSOLUTNYM BŁĘDEM. Aplikując na pozycję z pythonem jest oczywiste, że potraficie programować w pythonie. Projekt ma pokazać jak go umiecie, a nie, że go umiecie. Projekt, którym chwalicie się w CV powinien być odpicowany i pokazywać wasze maksimum umiejętności. Jeżeli już macie go w CV to osoba was rekrutująca oczekuje czegoś super, ekstra, czegoś czym warto się pochwalić – projek zbyt prosty, zawierający złe praktyki lub błędy naturalnie działa na waszą niekorzyść. Dlatego tym bardziej bym się zastanowiła czy ma to sens. Wiadomo, że na początku drogi te projekty mogą nie być jakieś najlepsze, co jest całkowicie zrozumiałe, ponieważ dopiero się uczycie. Pytanie czy jest to najlepszy czas na dzielenie się swoją wiedzą. 

Dalej chcę zrobić projekt

Ok. Według mnie dobry projekt:

1. Jest autorski

Projekt absolutnie nie powinien być kopią projektu z kursu! Czasami kursy udostępniają notebooki gdzie wymagają krok po kroku wykonania jakiś zadań. To nie jest wasz projekt tylko odtwórcza praca, której brakuje kluczowego aspektu – że jesteście w stanie poprowadzić projekt od początku do końca, od A do Z, że wiecie jak zrobić analizę krok po kroku. Projekt powinien być wasz, unikatowy i autorski.

2. Pokazuje to, co umiecie najlepiej

Nie da się ustalić odgórnie co powinno być waszym projektem – po prostu to, w czym czujecie się najlepiej. Może to być webscrapping, esploracyjna analiza danych, sieci neuronowe, szeregi czasowe, feature engineering. Po prostu coś, co jest waszym maksimum umiejętności i czym możecie się pochwalić. Tylko pamiętajcie, żeby to nie było na wyrost, tak, aby się nie okazało, że wasz kod zawiera błędy.

Czym się warto pochwalić:

  • dobrymi praktykami, np. pisaniem klas i funkcji w pythonie
  • nieoczywistym podejściem do analizy, np. nierandomowym podziałem danych na treningowe i testowe, target encoding zamiast one-hot encoding
  • radzeniem sobie z różnymi typami danych, np. przetrzennymi, czasowymi, tekstowymi
  • radzeniem sobie z „pułapkami”, np. duplikatami
  • wiedzą na temat analizy danych, data science i ML
  • umiejętnością wyciągania wniosków nie tylko na końcu, ale także w trakcie analizy. Kolejne kroki powinny wynikać z poprzednich.

3. Jest dobrze opisany

Opis to nie jest coś ekstra, opis to jest podstawa! Wy siedzicie w tym projekcie tygodnie, znacie go na wylot, ale osoba z zewnątrz pierwszy raz go widzi i ciężko jej zrozumieć co robicie i po co. Nikt nie ma czasu by się zastanawiać co autor miał na myśli. Dobry projekt powinien zawierać:

  • wstęp – po co robicie projekt, jaki jest cel, co chcecie uzyskać, streszczenie co projekt zawiera
  • komentarze prowadzące przez analizę – każdy krok powinien być robiony w jakimś celu, dlatego też każdy krok może być wyjaśniony. Nawet jeżeli wydaje się wam, że robicie coś oczywistego, typu usuwanie outlierów, to i tak warto napisać w jakim celu to robicie. Istnieją algorytmy odporne na outliery, więc nie trzeba tego kroku wykonywać za każdym razem – dlaczego zatem zdecydowaliście się go wykonać?
  • podsumowanie – wyniki, streszczenie całego projektu, wnioski, plany na przyszłość. Nawet mając wrażenie, że się powtarzacie, czasami warto jest powtórzyć pewnie kwestie kilka razy, szczególnie, jeżeli chcecie, aby było to zapamiętane.

4. Nie jest zbyt długi i powtarzający się

Ja wiem, że siedzieliście nad tym projektem tygodniami i TYLE TAM ZROBILIŚCIE. Wiem, że ciężko odrzucić lub zredukować swój własny kod. Sama mam cholerny problem z tym, że większość rzeczy idzie zazwyczaj do kosza. Ale na tym polega praca DA i DS – robi się 20 różnych wykresów aby odkryć, że 2 z nich mają sens. W projekcie zostawiamy właśnie te dwa. Skracanie projektu działa na waszą korzyść – nie ma sensu zostawiać zbędnych komórek, kodu, który nic nie wnosi lub wizualizacji, z których nic nie wynika.

Tak samo z powtarzającym się się kodem. Być może z punktu widzenia analizy powtarzający się kod lub powtarzająca się część projektu ma sens, ale, znowu, rekruter nie ma czasu. Jeżeli potraficie zrobić piękny wykres w seabornie, to powtórzenie tego samego wykresu 3 razy w trochę innej konfiguracji zabiera wam 3 „miejsca” na pochwalenie się czymś innym. Nie ma to żadnego sensu.

5. Nie zawiera błędów

 W DS i ML jest kilka „pułapek”, gdzie czegoś absolutnie należy albo nie należy robić, na przykład użycie niektórych algorytmów wymaga zeskalowania danych, a brak tego skalowania jest po prostu błędem. Warto, aby przed publikacją ktoś doświadczony rzucił na to okiem – najlepiej poprosić osobę pracującą na danym stanowisku o pomoc. Jeżeli nie znacie nikogo osobiście to możecie skorzystać z porad mentorów, których możecie znaleźć na dedykowanych grupach facebookowych (ja także udzielam takich konsultacji -> kontakt@crappydata.pl ).

6. Jest po angielsku

Myślę, że nie wymaga to komentarza. To jest branża, w której pracuje się po angielsku, dlatego projekt (i CV) powinno być w tym języku (i dlatego ja piszę bloga po polsku).

Czy jest sens posiadania kilku projektów?

Ta sama zasada -> nie ma się co powtarzać. Jeżeli każdy projekt jest inny i pokazuje całkowicie inną analizę, np. jeden dotyczy NLP, a drugi computer vision, to śmiało można stworzyć dwa odrębne notebooki. Jeżeli jednak projekty są do siebie podobne to nie ma sensu spamować. W przypadku posiadania kilku projektów warto też wybrać projekt flagowy i upewnić się, że to w nim wyląduje w pierwszej kolejności rekruter.

Jak wyróżnić swoją kandydaturę jak nie projektem

Dalej nie wiem jak taki projekt ma wyglądać

Jeżeli absolutnie nie macie pojęcia co zawrzeć w takim projekcie to polecam klasykę MLa czyli:

  1. Eksploracyjna analiza danych – sprawdzenie danych, duplikatów, targetu, kilka wizualizacji
  2. Przygotowanie danych pod machine learning
  3. Liniowy model ML stanowiący baseline, np. linear regression, logistic regression
  4. Nieliniowy model ML, np. random forest lub xgboost
  5. Hyperparameter tuning

Jeżeli chcecie projekt poza ML to:

  1. Postawienie problemu do rozwiązania
  2. Esploracyjna analiza danych – wizualizacje, statystyki, stawianie hipotez i ich sprawdzanie
  3. Testy statystyczne

Podsumowanie

  • moim zdaniem projekt w CV jest zbędny, ponieważ rzadko jest sprawdzany przez rekruterów a w dodatku może działać na naszą niekorzyść
  • projekty mimo wszystko warto robić, ale dla siebie, aby nauczyć się analizy i DS
  • projekt powinien być autorski, unikatowy i zawierać wasze the best of the best
  • projekt powinien być dobrze opisany, nie być zbyt długi oraz nie zawierać błędów

Spróbuję w następnych postach przygotować dla was przykład projektu z ML (ustaw przypomnienie!)

Jakie jest wasze doświadczenie z projektami w CV? Pomagają, nie pomagają? Zmieniają coś w rekrutacji?

1 thought on “Projekt do portfolio”

Comments are closed.