Full Stack Developer Sollicitatievragen

Je maakt je misschien zorgen dat een full stack traject betekent dat je twee complete gesprekken moet voorbereiden, frontend en backend, in de tijd die de meeste kandidaten aan één gesprek besteden. Die zorg is begrijpelijk, en deze sectie laat zien waarom de taak kleiner is dan hij lijkt. Interviewers herhalen zelden een gespecialiseerd frontend- of backendtraject; ze onderzoeken de plekken waar de lagen elkaar raken, want daar verdienen full stack engineers hun titel.

De meeste trajecten combineren vier soorten rondes:

• Coderen: een datastructuurprobleem of een praktische taak zoals parsen, groeperen of pagineren van records, vaak in JavaScript, TypeScript, Python of Java.
• Een feature bouwen: een kleine end-to-end taak, zoals een formulier dat opslaat naar een API en validatiefouten toont, in een gedeelde editor of een take-home repository.
• Ontwerp over de hele stack: schets een feature zoals reacties of meldingen, met het schema, de API, de client-state, en wat er gebeurt als het netwerk uitvalt.
• Gedrag: het eigenaarschap van een feature van ticket tot productie, en een bug die je door alle lagen hebt achtervolgd.

Laagspecifieke diepgang komt nog steeds aan bod, en de gerichte sets, inclusief aparte pagina's voor frontend developer en backend developer, staan in de hub met sollicitatievragen. Deze pagina behandelt wat daartussen zit.

De API is het contract tussen de twee helften van je werk, dus interviewers vragen ernaar vanuit beide kanten:

• Hoe zou je de endpoints voor een feature ontwerpen, en wat geeft elk endpoint terug bij succes en bij falen?
• Hoe verander je een API zonder clients die al in productie draaien te breken? (Versioning, additieve wijzigingen, deprecation-vensters.)
• Offset- of cursorpaginering: welke zou je gebruiken voor een activity feed, en waarom?
• Hoe maak je een POST veilig om opnieuw te proberen als de client een time-out krijgt? (Idempotency keys.)
• REST, GraphQL of RPC voor een bepaalde client: wat verandert er in caching, over-fetching en foutafhandeling?
• Waar leeft validatie, op de client, de server, of beide, en welke is leidend?
• Hoe voorkom je een N+1-query wanneer een list-endpoint geneste data teruggeeft?

Een sterk antwoord noemt de afweging, niet alleen de keuze. "Cursorpaginering, omdat rijen die worden ingevoegd terwijl de gebruiker scrolt een offset zouden verschuiven en items dupliceren" is beter dan beide opties opnoemen en daar stoppen.

Twee soorten vragen onderscheiden full stack kandidaten van specialisten. De eerste is authenticatie van begin tot eind: loop door wat er gebeurt vanaf het moment dat een gebruiker een loginformulier indient tot het moment dat een geauthenticeerde API-aanroep slaagt. Interviewers letten op waar de credential leeft (een cookie of client-opslag), hoe de server dit controleert, waarom een HttpOnly-cookie bestand is tegen scripttoegang, welke CSRF-bescherming een cookiegebaseerde session nodig heeft, hoe CORS een front end op een andere origin beïnvloedt, en hoe logout en het verlopen van tokens worden afgehandeld.

De tweede is het volgen: "Een gebruiker klikt op Save en er gebeurt niets. Loop met me mee hoe je dit zou debuggen." Een goed antwoord beweegt laag voor laag, van de browserconsole en het network-tabblad, naar de request en response, naar de serverlogs, naar de databaseschrijving, in plaats van te gokken.

Een full stack developer die solliciteert bij een middelgroot SaaS-bedrijf is een typisch geval. Op de vraag hoe een reactiefunctie zou werken, begon ze bij de tabel (reacties met een post-ID, een auteurs-ID en tijdstempels, geïndexeerd op post), definieerde ze het list-endpoint met cursorpaginering, beschreef ze optimistic rendering op de client met een rollback als de POST mislukte, en sloot ze af met hoe ze zou voorkomen dat een dubbele klik tweemaal zou posten. Ze hield elke laag kort, en de vervolgvragen van de interviewer gingen recht naar de raakvlakken die ze had genoemd.

Oefen het volgen hardop. Kies een feature uit een app die je dagelijks gebruikt en leg hem uit van schema tot scherm, doe het dan opnieuw met een ingebouwde storing: de API is traag, het schrijven slaagt gedeeltelijk, de gebruiker wordt midden in het verzoek uitgelogd. Neem jezelf op, of doorloop de vragen in een AI mock interview, dat vervolgvragen stelt op basis van je gesproken antwoorden.

In live rondes kan de desktopapp van SubcueAI voor macOS en Windows de interviewer transcriberen en een structuur voorstellen voor ontwerp- en gedragsantwoorden, waar de regels van het gesprek assistentie toestaan; de Chrome/Edge-extensie dekt gesprekken in een browsertab, en de iPhone-app luistert naar een gesprek dat op een ander apparaat wordt afgespeeld. De eerlijke grens telt het meest in full stack trajecten: het bouwen van een feature en coderondes vinden vaak plaats op een shared screen, en alles op een shared screen is zichtbaar, dus daar valt assistentie buiten de scope. Geproctorde online toetsen en door het bedrijf beheerde apparaten vallen ook buiten de scope. De installatie staat in de tutorial.