Jednym z najbardziej znanych ćwiczeń rekrutacyjnych jest fizz buzz: proste zadanie z liczbami, które szybko pokazuje, czy kandydat rozumie pętle, warunki i kolejność sprawdzania reguł. To nie jest egzamin z chytrze napisanego kodu, tylko test podstaw, a właśnie dlatego tak dobrze działa na rozmowach o pracę w IT. W tym tekście rozkładam je na części: od zasad, przez gotowy sposób rozwiązania, po najczęstsze błędy i to, co naprawdę ocenia osoba prowadząca rozmowę.
Najkrótsza wersja mówi, że liczą się podstawy, a nie sprytne sztuczki
- Zadanie polega na przejściu po sekwencji liczb i zastępowaniu wybranych wartości słowami „Fizz”, „Buzz” lub „FizzBuzz”.
- Najważniejsza zasada techniczna to sprawdzanie wielokrotności 15 przed 3 i 5.
- Na rozmowie rekrutacyjnej liczy się też to, jak tłumaczysz tok myślenia, a nie tylko sam wynik.
- Najlepsze rozwiązanie jest zwykle proste, czytelne i łatwe do przetestowania.
- To ćwiczenie dobrze pokazuje, czy kandydat umie pracować bez chaosu i bez niepotrzebnego komplikowania prostego problemu.
Czym jest zadanie FizzBuzz i po co w ogóle się je zadaje
Zadanie FizzBuzz polega na przejściu przez kolejne liczby i zamienianiu części z nich na słowa według prostych reguł. Jeśli liczba dzieli się przez 3, zwracasz „Fizz”, jeśli przez 5, zwracasz „Buzz”, a jeśli przez oba te dzielniki, zwracasz „FizzBuzz”. Wszystkie pozostałe liczby zostają bez zmian.
Brzmi banalnie, ale właśnie o to chodzi. W praktyce rekruter sprawdza w ten sposób kilka rzeczy naraz: czy umiesz napisać pętlę, czy rozumiesz instrukcje warunkowe, czy zauważasz przypadek graniczny oraz czy potrafisz mówić o rozwiązaniu w uporządkowany sposób. Sam traktuję takie zadanie jako szybki test fundamentów, nie jako próbę złapania kogoś na sztuczce.
To też dobry przykład na to, że w IT często wygrywa nie najbardziej efektowne rozwiązanie, tylko takie, które jest jasne, odporne na błędy i łatwe do utrzymania. Kiedy rozumiesz sens zadania, łatwiej przejść do samej sekwencji i zobaczyć, gdzie dokładnie zaczyna się reguła.
Jak działa reguła na liczbach od 1 do 15
Najprościej zrozumieć ten problem na krótkim przykładzie. Dla zakresu od 1 do 15 wynik wygląda tak:
| Liczba | Wynik |
|---|---|
| 1 | 1 |
| 2 | 2 |
| 3 | Fizz |
| 4 | 4 |
| 5 | Buzz |
| 6 | Fizz |
| 7 | 7 |
| 8 | 8 |
| 9 | Fizz |
| 10 | Buzz |
| 11 | 11 |
| 12 | Fizz |
| 13 | 13 |
| 14 | 14 |
| 15 | FizzBuzz |
Tu najłatwiej widać pułapkę: liczba 15 pasuje do dwóch warunków jednocześnie. Dlatego najpierw sprawdza się podzielność przez 15, a dopiero potem przez 3 i 5 osobno. Jeśli odwrócisz kolejność, 15 zostanie błędnie zapisane jako „Fizz” albo „Buzz”, zależnie od implementacji.
W rekrutacji ten szczegół ma duże znaczenie, bo pokazuje, czy kandydat myśli o wyjątkach, a nie tylko o najprostszym przypadku. Gdy ta zasada jest już jasna, sam algorytm staje się prosty do zapisania.
Jak rozwiązać to zadanie bez zbędnego kombinowania
Najlepsze rozwiązanie zwykle składa się z czterech prostych kroków: przejść przez liczby, sprawdzić podzielność przez 15, potem przez 3, potem przez 5, a w pozostałych przypadkach zwrócić samą liczbę. Nie ma potrzeby dorabiania specjalnych struktur danych ani wymyślania „genialnego” skrótu, jeśli nie poprawia czytelności.
- Ustal zakres, najczęściej od 1 do
n. - Dla każdej liczby sprawdź najpierw warunek dla 15.
- Jeśli nie pasuje, sprawdź 3, potem 5.
- Jeśli żaden warunek nie zachodzi, wypisz liczbę.
Przykładowo w Pythonie wygląda to tak:
def fizzbuzz(n):
for i in range(1, n + 1):
if i % 15 == 0:
print("FizzBuzz")
elif i % 3 == 0:
print("Fizz")
elif i % 5 == 0:
print("Buzz")
else:
print(i)Ten sam schemat przeniesiesz do JavaScriptu, Javy, C# czy Go. Jeśli zadanie ma zwracać tablicę zamiast drukować wynik na ekran, zmieniasz tylko sposób zapisu rezultatu, a nie samą logikę. To właśnie jest dobra odpowiedź na rozmowie: prosta, poprawna i łatwa do przeniesienia.
W praktyce samo rozwiązanie niewiele znaczy bez zrozumienia, co dokładnie chce usłyszeć osoba po drugiej stronie stołu, więc warto od razu spojrzeć na to oczami rekrutera.
Co rekruter naprawdę sprawdza
W takich zadaniach rekruter nie szuka pokazówki. Zwykle chce zobaczyć, czy kandydat potrafi przejść od wymagań do działającego, czytelnego kodu bez zgadywania i bez zgubienia przypadku granicznego. Ja patrzę na to bardziej jak na próbkę stylu pracy niż jak na łamigłówkę.
| Co sprawdza zadanie | Co oznacza dobra odpowiedź |
|---|---|
| Zrozumienie treści | Potrafisz własnymi słowami powtórzyć zasady i dopytać o niejasności. |
| Kolejność warunków | Wiesz, że przypadek 15 musi być sprawdzony przed 3 i 5. |
| Komunikacja | Mówisz, co robisz i dlaczego, zamiast pisać kod w ciszy. |
| Poprawność | Rozwiązanie działa dla małych i większych zakresów, nie tylko dla przykładu z tablicy. |
| Czytelność | Kod jest prosty do przeczytania po minucie, a nie po dziesięciu. |
To ważne zwłaszcza na stanowiskach juniorskich, gdzie liczy się nie tyle rozbudowany warsztat, ile zdrowe podstawy i sposób myślenia pod presją. Jeśli kandydat umie spokojnie przeprowadzić rozmowę przez rozwiązanie, zwykle robi lepsze wrażenie niż ktoś, kto wyprodukował „sprytny” kod bez wyjaśnienia.
Kiedy wiesz, co jest oceniane, łatwiej też zrozumieć, jakie błędy najczęściej psują całkiem niezłą odpowiedź.
Najczęstsze błędy i słabe odpowiedzi
Widziałem już wiele wariantów tego zadania i najczęściej problemem nie jest logika samego FizzBuzza, tylko pośpiech albo nadmierne kombinowanie. Oto błędy, które wracają najczęściej:
- Zła kolejność warunków - sprawdzenie 3 i 5 przed 15 powoduje błędny wynik dla wielokrotności obu liczb.
- Brak testu dla 15 - kandydat pokazuje działanie na 3 i 5, ale pomija najważniejszy przypadek wyjątkowy.
-
Założenie, że zakres zawsze wynosi 1–100 - w zadaniu często pojawia się parametr
n, więc warto myśleć elastycznie. - Przekombinowanie rozwiązania - kilka klas, abstrakcja i wzorzec projektowy do prostego zadania zwykle wyglądają gorzej niż dobrze napisany warunek.
- Niejasne wyjaśnienie na głos - jeśli nie potrafisz opisać kolejności działań, rekruter może uznać, że rozumiesz kod tylko powierzchownie.
- Pomijanie pytania o format wyniku - czasem trzeba wypisać tekst, a czasem zwrócić listę; to drobiazg, ale na rozmowie zdradza uwagę do detali.
Najlepsza obrona przed tymi błędami jest zaskakująco prosta: mów głośno o założeniach, zacznij od najczytelniejszej wersji i dopiero potem ewentualnie ją ulepszaj. Gdy to masz opanowane, warto przejść do ćwiczenia, które daje z tego zadania realną wartość w karierze.
Jak ćwiczyć ten typ zadania, żeby pomógł w karierze w IT
Sam polecam trenować FizzBuzza nie po to, żeby go „wykuć”, ale żeby wyrobić sobie automatyzm w pracy z prostymi regułami. To mała łamigłówka, ale bardzo dobrze pokazuje, czy umiesz myśleć krok po kroku, testować przypadki i nie zgubić się w podstawach.
- Napisz rozwiązanie z pamięci, bez podglądania gotowca.
- Opowiedz je na głos tak, jakbyś był na rozmowie technicznej.
- Dopisz testy dla 1, 3, 5, 15 i 16, żeby sprawdzić zwykłe i graniczne przypadki.
- Zrób wersję, która zwraca tablicę, a nie wypisuje wynik, bo to częsty wariant zadania.
- Zmień reguły i sprawdź, czy potrafisz szybko dostosować kod bez przepisywania wszystkiego od zera.
Jeśli dobrze opanujesz takie podstawowe ćwiczenia, rozmowy rekrutacyjne przestają być loterią. Zostaje spokojne pokazanie, że umiesz czytać wymagania, pisać prosty kod i kontrolować szczegóły, a w IT właśnie to bardzo często decyduje o pierwszym dobrym wrażeniu.
