Kandydatka wyrecytowała definicję user story bez jednego potknięcia. Poprosiłem, żeby napisała jedną - dla wyszukiwarki w sklepie internetowym. Trzy minuty ciszy. Siedziałem po obu stronach stołu rekrutacyjnego i ta scena powtarza się w kółko: kandydaci uczą się definicji, a rekruterzy sprawdzają myślenie.
Dlatego to nie jest kolejna lista w stylu „business analyst interview questions”, przepisana z dziesięciu innych list. Przy każdym z 15 pytań dostajesz trzy rzeczy: czego rekruter naprawdę szuka, odpowiedź w pierwszej osobie, którą sam bym obronił (adaptuj do swojej historii, nie wkuwaj), i czerwoną flagę - odpowiedź, która grzebie kandydata.
Jak wygląda rekrutacja analityka biznesowego w 2026 - etapy i co sprawdzają na każdym
Typowy proces ma trzy do czterech etapów. Screening CV robi rekruter albo system ATS - liczy się dopasowanie fraz z ogłoszenia, nie kreatywność graficzna. Rozmowa z HR (30-45 minut) sprawdza motywację, spójność historii i oczekiwania; tu padają pytania 14 i 15 z tej listy. Rozmowa techniczna z hiring managerem albo seniorem BA to serce procesu: pytania 1-13, czasem case na żywo albo zadanie domowe. Finałowa, jeśli jest, weryfikuje dopasowanie do zespołu i to, czy masz własne pytania.
O co pytają na technicznej? Nie muszę zgadywać. Prowadzę job board, który codziennie zbiera ogłoszenia dla analityków - na dziś 330 aktywnych ofert i 381 nowych w ostatnich 30 dniach. Wymagania z ogłoszeń to najlepszy dostępny proxy tego, co usłyszysz na rozmowie:
| Kompetencja | Odsetek aktywnych ofert (tagi + tytuły) |
|---|---|
| BPMN | 22% |
| UML | 20% |
| SQL | 15% |
| Jira | 14% |
| Confluence | 10% |
| Agile | 10% |
Dwie obserwacje. Modelowanie procesów i wymagań (BPMN, UML) wyprzedza SQL - rdzeniem rozmowy będą wymagania, procesy i interesariusze, nie bazy danych. I druga: wśród ofert z zadeklarowanym poziomem junior to tylko 25 pozycji przy 90 mid i 91 senior. Mniej ofert juniorskich to więcej kandydatów na każdą, więc rozmowa musi pójść Ci lepiej niż pozostałym. Świeże liczby śledzisz na Barometrze rynku BA.
Pytania o podstawy (1-5)
Format dalej jest stały: czego szukają, odpowiedź do adaptacji (w cytacie), czerwona flaga.
1. Czym różni się wymaganie funkcjonalne od niefunkcjonalnego?
Czego szukają: czy mówisz przykładami, nie definicjami z podręcznika.
Funkcjonalne opisuje, co system robi: użytkownik może zresetować hasło mailem. Niefunkcjonalne opisuje, jak ma to robić: link resetujący dochodzi w minutę, strona działa na telefonie, dane są szyfrowane. Rozdzielam je, bo inaczej się je testuje i kto inny za nie odpowiada. Na jednym z projektów to właśnie wymaganie niefunkcjonalne wywróciło harmonogram: wymóg dostępności wypłynął dopiero na testach, bo nikt nie zapisał go na starcie. Od tamtej pory przy każdym projekcie przechodzę checklistę kategorii: wydajność, bezpieczeństwo, dostępność, zgodność z przepisami.
Czerwona flaga: bezbłędna definicja i ani jednego przykładu. Rozgrzewkę z przykładami „źle - dobrze” masz we wpisie o wymaganiach funkcjonalnych i niefunkcjonalnych.
2. Jak zebrałbyś wymagania od interesariusza, który „nie ma czasu”?
Czego szukają: pragmatyzmu, gdy podręcznikowe techniki elicytacji nie działają.
Najpierw zbieram wszystko, co mogę bez niego: dokumentację, dane z systemów, wiedzę jego zespołu. Potem proszę o 20 minut, nie o dwugodzinny warsztat - i przychodzę z gotowym szkicem procesu, prosząc o wskazanie błędów. Poprawianie cudzego szkicu idzie ludziom szybciej niż opowiadanie od zera. Ustalenia wysyłam w krótkiej notatce z jawną zasadą: brak uwag w trzy dni traktuję jako akceptację. A gdy brak decyzji zaczyna blokować projekt, eskaluję do sponsora - z policzonym kosztem czekania, nie ze skargą.
Czerwona flaga: „wysłałbym ankietę i czekał” albo eskalacja jako pierwszy odruch.
3. Czym jest user story i z czego się składa?
Czego szukają: czy wiesz, że szablon to początek, a wartość rozstrzyga się w „żeby” i w kryteriach akceptacji.
User story to krótki opis potrzeby z perspektywy użytkownika: jako [rola] chcę [funkcjonalność], żeby [korzyść]. Najważniejsza jest część „żeby” - jeśli nie umiem jej napisać, nie rozumiem, po co budujemy funkcję, i wracam do interesariusza. Samo story to obietnica rozmowy, nie specyfikacja. Dlatego dopisuję kryteria akceptacji, najczęściej w formacie Given/When/Then - to one rozstrzygają na testach, czy skończyliśmy. Jakość story sprawdzam heurystyką INVEST, zwłaszcza czy jest małe i testowalne.
Czerwona flaga: recytacja szablonu i bezradność przy prośbie o napisanie story na poczekaniu. Warsztat podciągniesz wpisami o pisaniu user stories i kryteriach akceptacji.
4. Co zrobisz, gdy biznes i IT mówią co innego?
Czego szukają: roli tłumacza między światami - i tego, czy nie wybierasz stron.
Najpierw sprawdzam, czy to na pewno konflikt, a nie różnica słowników - połowa „sporów” znika po doprecyzowaniu pojęć. Potem sadzam obie strony przy jednym konkrecie: diagramie procesu albo makiecie, bo o konkret spiera się produktywniej niż o abstrakcje. Pilnuję podziału: co ma powstać, decyduje biznes; jak to zbudować, decyduje IT. Jeśli spór zostaje, przygotowuję porównanie opcji z kosztami i ryzykami i prowadzę do decyzji osobę z mandatem. Nie ja rozstrzygam. Ja pilnuję, żeby decyzja zapadła świadomie i została zapisana.
Czerwona flaga: „biznes płaci, więc biznes ma rację” - albo dokładnie odwrotnie.
5. Opowiedz o procesie, który poprawiłeś
Czego szukają: struktury, liczb i Twojego osobistego wkładu, nie sukcesu całego zespołu.
Opowiadam metodą STAR i zawsze z liczbami. Przykład: obieg akceptacji faktur trwał 11 dni i księgowość tonęła w monitach. Zmapowałem proces as-is i policzyłem, że 6 z tych 11 dni to czekanie na jedną osobę z prawem podpisu. Zaproponowałem wyższy próg samodzielnej akceptacji i zastępstwa - proces zszedł do 4 dni. Mój wkład: mapa, pomiar i rekomendacja; decyzję podjął dyrektor finansowy.
Czerwona flaga: „zrobiliśmy, wdrożyliśmy, poprawiliśmy” bez jednego „ja” i bez jednej liczby. Nie masz doświadczenia komercyjnego? Ta sama struktura działa dla projektu treningowego albo usprawnienia z obecnej, nieanalitycznej roli.
Pytania techniczne - SQL i modelowanie (6-10)
6. Napisz zapytanie: klienci z więcej niż 3 zamówieniami w miesiącu
Czego szukają: rozumienia GROUP BY i HAVING oraz tego, czy myślisz na głos, zanim piszesz.
Zanim napiszę, doprecyzuję: chodzi o klientów, którzy w którymkolwiek miesiącu złożyli więcej niż 3 zamówienia? Jeśli tak, grupuję po dwóch wymiarach naraz: kliencie i miesiącu.
SELECT customer_id,
DATE_TRUNC('month', order_date) AS miesiac,
COUNT(*) AS liczba_zamowien
FROM orders
GROUP BY customer_id, DATE_TRUNC('month', order_date)
HAVING COUNT(*) > 3;Dwie rzeczy mówię przy tym na głos. Warunek na wyniku agregacji musi trafić do HAVING, bo WHERE filtruje wiersze przed grupowaniem. A najczęstszy błąd to grupowanie tylko po kliencie - wtedy liczę zamówienia z całej historii, nie z miesiąca. Podstawy i typowe zadania przećwiczysz we wpisie SQL dla analityka biznesowego.
Czerwona flaga: WHERE COUNT(*) > 3. Zdradza, że kandydat pisał SQL wyłącznie w tutorialach.
7. Czym różni się INNER JOIN od LEFT JOIN?
Czego szukają: nie definicji, tylko świadomości, kiedy zły JOIN po cichu psuje raport.
INNER JOIN zwraca tylko wiersze z dopasowaniem po obu stronach; LEFT JOIN zwraca wszystkie wiersze z lewej tabeli, a przy braku pary wstawia NULL-e. Na przykładzie: łączę klientów z zamówieniami. INNER pokaże wyłącznie klientów, którzy coś kupili; LEFT pokaże wszystkich - dlatego LEFT JOIN z warunkiem IS NULL to standardowy sposób na znalezienie klientów bez zakupów. Konsekwencja biznesowa: jeśli w raporcie aktywności użyję INNER-a, klienci bez zamówień znikną bez ostrzeżenia i raport skłamie. Wybór JOIN-a zaczynam więc od pytania, czy wiersze bez pary mają być w wyniku.
Czerwona flaga: poprawna definicja i cisza przy pytaniu „a kiedy ta różnica ma znaczenie w raporcie?”.
8. Zmapuj proces zwrotu towaru w e-commerce
Czego szukają: jak myślisz, nie idealnego diagramu. Rekruter patrzy, czy pytasz przed rysowaniem.
Zaczynam od granic i pytań: gdzie proces się zaczyna (zgłoszenie klienta) i gdzie kończy (zwrot pieniędzy czy przyjęcie towaru na magazyn?), jakie kanały zwrotu obsługujemy i kto w nim występuje - klient, obsługa, magazyn, księgowość. Potem rysuję happy path: zgłoszenie, weryfikacja zamówienia, etykieta zwrotna, odbiór na magazynie, kontrola stanu towaru, zwrot płatności, powiadomienie klienta. Dopiero na końcu dokładam wyjątki, bo to one bolą w produkcji: towar uszkodzony, zwrot po terminie, płatność za pobraniem. I mówię głośno, co pomijam i dlaczego.
Czerwona flaga: rysowanie od pierwszej sekundy, zero pytań doprecyzowujących. Jak prowadzić takie mapowanie krok po kroku, pokazuję w analizie procesów as-is i to-be.
9. Jak zweryfikujesz jakość danych do raportu?
Czego szukają: systemu zamiast „patrzę, czy liczby wyglądają sensownie”.
Sprawdzam pięć rzeczy w stałej kolejności. Kompletność: NULL-e w polach obowiązkowych i dziury w okresach. Unikalność: duplikaty po kluczu biznesowym, nie technicznym. Spójność: jedną liczbę, na przykład sumę zamówień, porównuję z raportem, któremu biznes już ufa. Zakresy: wartości ujemne tam, gdzie ich być nie może, daty z przyszłości. Aktualność: kiedy dane były ostatnio zasilone. Do tego jedno pytanie do właściciela danych o znane problemy źródła - zwykle oszczędza mi dnia pracy.
Czerwona flaga: „zakładam, że dane z systemu są poprawne”.
10. Jakie znasz notacje modelowania i kiedy których używasz?
Czego szukają: doboru narzędzia do odbiorcy. Wyliczanka nazw nie jest odpowiedzią.
Kryterium mam jedno: kto będzie czytał model. Procesy modeluję w BPMN, ale z biznesem trzymam się podstawowego zestawu symboli, bo pełna notacja odstrasza. Do rozmów z deweloperami o interakcjach używam UML, najczęściej diagramów sekwencji i przypadków użycia. Strukturę danych pokazuję na ERD. A gdy odbiorcą jest zarząd, najlepszą „notacją” bywa prosty schemat blokowy - zrozumienie bije poprawność formalną. Model ma odpowiadać na konkretne pytanie, nie zdobić dokumentację.
Czerwona flaga: sześć nazw notacji i cisza przy „a kiedy której?”. Na naszym job boardzie BPMN pojawia się w 22%, a UML w 20% aktywnych ofert - to dwie najczęściej tagowane kompetencje, więc podstawy obu się opłacają; zacznij od wpisu czym jest BPMN.
Pytania 1-10 możesz sprawdzić na sucho już teraz: darmowe testy wiedzy działają bez konta i pokazują wynik od razu. Potraktuj je jak pierwszą przymiarkę przed próbą generalną z planu na końcu artykułu.
Pytania sytuacyjne i miękkie (11-15)
11. Interesariusz żąda funkcji, która nie ma sensu - co robisz?
Czego szukają: czy docierasz do problemu ukrytego za żądaniem, nie niszcząc relacji.
Nie oceniam żądania, tylko pytam o problem: co dziś nie działa i co się stanie, jeśli tej funkcji nie będzie? Zwykle wystarczą dwa, trzy „dlaczego”, żeby zejść z poziomu rozwiązania na poziom potrzeby - a za dziwnym żądaniem prawie zawsze stoi realny problem, który da się rozwiązać taniej. Jeśli po zrozumieniu kontekstu funkcja dalej nie ma uzasadnienia, pokazuję jej koszt i co innego moglibyśmy zrobić za te pieniądze. Decyzję zostawiam właścicielowi budżetu i zapisuję ją z uzasadnieniem. Moja rola to świadoma decyzja, nie wygrany spór.
Czerwona flaga: „klient nasz pan, robię” albo „mówię wprost, że to bez sensu”. Pierwsza oblewa test na analityka, druga na współpracownika. Jak pracować z trudnymi interesariuszami, opisuję w analizie interesariuszy.
12. Jak priorytetyzujesz wymagania?
Czego szukają: jednej techniki znanej naprawdę plus świadomości jej pułapek.
Najczęściej używam MoSCoW: Must, Should, Could, Won't. Na przykładzie sklepu internetowego: płatność online to Must, bo bez niej nie wdrażamy; filtrowanie produktów to Should; lista życzeń to Could; program lojalnościowy to Won't - świadomie odłożony, nie zapomniany. Pułapka tej techniki: bez dyscypliny wszystko ląduje w Must. Bronię się definicją - Must to wyłącznie to, bez czego wdrożenie traci sens prawny albo biznesowy - i proszę o uzasadnienie każdego Must osobno. Gdy interesariusze się spierają, dokładam drugi wymiar: wartość biznesową względem kosztu realizacji.
Czerwona flaga: zna nazwę MoSCoW, ale nie poda przykładu niczego, co włożyłby do Won't. Tę i 258 innych definicji znajdziesz w słowniku pojęć BA.
13. Projekt się pali, zakres rośnie - jaka jest Twoja rola?
Czego szukają: czy rozumiesz scope creep i czy w kryzysie wnosisz fakty, a nie nadgodziny.
Moja rola to dać decydentom rzetelny obraz: co dokładnie jest w zakresie, skąd przyszły nowe pozycje i ile każda kosztuje. Robię przegląd zakresu względem celu biznesowego - zwykle część „koniecznych” rzeczy tego celu nie wspiera i można je wyciąć albo odłożyć. Przygotowuję opcje z konsekwencjami: tniemy zakres, przesuwamy termin albo dokładamy ludzi. Nowe żądania kieruję przez formalną ścieżkę zmiany - nie żeby blokować, tylko żeby każda zmiana była świadomą decyzją, a nie przemyconym mailem. Panika jest zaraźliwa; analityk z faktami na stole jest w kryzysie najspokojniejszą osobą w pokoju.
Czerwona flaga: „zostawałbym po godzinach, żeby nadgonić” - odpowiedź o wysiłku, nie o zarządzaniu zakresem.
14. Czego nie wiesz i jak się tego nauczysz?
Czego szukają: samoświadomości i systemu uczenia się. To pułapka skromności: grzebie zarówno „nie mam słabych stron”, jak i zbyt szczera spowiedź.
Wybieram lukę prawdziwą, ale nie leżącą w rdzeniu roli - i pokazuję, że już nad nią pracuję. Na przykład: najsłabiej czuję się w tematach integracyjnych, konkretnie w czytaniu kontraktów REST API. Wiem to, bo na ostatnim projekcie prosiłem dewelopera o tłumaczenie dokumentacji. Robię z tym trzy rzeczy: przeszedłem podstawy protokołu, czytam dokumentację API przy każdej okazji i siadam z deweloperami, gdy projektują kontrakt. Cel na pół roku: samodzielnie przygotować specyfikację integracji tak, żeby wymagała przeglądu, a nie napisania od nowa.
Czerwona flaga: „jestem perfekcjonistą” oraz luka dyskwalifikująca w rdzeniu roli, typu „nie lubię rozmawiać z ludźmi”.
15. Dlaczego chcesz być analitykiem biznesowym / zmienić firmę?
Czego szukają: motywacji „do”, nie ucieczki „od”. I spójności z CV.
W poprzedniej roli najwięcej satysfakcji dawało mi tłumaczenie potrzeb między ludźmi mówiącymi różnymi językami - zauważyłem, że robię to chętniej niż własne zadania. Sprawdziłem, czy to nie chwilowy kaprys: przeszedłem kurs podstaw analizy, zrobiłem projekt treningowy z dokumentacją wymagań i porozmawiałem z trzema pracującymi analitykami o ich codzienności, także tej nudnej. Wiem, na co się piszę: dużo spotkań, dokumentacji i godzenia sprzeczności. I właśnie to mnie interesuje - być osobą, która zamienia chaos oczekiwań w coś, co da się zbudować.
Czerwona flaga: narzekanie na obecnego pracodawcę i motywacja czysto finansowa. Przechodzisz z innej branży? Przygotuj mostek kompetencji - jak go zbudować, opisuję we wpisie o przebranżowieniu na analityka biznesowego.
Zadanie domowe rekrutacyjne - jak je zrobić lepiej niż inni kandydaci
Trzy najczęstsze formaty: case biznesowy z rekomendacją, dokument wymagań albo user stories dla opisanej funkcji, diagram procesu na podstawie tekstu. Zasady są wspólne:
- Zanim zaczniesz, odeślij pytania doprecyzowujące. Błąd numer jeden to oddanie zadania bez ani jednego pytania. Treść jest celowo niedopowiedziana - rekruter sprawdza, czy zauważysz luki. Analityk, który nie pyta, produkuje fikcję.
- Założenia zapisuj jawnie. Tam, gdzie nie dostałeś odpowiedzi, przyjmij założenie i oznacz je w dokumencie. Dokładnie tak robi się w realnej pracy.
- Trzymaj się limitu. Rzecz skończona w zadanym zakresie bije rzecz ambitną w 60%.
- Daj strukturę: cel, zakres, rozwiązanie, ryzyka, pytania otwarte. Sekcja ryzyk i pytań otwartych odróżnia kandydatów myślących od wykonujących.
- Przygotuj obronę decyzji. Na kolejnym etapie usłyszysz „dlaczego tak?”. Ocenie podlega tok myślenia, nie sam plik.
Pytania, które Ty zadajesz rekruterowi
Brak pytań od kandydata to dla mnie sygnał ostrzegawczy: analityk, który o nic nie pyta na rozmowie o własną przyszłość, nie zapyta też na projekcie. Te sześć pokazuje dojrzałość:
- Jak wygląda proces wytwórczy: kto dziś pisze wymagania i co się z nimi dzieje dalej?
- Ilu analityków pracuje w organizacji i komu raportują - IT, biznesowi czy PMO?
- Po czym poznacie po trzech miesiącach, że ta rekrutacja się udała?
- Z jakimi interesariuszami będę pracować najczęściej i który bywa najtrudniejszy?
- Jakie narzędzia i notacje są standardem zespołu i czy mogę zobaczyć przykładowy, zanonimizowany artefakt?
- Jaki problem zespołu ta rola ma rozwiązać - dlaczego rekrutujecie właśnie teraz?
Pytanie trzecie ma bonus: odpowiedź to gotowa lista kryteriów sukcesu na okres próbny. Zapisz ją sobie.
Plan przygotowania na 7 dni przed rozmową
Plan zakłada, że podstawy masz. Jeśli dopiero układasz wejście do zawodu, zacznij od ścieżki jak zostać analitykiem biznesowym i wróć tu z zaproszeniem na rozmowę w ręku.
- Dzień 7 - wywiad. Przeczytaj ogłoszenie trzy razy i wypisz każdą wymaganą kompetencję. Sprawdź firmę: czym zarabia, co wdraża, kto będzie po drugiej stronie stołu.
- Dzień 6 - dopasowanie. Do każdej kompetencji z ogłoszenia przypisz swój dowód: projekt, kurs, artefakt. Braki zapisz - to kandydaci na pytanie 14.
- Dzień 5 - podstawy. Przejdź pytania 1-5 na głos, bez czytania. Powtórki zrób fiszkami - na platformie jest ich 318 i pokrywają definicje, które padają na rozmowach.
- Dzień 4 - technika. Pytania 6-10: napisz zapytania SQL ręcznie, narysuj proces zwrotu na kartce w 15 minut.
- Dzień 3 - historie. Przygotuj trzy opowieści STAR z liczbami: usprawnienie, konflikt, porażka z wnioskiem. Pokryją większość pytań sytuacyjnych.
- Dzień 2 - próba generalna. Zrób darmowy test wiedzy jak egzamin: bez podglądania, z zegarem. Wynik pokaże, gdzie wracać. Potem odpowiedz na głos na wszystkie 15 pytań - nagraj się telefonem i przesłuchaj.
- Dzień 1 - logistyka i głowa. Sprawdź link do spotkania, przygotuj pytania do rekrutera i wydrukowane CV. Żadnej nowej wiedzy. Wyśpij się.
Wolisz wersję do druku? Pełną listę pytań z miejscem na własne odpowiedzi zebrałem w darmowym pakiecie pytania rekrutacyjne dla BA.
FAQ: rozmowa kwalifikacyjna analityka biznesowego
Co robić, gdy nie znam odpowiedzi na pytanie techniczne?
Powiedz to wprost i pokaż, jak byś szukał: „nie pisałem takiego zapytania, ale zacząłbym od dokumentacji funkcji okna”. Rekruterzy wybaczają luki. Nie wybaczają ściemniania, bo jedno dopytanie je obnaża.
Czy na rozmowie na juniora pytają o SQL?
Coraz częściej o podstawy: JOIN-y, GROUP BY, proste warunki. Na naszym job boardzie SQL pojawia się w 15% aktywnych ofert - rzadziej niż BPMN i UML - więc nie buduj całego przygotowania wokół SQL-a. Rdzeń rozmowy to wymagania, procesy i interesariusze.
Czy muszę znać BABOK na pamięć?
Nie. Struktura BABOK-a pomaga uporządkować wiedzę, ale rekruterzy sprawdzają praktykę, nie paginację. Żadne z 15 pytań powyżej nie wymaga cytowania podręcznika; wszystkie wymagają myślenia.
Ile etapów ma typowa rekrutacja na analityka?
Z mojego doświadczenia: dwa do czterech etapów, najczęściej trzy (HR, techniczny, finałowy), rozłożone na kilka tygodni. Zadanie domowe pojawia się zwykle między rozmową HR a techniczną i odsiewa najwięcej kandydatów.
Na koniec uczciwie: żaden artykuł nie zastąpi przećwiczenia odpowiedzi na głos. Różnica między kandydatem, który przeczytał, a tym, który przećwiczył, jest słyszalna w pierwszych pięciu minutach rozmowy.
A jeśli chcesz mieć braki pod kontrolą wcześniej niż tydzień przed rozmową: na Analify masz 10 kursów, 200+ testów, sandbox SQL i symulator rozmów AI do ćwiczenia takich scenariuszy - dostęp kosztuje 109 zł/mies, a pierwsze 50 osób blokuje tę cenę bezterminowo.
Zacznij od próby generalnej: darmowy test wiedzy - bez konta, wynik od razu. Lepiej dziś zobaczyć, gdzie są dziury, niż odkryć je na rozmowie.