Typowy obrazek z końcówki rekrutacji: dwa rozwiązania tego samego zadania leżą obok siebie na stole. Pierwsze ma dwanaście stron, ładny diagram i komplet user stories. Drugie ma cztery strony, listę pytań na pierwszej i akapit zatytułowany "czego nie wiem". Zgadnij, które częściej kończy się ofertą. Siedziałem po obu stronach tego stołu wystarczająco wiele razy, żeby wiedzieć, że odpowiedź zaskakuje większość kandydatów.
Zadanie rekrutacyjne to moment, w którym CV przestaje się liczyć. Opowieść o doświadczeniu da się przygotować, na typowe pytania da się nauczyć odpowiedzi. Zadanie pokazuje, jak myślisz, kiedy dostajesz niepełną informację i musisz coś z nią zrobić. Czyli dokładnie to, co analityk robi w pracy. W tym wpisie pokażę Ci, na co patrzę, kiedy oceniam rozwiązania, i jak podejść do zadania, żeby ta ocena wypadła na Twoją korzyść.
Pięć form, w jakich przychodzi zadanie
Formy są różne, ale pod spodem sprawdzają to samo.
Case do domu. Dostajesz opis sytuacji biznesowej na stronę albo dwie, kilka dni i prośbę o "analizę". Sprawdza samodzielność i to, jak radzisz sobie bez możliwości dopytania. Najczęstsza pułapka: przesadny rozmiar. Nikt nie czyta dwudziestu stron.
Warsztat na żywo. Godzina z dwiema osobami z firmy, które grają interesariuszy. Tu testowana jest elicytacja: czy zadajesz pytania, czy słuchasz, czy potrafisz zawrócić rozmowę na cel. Nie ma się gdzie schować.
"Napisz user stories do tego opisu". Krótki opis funkcji i prośba o historyjki z kryteriami akceptacji. Sprawdza warsztat pisania, ale przede wszystkim to, czy zauważysz, że opis ma dziury, i co z nimi zrobisz.
"Narysuj proces". Opis, jak coś działa w firmie, i prośba o model. Sprawdza, czy umiesz wyłuskać z prozy kroki, decyzje i role, oraz czy zauważysz ścieżki wyjątków, o których nikt nie napisał.
Analiza dokumentu z lukami. Dostajesz gotową specyfikację albo listę wymagań z celowo wstawionymi sprzecznościami i brakami. Sprawdza czujność i sposób zgłaszania problemów: czy je wypunktujesz i zostawisz, czy zaproponujesz, jak je rozstrzygnąć.
Pytania z rozmowy, które zwykle poprzedzają zadanie albo po nim następują, zebrałem osobno we wpisie o pytaniach rekrutacyjnych dla analityka biznesowego. Tutaj zostajemy przy samym zadaniu.
Co naprawdę oceniam
Zacznę od tego, czego nie oceniam: poprawnej odpowiedzi. W większości zadań rekrutacyjnych poprawnej odpowiedzi nie ma, bo opis jest za krótki, żeby ją wyprowadzić. Ludzie, którzy układają te zadania, wiedzą o tym. Luki są tam celowo.
Oceniam sposób dojścia. Konkretnie pięć rzeczy.
Czy zapytałeś o cel i zakres. Zanim ruszysz z diagramem, chcę widzieć, że zastanowiłeś się, po co ten system albo proces ma istnieć i gdzie się kończy. Kandydat, który zaczyna od "zakładam, że celem jest skrócenie czasu obsługi, bo w opisie trzy razy pada słowo 'czekają'", już wygrał pierwszą rundę.
Czy nazwałeś założenia. Każde rozwiązanie stoi na założeniach. Różnica między dobrym a słabym kandydatem polega na tym, że dobry je wypisuje, a słaby w nie wierzy. Lista założeń na pierwszej stronie mówi mi o Tobie więcej niż cały diagram.
Co odrzuciłeś i dlaczego. Analiza to w dużej części decyzje, czego nie robić. Jeśli w rozwiązaniu widzę "rozważałem też wariant z automatyczną akceptacją, odrzuciłem go, bo w opisie jest wymóg kontroli przez kierownika", wiem, że myślisz opcjami, a nie pierwszym pomysłem.
Priorytety. Opis zwykle zawiera więcej, niż da się zrobić. Chcę zobaczyć, że umiesz powiedzieć: to najpierw, to później, tego w ogóle nie. I czym to uzasadniasz. Wartość dla biznesu i ryzyko to dobre kryteria, "bo tak mi się wydaje" nie.
Komunikacja. Czy rozwiązanie da się przeczytać w dziesięć minut. Czy ma strukturę, w której od razu wiem, gdzie szukać założeń, gdzie decyzji, gdzie pytań. Analityk, którego dokumentów nikt nie czyta, w projekcie nie istnieje.
Zwróć uwagę, że żadna z tych pięciu rzeczy nie wymaga znajomości branży. Wymagają nawyku myślenia, a nawyk da się wyćwiczyć.
Dlaczego to zadanie jest głównym filtrem
Na job boardzie Analify wisi 292 aktywnych ogłoszeń dla analityków biznesowych. Tam, gdzie ogłoszenie podaje poziom, rozkład wygląda tak: 22 oferty dla juniorów, 40 dla midów i 79 dla seniorów (odczyt: wrzesień 2026). Wejście do zawodu jest najciaśniejszym miejscem całej ścieżki, a na nieliczne ogłoszenia juniorskie przypada zwykle najwięcej kandydatów.
Przy takich proporcjach firma nie ma jak rozstrzygnąć rekrutacji na podstawie CV. Życiorysy juniorów są do siebie podobne: kurs, może certyfikat, może projekt z uczelni. Zadanie jest tym, co realnie rozdziela kandydatów. Jeśli jesteś przed pierwszym etatem, przeczytaj też, jak wygląda pierwsza praca junior business analysta, a proporcje między poziomami sprawdzaj na bieżąco w Barometrze rynku pracy analityków, bo się zmieniają.
Dla midów i seniorów zadanie waży trochę mniej, ale wciąż potrafi przeważyć. Widziałem kandydatów z długim stażem, którzy na warsztacie na żywo nie zadali ani jednego pytania. Staż ich nie obronił.
Procedura: siedem kroków
Ta sama procedura działa dla case'a do domu i, w skróconej wersji, dla zadania na żywo.
1. Przeczytaj dwa razy. Pierwszy raz, żeby zrozumieć, o co chodzi. Drugi raz z ołówkiem, żeby zaznaczyć każde miejsce, w którym opis czegoś nie mówi, mówi niejasno albo sam sobie przeczy. Za drugim razem zwykle znajdujesz to, co autor zadania tam schował.
2. Spisz pytania. Wszystkie, które przyszły Ci do głowy przy drugim czytaniu. Jeśli masz kontakt z rekruterem, wyślij trzy najważniejsze. Jeśli nie masz, lista zostaje w rozwiązaniu jako osobna sekcja. Sam fakt, że ją masz, jest częścią odpowiedzi.
3. Nazwij założenia. Na każde pytanie bez odpowiedzi przyjmij założenie i zapisz je jawnie, najlepiej z uzasadnieniem, skąd je wziąłeś. "Zakładam, że rezerwację może anulować tylko osoba, która ją założyła, bo opis nie wspomina o delegowaniu uprawnień." Bez tej sekcji rozwiązanie wisi w powietrzu.
4. Wybierz technikę. Jedną, najwyżej dwie. Proces prosi się o model procesu, funkcja o historyjki z kryteriami, dane o prosty model danych. Nie wrzucaj wszystkiego, co znasz. Pięć diagramów do jednego opisu to sygnał, że nie umiesz dobrać narzędzia do problemu.
5. Zrób artefakt. Porządnie, ale bez przesady w rozmiarze. Jeśli piszesz historyjki, niech mają kryteria akceptacji, które da się sprawdzić (jak je pisać, żeby nie były ozdobą, opisałem we wpisie o pisaniu user stories). Jeśli rysujesz proces, niech ma ścieżkę główną, wyjątki i role.
6. Dodaj sekcję "czego nie wiem i jak bym to sprawdził". To najbardziej niedoceniana część rozwiązania. Wypisz luki, których nie dało się domknąć założeniem, i przy każdej napisz, z kim byś porozmawiał albo jaki dokument obejrzał. Ta sekcja pokazuje, że rozumiesz, gdzie kończy się analiza przy biurku, a zaczyna rozmowa z ludźmi.
7. Zaplanuj prezentację. Zwykle jest na nią kilkanaście minut. Nie czytaj dokumentu. Zacznij od celu, jak go zrozumiałeś, potem trzy najważniejsze decyzje z uzasadnieniem, potem pytania, które zostały. Diagram pokazujesz, kiedy o niego zapytają, nie na dzień dobry.
To samo zadanie, dwa rozwiązania
Weźmy typowe zadanie ilustracyjne, jakie mogłoby trafić do kandydata: "Firma chce wdrożyć system rezerwacji sal konferencyjnych. Pracownicy skarżą się, że sale są zajęte, a potem stoją puste. Opisz wymagania." Tyle. Trzy zdania.
Słabe rozwiązanie wygląda tak: piętnaście user stories o tym, jak użytkownik loguje się, przegląda kalendarz, klika "rezerwuj", dostaje mail, edytuje, anuluje. Do tego diagram ekranów. Wszystko poprawne. I wszystko obok problemu, bo nikt nie zapytał, dlaczego sale stoją puste. Kandydat wziął słowo "system" i zbudował system.
Dobre rozwiązanie zaczyna się od zdania: "Problem z opisu to nie brak rezerwacji, tylko rezerwacje, z których nikt nie korzysta." Dalej pytania: czy sale są rezerwowane cyklicznie na zapas, czy ktoś je zwalnia, czy w ogóle istnieje informacja o tym, że spotkanie się nie odbyło. Założenie: przyjmuję, że główną przyczyną są rezerwacje cykliczne bez odwoływania, bo to najprostsze wyjaśnienie pasujące do opisu. Zakres: skupiam się na mechanizmie zwalniania sal, nie na całym module rezerwacji. Priorytety: najpierw potwierdzenie obecności i automatyczne zwolnienie, potem raport wykorzystania, na końcu integracja z kalendarzem. Do tego pięć historyjek zamiast piętnastu, jedno proste ujęcie procesu i lista "czego nie wiem": ile sal, ile osób, czy jest już jakieś narzędzie, kto jest sponsorem.
Drugie rozwiązanie jest krótsze, ma mniej artefaktów i więcej wartości. Z takim kandydatem chcę pracować, bo wiem, że na projekcie zapyta "po co", zanim zacznie rysować.
Czerwone flagi, które widzę najczęściej
Rozwiązanie bez ani jednego pytania. Oznacza, że kandydat albo nie zauważył luk, albo zauważył i uznał, że lepiej udawać, że ich nie ma. Oba przypadki są złe.
Objętość zamiast treści. Dwadzieścia stron, w których trzeba szukać, co kandydat właściwie zdecydował. Jeśli nie umiesz streścić swojej analizy na jednej stronie, na projekcie też nikt jej nie przeczyta.
Rozwiązanie techniczne zamiast analizy. Architektura, wybór bazy danych, propozycja frameworka. Nikt o to nie pytał. To sygnał, że kandydat ucieka w to, co zna, zamiast zmierzyć się z problemem biznesowym.
Brak priorytetów. Wszystko jest "must have". Analityk, który nie umie powiedzieć "to może poczekać", będzie na projekcie generował zakres zamiast go pilnować.
Obrona zamiast rozmowy. Na prezentacji pytam o alternatywę, a kandydat broni swojej wersji, jakby był na egzaminie. Chcę usłyszeć "nie rozważałem tego, ale gdyby tak było, zmieniłbym to i to". Elastyczność w rozmowie mówi mi więcej niż jakość diagramu.
I jedna flaga, o której mało się mówi: rozwiązanie wygenerowane w całości narzędziem AI. Poznaje się je szybko, bo jest gładkie, kompletne i nie ma w nim ani jednego pytania. Narzędzi możesz używać, ale myślenie ma być Twoje, bo na warsztacie na żywo i tak to wyjdzie.
Gdy zadanie jest niejasne
Będzie niejasne. Prawie zawsze. Pytanie brzmi, co z tym zrobisz.
Jeśli możesz zapytać, zapytaj, ale mądrze. Nie wysyłaj listy dwudziestu pytań, bo to przerzuca robotę na rekrutera. Wybierz dwa albo trzy, których odpowiedź naprawdę zmieniłaby Twoje podejście, i zapytaj o nie krótko, z propozycją, co przyjmiesz, jeśli odpowiedzi nie będzie. "Czy rezerwacje mają być widoczne dla wszystkich? Jeśli nie dostanę odpowiedzi, przyjmę, że tak, bo opis mówi o skargach na zajęte sale." Taki mail jest sam w sobie próbką Twojej pracy.
Jeśli zapytać się nie da, decyduj i dokumentuj. Każda decyzja podjęta w miejscu luki to założenie do spisania. Nie ma nic złego w błędnym założeniu, jeśli jest jawne. Złe jest założenie ukryte, bo wtedy nikt nie wie, na czym stoi rozwiązanie.
Na warsztacie na żywo niejasność jest samą treścią ćwiczenia. Osoby grające interesariuszy mają w scenariuszu sprzeczne oczekiwania. Twoja robota to je wydobyć i nazwać na głos: "Słyszę, że dla Pani liczy się czas obsługi, a dla Pana kontrola. Te dwie rzeczy będą się ciągnąć w różne strony. Które ma pierwszeństwo, gdy się zderzą?" Kandydat, który zada to pytanie, zrobił na warsztacie więcej niż ten, który narysował trzy diagramy.
Co zrobić z rozwiązaniem po rekrutacji
Niezależnie od wyniku masz w ręku gotowy materiał do portfolio. Większość kandydatów go wyrzuca. Szkoda.
Najpierw sprawdź, czy możesz go użyć. Jeśli zadanie zawierało dane firmy albo podpisałeś coś o poufności, zanonimizuj: zmień nazwy, usuń wszystko, co wskazuje na konkretną organizację. Sam problem, Twoje pytania, założenia i decyzje są Twoje.
Potem dopisz to, czego nie zdążyłeś dopisać przed terminem. Jeśli dostałeś feedback, wpleć go i napisz, co byś zmienił. Rozwiązanie z refleksją "po" jest cenniejsze niż pierwotne, bo pokazuje, że uczysz się na własnej robocie.
Jak taki materiał opisać i gdzie go pokazać, rozpisałem we wpisie o portfolio analityka biznesowego. Krótka wersja: opisuj problem, decyzje i to, co odrzuciłeś, nie diagramy same w sobie. Po trzech rekrutacjach masz trzy takie case'y. To więcej, niż większość kandydatów pokazuje po roku pracy. A jeśli dopiero piszesz życiorys, który ma Cię doprowadzić do etapu zadania, zajrzyj do wpisu o CV analityka biznesowego.
Zadanie rekrutacyjne nie sprawdza, czy znasz odpowiedź. Sprawdza, czy umiesz pracować bez niej. A to da się ćwiczyć na każdym opisie z trzech zdań, jaki sam sobie wymyślisz.
Jeśli chcesz przygotować się do całej rozmowy, a nie samego zadania, zebrałem zestaw pytań rekrutacyjnych dla analityka biznesowego. Przejrzyj go przed następną rekrutacją i spróbuj odpowiedzieć na głos, zanim zrobisz to przed kimś.