Przygotowanie do rozmowy

Programista Mobilny: pytania rekrutacyjne i odpowiedzi

Rozmowa na stanowisko Programista Mobilny sprawdza nie tylko znajomość kodu, ale też myślenie o architekturze, wydajności i pracy w warunkach słabego internetu. Ważne są także testy, integracja z backendem, lifecycle oraz umiejętność wyjaśniania decyzji technicznych.

Written & reviewed by the CVWon Editorial Team · Updated lipiec 2026

Utworzyć CV

Pytania i odpowiedzi

Pytania rekrutacyjne i wzorcowe odpowiedzi

Warto przygotować się na te częste pytania, korzystając ze szczegółowych wzorcowych odpowiedzi.

Dlaczego pada to pytanie

Rekruter chce sprawdzić, czy potrafisz myśleć o aplikacji jak o produkcie, a nie tylko o ekranach.

Wzorcowa odpowiedź

Stawiam na jasny podział odpowiedzialności, zwykle przez MVVM albo inny model z czytelnym flow danych. UI trzymam możliwie cienko, a logikę biznesową przenoszę do warstw, które da się testować bez zależności od frameworka. Dzielę też aplikację na moduły funkcjonalne, żeby zespół mógł pracować równolegle, a build i deployment nie zamieniały się w chaos. Dzięki temu aplikacja rośnie bez efektu 'spaghetti'.

Nazwij konkretny wzorzec architektoniczny i pokaż, jak wspiera testowalność oraz pracę zespołową.

Dlaczego pada to pytanie

W mobile performance bezpośrednio wpływa na retencję i oceny w store, więc to jeden z kluczowych tematów.

Wzorcowa odpowiedź

Najpierw profiluję, zamiast zgadywać. Sprawdzam czas startu, frame rate, użycie pamięci i miejsca, w których blokuje się główny wątek. Typowe usprawnienia to przeniesienie ciężkich operacji poza UI thread, poprawa renderowania list, ograniczenie overdraw, sensowne cache'owanie obrazów i unikanie nadmiarowych alokacji. Dbam też o rozmiar aplikacji, bo wpływa na instalację i pierwsze uruchomienie.

Pokaż, że diagnozujesz problem metrykami, a nie intuicją.

Dlaczego pada to pytanie

Na mobile sieć jest zawodna, więc sprawdzają, czy projektujesz pod realne warunki użycia.

Wzorcowa odpowiedź

Projektuję aplikację tak, żeby była użyteczna także bez stałego połączenia. Często oznacza to local cache, kolejkę operacji do synchronizacji i jasny status sync dla użytkownika. Przy konfliktach danych mam z góry ustaloną strategię, a sieć obsługuję przez timeouty, retry i backoff. Nie zakładam, że użytkownik ma idealne łącze, bo w praktyce to rzadkość.

Wspomnij o kolejkowaniu akcji i czytelnym feedbacku, nie tylko o cache'owaniu.

Dlaczego pada to pytanie

Lifecycle bugs są częstą przyczyną crashy, więc chcą ocenić Twoją znajomość platformy.

Wzorcowa odpowiedź

Pilnuję zasad platformy: stan ma się poprawnie zapisać i odtworzyć po przełączeniu aplikacji do tła, rotacji ekranu czy ubiciu procesu przez system. Ważne dane persystuję, żeby użytkownik wracał dokładnie tam, gdzie przerwał. Zwalniam też zasoby, nasłuchi i ciężkie obiekty, gdy aplikacja nie jest aktywna, żeby uniknąć wycieków pamięci i problemów z baterią. Dobrze obsłużony lifecycle to znak dopracowanej aplikacji.

Podkreśl, że myślisz o process death, a nie tylko o rotacji ekranu.

Dlaczego pada to pytanie

Chcą zobaczyć, czy masz realne doświadczenie w dowożeniu funkcji, a nie tylko pisaniu kodu.

Wzorcowa odpowiedź

Zbudowałem w aplikacji skaner dokumentów, który musiał działać płynnie na szerokiej gamie urządzeń. Przetwarzanie obrazu przeniosłem poza główny wątek, a wszystkie edge cases związane z permissionami i różnicami sprzętowymi obsłużyłem tak, żeby użytkownik nie wpadał w ślepe zaułki. Testowałem rozwiązanie na słabszych i mocniejszych telefonach, żeby uzyskać stabilny performance. Funkcja weszła na produkcję z niskim crash rate i dobrą adopcją.

Pokaż end-to-end ownership: od problemu biznesowego po edge cases i monitoring po wdrożeniu.

Techniczne

Rozmowa kwalifikacyjna: Programista Mobilny – jakie pytania techniczne padają najczęściej?

Na rozmowie kwalifikacyjnej warto spodziewać się tych pytań technicznych, typowych dla danego stanowiska.

Główny wątek odpowiada za renderowanie UI i obsługę inputu, więc jego blokowanie powoduje lagi, dropped frames i brak reakcji aplikacji. Ciężkie zadania, takie jak sieć, dysk czy obliczenia, powinny działać w tle, a wynik wracać do UI tylko wtedy, gdy trzeba zaktualizować ekran. W skrajnym przypadku system może uznać aplikację za nieodpowiadającą i ją zamknąć.

Pomagają: ładowanie obrazów w odpowiedniej rozdzielczości, cache, recycling widoków w długich listach, unikanie memory leaks przez czyszczenie referencji i listenerów oraz leniwe ładowanie ciężkich zasobów. Warto profilować pamięć, żeby znaleźć realne przecieki i duże alokacje. Niski footprint zmniejsza ryzyko ubicia aplikacji na słabszych urządzeniach.

Native development używa języka i narzędzi danej platformy, daje pełny dostęp do funkcji systemu i zwykle najlepszy performance, ale oznacza osobne codebase'y. Cross-platform pozwala współdzielić większość kodu między platformami, co przyspiesza development, ale czasem kosztuje to w performance albo w dostępie do najnowszych funkcji natywnych. Wybór zależy od potrzeb produktu, składu zespołu i tego, ile kodu realnie da się współdzielić.

Stosuję responsywny layout oparty na elastycznych ograniczeniach, a nie na sztywnych współrzędnych. Używam jednostek zależnych od gęstości, żeby interfejs wyglądał spójnie na różnych ekranach, oraz assetów w kilku rozdzielczościach albo grafik wektorowych. Testuję też na telefonach z małym i dużym ekranem, a jeśli trzeba, uwzględniam również tablety.

Tokeny i sekrety trzymam w secure storage, np. w keychain albo keystore, a nie w zwykłych preferencjach. Nie loguję wrażliwych danych, szyfruję lokalne bazy tam, gdzie to uzasadnione, i stosuję certificate pinning w wyżej wrażliwych integracjach. Zakładam też, że urządzenie może być częściowo skompromitowane, więc najbardziej krytyczne walidacje zostawiam po stronie backendu.

Sytuacyjne

Rozmowa kwalifikacyjna: Programista Mobilny – jak przygotować się do pytań sytuacyjnych?

Scenariusze behawioralne i sytuacyjne, które mogą pojawić się na rozmowie.

Mieliśmy crashe widoczne tylko na części słabszych urządzeń i nie dało się ich łatwo odtworzyć lokalnie. Sięgnąłem po crash analytics, wyciągnąłem stack trace i wzorzec urządzeń, co wskazało na problem z pamięcią przy ładowaniu obrazów w pełnej rozdzielczości. Zmieniłem sizing i cache'owanie, a testy wykonałem na podobnym low-end device. W efekcie crash rate dla tego problemu spadł praktycznie do zera.

Tuż przed premierą dostaliśmy odrzucenie związane z permissionami. Przeanalizowałem feedback, usunąłem zbędne permission i doprecyzowałem opis użycia tych, które były rzeczywiście potrzebne. Następnie wysłałem poprawioną wersję z jasnym wyjaśnieniem do review. Aplikacja została zaakceptowana na czas, a my dodaliśmy checklistę przed publikacją, żeby nie powtarzać błędu.

Aplikacja zbyt długo stawała się interaktywna po uruchomieniu, co obniżało retencję. Zprofilowałem startup, odsunąłem niekrytyczną inicjalizację poza ścieżkę krytyczną i lazy-loadowałem cięższe moduły. Zmierzyłem cold start przed i po zmianach, żeby potwierdzić efekt. Czas startu spadł wyraźnie, a early-session drop-off się poprawił.

Mieliśmy projekt z bogatymi animacjami, które mogły powodować jank na średnich urządzeniach. Wspólnie z designerem dopracowałem motion tak, żeby zachować premium feeling, ale jednocześnie renderować płynnie. Implementację zoptymalizowałem pod GPU i przetestowałem na reprezentatywnych modelach telefonów. Finalnie UI wyglądało zgodnie z projektem i działało stabilnie na całej grupie urządzeń.

Przygotowanie

Wskazówki dotyczące przygotowania

Przygotuj 2-3 konkretne historie z własnych projektów: architektura, performance, release albo bug produkcyjny.

Odśwież lifecycle, threading, memory management i zasady pracy z UI thread dla wybranej platformy.

Przećwicz opowieść o tym, jak diagnozujesz problem na podstawie metryk, crash analytics i profilingu.

Bądź gotów omówić integrację z backendem, offline support, cache i konflikt synchronizacji.

Jeśli aplikujesz do firm w hubach IT jak Warszawa, Kraków czy Wrocław, sprawdź też, czy rola jest pod pracę zdalną czy hybrydową.

Jak odpowiedzieć na pytanie: „Jakie są Pana/Pani oczekiwania finansowe?”

Na rynku polskim wynagrodzenie brutto/mies. dla Programisty Mobilnego zależy od doświadczenia, technologii i modelu współpracy. Przy umowie o pracę typowe widełki są zwykle niższe nominalnie niż przy B2B, ale dają ZUS i płatny urlop; zlecenie bywa pośrednie, a B2B (JDG) najczęściej ma najwyższą stawkę, ale samodzielnie ogarniasz ZUS i PIT. Dla ról w Warszawie, Krakowie i Wrocławiu różnice potrafią być znaczące, podobnie jak przy pracy zdalnej i hybrydowej. Ja najlepiej czuję się, gdy możemy odnieść stawkę do zakresu odpowiedzialności, poziomu i modelu współpracy, a potem doprecyzować konkretną kwotę po rozmowie o oczekiwaniach i zespole.

FAQ

Najczęściej zadawane pytania

To zależy od celu zawodowego. Głęboka specjalizacja w jednej platformie często mocniej pomaga w rekrutacjach do zespołów natywnych, zwłaszcza jeśli chcesz pracować nad bardziej wymagającym produktem. Cross-platform zwiększa elastyczność i bywa bardzo cenione w mniejszych firmach lub przy szybkich dostawach. W praktyce najlepiej znać jedną platformę naprawdę dobrze, a drugą rozumieć na poziomie świadomego korzystania.

Tak, bardzo możliwe. Wiele firm łączy pytania mobilne z ogólnymi zadaniami z kodowania, żeby sprawdzić podstawy programowania, myślenie o złożoności i umiejętność rozwiązywania problemów. Nie musisz być olimpijczykiem, ale powinieneś swobodnie pracować na listach, mapach, kolejkach i znać podstawy optymalizacji.

Bardzo ważny. Użytkownik szybko porzuca aplikację, która wolno działa, klatkuje albo długo się uruchamia. Dlatego warto umieć mówić o profilowaniu, pamięci, threading i testach na słabszych urządzeniach. To jeden z tematów, które często odróżniają juniora od bardziej dojrzałego kandydata.

Tak, bo to pokazuje, czy masz realne doświadczenie dowożenia produktu. Warto znać podstawy procesu publikacji, review, staged rollout, obsługi crashy po wdrożeniu i pracy z checklistą przed release. Jeśli wspomnisz też o CI/CD i monitoringu, zrobisz bardzo dobre wrażenie.

Pokaż, że myślisz jak osoba odpowiedzialna za produkt: performance, offline, crash rate, UX i edge cases mają dla Ciebie znaczenie. Pomagają konkretne przykłady z projektów, najlepiej z liczbami, np. skrócenie czasu startu albo zmniejszenie liczby crashy. Dodatkowy plus to dobra komunikacja i umiejętność współpracy z backendem, QA i designerem.