Programista Front EndOdpowiedzi na Rozmowę

Tworzyłem aplikacje produkcyjne w React przez [X years], pracując z komponentami funkcyjnymi, hookami (useState, useEffect, useContext, useMemo, useCallback, hooki własne) oraz wzorcami zarządzania stanem (Context API, Redux Toolkit, Zustand). Znam dogłębnie model renderowania Reacta — potrafię analizować, kiedy dochodzi do rerenderów i jak zapobiegać niepotrzebnym. Pracowałem też z Next.js dla renderowania po stronie serwera i generowania statycznego, co wprowadza znaczną złożoność wokół pobierania danych, hydracji i wdrożenia.

Wydajność zaczyna się od pomiaru: wyniki Lighthouse, Web Vitals (LCP, FID/INP, CLS) i metryki zorientowane na użytkownika. Optymalizuję rozmiar bundla (code splitting, tree shaking, dynamic imports), dostarczanie obrazów (WebP, leniwe ładowanie, obrazy responsywne przez srcset) oraz wydajność renderowania (memoizacja, wirtualizacja długich list). Audytuję i ograniczam skrypty firm trzecich. Ustawiam budżety wydajności w CI, aby regresje były wykrywane przed wdrożeniem. Wydajność to cecha produktu i jej utrzymanie wymaga ciągłej czujności.

Projektuję od mobile-first i używam kombinacji CSS Grid, Flexbox oraz jednostek responsywnych (rem, %, vw/vh, clamp()). Testuję na prawdziwych urządzeniach i w emulacji urządzeń w Chrome DevTools. Dla kompatybilności między przeglądarkami korzystam z Can I Use do sprawdzania wsparcia funkcji i testuję w Chrome, Firefox, Safari i Edge. Używam PostCSS i autoprefixer do dodawania prefiksów vendorowych. Dyskusje o wsparciu dla IE11 traktuję jako decyzję biznesową z realnymi kosztami — jasno przedstawiam kompromisy zamiast mówić jedynie tak lub nie.

Projektuję komponenty z myślą o ponownym użyciu i zasadzie pojedynczej odpowiedzialności. Rozdzielam komponenty prezentacyjne (tzw. dumb, bez efektów ubocznych) od kontenerowych (pobieranie danych, zarządzanie stanem). Jako podstawę używam systemu projektowego lub biblioteki komponentów i buduję na nich komponenty specyficzne dla aplikacji. Myślę o API komponentu z perspektywy jego konsumenta: czytelne, minimalne, dobrze typowane propsy. Dokumentuję komponenty za pomocą Storybooka, aby projektanci i inni inżynierowie mogli je odkrywać i rozumieć. Dobra architektura komponentów zmniejsza duplikację i sprawia, że kod jest łatwiejszy w utrzymaniu wraz ze skalowaniem.

Wdrażam dostępność od początku: semantyczne HTML jako podstawa (nav, main, section, button, a nie tylko divy), atrybuty ARIA tam, gdzie semantyka HTML jest niewystarczająca, widoczne stany focus, wystarczający kontrast kolorów (minimum WCAG AA), obsługa klawiatury dla wszystkich elementów interaktywnych oraz testowanie czytnikami ekranu (VoiceOver, NVDA). Używam axe-core lub Lighthouse do automatycznych kontroli dostępności w CI. Traktuję dostępność jako wymiar jakości, a nie jedynie pole do odhaczenia — dostępne interfejsy zazwyczaj są lepsze dla wszystkich.

Pracowałem z CSS Modules, BEM, CSS-in-JS (styled-components, Emotion) oraz frameworkami utility-first (Tailwind CSS). Preferencje zależą od projektu: Tailwind dla produktów opartych na systemie projektowym, CSS Modules dla izolacji komponentów w dużych zespołach, CSS-in-JS dla bardzo dynamicznych stylów. Znajomość kaskady CSS, specyficzności i kontekstu nakładania (stacking context) mam na głębokim poziomie — większość błędów w CSS wynika z nieporozumień w tych obszarach. Używam custom properties (zmiennych CSS) do themingu i design tokenów, aby zachować spójność.

Angażuję się w pracę nad projektem wcześnie — zanim projekty zostaną sfinalizowane. Przeglądam projekty z Figma i zgłaszam problemy wdrożeniowe (złożoność animacji, luki w zachowaniu responsywnym, problemy z dostępnością) w fazie projektowej, a nie podczas developmentu. Mówię językiem projektanta: potrafię rozmawiać o koncepcjach wizualnych, skalach typograficznych i systemach layoutu. Realizuję też projekty precyzyjnie: dbałość o spacing, typografię i kolory na poziomie pikseli ma znaczenie. Gdy muszę odejść od projektu z powodu ograniczeń, komunikuję to jasno i dbam o zgodność z zespołem.

Testuję zachowanie widoczne dla użytkownika, a nie szczegóły implementacji. Używam React Testing Library do testów komponentów — symulując interakcje użytkownika i sprawdzając wynik. Piszę testy integracyjne dla kluczowych ścieżek użytkownika (logowanie, checkout, wysyłanie formularza) za pomocą Cypress lub Playwright. Dla funkcji pomocniczych piszę testy jednostkowe w Jest. W testach komponentów i integracyjnych mockuję zależności zewnętrzne (wywołania API) przy użyciu MSW (Mock Service Worker). Unikam testowania szczegółów implementacyjnych, które czynią testy kruche — testy powinny dawać pewność, a nie tworzyć obciążenie konserwacyjne.