Programista Full Stack - pytania rekrutacyjne i odpowiedzi

Wzorcowa odpowiedź

Logikę biznesową, autoryzację, walidację krytycznych danych i reguły, które wpływają na bezpieczeństwo, trzymam po stronie serwera. Klient dostaje tylko to, co poprawia UX, na przykład natychmiastową walidację formularza, optimistic UI albo podpowiedzi w czasie rzeczywistym. Dzięki temu serwer pozostaje źródłem prawdy, a aplikacja nie dubluje skomplikowanych zasad w dwóch miejscach.

Wzorcowa odpowiedź

Najpierw doprecyzowuję wymagania i kryteria akceptacji, a potem rozpisuję przepływ danych, model i kontrakt API. Buduję backend z walidacją, testami i obsługą błędów, następnie podpina to frontend z czytelnymi stanami loading, empty i error. Na końcu sprawdzam observability, przygotowuję deployment i wdrażam etapami, żeby ryzyko było małe i łatwe do cofnięcia.

Wzorcowa odpowiedź

Utrzymuję mocny fundament w jednym lub dwóch obszarach, na przykład w API design i React, a w pozostałych warstwach dbam o solidną kompetencję roboczą. Gdy wchodzę w mniej znaną technologię, korzystam z dokumentacji, review i pair programming zamiast zgadywać. Dla mnie full stack oznacza rozumienie całego systemu na tyle dobrze, by podejmować sensowne decyzje, a nie bycie ekspertem absolutnie wszędzie.

Wzorcowa odpowiedź

Pracowałem nad funkcją komentarzy czasu rzeczywistego, która wymagała WebSocket, nowej tabeli w bazie, endpointów API i widoku w React. Zaprojektowałem schemat pod szybki odczyt wątków, po stronie backendu dodałem broadcast zdarzeń, a w UI zrobiłem optimistic update i synchronizację ze stanem serwera. Wdrożenie poszło etapami za flagą i pozwoliło wyłapać race condition, zanim trafiła do wszystkich użytkowników.

Wzorcowa odpowiedź

Stawiam na wspólne konwencje, linting i formatowanie wymuszane w CI/CD, żeby styl nie był przedmiotem dyskusji. Dbam o jasny podział odpowiedzialności między UI, API i warstwę danych, aby każda część mogła rozwijać się niezależnie. Piszę testy na właściwym poziomie, szczególnie integracyjne, które obejmują realne ścieżki użytkownika, i dokumentuję decyzje architektoniczne, żeby nowi ludzie szybko odnaleźli się w projekcie.

Przeglądarka waliduje i serializuje dane, a potem wysyła request HTTP na serwer, zwykle przez fetch lub podobny mechanizm. Serwer uwierzytelnia żądanie, sprawdza payload, wykonuje logikę biznesową i zapisuje lub odczytuje dane z bazy w ramach transakcji. Na końcu zwraca odpowiedni status code, a frontend aktualizuje stan UI, uwzględniając sukces i błędy.

Po zalogowaniu serwer wydaje credential, najczęściej signed token albo session cookie, a klient dołącza go do kolejnych requestów. Preferuję httpOnly cookies, bo ograniczają ryzyko kradzieży tokena przez XSS, i łączę je z ochroną przed CSRF. Backend weryfikuje credential przy każdym chronionym request i nigdy nie ufa deklaracji tożsamości przesłanej przez klienta.

CORS to mechanizm bezpieczeństwa przeglądarki, który ogranicza cross-origin requests, jeśli serwer nie zezwoli na nie odpowiednimi headerami. Zobaczysz go wtedy, gdy frontend działa na jednym origin, a API na innym. Rozwiązaniem jest poprawna konfiguracja serwera i zaufanych originów, a nie wyłączanie zabezpieczeń na siłę.

Najpierw dodałbym właściwe indexy i zoptymalizował query, a następnie ustawił timeouts, żeby wolne zapytanie nie blokowało zasobów zbyt długo. Przy częstych odczytach rozważyłbym cache, a przy dużym ruchu connection pool z limitami. Jeśli operacja jest ciężka, przeniósłbym ją poza request path do background job.

Server-side rendering generuje HTML po stronie serwera, więc pierwszy render jest szybszy i treść lepiej nadaje się do indeksowania, ale rośnie obciążenie backendu. Client-side rendering wysyła bundle JavaScript, który buduje UI w przeglądarce, co dobrze pasuje do bardzo interaktywnych aplikacji, ale może opóźniać pierwszy meaningful paint. W praktyce wiele zespołów łączy oba podejścia przez hydration albo static generation.

Użytkownicy zgłaszali sporadyczną utratę danych przy zapisie. Odtworzyłem problem i sprawdziłem requesty w network, co wskazało, że frontend wysyła poprawne dane, więc skupiłem się na backendzie. Okazało się, że race condition przy równoległych update'ach nadpisywał pola, więc dodałem optimistic locking z wersjonowaniem i pokazałem konflikt w UI. Utrata danych zniknęła, a użytkownik dostał jasny komunikat przy kolizji.

Budowałem wewnętrzne narzędzie administracyjne solo pod mocno napięty termin. Brutalnie ograniczyłem zakres do kluczowych flow, wybrałem znany stack, a komponenty i ORM wykorzystałem tak, by nie wymyślać koła na nowo. W dwa tygodnie dostarczyłem działające narzędzie, które od razu przejął zespół operacyjny, a potem wszystko dobrze udokumentowałem, żeby inżynier mógł to dalej utrzymywać.

Gdy zostały nam dwa dni do demo, animacje w UI i nieobsłużona ścieżka błędu wymagały pracy. Priorytetem uczyniłem stabilność, bo crash na demo byłby najgorszym scenariuszem, a UI zostawiłem w czystej, ale prostszej formie. Z góry zakomunikowałem trade-off zespołowi. Demo przeszło bez problemu, a dopieszczanie warstwy wizualnej wróciło w kolejnym sprincie.

Onboarding trwał za długo, bo lokalne środowisko było niestabilne i każdy zestawiał je inaczej. Zcontainerizowałem cały stack tak, by jednym poleceniem uruchamiać aplikację, bazę i dane testowe. Dodałem też dokumentację i make targety do testów. Nowi ludzie zaczęli być produktywni pierwszego dnia, a zespół przestał tracić czas na walkę ze środowiskiem.