Pytania na Rozmowę Full Stack Developer

Możesz obawiać się, że proces full stack oznacza przygotowanie dwóch pełnych rozmów, frontendowej i backendowej, w czasie, jaki większość kandydatów poświęca na jedną. Ta obawa jest zrozumiała, a ta sekcja pokazuje, dlaczego zadanie jest mniejsze, niż się wydaje. Rekruterzy rzadko powtarzają wyspecjalizowany proces frontendowy lub backendowy; badają miejsca, w których warstwy się stykają, bo właśnie tam full stack engineer zasługuje na swój tytuł.

Większość procesów łączy cztery rodzaje rund:

• Kodowanie: zadanie ze struktur danych lub praktyczne zadanie, takie jak parsowanie, grupowanie czy pagination rekordów, często w JavaScript, TypeScript, Python lub Java.
• Zbudowanie funkcji: niewielkie zadanie end-to-end, na przykład formularz zapisujący dane do API i pokazujący błędy walidacji, we wspólnym edytorze lub w repozytorium take-home.
• Projekt na całym stacku: naszkicuj funkcję, taką jak komentarze czy powiadomienia, obejmując schemat, API, state klienta i to, co dzieje się, gdy sieć zawiedzie.
• Behawioralne: odpowiedzialność za funkcję od ticketu po produkcję oraz błąd, który śledziłeś między warstwami.

Dogłębność specyficzna dla warstwy nadal się pojawia, a dedykowane zestawy, w tym osobne strony dla frontend developer i backend developer, znajdują się w centrum pytań rekrutacyjnych. Ta strona omawia to, co jest pomiędzy nimi.

API to kontrakt między dwiema połówkami twojej pracy, więc rekruterzy pytają o nie z obu stron:

• Jak zaprojektowałbyś endpointy dla funkcji i co zwraca każdy z nich w przypadku sukcesu i porażki?
• Jak zmieniasz API, nie psując clientów już działających na produkcji? (Versioning, zmiany addytywne, okna deprecation.)
• Pagination przez offset czy przez cursor: którą wybrałbyś dla activity feed i dlaczego?
• Jak sprawiasz, że POST jest bezpieczny do ponowienia, gdy client trafi na timeout? (Idempotency key.)
• REST, GraphQL czy RPC dla danego clienta: co zmienia się w caching, over-fetching i obsłudze błędów?
• Gdzie żyje walidacja, po stronie clienta, servera, czy obu, i która jest rozstrzygająca?
• Jak unikasz zapytania N+1, gdy endpoint typu list zwraca zagnieżdżone dane?

Mocna odpowiedź nazywa trade-off, a nie tylko wybór. "Cursor pagination, bo wiersze wstawiane, gdy użytkownik przewija, przesunęłyby offset i zduplikowały elementy" jest lepsze niż wymienienie obu opcji i zatrzymanie się na tym.

Dwa rodzaje pytań odróżniają kandydatów full stack od specjalistów. Pierwszy to uwierzytelnianie od początku do końca: przeprowadź przez to, co się dzieje od momentu, gdy użytkownik wysyła formularz logowania, do momentu, gdy uwierzytelnione wywołanie API kończy się sukcesem. Rekruterzy zwracają uwagę na to, gdzie żyje poświadczenie (cookie czy przechowywanie po stronie clienta), jak server je weryfikuje, dlaczego cookie HttpOnly jest odporne na dostęp ze skryptów, jakiej ochrony CSRF potrzebuje session oparta na cookie, jak CORS wpływa na front end na innym origin, oraz jak obsługiwane są logout i wygasanie tokenu.

Drugi to śledzenie: "Użytkownik klika Save i nic się nie dzieje. Przeprowadź mnie przez to, jak byś to debugował." Dobra odpowiedź porusza się warstwa po warstwie, od konsoli przeglądarki i zakładki network, przez request i response, po logi servera i zapis do bazy danych, zamiast zgadywać.

Full stack developer na rozmowie w średniej wielkości firmie SaaS to typowy przypadek. Zapytana, jak działałaby funkcja komentarzy, zaczęła od tabeli (komentarze z post ID, author ID i timestampami, indeksowane po poście), zdefiniowała endpoint list z cursor pagination, opisała optimistic rendering po stronie clienta z rollbackiem, gdy POST się nie powiedzie, i zakończyła tym, jak zapobiegłaby podwójnemu opublikowaniu przy podwójnym kliknięciu. Każdą warstwę trzymała zwięźle, a pytania dodatkowe rekrutera trafiały prosto w styki, które wymieniła.

Ćwicz śledzenie na głos. Wybierz funkcję z aplikacji, której używasz codziennie, i wyjaśnij ją od schematu po ekran, a potem powtórz to, wprowadzając awarię: API działa wolno, zapis kończy się częściowym sukcesem, użytkownik zostaje wylogowany w trakcie requesta. Nagraj siebie albo przejdź przez pytania w AI mock interview, który zadaje pytania dodatkowe na podstawie twoich wypowiedzianych odpowiedzi.

Na rozmowach na żywo aplikacja desktopowa SubcueAI na macOS i Windows może transkrybować rekrutera i sugerować strukturę odpowiedzi projektowych i behawioralnych tam, gdzie zasady rozmowy pozwalają na pomoc; rozszerzenie Chrome/Edge obejmuje rozmowy w karcie przeglądarki, a aplikacja iPhone nasłuchuje rozmowy odtwarzanej na innym urządzeniu. Uczciwe ograniczenie liczy się najbardziej w procesach full stack: rundy budowania funkcji i kodowania często odbywają się na shared screen, a wszystko na shared screen jest widoczne, więc pomoc jest tam poza zakresem. Egzaminy online proctored i urządzenia zarządzane przez firmę też są poza zakresem. Konfiguracja znajduje się w tutorialu.