Intervjufrågor Full Stack Developer

Du kanske oroar dig för att en full stack-process innebär att förbereda två fullständiga intervjuer, frontend och backend, på den tid de flesta kandidater lägger på en enda. Den oron är rimlig, och det här avsnittet visar varför uppgiften är mindre än den ser ut. Intervjuare upprepar sällan en specialiserad frontend- eller backend-process; de undersöker platserna där lagren möts, för det är där full stack-ingenjörer förtjänar sin titel.

De flesta processer blandar fyra typer av omgångar:

• Kodning: ett datastrukturproblem eller en praktisk uppgift som parsning, gruppering eller pagination av poster, ofta i JavaScript, TypeScript, Python eller Java.
• Bygg en feature: en liten end-to-end-uppgift, till exempel ett formulär som sparar till ett API och visar valideringsfel, i en delad editor eller ett take-home-repo.
• Design över hela stacken: skissa en feature som kommentarer eller notiser, och täck schemat, API:et, client-state och vad som händer när nätverket fallerar.
• Beteendebaserat: att äga en feature från ticket till produktion, och en bugg du spårat genom lagren.

Lagerspecifikt djup dyker fortfarande upp, och de dedikerade sammanställningarna, inklusive separata sidor för frontend developer och backend developer, finns i navet för intervjufrågor. Den här sidan täcker det som ligger mellan dem.

API:et är kontraktet mellan de två halvorna av ditt arbete, så intervjuare frågar om det från båda hållen:

• Hur skulle du utforma endpoints för en feature, och vad returnerar var och en vid framgång respektive misslyckande?
• Hur ändrar du ett API utan att förstöra klienter som redan körs i produktion? (Versioning, additiva ändringar, deprecation-fönster.)
• Offset- eller cursor-pagination: vilken skulle du använda för ett activity feed, och varför?
• Hur gör du en POST säker att försöka igen om klienten får timeout? (Idempotency keys.)
• REST, GraphQL eller RPC för en given client: vad ändras i caching, over-fetching och felhantering?
• Var lever valideringen, på clienten, servern, eller båda, och vilken är auktoritativ?
• Hur undviker du en N+1-fråga när en list-endpoint returnerar nästlad data?

Ett starkt svar namnger avvägningen, inte bara valet. "Cursor pagination, eftersom rader som infogas medan användaren skrollar skulle förskjuta en offset och duplicera poster" slår att bara räkna upp båda alternativen och stanna där.

Två typer av frågor skiljer full stack-kandidater från specialister. Den första är autentisering från start till slut: gå igenom vad som händer från det ögonblick en användare skickar ett inloggningsformulär till det ögonblick ett autentiserat API-anrop lyckas. Intervjuare lyssnar efter var credentialen lever (en cookie eller client-lagring), hur servern kontrollerar den, varför en HttpOnly-cookie står emot skriptåtkomst, vilket CSRF-skydd en cookiebaserad session behöver, hur CORS påverkar en front end på en annan origin, och hur logout och tokens utgång hanteras.

Den andra är spårningen: "En användare klickar på Save och inget händer. Gå igenom hur du skulle felsöka det." Ett bra svar rör sig lager för lager, från webbläsarkonsolen och network-fliken, till request och response, till serverloggarna, till databasskrivningen, i stället för att gissa.

En full stack developer som intervjuas på ett medelstort SaaS-företag är ett typiskt fall. På frågan hur en kommentarsfunktion skulle fungera började hon vid tabellen (kommentarer med ett post-ID, ett author-ID och tidsstämplar, indexerade på post), definierade list-endpointen med cursor pagination, beskrev optimistic rendering på clienten med en rollback om POST:en misslyckades, och avslutade med hur hon skulle förhindra att en dubbelklickning postar två gånger. Hon höll varje lager kort, och intervjuarens följdfrågor gick rakt till de skarvar hon hade namngett.

Öva spårningen högt. Välj en feature från en app du använder dagligen och förklara den från schema till skärm, gör det sedan igen med ett fel inbyggt: API:et är långsamt, skrivningen lyckas delvis, användaren loggas ut mitt i requesten. Spela in dig själv, eller kör frågorna i en AI mock interview, som ställer följdfrågor baserat på dina talade svar.

I live-omgångar kan SubcueAI:s skrivbordsapp för macOS och Windows transkribera intervjuaren och föreslå en struktur för design- och beteendesvar där intervjuns regler tillåter assistans; Chrome/Edge-tillägget täcker samtal i en webbläsarflik, och iPhone-appen lyssnar på ett samtal som spelas upp på en annan enhet. Den ärliga gränsen betyder mest i full stack-processer: att bygga en feature och kodningsomgångar sker ofta på en shared screen, och allt på en shared screen är synligt, så assistans faller utanför scope där. Proctorade onlineprov och företagsstyrda enheter faller också utanför scope. Installationen finns i tutorial.