Data Scientist: pytania i odpowiedzi na rozmowie

Wzorcowa odpowiedź

Prowadziłem analizę churnu dla produktu subskrypcyjnego, gdzie celem nie było samo 'podkręcenie modelu', tylko lepsze priorytetyzowanie działań retencyjnych. Zamiast gonić za samą dokładnością, zoptymalizowałem model pod precision w top decylu, bo to ten fragment trafiał do zespołu CRM. Następnie razem z biznesem przetestowaliśmy kampanię w A/B teście i zobaczyliśmy wzrost retencji w grupie objętej interwencją. Najważniejsze było to, że analiza przełożyła się na decyzję, a nie tylko na raport.

Wzorcowa odpowiedź

Zaczynam od celu, jakości danych i ograniczeń wdrożeniowych. Jeśli potrzebuję szybko wytłumaczalnego baseline'u, często wybieram regresję logistyczną albo prosty model drzewiasty, a dopiero potem porównuję bardziej złożone podejścia. Patrzę też na interpretowalność, latency, koszt utrzymania oraz to, czy model ma działać w batch czy online. W praktyce lepszy bywa model prostszy, ale stabilny i zrozumiały dla zespołu.

Wzorcowa odpowiedź

Zaczynam od rekomendacji: co z tego wynika i jaką decyzję warto podjąć. Potem pokazuję tylko tyle dowodów, ile jest potrzebne, np. wpływ na przychód, retencję lub koszt, zamiast zasypywać AUC czy p-value bez kontekstu. Unikam żargonu, a jeśli muszę użyć terminu technicznego, od razu go przekładam na język biznesowy. Dobrze działa prosta wizualizacja i jasne wskazanie założeń oraz ryzyk.

Wzorcowa odpowiedź

Pracuję na wersjonowanym kodzie i danych, opisuję pipeline od surowych danych do wyniku i pilnuję, żeby każdy etap dało się odtworzyć. Sprawdzam data leakage, testuję założenia i porównuję wyniki z prostymi benchmarkami, żeby uniknąć zbyt pięknych rezultatów. Dokumentuję ograniczenia, a przed oddaniem pracy proszę o peer review analizy lub code review. Dobra analiza to taka, której ktoś inny może użyć bez zgadywania, co miałem na myśli.

Wzorcowa odpowiedź

Zdarzyło mi się, że zespół był przekonany, iż jedna funkcja mocno podnosi konwersję. Po kontroli o intent użytkownika okazało się, że efekt był dużo słabszy, a miejscami znikał całkiem. Zweryfikowałem wyniki na kilka sposobów, żeby wykluczyć błąd w danych albo w metodologii, i dopiero wtedy pokazałem wnioski. Przy prezentacji byłem spokojny i precyzyjny, bo w takich sytuacjach liczy się rzetelność, a nie bronienie ego.

Type I error to fałszywie dodatni wynik - odrzucasz prawdziwą hipotezę zerową. Type II error to fałszywie ujemny wynik - nie odrzucasz fałszywej hipotezy zerowej. W praktyce chodzi o balans kosztów: czasem bardziej bolesny jest false positive, a czasem false negative, więc próg istotności i moc testu dobiera się do kontekstu biznesowego.

Bias to błąd wynikający ze zbyt prostych założeń modelu, czyli underfitting. Variance to wrażliwość modelu na dane treningowe, czyli skłonność do overfittingu. Im bardziej złożony model, tym zwykle niższy bias, ale wyższa variance. Celem jest znalezienie punktu, w którym błąd na danych niewidzianych jest najmniejszy.

Cross-validation dzieli dane na foldy, trenuje model na części z nich, a waliduje na pozostałej części, po czym rotuje ten proces tak, aby każdy rekord był oceniony. Wynik uśredniony z kilku foldów daje stabilniejszą ocenę niż pojedynczy train/test split. Jest szczególnie przydatny przy mniejszych zbiorach danych i przy doborze hyperparameterów, bo ogranicza ryzyko dopasowania się do jednego podziału.

Gdy dane są niezbalansowane albo koszt błędów jest asymetryczny. Accuracy może wyglądać dobrze nawet wtedy, gdy model ignoruje klasę rzadką, więc w takich przypadkach ważniejsze są precision i recall. Jeśli np. wykrywasz fraud, zależy Ci zwykle na wysokim recall; jeśli filtrujesz spam, często ważniejszy jest precision. Dobór metryki powinien wynikać z kosztu biznesowego błędu.

Regularisation dodaje karę za złożoność modelu, żeby ograniczyć overfitting. L1, czyli Lasso, karze sumę wartości bezwzględnych współczynników i może wyzerować część z nich, więc działa trochę jak feature selection. L2, czyli Ridge, karze kwadraty współczynników i zwykle tylko je wygładza, co dobrze sprawdza się przy skorelowanych cechach.

Dostałem zbiór transakcji z niespójnymi formatami dat, brakami i duplikatami. Najpierw policzyłem skalę problemu, a potem dla każdej kolumny zdecydowałem, czy lepiej imputować, odrzucić rekordy, czy dodać flagę braku danych. Każdą decyzję opisałem tak, żeby było wiadomo, co zostało zmienione i dlaczego. Dzięki temu zespół przestał traktować dataset jako jednorazowy plik, a zaczął jako powtarzalny asset.

Model wyglądał dobrze offline, ale po wdrożeniu pogorszył się, bo rozkład cech w produkcji zaczął dryfować względem danych treningowych. Włączyłem monitoring rozkładów wejść i jakości predykcji, żeby szybko wykrywać podobne zmiany. Potem zbudowałem pipeline okresowego retrainingu na świeższych danych. Dzięki temu wyniki wróciły do akceptowalnego poziomu, a monitoring pomógł złapać kolejny drift zanim zaszkodził użytkownikom.

Miałem przygotować estymację market size przed spotkaniem zarządu i miałem na to dwa dni. Zamiast budować idealny model, zawęziłem zakres do najbardziej wiarygodnych danych i zrobiłem defensywny back-of-the-envelope calculation z jasno opisanymi założeniami. Podałem też widełki i poziom niepewności, żeby decyzja była świadoma. To pozwoliło zespołowi podjąć ruch na czas, a później można było zrobić dokładniejszą analizę.

Zespół oceniał feature po prostym 'before/after', ale wyniki były skażone seasonality i innymi zmianami w produkcie. Zaproponowałem A/B test jako sposób na odseparowanie realnego efektu od szumu. Po pilotażu okazało się, że funkcja, którą uznawano za sukces, była w praktyce neutralna. To pomogło wprowadzić eksperymenty jako standard przy większych wdrożeniach.