Rozmowy rekrutacyjne z projektowania systemów frontendowych

Podczas rozmów kwalifikacyjnych na stanowiska senior frontend prosi się o zaprojektowanie nietrywialnej funkcji interfejsu od początku do końca: kanału aktualności, autouzupełniania, galerii obrazów czy pulpitu z nieskończonym przewijaniem. Ocenia się architekturę, świadomość kompromisów, wyczucie wydajności i sposób komunikacji — a nie znajomość szczegółów frameworka.

Większość rozmów trwających 45–60 minut przebiega następująco: 1) Doprecyzowanie wymagań (5 min). 2) Naszkicowanie architektury wysokiego poziomu (10 min). 3) Podział na komponenty (10 min). 4) Pobieranie danych i zarządzanie stanem (10 min). 5) Wydajność i dostępność (10 min). 6) Dogłębne omówienie jednego obszaru (wybranego przez osobę prowadzącą rozmowę).

Nie zaczynaj od kodowania. Zapytaj: jakie urządzenia są docelowe? Czy użytkownik może być zalogowany lub anonimowy? Czy potrzebna jest obsługa trybu offline? Czy aktualizacje mają być przesyłane w czasie rzeczywistym? Jaka jest oczekiwana skala (10 użytkowników czy 10 mln)? Jakie są wymagania dotyczące dostępności? Jakie przeglądarki mają być obsługiwane? Są to decyzje, które wpływają na cały projekt.

Narysuj podstawowe elementy: klient (SPA czy SSR?), bramka API, usługi, bufor, CDN. Zaznacz działania użytkownika i przepływ danych. Wspomnij wcześnie o przypadkach brzegowych — pokazują, że tworzyłeś rzeczywiste systemy.

Naszkicuj hierarchię komponentów. NewsFeed → Header, Story[], Composer. Story → Avatar, Content, Actions, Comments. Wskaż, które komponenty można ponownie wykorzystać, a które dotyczą konkretnej funkcji.

Gdzie przechowywany jest każdy element stanu? Lokalnie (useState), w adresie URL (router), w stanie serwera (React Query) czy w stanie klienta (Zustand)? Omów strategię pobierania: początkowy SSR, nieskończone przewijanie, aktualizacje w czasie rzeczywistym przez WebSocket oraz optymistyczny interfejs.

Dzielenie kodu na granicach tras. Listy zwirtualizowane dla długich kanałów. Optymalizacja obrazów (leniwe ładowanie oraz AVIF/WebP). Unikanie blokowania głównego wątku. Budżety rozmiaru bundla. Service worker z priorytetem bufora dla ponownych odwiedzin.

Semantyczny HTML. Nawigacja za pomocą klawiatury. Role ARIA i regiony live. Kontrast kolorów. Testowanie z czytnikiem ekranu. Dodatkowe punkty uzyskasz za wspomnienie o zarządzaniu fokusem podczas zmiany trasy.

Omów: nieskończone przewijanie z IntersectionObserver, wirtualizację w celu ograniczenia zużycia pamięci, optymistyczne polubienia, wskaźnik nowych wpisów w czasie rzeczywistym, leniwe ładowanie obrazów z rozmytym placeholderem, SSR na potrzeby SEO oraz buforowanie ISR lub na brzegu sieci dla popularnych kanałów.

Omów: opóźnienie obsługi wpisywania, AbortController do anulowania nieaktualnych żądań, deduplikację żądań, buforowanie odpowiedzi (LRU), nawigację za pomocą klawiatury (góra/dół/enter/escape), role ARIA combobox oraz obsługę wirtualnej klawiatury na urządzeniach mobilnych.

Omów: układ masonry i grid, responsywny srcset dla ekranów retina, leniwe ładowanie oparte na przecięciach, wstępne pobieranie następnego obrazu, lightbox lub modal z pułapką fokusu, gesty przesuwania na urządzeniach mobilnych, nawigację strzałkami klawiatury oraz deep linking.

Przy każdym wyborze wspomnij o alternatywie i wyjaśnij, dlaczego wybrałeś dane rozwiązanie. „Użyłbym IntersectionObserver do leniwego ładowania, ponieważ jest natywny i wydajny. Alternatywa: listener przewijania z throttle — prostszy, ale bardziej podatny na zacięcia na wolniejszych procesorach”. To właśnie doceniają osoby prowadzące rozmowy na stanowiska senior.

1) Przejście do kodowania przed doprecyzowaniem wymagań. 2) Ignorowanie dostępności. 3) Pomijanie stanów błędów (awaria sieci, puste wyniki). 4) Nieuwzględnianie stanów ładowania. 5) Ogólnikowe odpowiedzi („Użyłbym Reacta” — ale jakiej architektury?).

Podczas rozmowy kwalifikacyjnej dotyczącej projektowania systemu poproszono Cię o zaprojektowanie pola wyszukiwania z autouzupełnianiem. Co należy zrobić w pierwszej kolejności?

Najpierw doprecyzuj zakres. Następnie omów architekturę wysokiego poziomu (klient, API, bufor, CDN), drzewo komponentów, miejsce przechowywania stanu (lokalne, URL, bufor serwera, globalne), strategię pobierania danych, wydajność (dzielenie kodu, wirtualizacja, optymalizacja obrazów) oraz dostępność (klawiatura, ARIA, kontrast). Komunikuj kompromisy. Nie przechodź od razu do kodu. Ćwicz klasyczne wzorce: kanał aktualności, autouzupełnianie, galeria i pulpit.