Întrebări Interviu Full Stack Developer

S-ar putea să te îngrijorezi că un proces full stack înseamnă să pregătești două interviuri complete, frontend și backend, în timpul pe care majoritatea candidaților îl alocă unuia singur. Această îngrijorare e firească, iar această secțiune arată de ce sarcina e mai mică decât pare. Intervievatorii rareori repetă un proces specializat de frontend sau backend; ei investighează locurile unde straturile se întâlnesc, pentru că acolo își câștigă full stack engineerii titlul.

Majoritatea proceselor combină patru tipuri de runde:

• Coding: o problemă de structuri de date sau o sarcină practică precum parsarea, gruparea sau pagination-ul înregistrărilor, adesea în JavaScript, TypeScript, Python sau Java.
• Construirea unei funcționalități: o sarcină mică end-to-end, cum ar fi un formular care salvează într-un API și afișează erori de validare, într-un editor comun sau un repository take-home.
• Design pe tot stack-ul: schițează o funcționalitate precum comentarii sau notificări, acoperind schema, API-ul, state-ul de pe client și ce se întâmplă când rețeaua cedează.
• Comportamental: asumarea unei funcționalități de la ticket până la producție, și un bug pe care l-ai urmărit între straturi.

Profunzimea specifică unui strat tot apare, iar seturile dedicate, inclusiv pagini separate pentru frontend developer și backend developer, se află în hub-ul de întrebări de interviu. Această pagină acoperă ce se află între ele.

API-ul este contractul dintre cele două jumătăți ale muncii tale, așa că intervievatorii întreabă despre el din ambele părți:

• Cum ai proiecta endpoint-urile pentru o funcționalitate, și ce returnează fiecare la succes și la eșec?
• Cum schimbi un API fără să strici clienții deja aflați în producție? (Versioning, modificări aditive, ferestre de deprecation.)
• Pagination cu offset sau cu cursor: pe care l-ai folosi pentru un activity feed, și de ce?
• Cum faci ca un POST să fie sigur de reîncercat dacă clientul primește timeout? (Idempotency key.)
• REST, GraphQL sau RPC pentru un anumit client: ce se schimbă la caching, over-fetching și gestionarea erorilor?
• Unde locuiește validarea, pe client, pe server, sau pe amândouă, și care e cea autoritară?
• Cum eviți o interogare N+1 când un endpoint de tip list returnează date imbricate?

Un răspuns puternic numește trade-off-ul, nu doar alegerea. "Cursor pagination, pentru că rândurile inserate cât timp utilizatorul face scroll ar deplasa un offset și ar duplica elemente" e mai bun decât să enumeri ambele opțiuni și să te oprești acolo.

Două tipuri de întrebări îi separă pe candidații full stack de specialiști. Primul este autentificarea completă: parcurge ce se întâmplă din momentul în care un utilizator trimite un formular de login până în momentul în care un apel API autentificat reușește. Intervievatorii ascultă unde locuiește credențiala (un cookie sau stocare pe client), cum o verifică server-ul, de ce un cookie HttpOnly rezistă la accesul din script, ce protecție CSRF are nevoie o session bazată pe cookie, cum afectează CORS un front end aflat pe un origin diferit, și cum sunt gestionate logout-ul și expirarea token-ului.

Al doilea este urmărirea: "Un utilizator dă clic pe Save și nu se întâmplă nimic. Parcurge-mă prin cum ai debugui asta." Un răspuns bun se mișcă strat cu strat, de la consola browser-ului și tab-ul network, la request și response, la log-urile server-ului, la scrierea în baza de date, în loc să ghicească.

Un full stack developer care are un interviu la o companie SaaS de dimensiune medie este un caz tipic. Întrebată cum ar funcționa o funcționalitate de comentarii, a pornit de la tabel (comentarii cu un post ID, un author ID și timestamp-uri, indexate după post), a definit endpoint-ul de list cu cursor pagination, a descris optimistic rendering pe client cu un rollback dacă POST-ul eșua, și a încheiat cu modul în care ar preveni ca un dublu clic să posteze de două ori. A păstrat fiecare strat concis, iar întrebările de follow-up ale intervievatorului au mers direct la punctele de îmbinare pe care le numise.

Exersează urmărirea cu voce tare. Alege o funcționalitate dintr-o aplicație pe care o folosești zilnic și explic-o de la schemă la ecran, apoi repet-o injectând o defecțiune: API-ul e lent, scrierea reușește parțial, utilizatorul e delogat în mijlocul request-ului. Înregistrează-te, sau parcurge întrebările într-un AI mock interview, care pune întrebări de follow-up bazate pe răspunsurile tale rostite.

În rundele live, aplicația desktop SubcueAI pentru macOS și Windows poate transcrie intervievatorul și poate sugera o structură pentru răspunsurile de design și comportamentale acolo unde regulile interviului permit asistență; extensia Chrome/Edge acoperă apelurile din tab-ul browser-ului, iar aplicația iPhone ascultă un apel redat pe alt dispozitiv. Limita onestă contează cel mai mult în procesele full stack: rundele de construire a unei funcționalități și cele de coding au loc adesea pe un shared screen, iar tot ce e pe un shared screen e vizibil, deci asistența nu se aplică acolo. Testele online proctored și dispozitivele gestionate de companie sunt de asemenea în afara domeniului. Configurarea se află în tutorial.