Full Stack Developer Állásinterjú Kérdések

Aggódhatsz amiatt, hogy egy full stack folyamat két teljes interjú, frontend és backend, előkészítését jelenti abban az időben, amit a legtöbb jelölt egyetlen interjúra szán. Ez az aggodalom érthető, és ez a szakasz megmutatja, miért kisebb a feladat, mint amilyennek látszik. Az interjúztatók ritkán ismételnek meg egy külön frontend vagy backend folyamatot; azokat a pontokat vizsgálják, ahol a rétegek találkoznak, mert ott érdemlik ki a full stack engineerek a címüket.

A legtöbb folyamat négyféle fordulót kombinál:

• Kódolás: egy adatstruktúra-feladat vagy egy gyakorlati feladat, például rekordok parsolása, csoportosítása, vagy pagination-je, gyakran JavaScript, TypeScript, Python, vagy Java nyelven.
• Funkció megépítése: egy kis end-to-end feladat, például egy űrlap, amely egy API-ba ment és validációs hibákat jelenít meg, egy megosztott editorban vagy egy take-home repository-ban.
• Design az egész stacken át: vázolj fel egy funkciót, például kommenteket vagy értesítéseket, lefedve a sémát, az API-t, a client state-jét, és azt, mi történik, ha a hálózat meghibásodik.
• Viselkedési: egy funkció felelősségének viselése a ticket-től a productionig, és egy bug, amit rétegeken át követtél.

A rétegspecifikus mélység továbbra is előjön, és a dedikált kérdéscsomagok, köztük a külön frontend developer és backend developer oldalak, megtalálhatók az interjúkérdés-központban. Ez az oldal azzal foglalkozik, ami közöttük van.

Az API a szerződés a munkád két fele között, ezért az interjúztatók mindkét oldalról kérdeznek róla:

• Hogyan terveznéd meg egy funkció endpointjait, és mit ad vissza mindegyik sikeres és sikertelen esetben?
• Hogyan módosítasz egy API-t anélkül, hogy elrontanád a productionben már futó clienteket? (Versioning, additív módosítások, deprecation ablakok.)
• Offset vagy cursor pagination: melyiket használnád egy activity feedhez, és miért?
• Hogyan teszed biztonságossá a POST-ot az újrapróbálásra, ha a client timeoutot kap? (Idempotency key.)
• REST, GraphQL, vagy RPC egy adott clienthez: mi változik a caching, over-fetching, és hibakezelés terén?
• Hol él a validáció, a clienten, a serveren, vagy mindkettőn, és melyik a mérvadó?
• Hogyan kerülöd el az N+1 lekérdezést, amikor egy list endpoint beágyazott adatot ad vissza?

Egy erős válasz megnevezi a trade-offot, nem csak a választást. "Cursor pagination, mert a felhasználó görgetése közben beszúrt sorok eltolnának egy offsetet és duplikálnának elemeket" jobb, mint felsorolni mindkét lehetőséget és ott megállni.

Két kérdéstípus különíti el a full stack jelölteket a specialistáktól. Az első a végponttól végpontig terjedő hitelesítés: vezess végig azon, mi történik attól a pillanattól, hogy a felhasználó beküld egy bejelentkezési űrlapot, addig, hogy egy hitelesített API-hívás sikerrel jár. Az interjúztatók arra figyelnek, hol él a credential (egy cookie vagy client storage), hogyan ellenőrzi ezt a server, miért áll ellen egy HttpOnly cookie a script-hozzáférésnek, milyen CSRF-védelemre van szüksége egy cookie-alapú sessionnek, hogyan hat a CORS egy másik originon lévő front endre, és hogyan kezelik a logoutot és a token lejáratát.

A második a nyomon követés: "Egy felhasználó a Save-re kattint, és semmi sem történik. Vezess végig azon, hogyan debugolnád ezt." Egy jó válasz rétegről rétegre halad, a böngésző konzoljától és a network fültől a requestig és response-ig, a server logjaiig, az adatbázisba íráshoz, találgatás helyett.

Egy full stack developer, aki egy közepes méretű SaaS-cégnél interjúzik, tipikus eset. Arra a kérdésre, hogyan működne egy komment funkció, a táblázatból indult ki (kommentek post ID-vel, author ID-vel, és timestampekkel, postonként indexelve), meghatározta a list endpointot cursor paginationnel, leírta az optimistic renderinget a clientnél rollbackkel, ha a POST sikertelen, és azzal zárta, hogyan akadályozná meg, hogy egy dupla kattintás kétszer postoljon. Minden réteget rövidre fogott, és az interjúztató follow-up kérdései egyenesen az általa megnevezett illesztésekhez mentek.

Gyakorold a nyomon követést hangosan. Válassz egy funkciót egy alkalmazásból, amit naponta használsz, és magyarázd el a sémától a képernyőig, majd csináld újra egy beépített hibával: az API lassú, az írás csak részben sikeres, a felhasználót a request közepén kijelentkezteti a rendszer. Vedd fel magad, vagy futtasd le a kérdéseket egy AI mock interview-ban, amely a kimondott válaszaid alapján tesz fel follow-up kérdéseket.

Élő fordulókban a SubcueAI macOS-re és Windowsra készült desktop alkalmazása át tudja írni az interjúztatót, és szerkezetet javasolhat a design és viselkedési válaszokhoz ott, ahol az interjú szabályai megengedik a segítséget; a Chrome/Edge bővítmény lefedi a böngészőfülben zajló hívásokat, az iPhone alkalmazás pedig egy másik eszközön lejátszott hívást hallgat. Az őszinte korlát a full stack folyamatokban számít a legtöbbet: a funkció megépítése és a kódolási fordulók gyakran egy shared screenen zajlanak, és minden, ami egy shared screenen van, látható, így ott a segítség nincs a scope-ban. A proctored online tesztek és a cég által kezelt eszközök szintén nincsenek a scope-ban. A beállítás a tutorialban található.