Întrebări Interviu Spring Boot

Probabil folosești Spring Boot zilnic fără să-i citești logul de pornire, iar intervievatorii știu asta, de aceea încep de aici. Această secțiune acoperă întrebările care verifică dacă înțelegi framework-ul sau doar valorile lui implicite.

• Ce combină de fapt @SpringBootApplication, și ce s-ar strica dacă ai elimina o parte?
• Cum decide autoconfiguration ce să configureze, și ce rol joacă conditional annotation?
• Ce este un starter, și ce conține pe lângă dependency?
• Cum suprascrii sau dezactivezi o anumită autoconfiguration?
• De unde vine un embedded server, și cum l-ai înlocui?

Un răspuns bun leagă mecanismul de ceva ce ai făcut chiar tu: un bean pe care a trebuit să-l excluzi, un starter pe care l-ai înlocuit, sau o eroare de pornire pe care ai urmărit-o prin condition evaluation report.

• Dependency injection. Constructor versus field injection, de ce constructor injection e preferat, și cum rezolvi doi candidați bean de același tip.
• Ciclul de viață și scope-urile bean. De ce singleton e implicit, când request sau prototype scope e corect, și ce face nesigură partajarea unui bean singleton.
• Configurare. Precedența property, profiluri pe mediu, și @ConfigurationProperties versus value injection împrăștiat.
• Spring Data JPA. Metode query derivate, problema N plus 1, lazy versus eager fetching, și când cobori la un query nativ.
• Tranzacții. Ce interceptează de fapt proxy-ul @Transactional, de ce o self-invocation ocolește tăcut tranzacția, și cum funcționează regulile de rollback cu checked exception.

Întrebarea despre proxy-ul tranzacției e locul cel mai comun în care un răspuns încrezător se destramă, așa că fii pregătit să explici limita proxy-ului, nu doar să numești annotation.

Dincolo de container, intervievatorii vor să vadă părțile care apar în producție. La nivelul web: alegerea status code, validare, și tratarea centralizată a erorilor cu @ControllerAdvice în loc de try-catch în fiecare controller. La testing: diferența dintre un @SpringBootTest complet și un slice precum un test la nivel web, și de ce pornirea întregului context pentru un singur test de controller e un obicei lent. La operațiuni: ce expune Actuator, ce endpoint nu trebuie să fie publice, și cum alimentează health check un deployment.

Imaginează-ți o inginer backend care dă un interviu pentru un rol mid-level la o companie de logistică. E întrebată de ce un job programat scria uneori date parțiale. În loc să ghicească, parcurge limita tranzacției, observă că job-ul apela o metodă transactional pe el însuși, și explică comportamentul proxy-ului care a sărit peste asta. Intervievatorul a trecut direct la o discuție despre ofertă, pentru că răspunsul arăta un obicei de debugging, nu o definiție memorată.

Seturile de întrebări pentru alte limbaje și framework-uri sunt adunate sub question banks.

Citește o dată logul de pornire al propriului serviciu și fii capabil să-l povestești. Apoi exersează cu voce tare, pentru că diferența dintre a cunoaște un concept și a-l explica în patruzeci de secunde e ceea ce decide aceste interviuri. Un intervievator AI pe pagina /mock-interview poate pune întrebările suplimentare pe care nu ți le-ai pune singur.

În timpul unui interviu video vorbit, SubcueAI transcrie întrebarea intervievatorului și afișează pe partea ta o structură sugerată, în overlay-ul desktop pe macOS și Windows sau în panoul lateral al extensiei de browser Chromium. Niciun meeting bot nu se alătură apelului, și nimic nu e injectat în pagina întâlnirii. Limita onestă e runda de coding: dacă trece pe o platformă monitorizată pe ecran sau cu proctoring, ajutorul live nu se aplică, iar dacă îți distribui ecranul, tot ce e pe el devine vizibil.