Trochę wykopalisko, ale temat ciekawy i aktualny, więc myślę że warto pociągnąć
Z racji mojego stanowiska mam kontakt z różnymi projektami, z czego większość w ostatnich 3 latach to tematy big data i data science i każdy data scientist z którym pracowałem miał doktorat z matematyki. To o co mi chodziło, to to, że znajomość biblioteki do ML to nie data science. Podobnie jak znajomość bootstrapa. Owszem można się go nauczyć i wyrzeźbić jakiś tam layout na podstawie tutka (80% frontent devów*), ale znajomość tego w jaki sposób bootstrap działa pod spodem to już nisza (20% devów*).
*dane z d**y
Projekty, o których piszesz, były związane z jakąś konkretną domeną biznesową? Bo jeśli twierdzisz, że ,,każdy data scientist z którym pracowałeś miał doktorat z matematyki" to albo mowa o jakiejś specyficznej, wąskiej niszy, gdzie faktycznie wymagane są umiejętności w obszarze niskopoziomowej implementacji konkretnych algorytmów w oparciu o najnowsze publikacje, albo koloryzujesz.
Pracuję jako data scientist od ponad 4 lat (wcześniej, jeszcze w trakcie studiów i zaraz po nich były to stanowiska typu data analyst / analityk, więc podobny obszar) i spośród kilkudziesięciu DS-ów których poznałem doktorat miały może trzy osoby (akurat nie z matmy a bodajże biotechnologii i fizyki), do tego dwie były w trakcie studiów doktoranckich. Jeśli chodzi o osoby z tytułem to jedna z nich była moim bezpośrednim przełożonym w dużym korpo spod znaku big pharmy i po jakimś czasie wróciła na rodzimy uniwersytet prowadzić tam projekty. Drugi miał zerowe soft skille, nie dało się z nim dogadać ani w tematach biznesowych ani około-DSowych (stawiałbym na coś z gatunku autyzmu, ale się nie znam więc strzelam) i finalnie dostał wypowiedzenie, nie znam jego dalszych losów. Trzeci jest osobą typowo overqualified, łebski gość, ale pewnie dosyć sfrustrowany, bo większość tasków nie przystaje do jego możliwości intelektualnych. Z drugiej strony jeden ze znajomych DS-ów jest ,,skromnym magistrem", a jakiś czas temu został Head of AI w amerykańskim start-upie, przy czym sporo się udziela w sieci, prowadził bloga, publikował artykuły i ewidentnie ma zajawkę. Ciekawostka - znam też jednego czy dwóch DS-ów którzy z różnych względów zatrzymali się na poziomie licencjatu i też dobrze sobie radzą w branży, aczkolwiek przyznaję, że jest to raczej rzadkość. Żeby nie ograniczać się do dowodów anegdotycznych polecam przejrzeć oferty typu ,,Data Scientist" lub ,,Machine Learning Engineer" na Justjoinit czy innym job boardzie pod kątem wymaganego wykształcenia. Oczywiście wyższe jest zwykle wymagane, często magister to minimum, ale jak do tej pory chyba tylko 2-3 razy w życiu widziałem na oczy ogłoszenia z cyklu ,,PhD to must have", z czego jedno było do projektu typowo uniwersyteckiego za bieda-pieniądze. Jeśli o mnie chodzi to promotor mojej pracy magisterskiej zachęcał mnie, żebym został na studiach doktoranckich, proponował asystenturę, ale miałem już w tym czasie dobrze płatną pracę i dzieciaka w drodze, więc ze względów czysto praktycznych odpuściłem. Absolutnie nie żałuję. Może za jakiś czas skuszę się na opcję otwarcia przewodu w trybie zaocznym (jakieś publikacje mam, więc kryteria z tego co kojarzę spełniam) ale raczej dla własnej satysfakcji.
Podsumowując temat wykształcenia - doktorat nie zaszkodzi, ale poza niszowymi lub uniwersyteckimi projektami zwykle nie jest wymagany, magister w zupełności wystarczy. Oczywiście znajomość matmy (algebra liniowa i analiza matematyczna to must have), statystyki, rachunku prawdopodobieństwa i zagadnień z obszaru badań operacyjnych (nie wszędzie, ale często się przydaje) jest konieczna, natomiast chodzi raczej o ogólne zrozumienie tematu i umiejętność samodzielnego poszerzenia wiedzy w razie potrzeby - w większości przypadków raczej nikt nie każe wyliczać całek podwójnych na czas na kartce. Osobiście tylko 2 razy implementowałem jakieś algorytmy od zera, na podstawie publikacji naukowych - w obu przypadkach na potrzeby prac dyplomowych, nie zawodowo (choć z jednego algorytmu zdarzyło mi się później korzystać, dosyć niszowy temat dotyczący analizy szeregów czasowych). Ważna jest też intuicja dotycząca samej analizy danych, czasem znajomość domeny biznesowej i soft skille żeby być w stanie przetłumaczyć język matematyki / statystyki na treść zrozumiałą dla biznesu. Raczej niewiele jest projektów (przynajmniej na polskim rynku) gdzie DS ma kontakt wyłącznie z ludźmi technicznymi, zwykle trzeba komunikować się z managementem, który w najlepszym wypadku kojarzy pojęcia odchylenia standardowego i mediany. Kolega wyżej stwierdził, że ,,Umiejętność użycia tensor flow w projekcie do rozwiązania jakiegoś trywialnego problemu to nie data science" - i tak i nie. Faktycznie w większości przypadków nie wystarczy zaczytać surowych danych z csv-ki, zaimportować klasę danego modelu, wytrenować i gotowe. Trzeba zrozumieć problem, przeprowdzić jakąś wstępną, eksploracyjną analizę, pomyśleć o przypadkach brzegowych, outlierach, etc. Często dyskusje z biznesem trwają dłużej niż napisanie ostatecznego rozwiązania. Jednak finalnie w 95% przypadków (tak na oko) korzysta się z gotowych bibliotek, tak jak wspomniałem implementacja algorytmów od zera to rzadkość.
Jeśli chodzi o rozwój data science ogółem, to moim zdaniem praca była, jest i nadal będzie, ale temat był swego czasu mocno przehypowany i faktycznie obecnie jest spora konkurencja, a ofert znacznie mniej na stanowiska typowo developerskie. Niestety na polskim rynku projektów spod znaku R&D nie jest dużo, a jeśli nawet uda się dostać przez kontraktornię bezpośrednio do zachodniej firmy, to często są to mniej ambitne zadania niż te delegowane do zespołów amerykańskich / szwajcarskich / brytyjskich. Boom na AI zmienił tyle, że wyroiło się sporo ogłoszeń z wymaganą znajomością LLM-ów, czyli w najlepszym wypadku sprowadza się to zapewne do dotrenowywania modeli w PyTorchu na podstawie danych klienta albo klejenia customowego RAG-a, a w najgorszym do jakiegoś prompt-engineeringu.
Powstaje pytanie - czym można się wyróżnić? Z moich obserwacji wynika, że sporo DS-ów baardzo słabo koduje, a programowanie to nieodłączna część tego zawodu. Dotyczy to przede wszystkim hindusów, ale ogółem często zamiast czystego kodu widuje się jakieś fikołki w Jupyterze, który może i jest fajnym narzędziem do testów, wstępnej analizy i prototypowania, ale zwykle bywa zmorą osób, które muszą te jupyterowe potworki tłumaczyć na produkcyjne rozwiązania. Najgorzej jest chyba wśród R-owców, jako że R sam w sobie jest językiem mało wydajnym, a nieoptymalny kod napisany w nieoptymalnym języku boli podwójnie. Jednocześnie R ma sporą kolekcję niszowych bibliotek znajdujących zastosowania np. w analizie badań klinicznych, więc nadal jest na niego ssanie w pewnych kręgach. Wniosek? Jeśli chcesz zabłysnąć na tle innych kandydatów warto - oprócz wspomnianej już staty, matmy, etc. - poznać dobrze bibliotekę standardową samego pythona, poczytać coś o czystym kodzie, nauczyć się dobrych praktyk, etc. Dodatkowo fajnie jest mieć pojęcie o procesie deployowania modeli (CI/CD, Docker, K8s, środowiska chmurowe, REST API). Inna opcja to pójście w niszowe tematy, typu wspomniane już badania kliniczne i język R (choć tutaj warto mieć wykształcenie kierunkowe), wtedy łatwo załapać się do jakiegoś korpo spod znaku big pharmy.
To tyle, trochę się rozpisałem, chętnie podyskutuję jeśli ktoś ma odmienne spojrzenie na któryś z poruszonych tematów : )
Pozdrawiam