Dzisiejszy post tłumaczy jak wykonać hometask, czyli zadanie rekrutacyjne sprawdzające umiejętności techniczne kandydata, które jest wykonywane offline poza rozmową rekrutacyjną.
Jak wygląda hometask?
Istnieją różne formy sprawdzenia umiejętności technicznych kandydata podczas rekrutacji na pozycję analityka danych lub data scientist. Sprawdzenie może mieć miejsce podczas rozmowy rekrutacyjnej zadając pytania techniczne lub prosząc o napisanie kodu, lub wykorzystując formę offline, tzw. hometask, czyli zadanie, które wykonuje się bez nadzoru we własnym czasie.
Sam hometask może mieć przeróżne formy, zarówno jeżeli chodzi o to, co trzeba zrobić, jak i czas jego wykonania.
W rekrutacji na analityka danych lub data scientist zadanie jest zazwyczaj powiązane z danymi (what a suprise!). Dane dostarczane są przez firmę, a samo zadanie… zależy od firmy (another suprise!). Może być w formie zamkniętych pytań (odpowiedzenie na konkretne pytania za pomocą SQL lub pythona) lub w formie otwartej (zbudowanie modelu uczenia maszynowego, dashboardu, root cause analysis). Czasami dodatkowo trzeba zrobić prezentację lub zaproponować coś w formie pisemnej (np. zaproponować KPIs).
Może to być zadanie, na które mamy ograniczoną ilość czasu, np. musimy je odesłać w przeciągu 3 godzin po jego otrzymaniu, a może to być zadanie na “nieograniczony” czas, kiedy sami decydujemy ile spędzimy nad nim godzin. Nieograniczony w cudzysłowie ponieważ mamy na niego zazwyczaj tydzień, ale to już my decydujemy czy spędzimy nad nim 3, 10 czy 20 godzin.
Artykuł pokrywa jak rozwiązać zamknięte zadania, stworzyć otwartą analizę, przygotować prezentację oraz podejść do zadania, gdy czas jest ograniczony. Artykuł NIE pokrywa tematu jak zbudować dashboard oraz jak zaprezentować hometask na kolejnej rozmowie rekrutacyjnej, ponieważ tematy te są/będą poruszone w osobnych postach.
Zamknięte zadanie
Czasami hometask polega na odpowiedzeniu na zamknięte pytania za pomocą kodu w SQL lub w pythonie. Są to zadania stosunkowo proste do wykonania, ponieważ mamy jasne wytyczne co mamy napisać. Aby wykonać je dobrze należy:
- Upewnić się, że wszystkie warunki z polecenia zostały spełnione. Czasami w pytaniu jest napisanych kilka warunków i przez niedopatrzenie możemy przypadkowo pominąć jeden z nich. Pominięcie jakiegokolwiek warunku jest bardzo dużym błędem. Celem tego zadania jest nie tylko sprawdzenie umiejętności pisania kodu, ale także zdolności czytania ze zrozumieniem i zwracania uwagi na szczegóły. Możesz przy czytaniu polecenia wypisać sobie wszystkie warunki i po kolei je odhaczać podczas pisania kodu, aby mieć pewność, że o niczym nie zapomnisz. Na przykład pytanie „ile zrealizowanych zamówień produktów z kategorii elektroniki zostało wykonanych w każdym miesiącu 2022 roku” ma 3 warunki zamówień: 1) muszą być zrealizowane, 2) pochodzą z kategorii elektroniki, 3) są z 2022 roku.
- Sprawdzić czy wynik jest prawidłowy. Spójrz na końcowe cyfry i upewnij się, że nie są podejrzanie małe lub duże. Porównaj wynik z prostymi kalkulacjami, np. poszczególne miesiące powinny się sumować do całego roku, a ilość zamówień z kategorii elektroniki powinna być mniejsza niż suma wszystkich kategorii.
- Zadbać o czysty kod oraz poprawne użycie funkcji.
Otwarte zadanie
Otwarte zadanie to zadanie, które może zostać wykonane w różny sposób. Może to być na przykład zbudowanie modelu uczenia maszynowego przewidującego podejrzane transakcje. Chociaż takie polecenie precyzuje co należy zbudować, to nie precyzuje jak to należy zrobić, dając nam dowolność w przygotowaniu danych, użycia różnych algorytmów ML, decyzyjność oceny modelu itd.
Czas
Zacznijmy od tego ile czasu planujesz poświęcić na dokonanie zadania. Czasami firmy informują, ile mniej więcej czasu powinno zająć zadanie, albo ile rekomendują na jego poświęcenie. Z mojego doświadczenia wynika, że to zawsze jest BARDZO optymistyczne założenie i prawdopodobnie spędzimy nad nim DUŻO więcej czasu. I to nie jest różnica 20%, ale nawet 2-3x więcej czasu niż zakładają firmy.
Otwarte zadania mają to do siebie, że im więcej czasu im poświęcimy tym zazwyczaj lepiej je zrobimy. Ile zatem przeznaczyć tego czasu? Moim zdaniem minimum, aby zaimponować. Minimum, aby wykazać, że potrafimy poprawnie podejść do problemu, znamy dobre praktyki i zagrożenia, potrafimy napisać dobry kod i radzimy sobie z różnymi typami problemów. Nie musimy zbudować najlepszego modelu ever, przeanalizować wszystkich możliwości czy zbudować prawdziwy kompletny dashboard – mamy „tylko” pokazać nasz tok myślenia i przejść do kolejnego etapu. Jak to się przekłada na liczbę godzin? Dokładną odpowiedź na to pytanie zostawiam już dla ciebie, ponieważ zależy ile czasu jesteś w stanie poświęcić, jak bardzo ci zależy i jak dokładnie przykładasz się do pracy. Z mojej strony za to polecam mierzyć dokładny czas, aby wiedzieć ile godzin ci to zajęło i chociażby wykorzystać tę wiedzę w planowaniu kolejnych rekrutacji.
Wstęp
Zacznij od dokładnego zapoznania się z opisem zadania. Zrozum co jest jego głównym założeniem, wypisz sobie kluczowe punkty oraz co trzeba dostarczyć i w jakiej formie. Ważne jest, żeby niczego nie zapomnieć, a w trakcie robienia zadania nie odpłynąć od głównej wizji w całkowicie innym kierunku. Ja sama kilkukrotnie w trakcie pracy nad hometaskiem wracam do czytania opisu i do wypisanych przeze mnie kluczowych punktów w notatkach, aby nagle się nie okazało, że pominęłam na początku jakiś warunek i brnę z analizą na złych danych. Czasami jakieś założenie jest napisane tylko w dwóch słowach i naprawdę łatwo je przeoczyć, a wpływa on znacząco na dane, na których działamy.
Spróbuj wyłapać z opisu na czym firmie najbardziej zależy. Na aspekcie technicznym? Biznesowym podejściu? Jakiejś szczególnej technice? Czystym kodzie? Na co zwracają uwagę? Skup się na tym, co najważniejsze, ale miej z tyłu głowy, że hometask jest z reguły sprawdzeniem technicznym i to na tym aspekcie powinniśmy skupić się najbardziej. Jeżeli zadanie wymaga zrobienia zarówno analizy w pythonie jak i prezentacji, to sama analiza jest dużo ważniejsza niż prezentacja, na którą wystarczy poświęcić ok. 5-10% czasu.
Analiza w pythonie
Często zadanie polega na napisaniu kodu w pythonie w jupyterze notebooku. Jak podejść do takiej analizy?
- Zacznij od sprawdzenia danych. Upewnij się, że rozumiesz, co reprezentuje każda kolumna. Zobacz czy zestaw danych nie zawiera duplikatów. Następnie sprawdź każdą kolumnę: jakie ma wartości, czy ma outliery, czy zawiera nieprawidłowy typ danych, czy istnieją nieprawidłowe wartości. Posprzątaj dane jeżeli tego wymagają i zamień typy danych na prawidłowe.
- Krok po kroku wykonaj zleconą analizę. Jeżeli jest to tzw. root cause analysis, czyli analiza szukająca przyczyny jakiegoś problemu (np. spadku przychodów w firmie), to na początku potwierdź ten problem, a następnie po kolei twórz hipotezy zakładające możliwą przyczynę problemu i sprawdzaj te założenia w danych. Pamiętaj, że każdy kolejny krok ma być logiczną konsekwencją poprzedniego, a całość ma tworzyć spójny sensowny ciąg. Po każdej sekcji wyciągaj wnioski. Pamiętaj o ubraniu całej analizy w storytelling – ma ona tworzyć dobrze opowiedzianą historię ze wstępem, rozwinięciem i zakończeniem.
- Przyjmuj założenia. Z racji tego, że w pracy DA czy DS rzadko kiedy wszystko jest jasne lub dostępna jest pełna dokumentacja, praca na tych stanowiskach często polega na przyjmowaniu założeń – podobne zjawisko może mieć miejsce podczas hometasku. Jeżeli coś w danych jest bardzo niejasne albo wygląda naprawdę podejrzliwie (np. obawiasz się, że dane są niekompletne), to możesz napisać do pracodawcy z prośbą o wyjaśnienie, ale jednak większość przypadków nie wymaga kontaktu tylko podjęcia decyzji przez ciebie i przyjęcia określonych założeń. Pamiętaj tylko, żeby wytłumaczyć dlaczego je przejmujesz, np.: „Z racji tego, że transakcje o statusie 'cancelled’ stanowią tylko 0.5% transakcji i nie mają znacznego wpływu na analizę, decyduję się je usunąć. Gdyby taka sytuacja miała miejsce w pracy to skonsultowałabym te transakcje z product ownerem.”
- Dodaj duuuużo komentarzy tłumaczących twój ciąg myślowy. Dobra analiza to świadoma analiza, dlatego na bieżąco informuj odbiorcę dlaczego decydujesz się na poszczególne kroki. Dlaczego usuwasz duplikaty? Dlaczego sprawdzasz zależność między transakcjami a krajami klientów? Dlaczego wnioskujesz, że istnieją zależności między kolumną X i Y? Jeżeli odbiorca analizy ma wrażenie, że jest ona prosta, logiczna i spójna, to wykonała/eś dobrą robotę, a nic tak nie ułatwia jej odbioru niż poprowadzenie przez analizę dobrymi komentarzami. Odbiorca nie powinien mieć trudności w jej zrozumieniu i zastanawiać się, dlaczego akurat postawiła/eś na ten krok czy użyła/eś takiej funkcji.
- Wykaż się. Pokaż co potrafisz. Udowodnij szeroki zakres posiadanych umiejętności. Jeżeli kolumny mają różny typ danych: dane numeryczne, kategorialne, czasowe i tekstowe, to pokaż, że jesteś w stanie poradzić sobie z każdą kolumną. Przetwarzaj dane na różne sposoby. Twórz wiele rodzajów wykresów. Wyciągaj wnioski raz z wizualizacji, raz z podsumowań numerycznych. Używaj fancy funkcji, np. stwórz mapę dla danych geograficznych używając biblioteki folium.
- Dodaj coś nadprogramowego. Pokaż, że potrafisz coś więcej niż to, co zazwyczaj jest wymagane. Nie mam tutaj na myśli marnowania czasu na porywanie się z motyką na słońce (np. budowania sieci neuronowej zamiast zwykłej analizy danych), ale dodania jakiegoś drobiazgu, który niby nie jest wymagany, ale robi robotę. Dobrym przykładem jest dodanie prostego testu statystycznego – wymaga to niewiele wysiłku, a pokazuje, że wiemy jak naukowo potwierdzić różnice między grupami.
- Automatyzuj. Jeżeli twój kod się powtarza to czas na automatyzację. Napisz kod raz zamykając go w funkcji albo klasie, którą użyjesz kilka razy.
- Opisz co byś zrobił(a), gdyby było więcej czasu. Z racji minimalizacji czasu i wysiłku nie jesteś w stanie zrobić wszystkiego, zatem jak masz jakiś dobry pomysł, którego nie masz czasu realizować, to opisz go słownie w komentarzu.
- Kolejne punkty należy wykonać zbliżając się do końca analizy…
- Sprawdź ponownie opis zadania i upewnij się, że niczego nie zapomniała/eś.
- Uprzątnij analizę. Ja wiem, że jej napisanie wymagało tyle kodu, tyle pracy i tyle wysiłku i najchętniej to byś zostawił(a) wszystko! Ale więcej nie znaczy lepiej, a w analizie danych bywa wręcz odwrotnie. Tworząc analizę zawsze się pisze więcej kodu niż jest to wymagane, a częścią pracy jest końcowe odsianie tego, co nie jest istotne. Zostaw tylko najważniejszy kod – każdy fragment czy wykres ma coś wnosić do historii.
- Uprzątnij kod i wykresy. Podpisz wszystkie osie i dodaj tytuły na wizualizacjach.
- Dodaj wstęp i zakończenie. We wstępie przedstaw problem i wypunktuj zawartość notebooka. W zakończeniu przypomnij co zrobiła/eś, napisz podsumowanie, wyciągnij wnioski oraz zasugeruj co można zrobić dalej w formie konkretnych punktów, a nie lania wody typu „dalsza, bardziej dogłębna analiza”.
- Sprawdź angielski w opisach z grammarly.
- Uruchom wszystkie komórki w notebooku od nowa, aby mieć pewność, że kod wykonuje się tak jak jest napisany. Kliknij
Kernel->Restart & Run All. Końcowy plik powinien mieć kod wykonany w tej samej kolejności co jest napisany w poszczególnych komórkach.
Prezentacja
Tak jak już wspominałam między wersami wyżej, sama analiza jest dużo ważniejsza niż prezentacja, więc nawet gdy zadanie wymaga prezentacji w powerpoincie, to można ją potraktować raczej jako dodatek do całości. Ale i tak nie znaczy to, że warto ją olać i zrobić ją źle 🙂
Prezentacja powinna podsumowywać to, co pokazuje analiza w formie storytellingu, czyli dobrze opowiedzianej historii. Zaczynamy od wstępu jako przedstawienia problemu, a każdy kolejny slajd to poprowadzenie przez analizę. Tytuł slajdu powinien zaznaczać kolejny aspekt badanego problemu, a w jego treści pokazujemy wyniki w formie wykresów. Można czasami dodać tabelę, ale wykres mówi więcej niż tysiąc słów tabel. Przy wykresach pamiętaj o jednostkach, podpisaniu osi i tytule wykresu. Możemy też dodać kluczowy tekst lub wnioski, ale nie warto dodawać absolutnie wszystkiego co zamierzamy powiedzieć.
Slajdy w powerpoincie nie są same z siebie kompletną formą – zawsze są uzupełniane przez prezentację prowadzącego. Dlatego slajd ma tylko podsumowywać treść mówioną. Tytuł służy poprowadzeniu narracji. Jeżeli ktoś się zawiesi i przestanie nas słuchać, to powinien wrócić do tematu na podstawie tytułu slajdu. Wykresy czy tabele potwierdzają nasze tezy, a dodatkowy tekst podkreśla główne wnioski.
Prezentacje kończymy wnioskami, take-home message i informacjami, co by można zrobić dalej.
Ograniczony czas
Omówmy na końcu przypadek, gdy czas na wykonanie zadania jest bardzo ograniczony, np. musimy go odesłać w przeciągu 3h od jego dostania. Warto w tej sytuacji jednak trochę inaczej podejść do analizy, ponieważ nie mamy nieograniczonego czasu na sprawdzanie danych, zastanawianie się nad problemem czy zostawienie sprzątania dopiero na koniec.
Kluczowe w takim przypadku jest właściwe rozplanowanie czasu. Mimo że przed dostaniem zadania dokładnie nie wiemy, co jest do zrobienia, to już wtedy możemy narzucić sobie rygor ile czasu poświęcimy na jaką jego część. W mojej opinii kluczem do sukcesu jest założenie „najgorszego” i wkalkulowanie czasu na błędy. Nie możemy dopuścić do sytuacji, gdy minęło 85% czasu, a my nadal męczymy się z napisaniem jakiejś funkcji. To od nas zależy czy dopuścimy do takiej sytuacji i przez to przegramy z czasem. Lepiej zrobić mniej, ale dokończyć to co mieliśmy zrobić i oddać kompletne, zamknięte zadanie.
Przykład rozplanowania czasu na 3h zadania:
- 0 – 30 minut: Zapoznanie się z opisem zadania i danymi, sprawdzenie czy rozumiemy co reprezentuje każda kolumna i jaki jest poziom agregacji danych. Ewentualne sprawdzenie poprawności danych, ale można to zostawić na kolejne etapy.
- 30 minut – 1.5h: Praca nad analizą oraz pierwszymi opisami kodu. Kod staramy się pisać na czysto (3h to za mało czasu, żeby go później przepisywać). Na piękne opisy przyjdzie jeszcze czas, ale warto przynajmniej dodać opisy na brudno, żeby nie marnować później czasu na odnalezienie się w logice kolejnych kroków.
- 1.5h – 2h: Upewnienie się, ze odpowiedzieliśmy na wszystkie zadane pytania i niczego nie brakuje. Posprzątanie kodu, ewentualnie poukładanie lub posprzątanie całej analizy. Dodanie opisów w pełnych zdaniach. Dodanie wstępu i zakończenia.
- 2h – 2.5h: Finalne przejście przez analizę. Upewnienie się, że nie ma żadnych błędów, ostatnie poprawki w opisach.
- 2.5h – 3h: Odesłanie analizy.
Plan może wydawać się nieco rygorystyczny, bo tak naprawdę na główną analizę i pisanie kodu dajemy sobie tylko połowę czasu – kończymy go po 1.5 godziny. Ale to jest właśnie plan, który daje przestrzeń na błędy. Jeżeli w opisie zadania znajduje się coś, czego zapomnieliśmy zrobić, to mamy jeszcze czas, żeby to dodać. Jeżeli przy układaniu całej analizy stwierdzimy, że brakuje fragmentu kodu do jej dopełnienia, to także możemy to zmienić. Jeżeli wyłapiemy jakiś błąd w kodzie, to można go jeszcze naprawić. Nie wystarczyłoby na to czasu, gdyby dopiero 20 minut przed deadlinem zaczęlibyśmy sprawdzać powtórnie opis zadania, aby upewnić się, że wszystko zawarliśmy. Albo gdy w ostatnich 10 minutach stwierdzilibyśmy, że warto dopisać na końcu wnioski. Kompletny i zamknięty hometask jest lepszy, niż idealny hometask skończony w 75%.
Ten plan zakłada, że nie produkujemy kodu jak leci, tylko tworzymy kompleksową analizę – logiczną, spójną, łatwą do odbioru poprzez komentarze, ze wstępem, rozwinięciem i zakończeniem.
Podsumowanie
Opowiedzieliśmy sobie jak wygląda hometask, jak podejść do zamkniętych pytań i otwartego zadania, jak zrobić prezentacje i rozplanować zadanie w ograniczonym czasie.
W kolejnych postach poruszę temat jak zrobić hometask w formie dashboardu (już jest!) oraz jak zaprezentować prezentację z hometaska na kolejnej rozmowie, co często jest kolejnym etapem rekrutacji po otwartym zadaniu. Jeżeli interesuje cie tematyka rekrutacji to na blogu już znajdziesz dużo postów na ten temat w kategorii rekrutacja.
Aby dostać powiadomienie o nowym poście zapraszam do subskrypcji newsletteru. Gwarantuje to także dostanie dodatkowych, nigdzie indziej nie publikowanych materiałów, np. przy okazji powiadomienia o tym poście było podsumowanie wszystkich hometasków, które ja dotychczas musiałam wykonać.
Keywords: hometask, rekrutacja data scientist, rekrutacja analityk danych, rekrutacja analityk, data scientist, analityk danych, jak zostać analitykiem danych, jak zostać data scientist, jak zostać data science, data science – jak zacząć, data scientist – jak zacząć, jak znaleźć pracę w data science, data scientist jak zostać, analityk danych jak zostać, data science od podstaw, analiza danych od podstaw, data science rekrutacja, data science hometask, data science zadanie, data science zadanie rekrutacyjne, data science kurs, data scientist pytania rekrutacyjne, analityk danych pytania rekrutacyjne, junior data scientist pytania rekrutacyjne, data scientist zadanie rekrutacyjne, praca data scientist, data scientist czym się zajmuje, data scientist cv, data scientist jak zacząć, data scientist opis stanowiska, data science polska, co to data science, co do data scientist, data scientist obowiązki,