Mga Tanong sa Full Stack Developer Interview

Baka mangamba ka na ang isang full stack interview ay nangangahulugang paghahanda para sa dalawang kumpletong interview, frontend at backend, sa parehong oras na inilalaan ng karamihan ng kandidato para sa iisa lamang. Makatwiran ang pag-aalala na iyon, at ipinapakita ng bahaging ito kung bakit mas maliit ang trabaho kaysa sa itsura nito. Bihira nang inuulit ng mga interviewer ang isang espesyalisadong frontend o backend interview; sinusuri nila ang mga bahaging nagtatagpo ang mga layer, dahil doon talaga nakukuha ng full stack engineer ang kanilang titulo.

Karamihan ng proseso ay pinaghahalo ang apat na uri ng round:

• Coding: isang data-structures na problema o isang praktikal na gawain tulad ng pag-parse, pagpapangkat, o pag-paginate ng mga record, kadalasan sa JavaScript, TypeScript, Python, o Java.
• Pagbuo ng feature: isang maliit na end-to-end na gawain, tulad ng isang form na nagse-save sa isang API at nagpapakita ng mga validation error, sa isang shared editor o take-home repository.
• Design sa buong stack: mag-sketch ng feature tulad ng comments o notifications, na sumasaklaw sa schema, API, client state, at kung ano ang mangyayari kapag nabigo ang network.
• Behavioral: pagmamay-ari ng isang feature mula sa ticket hanggang production, at isang bug na sinundan mo sa iba't ibang layer.

Lumalabas pa rin ang mga tanong na tiyak sa isang layer, at makikita ang mga dedikadong set, kasama ang hiwalay na mga pahina para sa frontend at backend developer, sa interview questions hub. Ang pahinang ito ay tumatalakay sa nasa pagitan ng dalawa.

Ang API ang kontrata sa pagitan ng dalawang kalahati ng iyong trabaho, kaya nagtatanong ang mga interviewer mula sa magkabilang panig:

• Paano mo dine-design ang mga endpoint para sa isang feature, at ano ang ibinabalik ng bawat isa kapag matagumpay at kapag nabigo?
• Paano mo babaguhin ang isang API nang hindi sinisira ang mga client na nasa production na? (Versioning, additive na pagbabago, deprecation windows.)
• Offset o cursor pagination: alin ang gagamitin mo para sa isang activity feed, at bakit?
• Paano mo gagawing ligtas na ulitin ang isang POST kung nag-timeout ang client? (Idempotency keys.)
• REST, GraphQL, o RPC para sa isang partikular na client: ano ang nagbabago sa caching, over-fetching, at error handling?
• Saan dapat mamalagi ang validation, sa client, sa server, o sa dalawa, at alin ang authoritative?
• Paano mo iiwasan ang N+1 query kapag ang isang list endpoint ay nagbabalik ng nested data?

Ang matibay na sagot ay pinapangalanan ang trade-off, hindi lang ang pagpili. Mas maganda ang "Cursor pagination, dahil ang mga row na na-insert habang nag-scroll ang user ay magpapaikot sa offset at magdadoble ng mga item" kaysa sa pag-list lang ng dalawang opsyon nang walang desisyon.

May dalawang uri ng tanong na naghihiwalay sa mga full stack candidate mula sa mga espesyalista. Ang una ay ang end-to-end na authentication: ipaliwanag kung ano ang nangyayari mula sa sandaling isumite ng user ang isang login form hanggang sa sandaling magtagumpay ang isang naka-authenticate na API call. Nakikinig ang mga interviewer kung saan namamalagi ang credential (isang cookie o client storage), paano ito sinusuri ng server, bakit lumalaban ang isang HttpOnly cookie sa script access, anong CSRF protection ang kailangan ng isang cookie-based session, paano naaapektuhan ng CORS ang isang frontend na may ibang origin, at paano hinahawakan ang logout at ang pag-expire ng token.

Ang pangalawa ay ang pagsubaybay: "Nag-click ang isang user sa Save at walang nangyayari. Ipaliwanag mo kung paano mo ito ide-debug." Ang magandang sagot ay umuusad nang layer by layer, mula sa browser console at network tab, patungo sa request at response, patungo sa server logs, hanggang sa pagsulat sa database, sa halip na manghula.

Ang isang full stack developer na nag-i-interview sa isang mid-size na SaaS company ay isang tipikal na halimbawa. Nang tanungin kung paano gagana ang isang comment feature, nagsimula siya sa table (mga comment na may post ID, author ID, at timestamp, na naka-index base sa post), nagtakda ng list endpoint gamit ang cursor pagination, inilarawan ang optimistic rendering sa client na may rollback kung mabigo ang POST, at nagtapos sa kung paano niya pipigilan ang isang double-click na mag-post nang dalawang beses. Pinanatili niyang maikli ang bawat layer, at diretsong napunta ang mga follow-up ng interviewer sa mga tagpuan na kanyang binanggit.

I-practice nang malakas ang pagsubaybay. Pumili ng isang feature mula sa isang app na ginagamit mo araw-araw at ipaliwanag ito mula sa schema hanggang sa screen, pagkatapos ay ulitin ito na may itinurok na kabiguan: mabagal ang API, bahagya lang nagtagumpay ang pagsulat, na-log out ang user sa gitna ng request. I-record mo ang sarili mo, o gawin ang mga tanong sa isang AI mock interview, na nagtatanong ng follow-up base sa iyong mga sinabing sagot.

Sa mga live round, maaaring i-transcribe ng desktop app ng SubcueAI para sa macOS at Windows ang interviewer at magmungkahi ng istruktura para sa mga sagot sa design at behavioral kung saan pinapayagan ng mga patakaran ng interview ang tulong; sinasaklaw ng Chrome/Edge extension ang mga tawag sa browser tab, at nakikinig ang iPhone app sa isang tawag na tumutugtog sa ibang device. Ang tapat na limitasyon ay pinakamahalaga sa mga full stack round: madalas nangyayari ang pagbuo ng feature at coding round sa isang shared screen, at nakikita ang lahat ng nasa shared screen, kaya wala sa saklaw ang tulong doon. Wala rin sa saklaw ang mga proctored online assessment at mga device na pinamamahalaan ng kompanya. Nasa tutorial ang setup.