Jak opowiadać o projekcie analitycznym na rekrutacji

Jak pracowałam jako analityk danych miałam te ogromne szczęście, że byłam osobą rekrutującą innych analityków danych. Siedzenie po drugiej stronie dało mi wiele więcej niż wszystkie rekrutacje przez które ja przechodziłam – byłam w stanie zobaczyć jak ludzie reagują na stres, jak sobie radzą z mniej i bardziej typowymi pytaniami, co powoduje u nich zakłopotanie czy jakie błędy najczęściej popełniają. Po kilkunastu rozmowach zauważyłam, że feedback, który im dostarczam zaczyna się powtarzać – wiele osób popełniało w kółko te same błędy. Nie raz sobie wtedy myślałam, że kurczę, gdybym tylko mogła to wszystko spisać i raz, a porządnie wytłumaczyć co robią nie tak…

W dzisiejszy poście omówimy sobie jak odpowiadać na pytanie:

opowiedz mi o analitycznym projekcie, w którym brałaś/eś udział

Było to pytanie, na którym skupiał się mój etap rekrutacyjny, i pytanie, które pojawia się w prawie każdym procesie rekrutacyjnym. Czasami jest to błahe pytanie na rozgrzewkę, ale często się zdarza, że jest to poważne pytanie decydujące o twoim być albo nie być w danej organizacji.

Uwaga! post jest moją subiektywną opinią jak należy odpowiadać na to pytanie. Inne osoby rekrutujące lub rekrutowane mogą mieć inną opinię na ten temat. Kilka faktów nakreślających moją wizję:

• rekrutowałam tylko na stanowisko analityk danych, na wszystkie poziomy (od juniora do leada)
• przeprowadziłam w sumie kilkadziesiąt rekrutacji z osobami z całego świata
• przeprowadzałam rozmowę techniczną, nie biznesową (wytłumaczę to rozróżnienie w poście)
• rekrutowałam do różnych zespołów do całej firmy. Nie były to osoby, z którymi miałam bezpośrednio pracować lub miały być częścią mojego zespołu, więc byłam osobą neutralną – nie miałam żadnego interesu w tym, aby kogoś na gwałt zatrudnić, albo też żeby kogoś odrzucać, bo mi się osobiście nie spodobał
• cały proces starania się o pracę był wieloetapowy, zawierał wiele etapów technicznych i biznesowych, a każdy z nich był eliminacyjny. Przejście przez nie wszystkie nie było łatwe i dużo osób odpadało. Poprzeczka była postawiona dość wysoko
• miałam pełną decyzyjność kto przechodzi, a kto odpada na mojej części. Nigdy nie było żadnej presji z góry, zacieśniania lub luzowania zasad aby manipulować liczbą przechodzących osób.

Podsumowując, cały proces był trudny, a moją rolą była jedynie (jak najbardziej) obiektywna ocena umiejętności analitycznych kandydata.

Przejdźmy sobie przez 6 najważniejszych punktów, a na końcu omówmy, które z błędów się najczęściej powtarzały i co mnie najbardziej irytowało.

1. Odróżnij osoby biznesowe od technicznych

Poznaj background swojego interlokutora przed rozmową. Podejście do osób biznesowych oraz do osób technicznych całkowicie się różni. Kwestia, czy rozmówca jest osobą biznesową czy techniczną jest kluczową wiedzą. Osobie biznesowej zależy na zrozumieniu twojej motywacji, wiedzy o biznesie, umiejętności zarządzania projektem czy zdolnością komunikacji. Osoba techniczna ma za zadanie ocenę twoich konkretnych umiejętności technicznych, np. umiejętności analitycznych, pisania kodu w SQL czy ocenę wiedzy o narzędziach do wizualizacji danych.

Powinniśmy inaczej opowiadać o projekcie gdy rozmawiamy z osobą biznesową i techniczną. Przy rozmowie technicznej skupiamy się na szczegółach, narzędziach, językach programowania. Rozmowa biznesowa nie powinna wchodzić w taki poziom detali – w niej bardziej liczy się kontekst biznesowy, umiejętność łatwego wytłumaczenia projektu czy końcowy wpływ na firmę.

Jak się dowiedzieć do której grupy należy wasz rozmówca? Spytajcie rekrutera, który was przeprowadza przez cały proces, albo wygooglujcie / wylinkedinujcie imię i nazwisko umówionej osoby.

2. Bądź przygotowany

Ciężko jest przejść pomyślnie przez to zadanie, gdy nie jesteśmy do niego przygotowani.

Co powinniśmy przygotować PRZED dyskusją:

• Z kim będziemy rozmawiać (punkt 1)
• Powinniśmy wiedzieć, ile czasu będzie poświęcone naszemu projektowi. Czasami jesteśmy zapytani o projekt tylko jako rozruch na początek, a czasami całe spotkanie się na tym opiera. Inaczej opowiadamy o projekcie przez 3, 5, 10 lub 20 minut. Powinniśmy się przygotować na wszystkie te opcje. Przećwiczcie sobie w domu na sucho głośne opowiadanie o projekcie w każdym wariancie czasowym. Jeżeli jesteście w trakcie rozmowy i nie macie pojęcia jak długiej odpowiedzi się od was oczekuje, po prostu zapytajcie waszego rozmówcę.
• Dobry projekt

Co tzn. dobry projekt:

• analityczny – związany z analizą danych lub data science
• dopasowany do roli na którą aplikujecie – inny projekt na DA/DS, juniora/leada
• skomplikowany lub nietuzinkowy
• wielowymiarowy, pokrywający wiele technicznych zagadnień
• projekt przy którym możecie się wykazać: umiejętnościami analitycznymi, wiedzą o narzędziach, niestandardowym podejściem, logicznym myśleniem lub proaktywnością
• który rzeczywiście robiłaś/eś! Nie który chciał(a)byś zrobić lub robili twoi podwładni.

Ok, pewnie to wszystko razem wzięte brzmi jak doktorat z fizyki jądrowej, ale nie musicie spełniać od razu wszystkich wymagań, bardziej zmierzać w ich kierunku. Po prostu nie mówcie o pierwszym lepszym zadaniu, które robiliście tydzień temu. Co mega istotne, ważniejsza od samego projektu jest jego prezentacja. Nie istnieje projekt skreślający was na samym początku. Ale opisywanie i wybronienie dobrze wybranego projektu jest dużo prostsze, niż wybranie projektu banalnego i niezbyt dopasowanego.

3. Struktura wypowiedzi

Opowiadanie o projekcie jest jak prezentacja – powinno mieć wstęp, rozwinięcie i zakończenie.

Wstęp: Nakreślenie celu projektu, kontekstu biznesowego czy jego historii. Weźcie pod uwagę, że wy pracowaliście nad projektem tygodnie/miesiące, a wasz(a) interlokutor(ka) słyszy ten temat po raz pierwszy. Bądźcie pewni, że dobrze tę osobę wprowadzicie, ponieważ łatwiej będzie jej zrozumieć kolejne części.

Rozwinięcie: Główna część, powinna trwać najdłużej. Omówiona w kolejnym punkcie.

Zakończenie: Podsumowanie, w jaki sposób były dostarczone wyniki (prezentacja, dashboard, spotkanie ze stakeholderami), określenie stopnia zakończenia projektu (zakończył się, wciąż trwa, był kontynuowany w innej formie/przez inną osobę), wpływ na firmę (co zmienił w organizacji i jakie korzyści biznesowe przyniósł).

4. Opowiadanie o projekcie

Główną zawartością waszej wypowiedzi jest przedstawienie krok po kroku analizy. Waszym celem jest udowodnienie co potraficie zrobić, jakie znacie narzędzia/programy i czy poprawnie ich używacie.

Błędem jest powierzchowne przedstawienie tylko koncepcji, kroków i celów analizy. Powinniście skupić się na szczegółach technicznych, narzędziach, programach, językach programowania, funkcjach i algorytmach. Spróbujmy to zrozumieć za pomocą przykładów:

PRZYKŁAD 1

ŹLE: Przeprowadziłam analizę służącą do określenia KPI dla najnowszych produktów.

Jaką analizę? W jakim programie lub języku programowania? Skąd wziałaś dane? Jak je zimportowano?

DOBRZE: Dane wyciągnęłam za pomocą języka SQL z relacyjnej bazy danych. Zostały one zimportowane za pomocą plików csv do środowiska jupyter notebook, aby przeprowadzić analizę w pythonie. Analiza została w głównej mierze przeprowadzona w bibliotece pandas.

PRZYKŁAD 2

ŹLE: Przygotowałem dane, a następnie na ich podstawie stworzyłem dashboard.

Skąd miałeś dane? Jak je przygotowałeś? W czym to zrobiłeś? Jak zimportowałaś dane do dashboardu? W jakim programie zrobiłeś dashboard? Co on pokazywał?

DOBRZE: Za pomocą języka SQL przygotowałem dane z relacyjnych baz danych – określiłem ilość brakujących rekordów i zastąpiłem je średnią. Gotowe dane zapisałem w formie tabeli, która następnie została podłączona pod Tableu. W Tableau stworzyłem dashboard, który zawierał sekcję z zagregowanymi danymi z zeszłego tygodnia, trendy czasowe oraz szczegóły projektu.

Na co szczególnie zwracać uwagę? Najbardziej liczy się poziom umiejętności technicznych, nietuzinkowość oraz proaktywność! Jeżeli jakakolwiek część waszego projektu była bardziej złożona, podeszliście do niej w nietypowy sposób albo wykazaliście się wyjątkowym zapałem, powiedźcie o tym!

Szczegóły techniczne są ważne, ale nie możemy zapomnieć o zachowaniu równowagi między szczegółem a ogółem. Analityk danych musi być w stanie piorytetyzować i wyciągnąć najważniejsze informacje – więc z jednej strony skupiamy się na detalach, ale z drugiej mamy cały czas z tyłu głowy ogólny cel i zarys projektu. Za duży poziom niuansów jest równie niewłaściwym podejściem co nieopowiadanie o nich wcale. Jak zbudowaliście dashboard, to nie musicie wymieniać po kolei zawartość osi x i y każdego wykresu – powiedźcie jakie sekcje zawierał, czemu one służyły lub jakie tematy pokrywały.

Jak to pogodzić te wszystkie szczegóły, ogóły, nietuzinkowość i tykający czas? Nie opowiadając o KAŻDEJ zrobionej części projektu, ale bacznie wybierając z niego jedynie najważniejszą kwintesencję. Ja wiem, że wy tyle pracowaliście, tyle się narobiliście i chcecie opowiedzieć o wszystkim. Ale działa to na waszą niekorzyść. Nie jesteście w stanie opowiedzieć o wszystkim, więc musicie wybrać jeden fragment, na który poświęcicie najwięcej uwagi.

DOBRZE: mój projekt był wielowymiarowy, zawierał eksplorację oraz przygotowanie danych, przygotowanie zagregowanych tabel oraz finalnego dashboardu. Z racji ograniczonego czasu, chciałabym się przede wszystkim skupić na elemencie przygotowania danych…

5. Pytania od rekrutera

Może to co teraz napiszę będzie wydawać się banalne, ale gdyby takie było to bym nie musiała o tym pisać 🙂

Słuchajcie dokładnie pytań osoby was rekrutującej.

Nie zakładajcie o co będziecie pytani albo nie próbujcie zaczynać odpowiadać w połowie niedokończonego pytania – zaczekajcie do końca i bądźcie pewni, że dokładnie zrozumieliście jego sens.

Nie macie pojęcia jak wiele osób nie słucha uważnie swoich interlokutorów. Ja się spotykałam NAGMINNIE z sytuacją, że otrzymywałam odpowiedź na pytanie, którego nie zadawałam. Przede wszystkim miało to miejsce przy zapytaniach typu „dlaczego” – być może wynika to z faktu, że pytanie w stylu „dlaczego użyłaś/eś tej funkcji” nie jest czymś, czego spodziewali się pretendenci, ale rzeczywiście była to rzecz, o jaką pytałam.

 Jak ktoś pyta „jak”, to nie pyta „dlaczego”. Co istotniejsze, jak ktoś pyta „dlaczego”, to nie obchodzi go „jak”.

Po prostu słuchajcie rozmówcę. 

Jak dobrze odpowiadać na pytania?

Precyzyjnie. Jeżeli pytanie jest o źródło waszych danych, wystarczy prosta odpowiedź „relacyjna baza danych”. Nie musicie tworzyć elaboratu jak te dane były stworzone i opisywać po kolei każdą tabelę. Oczywiście, mogą pojawić się też bardziej rozbudowane zapytania, wtedy odpowiedzi także powinny być bardziej rozbudowane, ale powinny one cały czas dotyczyć konkretnego tematu.

Uważne słuchanie pytań jest także kluczowe, gdy wasza prezentacja projektu nie jest tym, czego się od was oczekuje – np. gdy opowiadacie zbyt pobieżnie o swojej analizie. Często w takich sytuacjach pracownik próbuje was naprowadzić na właściwy trop – jesteście w stanie z tego wybrnąć tylko wtedy, gdy słuchacie uważnie pytań i odpowiednio na nie reagujecie.

Pytania typu dlaczego

Zdecydowanie moja ulubiona część rozmowy, a do tego niesamowicie istotny sprawdzian dla pretendenta. Jeżeli pytanie zaczyna się od słowa „dlaczego”, np:

• Dlaczego używałeś excela?
• Dlaczego postanowiłaś użyć algorytmu Random Forest?
• Dlaczego twoim kolejnym krokiem w analizie było ustandaryzowanie danych?

…to zdecydowanie wchodzimy na wyższy poziom. Łatwo jest opowiadać co się zrobiło, trochę trudniej to wszystko później wybronić. Pytania tego typu sprawdzają, czy wiesz co robisz, czy po prostu robisz to co inni robią bez większego zastanowienia.

Jak odpowiadać na pytanie „dlaczego„?

 Absolutnie nigdy, przenigdy w stylu „bo ktoś mi to tak kazał zrobić’!! Chyba nic cię nie może tak skreślić kandydata jak to jedno pojedyńcze zdanie.

Najlepsza odpowiedź, to, że albo:

1. wynikało to z danych – przeprowadziłaś/eś dogłębną analizę, próbowałaś/eś kilka powszechnie znanych rozwiązań i to rozwiązanie okazało się dawać najlepsze wyniki. Przykład: Użyłam ostatecznie algorytmu RF ponieważ uzyskiwałam dzięki niemu największą precyzję. Próbowałan także innych algorytmów używających drzew decyzyjnych.
2. wynikało to z twojej wiedzy eksperckiej – zastosowałaś/eś ogólnie akceptowane poprawne podejście lub powszechną praktykę stosowaną przy każdej analizie. Przykład: Użyłem mediany zamiast średniej ponieważ rozkład wartości nie był rozkładem normalnym.

Ale! Jedyna odpowiedź w stylu „bo tak się u nas robi” jaką akceptowałam to jeżeli dotyczyła używanych narzędzi. Osoby pracujące w firmach rzadko mają wpływ na to, na jakich narzędziach pracują. Jeżeli był to excel, no to trudno, był to excel.  

Jak odpowiadać na pytanie dlaczego pracowałaś/eś w excelu? 
Ponieważ jest to narzędzie używane u nas w firmie. Zdaję sobie sprawę, że to nie jest to optymalne rozwiązanie, i gdybym mogła to przeprowadziłabym analizę w pythonie, aczkolwiek mój pracodawca wymagał użycia excela do rozwiązania tego zadania.

Szczera, prosta odpowiedź, zaznaczająca, że zdajecie sobie sprawę, że to nie jest najlepszy wybór.

6. Zadawanie pytań

Na samym końcu sytuacja się odwraca i to wy możecie zadawać pytania do rekrutera. Wydawać by się mogło, że najgorsze już za nami, ale czy do końca możemy już odpuścić?

Zadawanie pytań służy, aby dowiedzieć się, jak pracuje się w danej firmie. Wykorzystajcie ten czas mądrze! Zadawanie pytań to wasza jedyna okazja, aby przekonać się jak będzie wyglądało miejsce, w którym będziesz spędzać 8 godzin dziennie. Nie możecie jej zmarnować.

Ale czy ta część służy tylko i wyłącznie wam?

Możecie mi wierzyć lub nie, ale byłam w stanie ocenić czy ktoś się nadawał się na stanowisko tylko po tym, jakie pytania zadawał. Osoby kompetentne mogą wybierać między wieloma firmami, przez co zależy im, żeby wybrać jak najlepiej – będą one zadawały masę kluczowych pytań, adekwatnych do stanowiska – o używane technologie, typowy dzień pracy, zarządzanie, typowe zadania, ile czasu na co spędzacie, i wiele, wiele więcej. Zatem jest to wasza kolejna szansa na wykazanie się wiedzą i kompetencją na temat określonego stanowiska, a zresztą chyba jesteście ciekawi jak będzie wyglądać wasza praca?

Osoby nie zadające pytań nie są dobrymi kandydatami.

Zastosowanie powyższych punktów pozwoli wam z powodzeniem przebrnąć przez to pytanie na rekrutacji. Nie wszystkie jednak błędy, które wymieniłam powtarzały się z taką samą częstotliwością. Były także błędy mniej i bardziej mnie denerwujące.

Najczęstsze błędy

• Brak skupienia się na technicznych aspektach. Pretendenci nie mówią o narzędziach, programach, językach programowania, nie mówili dokładnie krok po kroku jak wyglądała analiza.
• Brak zachowania równowagi między ogółem a szczegółem. Albo opowiadają o projekcie zbyt powierzchownie, nie wchodząc w żadne szczegóły, albo skupiają się na detalach, które są nieistotne.

Co mnie osobiście najbardziej denerwowało?

• Kandydaci nie uważający mnie za osobą techniczną i zakładający, że nie znam się na szczegółach technicznych. Starałam się być tak obiektywna jak mogłam, ale ciężko pozostać obiektywnym jak jest się traktowanym przez kogoś z góry. Pretensjonalność i wywyższanie się kandydata jest najprostszą drogą do porażki. Bezpieczniej jest założyć, że osoba z którą rozmawiacie wie więcej niż mniej.
• Nadawanie niepotrzebnej wartości/trudności wykonanym zadaniom. Kurczę, to jest rozmowa techniczna, osoba rekrutująca zna się na tym co robi, i naprawdę nie musisz jej tłumaczyć co jest trudne, a co jest proste. Nie podkreślaj, że to co zrobiłaś/eś było TAKIE TRUDNE i tyle się musiałaś/eś narobić, żeby donieść ten projekt. Skup się na faktach i pozostaw rozmówcy ocenę trudności twoich dokonań.
• A propos poprzedniego punktu, to chyba jeszcze gorsze jest pójście w drugą stronę – umniejszanie swojej analizie, wstyd oraz przepraszanie. Nie przepraszajcie za to, że pracujecie w excelu. Nie mówcie, że ta analiza to nic takiego i w sumie nie ma co opowiadać. To brzmi TAK ŹLE, że aż szkoda słów.
• To, że to ja muszę „ciągnąć” osobę do góry, zarówno pod względem merytorycznym jak i motywacyjnym. Na początku miewałam wyrzuty sumienia, na przykład gdy osobie źle szło albo siadała jej motywacja – próbowałam te osoby dopytywać, naprowadzać, motywować do działania. Po jakimś czasie dałam sobie spokój, tzn. dalej próbowałam naprowadzać osoby na właściwy tor, ale nie robiłam tego za wszelką cenę lub próbując wręcz motywować kandydatów. To nie ja starałam się o pracę. To waszym zadaniem jest przejście przez proces rekrutacyjny. Waszą rolą jest wykazanie się motywacją, dobry wybór projektu i prawidłowe zaprezentowanie się. Nikt za was tej pracy nie zdobędzie.

Jeżeli nie chcecie przegapić kolejnych materiałów z cyklu rekrutacyjnego, w tym:

• Jak przejść przez wstępną rozmowę z rekruterem
• Jak przejść przez live coding
• Jakie pytania zadawać, aby wyciągnąć najwięcej wiedzy o firmie od rekruterów
• Jakie pytania zadają rekruterzy
• Czerwone flagi podczas rekrutacji

To zapraszam do zapisu do newslettera: