Dlaczego nie mogę znaleźć pracy? Jak układam strategię przebranżowienia

„Dlaczego nie mogę znaleźć pracy?” to pytanie, które łatwo zadać sobie po kolejnym mailu zaczynającym się od podziękowania za zainteresowanie. Znasz ten gatunek literacki. Trzy grzeczne zdania, zero informacji i poczucie, że kolejny tydzień poszedł w kosmos.

Kiedy myślę o przebranżowieniu, zaczynam od odległości między tym, co umiem dzisiaj, a zadaniami osoby, którą firma chce zatrudnić. Tę odległość da się zmniejszać na różne sposoby. Czasem potrzebny jest kurs, czasem lepszy opis doświadczenia, a czasem stanowisko pośrednie, które daje dostęp do właściwych problemów.

Sam przeszedłem od studiów humanistycznych i customer service do pracy z danymi. Znam więc pokusę patrzenia na branżę jak na klub, do którego wszyscy oprócz mnie dostali hasło. Moja historia nie gwarantuje takiego samego wyniku każdemu. Pokazuje natomiast kierunek, który warto rozważyć: budowanie na tym, do czego mam już dostęp.

Poniżej opisuję sposób myślenia i plan działania. Przykładowe osoby, projekty oraz liczby są ilustracjami. Nie są historiami konkretnych kursantów ani obietnicą zatrudnienia po określonej liczbie tygodni.

Wersję audio tego materiału znajdziesz również na Spotify.

Najpierw sprawdzam, gdzie naprawdę utknął proces

Brak pracy jest rezultatem. Sam w sobie mówi niewiele o przyczynie. Mogę wysyłać aplikacje na stanowiska wymagające innego doświadczenia, opisywać swoje umiejętności nieczytelnie albo mieć problem na konkretnym etapie rozmowy. Mogę też trafić na wstrzymane rekrutacje. Nie wszystkie elementy zależą ode mnie.

Zamiast wrzucać wszystko do worka „jestem beznadziejny”, zapisuję etapy: wysłana aplikacja, zaproszenie, rozmowa, zadanie, kolejna rozmowa, decyzja. Dodaję nazwę roli, wymagania, wersję CV i datę. Wystarczy zwykła tabela. Budowanie systemu rekrutacyjnego przez trzy weekendy raczej nie przyspieszy pierwszego zaproszenia.

Jeśli nie dostaję rozmów, przyglądam się doborowi ofert i pierwszym kilkunastu sekundom czytania CV. Jeśli rozmowy są, a zadania regularnie mnie zatrzymują, mam bardziej konkretny temat do nauki. Jeżeli dochodzę do końca, sprawdzam sposób opowiadania o pracy, oczekiwania i informacje zwrotne, które rzeczywiście udało się uzyskać.

Nie wyciągam wielkich wniosków z dwóch aplikacji. Przy małej liczbie prób przypadek potrafi udawać strategię. Porównuję podobne role i warunki, a brak odpowiedzi traktuję jako brak informacji. To mniej dramatyczne od diagnozy własnego charakteru i znacznie bardziej użyteczne.

Jak wygląda taka diagnoza w praktyce

Załóżmy, że ktoś wysłał 20 aplikacji, z czego 15 na stanowiska z wymaganym doświadczeniem we wdrażaniu hurtowni danych. Sam ma pierwsze projekty w Excelu. W takim układzie nie zaczynałbym od kolejnej kosmetyki zdjęcia w CV. Najpierw zmieniłbym dobór ofert i poszukał zadań bliższych obecnym umiejętnościom.

W innym scenariuszu kandydat dostaje rozmowy, ale nie potrafi wyjaśnić, dlaczego po połączeniu tabel wzrosła suma sprzedaży. Tutaj ćwiczyłbym relacje, poziom szczegółowości i kontrolę wyniku. Te dwa przypadki mogą prowadzić do identycznego pytania w wyszukiwarce. Potrzebują jednak innej pracy.

Wybieram rolę na podstawie zadań

„Chcę pracować w IT” jest dobrym początkiem rozmowy, ale słabym filtrem ofert. W tak szerokiej kategorii mieszczą się bardzo różne codzienności. Ja próbowałbym opisać konkretny tydzień pracy: przygotowywanie raportów, rozmowy z użytkownikami, czyszczenie danych, wyjaśnianie odchyleń, utrzymywanie dashboardów.

Nazwa stanowiska pomaga, lecz nie wystarcza. Analityk w jednej firmie przygotowuje zestawienia operacyjne, w drugiej buduje modele danych, a w trzeciej spędza większość czasu na zbieraniu wymagań. Dlatego czytam obowiązki i przykłady problemów. Tytuł na LinkedInie ma niewielką moc zmieniania zawartości kalendarza.

Przejrzałbym kilkanaście aktualnych ofert z lokalizacji i trybu pracy, które rzeczywiście wchodzą w grę. Wypisałbym powtarzające się zadania i narzędzia. Oddzieliłbym wymagania konieczne od mile widzianych, jeśli ogłoszenie je rozróżnia. Własne domysły zaznaczyłbym jako domysły.

Jako szerszy punkt odniesienia można wykorzystać opis Business Intelligence Analysts w O*NET. Widać tam raportowanie, pracę z narzędziami BI, dokumentację i komunikowanie wyników. To amerykański opis zawodu, więc traktuję go jako mapę zadań, a nie statystykę polskiego rynku ani wymagania każdej firmy.

Rola pośrednia, która faktycznie przybliża do celu

Rozważyłbym stanowiska w operacjach, obsłudze klienta, logistyce, administracji czy wsparciu sprzedaży, jeśli zawierają realną pracę z danymi. Mogą pozwolić wykorzystać dotychczasową wiedzę branżową i stopniowo zwiększać zakres analityczny. To centralny pomysł mojej strategii przebranżowienia.

Sama duża firma nie daje gwarancji. Można trafić do zespołu, w którym przez rok kopiujesz komórki bez prawa zmiany czegokolwiek. Można też znaleźć małą organizację, gdzie szybko bierzesz odpowiedzialność za raport. Sprawdzam konkretne warunki, bez dopisywania magicznych właściwości do słowa „korporacja”.

Na rozmowie zapytałbym, jakie raporty przygotowuje zespół, kto korzysta z wyników, czy nowa osoba może poprawiać proces i jak wygląda współpraca z analitykami. Poprosiłbym o przykład ostatniego usprawnienia. Konkretna historia mówi więcej niż deklaracja „stawiamy na rozwój”, którą da się nadrukować na dowolnym kubku.

Spisuję doświadczenie, które już mam

Kiedy zmieniam branżę, łatwo uznać dotychczasowe lata pracy za przerwę w oczekiwaniu na właściwe życie. Ja patrzę na nie inaczej: jakie procesy znam, jakie błędy potrafię zauważyć i z kim umiem rozmawiać? Obsługa reklamacji, planowanie grafików czy kontrola stanów magazynowych dają wiedzę o tym, co dane próbują opisać.

Przykładowo osoba z customer service może rozumieć powody kontaktu, przekazywanie spraw i różnicę między zamknięciem zgłoszenia a rozwiązaniem problemu. Ta wiedza pomaga zadawać sensowne pytania do raportu. Trzeba jeszcze dołożyć warsztat, ale punkt startowy jest konkretny.

Robię prosty spis: proces, problem, moja czynność, użyte narzędzie, rezultat i sposób sprawdzenia. Jeśli nie mierzyłem rezultatu, piszę to uczciwie. Nie dorabiam „wzrostu efektywności o 37%”, bo liczba 37 wygląda wiarygodniej niż 40. Rekruter może zapytać, skąd się wzięła, i wtedy zaczyna się literatura improwizowana.

Szukam też rzeczy, których nie zrobiłem jeszcze samodzielnie. Może przygotowuję dane, ale wnioski formułuje ktoś inny. Może umiem raportować, ale nie rozumiem źródła danych. Taka luka daje kierunek następnego zadania. Lista braków jest przydatna, kiedy prowadzi do ćwiczenia, a nie do kolejnego wieczoru samokrytyki.

Jak uczciwie opisać zwykłe zadanie

Zdanie „obsługa klientów i praca w Excelu” niewiele mówi o sposobie działania. Gdy odpowiada prawdzie, można napisać: „Porządkowałem kategorie zgłoszeń i przygotowywałem tygodniowe zestawienie powodów kontaktu dla lidera zespołu”. Widać czynność, dane, rytm i odbiorcę.

Jeśli pojawiła się zmiana procesu, dopisuję co zostało zmienione i jak to sprawdzono. Gdy nie było pomiaru, pozostaję przy obserwowalnym rezultacie, na przykład użyciu zestawienia na spotkaniu zespołu. Precyzja jest wystarczająco dobra. Nie każdy punkt w CV potrzebuje sztucznych fajerwerków.

Buduję mały projekt z prawdziwym pytaniem

Projekt zaczynam od problemu, który potrafię wyjaśnić bez nazwy narzędzia. „Chcę zobaczyć, które rodzaje zgłoszeń najczęściej wracają do zespołu” jest wystarczająco konkretne. „Zrobię dashboard w popularnej technologii” zostawia najważniejszą decyzję na później.

Do publicznego portfolio wybieram dane publiczne z odpowiednimi warunkami użycia albo tworzę dane syntetyczne i wyraźnie je oznaczam. Danych pracodawcy nie przenoszę na prywatny komputer ani do publicznego repozytorium bez właściwej zgody. Podmiana nazw klientów nie daje automatycznie prawa do publikacji całego zbioru.

Potem opisuję jednostkę obserwacji. Czy jeden wiersz to zgłoszenie, wiadomość, czy zmiana statusu? Sprawdzam braki, duplikaty, zakres dat i znaczenie kategorii. Jeśli nie rozumiem tej warstwy, ładny wykres tylko szybciej rozprowadzi błędną interpretację.

Wynik projektu powinien zawierać odpowiedź, ograniczenie i następny krok. Na przykład: w syntetycznej próbce najwięcej powrotów dotyczy określonej kategorii, ale bez rozróżnienia trudności spraw nie oceniam jakości pracy poszczególnych osób. Proponuję sprawdzić procedurę i próbkę przypadków. To już przypomina rozmowę analityczną.

Co pokazałbym w portfolio

Przygotowałbym krótki opis problemu, pochodzenie danych, instrukcję odtworzenia, kilka ważnych kontroli i końcowe wnioski. Zostawiłbym jeden czytelny wykres zamiast galerii wszystkich dostępnych typów wizualizacji. Rekruter ma zrozumieć mój tok myślenia bez organizowania wyprawy archeologicznej po plikach.

Dodałbym też małą zmianę wymagań. Co zrobię, gdy pojawi się nowa kategoria albo miesiąc z brakującymi danymi? Czy rozwiązanie nadal działa? W praktycznej pracy takie pytania przychodzą regularnie. Pokazanie reakcji na zmianę jest mocniejszym sygnałem niż idealny wynik na jednej przygotowanej tabeli.

Jeżeli potrzebujesz punktu startowego, mój histogram w SQL pozwala przećwiczyć zmianę poziomu agregacji i przypadki brzegowe. Z kolei artykuł o KPI pomoże nazwać pytanie biznesowe. Potem zmieniłbym temat i dane tak, żeby projekt stał się własnym rozwiązaniem.

Uczę się pod konkretne zadania

Najchętniej układam naukę wokół najbliższej rzeczy do zrobienia. Jeśli trzeba połączyć trzy miesięczne pliki, uczę się odpowiedniej transformacji. Jeśli muszę policzyć klientów, sprawdzam grupowanie i identyfikatory. Tak łatwiej zauważyć, czy umiejętność rzeczywiście została ze mną po zamknięciu lekcji.

Na start wybrałbym wąski zestaw narzędzi pasujący do ofert i projektu. Arkusz, SQL oraz jedno narzędzie wizualizacji mogą już dać sporo pracy. Dokładna kolejność zależy od punktu wyjścia. Nie dorzucałbym pięciu języków tylko dlatego, że pojawiły się na czyjejś grafice „roadmap do sukcesu”.

Każdy fragment kursu próbowałbym odtworzyć bez podpowiedzi, a potem zmienić dane lub warunek. Jeśli umiem wykonać ćwiczenie wyłącznie w rytmie nagrania, potrzebuję jeszcze praktyki. Oglądanie osoby, która sprawnie pisze SQL, daje wiedzę o tym, że ta osoba sprawnie pisze SQL.

AI może pomagać wyjaśnić błąd, wymyślić dodatkowy przypadek i skomentować rozwiązanie. Ja nadal sprawdzam wynik na małych danych, które potrafię policzyć ręcznie. W portfolio chcę pokazać decyzje, które rozumiem. Na rozmowie ekran z czatem nie odpowie za mnie na pytanie o zmianę warunków.

Jak wyznaczam mały próg samodzielności

Wybieram zadanie i sprawdzam, czy potrafię je rozpocząć od pustego pliku, znaleźć potrzebną dokumentację, wyjaśnić kolejne kroki i sprawdzić wynik. Nie wymagam pamięciowego opanowania każdej funkcji. Oczekuję natomiast, że wiem, czego szukam i dlaczego.

Proszę też drugą osobę o konkretne uwagi: co jest niejasne w opisie, którego wniosku nie bronią dane, co przestaje działać po zmianie wejścia. Pytanie „czy projekt jest fajny?” zwykle produkuje uprzejmość. Pytania o konkretne fragmenty dają materiał do poprawy.

Pokazuję dopasowanie w CV i na rozmowie

CV układam pod zakres roli, zachowując prawdę o doświadczeniu. Na początku pokazuję najbardziej istotne zadania i projekty. Oddzielam pracę zawodową od ćwiczeń. Ukończony kurs może być dobrym elementem historii, ale nie opisuję go jak komercyjnego wdrożenia dla klienta.

Przy każdej ważnej umiejętności chcę mieć przykład. „SQL” powinien prowadzić do rozmowy o tym, co policzyłem, na jakich danych i jak sprawdziłem poprawność. „Komunikacja z biznesem” powinna mieć odbiorcę, pytanie i rezultat. Same etykiety są tanie, więc rynek ma ich pod dostatkiem.

Na rozmowę przygotowuję kilka krótkich historii: problem, moje działanie, rezultat i ograniczenie. Ćwiczę je na głos. Szczególnie pilnuję słowa „ja”: co zrobiłem osobiście, a co zespół. Potrafię docenić współpracę i jednocześnie jasno opisać własny wkład.

Gdy czegoś nie wiem, mówię, jak bym to sprawdził. Mogę rozrysować przykład, wskazać dokumentację albo zaproponować test. Zmyślona pewność jest kosztowna, bo zwykle wymaga kolejnych zmyślonych odpowiedzi. Wolę pokazać sensowny proces dochodzenia do wyniku.

Kontakty i informacje zwrotne

Rozmawiałbym z osobami wykonującymi podobną pracę o konkretnych zadaniach. Poprosiłbym o ocenę jednego opisu projektu lub o wyjaśnienie, jak wygląda raportowanie w ich zespole. Taka rozmowa pomaga sprawdzić własne wyobrażenia i znaleźć język używany w danej branży.

Nie oczekiwałbym, że każda nowa znajomość zamieni się w polecenie. Szanuję czas drugiej osoby i pokazuję, że wykonałem już część pracy. Krótkie pytanie z kontekstem jest łatwiejsze do podjęcia niż wysłane obcej osobie „jak zostać analitykiem, opowiedz wszystko”.

Układam plan, który da się utrzymać

Pierwszy etap poświęciłbym diagnozie: analiza ofert, spis własnych doświadczeń i wybór jednego kierunku. Drugi przeznaczyłbym na mały projekt i uzupełnienie najważniejszej luki. W trzecim przygotowałbym opis pracy, CV oraz serię dobrze dobranych aplikacji. Etapy mogą się nakładać i trwać różnie zależnie od sytuacji.

W kalendarzu zapisałbym realne bloki czasu. Jeśli mam dwa wieczory w tygodniu, planuję dwa wieczory, a nie fikcyjne życie człowieka, który nie śpi i nie ma prania. Lepiej regularnie kończyć małe zadania niż co miesiąc tworzyć nowy ambitny harmonogram po poprzedniej katastrofie.

Co tydzień sprawdzam rezultaty: ukończony fragment projektu, wyjaśniony błąd, poprawiony opis, sensowna aplikacja, uzyskana informacja. Liczba godzin jest pomocnicza. Długi wieczór przed monitorem może oznaczać dobrą pracę albo wyjątkowo rozbudowaną formę unikania pierwszego zadania.

Uwzględniam koszty zmiany, obowiązki domowe i czas na odpoczynek. Nie traktowałbym rezygnacji z obecnej pracy jako obowiązkowego dowodu determinacji. Bezpieczny dla danej osoby sposób przejścia może dać więcej przestrzeni na naukę niż presja szybkiego znalezienia czegokolwiek.

Jak porównuję dwie możliwe oferty

Załóżmy, że jedna rola ma w nazwie „analityk”, ale polega głównie na ręcznym aktualizowaniu gotowych plików. Druga dotyczy operacji, za to obejmuje sprawdzanie jakości danych, rozmowę z odbiorcami raportów i możliwość poprawiania procesu. Nie wybierałbym wyłącznie na podstawie tytułu. Zapisałbym, czego realnie nauczę się w każdej z nich przez najbliższe miesiące.

Porównałbym dostęp do narzędzi, zakres samodzielności, wsparcie bardziej doświadczonej osoby, częstotliwość pracy z danymi i warunki zatrudnienia. Każdą niepotwierdzoną rzecz oznaczyłbym jako pytanie do pracodawcy. Obietnica „później będziesz mógł robić analizy” wymaga doprecyzowania: jakie analizy, kiedy i kto pomoże wydzielić na nie czas.

Ustaliłbym również własny punkt kontrolny. Chciałbym po kilku miesiącach umieć pokazać konkretny raport, usprawnienie albo rozwiązany problem, z zachowaniem zasad poufności. Jeżeli oferta nie daje żadnej realnej drogi do takiego rezultatu, traktowałbym ją ostrożniej jako etap przebranżowienia, nawet jeśli sama w sobie jest dobrą pracą.

Nie ma jednej odpowiedniej wagi tych kryteriów. Dla osoby z dużymi obowiązkami domowymi przewidywalny grafik może być warunkiem rozwoju, bo umożliwia regularną naukę. Dla kogoś innego najważniejszy będzie dostęp do zespołu analitycznego. Ja chcę, żeby wybór wynikał z własnej sytuacji i sprawdzonych informacji, a nie z wyobrażenia, jak prestiżowo zabrzmi nowa stopka mailowa.

Kiedy koryguję kierunek

Po kolejnej porównywalnej serii aplikacji wracam do tabeli. Jeżeli problem jest nadal ten sam, zmieniam jeden ważny element: zakres ofert, opis projektu albo konkretną umiejętność. Zmienianie wszystkiego jednocześnie utrudnia zrozumienie, co rzeczywiście pomogło.

Sprawdzam też rolę pośrednią po jej podjęciu. Czy pojawiają się zadania z danymi? Czy mam od kogo się uczyć? Czy rośnie moja samodzielność? Jeśli przez dłuższy czas odpowiedzi pozostają negatywne, szukam innego sposobu zdobycia doświadczenia. Sam upływ miesięcy nie wykonuje pracy za mnie.

Na dziś wybrałbym jedną rzecz: przejrzeć pięć sensownych ofert, opisać jedno własne zadanie albo postawić pytanie do małego zbioru danych. Z takiego działania powstaje materiał na następny krok. Właśnie tak rozumiem strategię przebranżowienia: kolejne decyzje, po których mam więcej umiejętności, dowodów i wiedzy o rynku niż przed nimi.