Przygotowanie do rozmowy

Programista Frontend: pytania i odpowiedzi na rozmowie

Rozmowa na stanowisko Programisty Frontend sprawdza nie tylko JavaScript i framework, lecz także sposób myślenia o przeglądarce, wydajności, dostępności i współpracy z designem. Poniżej znajdziesz pytania, które naprawdę padają na rozmowach, oraz odpowiedzi pokazujące świadome, produktowe podejście do UI.

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

To sprawdza, czy projektujesz stan świadomie, zamiast automatycznie wrzucać wszystko do jednego miejsca.

Wzorcowa odpowiedź

Zacząłbym od zasady, że stan powinien być jak najbliżej miejsca użycia. Jeśli dotyczy jednego komponentu, zostawiam go lokalnie, bo wtedy łatwiej go testować i utrzymywać. Jeśli kilka sąsiednich komponentów musi reagować na te same zmiany, wynoszę stan wyżej. Globalny store zostawiam dla danych faktycznie współdzielonych w całej aplikacji, takich jak zalogowany użytkownik, motyw albo stan koszyka. Dane z backendu wolę obsługiwać warstwą do fetchowania i cache'owania niż wkładać je bezpośrednio do globalnego store.

Pokaż prostą regułę decyzyjną, a nie listę narzędzi.

Dlaczego pada to pytanie

Rekruter chce zobaczyć, że mierzysz, diagnozujesz i dowozisz poprawę, a nie zgadujesz.

Wzorcowa odpowiedź

W jednym projekcie dashboard na mobile miał zbyt wysoki Largest Contentful Paint. Najpierw sprawdziłem problem w Lighthouse i DevTools, a potem okazało się, że winny był ciężki obraz hero i zbyt duży bundle blokujący render. Zastosowałem responsive images, nowszy format obrazów, code splitting dla widoku i odroczenie skryptów niekrytycznych. Efekt był odczuwalny: strona zaczęła ładować się wyraźnie szybciej, a użytkownicy rzadziej ją opuszczali przed interakcją.

Podawaj konkretny metryczny efekt i narzędzia diagnozy.

Dlaczego pada to pytanie

To pokazuje, czy dostępność jest u Ciebie nawykiem, a nie dodatkiem na końcu projektu.

Wzorcowa odpowiedź

Zaczynam od semantycznego HTML, bo natywne elementy dają od razu lepszą obsługę klawiatury i czytników ekranu. Potem testuję ekran wyłącznie klawiaturą, sprawdzam widoczność focus state i kontrast kolorów. ARIA używam wtedy, gdy semantyka HTML nie wystarcza, a nie jako zamiennik dobrego markup'u. Wprowadzam też automatyczne checki dostępności do CI, żeby regresje wychwytywać wcześniej.

Mów o realnym teście: keyboard-only, screen reader, kontrast.

Dlaczego pada to pytanie

Frontend to praca cross-functional, więc sprawdzają, czy umiesz łączyć wymagania biznesowe, design i technikę.

Wzorcowa odpowiedź

Traktuję design jak wspólny proces, a nie gotowy plik do wdrożenia. Włączam się wcześniej, żeby wyłapać edge cases, takie jak empty state, error state czy zachowanie na małych ekranach. Jeśli widzę konflikt między pixel-perfect a wydajnością albo dostępnością, od razu go nazywam i proponuję kompromis. Pomaga mi też wspólny design system albo biblioteka komponentów, bo wtedy łatwiej utrzymać spójność między projektem a implementacją.

Pokaż partnerstwo i gotowość do rozmowy o trade-offach.

Dlaczego pada to pytanie

To sygnał, czy rozwijasz się dojrzale i potrafisz filtrować trendy.

Wzorcowa odpowiedź

Nie próbuję śledzić wszystkiego, tylko wybieram kilka zaufanych źródeł: release notes przeglądarek, dokumentację frameworka, którego używam, i materiały maintainerów. Nowe biblioteki oceniam przez pryzmat realnego problemu w projekcie, a nie dlatego, że są modne. Zanim coś polecę zespołowi, robię mały prototype i sprawdzam, czy to faktycznie upraszcza pracę. Dzięki temu jestem na bieżąco, ale nie wprowadzam chaosu do codebase'u.

Pokaż selektywne uczenie się, a nie pogoń za hype'em.

Techniczne

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

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

var jest funkcyjnie zakresowy i jest hoistowany z początkową wartością undefined, co bywa źródłem błędów. let i const są blokowo zakresowe i przed deklaracją znajdują się w temporal dead zone. const blokuje ponowne przypisanie referencji, ale sam obiekt, do którego wskazuje, nadal może być modyfikowany.

Virtual DOM to in-memory reprezentacja interfejsu, którą framework porównuje z poprzednią wersją, aby wyliczyć minimalny zestaw zmian w real DOM. Ponieważ bezpośrednia manipulacja DOM jest kosztowna, ograniczenie liczby aktualizacji poprawia wydajność. Dodatkowo pozwala to pisać deklaratywny kod, a framework zajmuje się reconciliacją.

Event delegation polega na podpięciu jednego listenera do wspólnego rodzica i wykorzystaniu bubblingu do obsługi zdarzeń z wielu dzieci. Zmniejsza to zużycie pamięci i działa także dla elementów dodanych dynamicznie, bez ponownego bind'owania. W praktyce sprawdzasz event.target, aby ustalić, który element wywołał zdarzenie.

Debounce opóźnia wykonanie funkcji do momentu, aż seria zdarzeń się zatrzyma, więc dobrze sprawdza się przy wyszukiwaniu wpisywanym na bieżąco. Throttle gwarantuje wykonanie maksymalnie raz w określonym przedziale czasu, więc pasuje do scrolla lub resize. Oba mechanizmy ograniczają liczbę kosztownych wywołań przy szybkim strumieniu eventów.

Specificity określa, który selektor wygra: najpierw inline styles, potem ID, potem klasy i atrybuty, a na końcu elementy. Gdy specificity jest taka sama, decyduje kolejność w source order. Nadużywanie ID i !important robi style kruche, więc w praktyce lepiej opierać się na prostych selektorach klasowych.

Sytuacyjne

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

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

Pracowałem przy aplikacji, która miała działać również w starszym browserze używanym w magazynach. Najpierw zrobiłem audyt feature'ów, z których korzystaliśmy, a potem dodałem tylko potrzebne polyfills i progressive enhancement. Testy ustawiłem w BrowserStack, żeby przed każdym release sprawdzać wymagany matrix przeglądarek. Dzięki temu aplikacja działała poprawnie także w starszym środowisku, bez nadmiernego rozdymania bundle'a dla nowoczesnych przeglądarek.

Po deployu jedna zmiana w zależności spowodowała inny format daty i rozbiła ekran raportowy. Najpierw przywróciłem poprzednią wersję, żeby szybko odblokować użytkowników, a potem odtworzyłem problem w branchu. Zablokowałem problematyczną wersję dependency, dodałem visual regression test dla tego widoku i ponownie wypuściłem poprawkę. Po tym incydencie wprowadziliśmy też screenshot diffs do CI.

W jednym projekcie zaproponowano bardzo mały tap target na mobile. Zamiast spierać się opiniami, przygotowałem szybki prototype dwóch wariantów i pokazałem wynik testu kilku osobom z zespołu, gdzie większy target wyraźnie zmniejszył liczbę pomyłek. Dane przedstawiłem designerowi i wspólnie poprawiliśmy rozwiązanie. Finalnie zmieniliśmy też wytyczne w design systemie, żeby podobny problem nie wracał.

W projekcie trzy zespoły utrzymywały podobne komponenty, ale każdy w trochę innej wersji. Zaproponowałem wydzielenie wspólnej biblioteki komponentów z jasno opisanymi propsami i przykładami w Storybooku. Migrację prowadziliśmy etapami, żeby nie robić ryzykownego big-bang change. Po kilku sprintach duplikacja spadła, a nowe funkcje zaczęły powstawać szybciej i spójniej.

Przygotowanie

Wskazówki dotyczące przygotowania

Przećwicz czysty JavaScript bez frameworka, bo na rozmowach często wracają closures, promises i event loop.

Odśwież mały projekt w swoim głównym frameworku, żeby umieć konkretnie mówić o architekturze komponentów i state.

Powtórz browser rendering, critical rendering path i diagnostykę w Lighthouse oraz DevTools.

Przygotuj historię o dostępności, w tym testowanie klawiaturą i screen readerem, bo to coraz częściej pada na rozmowie.

Powtórz CSS layout: flexbox, grid i responsywność, żeby przejść live coding bez zgadywania.

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

Jeśli pytasz o wynagrodzenie na stanowisku Programisty Frontend, warto mówić o kwocie brutto/mies. w PLN i od razu doprecyzować formę współpracy. Na umowie o pracę liczy się stabilność, urlop i świadczenia, ale realna kwota brutto wygląda inaczej niż przy zleceniu czy B2B (JDG), gdzie inaczej wchodzą ZUS i PIT. Na rynku w hubach IT takich jak Warszawa, Kraków i Wrocław stawki dla Frontend Developera są mocno zależne od doświadczenia, technologii i tego, czy pracujesz zdalnie czy hybrydowo. Na etapie rozmowy najlepiej podać widełki dopasowane do Twojego poziomu i zaznaczyć, że jesteś otwarty na rozmowę o całościowym pakiecie, nie tylko o samej podstawie.

FAQ

Najczęściej zadawane pytania

Tak, bardzo często. Może to być prosty komponent UI, zadanie w JavaScript albo mały fragment layoutu w shared editorze. Najlepiej ćwicz budowanie komponentu z state i pobraniem danych z API pod presją czasu.

Najważniejsze są fundamenty JavaScript, bo frameworki się zmieniają. Jednocześnie powinieneś dobrze znać swój główny framework i umieć wyjaśnić jego model renderowania, state i komunikacji między komponentami.

Na poziomie mid i senior bardzo często tak. Możesz dostać zadanie zaprojektowania np. feedu, autocomplete albo dashboardu z cache'owaniem, renderowaniem i architekturą komponentów.

Tak, to duży plus. Frontend to nie tylko kod, ale też praca nad użytecznością, spójnością i wdrażaniem design systemu. Mów o tym przez konkretne efekty, nie przez hasła.

Pokaż, że myślisz o użytkowniku end-to-end: wydajność, dostępność, edge cases i jakość wdrożenia. Dobrze działają konkretne przykłady z produkcji, np. poprawa LCP, lepsze focus states albo ograniczenie regresji po deployu.