Interviul. Ce te întreabă, ce răspunzi, și ce faci când te blochezi.

„E modul de lucru în care cei care scriu aplicația și cei care o țin în funcțiune lucrează pe același obiectiv, în loc să-și paseze responsabilitatea. Practic înseamnă că livrarea, infrastructura și monitorizarea sunt automatizate și versionate, ca oricine din echipă să poată livra în siguranță, și ca atunci când ceva se strică să știi imediat ce s-a schimbat.”

Ce nu spui: „e o cultură”. E adevărat și nu spune nimic. Dă o definiție operațională.

„Dimineața mă uit la ce s-a întâmplat peste noapte — alerte, livrări, joburi eșuate. Pe parcursul zilei sunt trei feluri de muncă: construiesc automatizări, ajut dezvoltatorii când li se blochează ceva în conductă, și mă ocup de ce a picat. Peste asta vine munca planificată — actualizări de versiuni, curățenie, reducere de costuri. Când e incident, tot restul se oprește.”

„Înseamnă că verificările se mută cât mai devreme în proces. Testele, analiza de securitate, verificarea configurației se fac la fiecare modificare, nu într-un audit la final. Motivul e simplu: o problemă prinsă în editor costă minute, aceeași problemă prinsă în producție costă zile și, uneori, clienți.”

„Prin patru numere care se măsoară: cât de des livrăm, cât durează de la commit până în producție, cât de des o livrare cauzează o problemă, și cât durează să ne revenim. Automatizarea le îmbunătățește pe toate patru simultan, iar ultimul e cel care contează pentru client. Contraintuitiv, echipele care livrează des sunt și cele mai stabile — pentru că livrează schimbări mici, ușor de înțeles și de întors.”

„DevOps e modul de lucru. SRE e o implementare concretă a lui, cu accent pe fiabilitate măsurată: definești ținte, măsori, și ai un buget de erori care decide dacă echipa livrează mai agresiv sau se oprește să repare. În practică, în majoritatea firmelor din România, titlul e DevOps și munca conține ambele.”

„Să nu presupună. Majoritatea incidentelor lungi durează mult nu pentru că problema era grea, ci pentru că cineva a plecat de la o presupunere pe care n-a verificat-o. Disciplina de a verifica înainte de a acționa e ce separă un incident de zece minute de unul de trei ore.”

„La continuous delivery, orice modificare care a trecut testele e gata de livrat, dar cineva apasă butonul. La continuous deployment nu există buton — dacă a trecut tot, ajunge singură în producție. Diferența e un om, iar alegerea depinde de cât de bine ai acoperit riscul cu teste automate și cu posibilitatea de a reveni rapid.”

„Descarc codul, instalez dependențele, verific stilul și analiza statică, rulez testele unitare, construiesc artefactul o singură dată, îl scanez de vulnerabilități, îl urc într-un registru, îl livrez în mediul de test, rulez testele de integrare, aștept aprobarea dacă e nevoie, livrez în producție și verific starea livrării. Regula pe care o țin e că artefactul se construiește o singură dată și același trece prin toate mediile — ce diferă e doar configurația.”

„Pentru că dacă reconstruiești pentru fiecare mediu, ceea ce testezi nu e ce livrezi. O dependență se poate rezolva altfel, un cache poate fi diferit, și ajungi în situația clasică în care merge în test și nu merge în producție. Construiesc o dată, urc în registru, și de acolo livrez peste tot.”

„Un workflow e un fișier YAML în .github/workflows, pornit de un eveniment. Conține joburi; fiecare job rulează pe un agent, în mașina lui curată, și are pași. Un pas e sau o comandă, sau o acțiune refolosibilă. Joburile rulează în paralel dacă nu spui altfel; cu needs le pui în ordine.”

„Prin artefacte — upload-artifact într-un job, download-artifact în celălalt. E o capcană frecventă la cei care vin din Jenkins, unde stagiile împart același spațiu de lucru. În Actions fiecare job pornește pe o mașină nouă, deci nimic nu se transmite implicit. Valorile mici se transmit prin outputs.”

„Pe trei niveluri: la nivel de organizație pentru ce e comun, la nivel de depozit pentru ce e specific, și la nivel de mediu pentru producție — acolo pot cere și aprobare umană înainte ca jobul să pornească. Dar dacă merg spre un furnizor de cloud, prefer să nu mai am secrete deloc și folosesc OIDC.”

„În loc să țin o cheie permanentă în secretele depozitului, workflow-ul primește un jeton de identitate semnat de GitHub, iar furnizorul de cloud îl acceptă pe baza unei relații de încredere configurate o singură dată. Jetonul trăiește câteva minute și e legat de depozitul și ramura care l-a cerut. Nu mai ai ce să pierzi, nu mai ai ce să rotești. Detaliul care contează: condiția de încredere se scrie pe identificatori care nu se pot schimba, nu pe numele depozitului — numele se poate redenumi și preluare de altcineva.”

„Le fixez pe hash-ul complet al commitului, nu pe etichetă, pentru că o etichetă poate fi mutată. Apoi las Dependabot să-mi propună actualizările, ca să nu rămân pe o versiune veche. Și dau workflow-ului permisiuni minime — implicit e doar citire, și adaug scriere doar unde chiar trebuie.”

„Pentru că rulează cu secretele depozitului, dar în contextul unui pull request care poate veni de la oricine. Dacă în el descarci codul propunerii și îl execuți, ai dat unui străin acces la secrete. Se folosește doar pentru lucruri care nu ating codul propunerii — de exemplu pus de etichete sau comentarii.”

„Conductele mele le-am construit în Azure DevOps și în Jenkins, inclusiv o livrare albastru–verde. Modelul e același — declanșator, etape, artefact, aprobare, livrare — și se traduce direct: ce în Jenkins e agent, în Actions e runs-on; ce e stages devin joburi, cu diferența importantă că în Actions fiecare job pornește curat, deci artefactele se transmit explicit. Am lucrat cu Actions la nivelul la care pot citi și modifica un workflow; ce nu am făcut e să duc o organizație întreagă pe ele, și asta aș învăța-o pe parcurs.”

Formulare onestă. Nu pretinde mai mult decât poți susține la a doua întrebare, dar nici nu-ți aruncă experiența reală la coș.

„Întâi verific dacă eșecul e în test sau în infrastructură — un apel de rețea fără timp de așteptare și fără reîncercare e cauza cea mai des întâlnită. Dacă e test instabil, îl izolez și îl marchez, pentru că un test în care nimeni nu mai are încredere e mai rău decât niciun test. Nu las niciodată eșecul intermitent «să treacă», pentru că antrenează echipa să ignore roșul.”

„E un sistem care ține containerele în funcțiune pe un grup de mașini. Tu îi descrii starea dorită — vreau trei exemplare din aplicația asta, cu configurația asta — și el compară permanent realitatea cu ce ai cerut și corectează diferența. Dacă moare un container, îl repornește. Dacă moare un nod, mută sarcina pe altul. Asta e tot; restul sunt detalii peste ideea asta.”

„E unitatea cea mai mică pe care o planifică Kubernetes. De obicei un container, dar poate avea mai multe care împart aceeași adresă de rețea și aceleași volume. Important: podul e de unică folosință. Nu se repară, se înlocuiește. Are o adresă IP care dispare cu el, de aceea traficul nu merge niciodată direct la un pod, ci la un Service.”

„Deployment-ul e ce scriu eu. El creează un ReplicaSet, care se ocupă să existe numărul cerut de pod-uri. La fiecare modificare de imagine, Deployment-ul creează un ReplicaSet nou și îl umflă treptat în timp ce îl dezumflă pe cel vechi — de aici vine actualizarea progresivă. ReplicaSet-ul vechi rămâne gol, ca să pot reveni la el.”

„ClusterIP e implicit și e vizibil doar în interiorul clusterului. NodePort deschide același port pe toate nodurile. LoadBalancer cere un echilibrator de la furnizorul de cloud. ExternalName e doar un alias DNS. În practică folosesc ClusterIP peste tot și un singur Ingress în față, pentru că un LoadBalancer per serviciu costă și nu aduce nimic.”

„Prima comandă e kubectl get endpoints. Dacă lista e goală, Service-ul nu găsește niciun pod — și în nouă cazuri din zece e o nepotrivire între eticheta pod-ului și selectorul serviciului, o literă în plus undeva. Dacă lista are pod-uri dar nu merge, atunci e portul: targetPort trebuie să fie portul pe care ascultă efectiv aplicația, nu cel pe care îl expune serviciul.”

„Service-ul lucrează la nivel de rețea și duce traficul la un set de pod-uri. Ingress-ul lucrează la nivel de HTTP: rutează după domeniu și după cale, termină TLS, și toate serviciile intră printr-o singură ușă. Ingress-ul singur nu face nimic — trebuie să ai un controler instalat care citește regulile și le aplică.”

„Ambele duc configurație în pod, ca variabile de mediu sau ca fișiere montate. Diferența declarată e că Secret-ul e pentru date sensibile. Diferența reală e mult mai mică decât pare: implicit, un Secret e doar codificat în base64, nu criptat. Cine are drept de citire pe el îl citește în clar. De aceea, pentru ceva serios, se activează criptarea în etcd sau se ține secretul în afară — Vault, External Secrets Operator, Sealed Secrets.”

Fraza despre base64 e una dintre puținele care, spuse spontan, arată imediat că ai lucrat efectiv.

„Deployment e pentru aplicații fără stare: pod-urile sunt interschimbabile, au nume aleatoare, pornesc și se opresc în orice ordine. StatefulSet e pentru ce are identitate: nume stabile și numerotate, disc propriu care rămâne al lui, pornire și oprire în ordine. Baze de date, cozi, orice are date locale. Diferența practică la care se sapă des: dacă un nod devine inaccesibil, pod-urile de Deployment se recreează imediat în altă parte, pe când un pod de StatefulSet nu se recreează automat — pentru că sistemul nu poate ști dacă cel vechi chiar a murit, iar două exemplare cu aceeași identitate ar strica datele.”

„Readiness înseamnă «pot primi trafic» — dacă pică, podul e scos din serviciu, dar nu se repornește. Liveness înseamnă «sunt viu» — dacă pică, containerul se repornește. Startup e pentru aplicații care pornesc greu și oprește celelalte două până termină pornirea. Greșeala pe care am văzut-o e sonda de liveness pusă pe un endpoint care verifică baza de date: baza are o problemă de zece secunde, toate pod-urile se repornesc simultan, și dintr-o încetinire iese o cădere totală.”

„Request e cât rezervi și după el se decide pe ce nod intră pod-ul. Limit e plafonul din timpul rulării. Asimetria e importantă: la procesor, dacă depășești limita, ești încetinit — aplicația merge, dar prost, și e greu de diagnosticat. La memorie nu există încetinire. Depășești și ești oprit — OOMKilled, cod de ieșire 137.”

„Planificatorul n-are unde să-l pună. Cel mai des nu sunt destule resurse libere pentru cât cere, dar mai poate fi un taint pe noduri fără toleranță în pod, un selector de nod care nu se potrivește, sau un volum care nu se poate atașa în zona aia. kubectl describe pod scrie motivul exact în evenimente, la final.”

„Containerul pornește, moare, și Kubernetes îl repornește cu pauze tot mai lungi. Prima comandă e kubectl logs --previous, ca să văd de ce a murit exemplarul dinainte, nu cel care tocmai pornește. Apoi codul de ieșire: 137 înseamnă oprit forțat, de obicei memorie; 1 sau 2 e de obicei o eroare a aplicației sau lipsește o configurație ori un secret.”

„Containerul rulează, dar sonda de pregătire nu trece. Aplicația e pornită și nu e gata, sau sonda e pusă greșit — calea greșită, portul greșit, sau un timp de așteptare prea scurt pentru cât durează pornirea. Verific în describe ce zice sonda și încerc endpoint-ul din interiorul pod-ului.”

„Actualizare progresivă cu maxUnavailable: 0 și maxSurge: 1 — adică ridic un pod nou înainte să scot unul vechi, deci capacitatea nu scade niciodată. Am nevoie de sondă de pregătire corectă, altfel traficul intră în pod-uri nepornite, și de oprire elegantă în aplicație, ca cererile în curs să se termine. Și în conductă pun obligatoriu kubectl rollout status cu timp limită, pentru că altfel comanda de actualizare întoarce succes imediat și livrarea pare reușită chiar dacă niciun pod nou nu a pornit.”

„Nu se întâmplă nimic rău, și ăsta e exact pericolul. Dacă pod-urile noi nu trec de sonda de pregătire, actualizarea se oprește pur și simplu: cele vechi continuă să servească trafic, cele noi stau nepregătite. Nu există revenire automată. Verific cu kubectl rollout status, mă uit în evenimente și în logurile pod-ului nou, și dacă nu e ceva de reparat pe loc, dau kubectl rollout undo.”

„Orizontal, cu Horizontal Pod Autoscaler, pe procesor sau pe o metrică proprie, și cu autoscalare de noduri dedesubt, ca să existe unde să încapă. Merge doar dacă aplicația e fără stare. Capcana e scalarea pe procesor pentru un serviciu care nu e limitat de procesor — dacă gâtuirea e numărul de conexiuni la baza de date sau lungimea unei cozi, scalarea pe procesor fie nu pornește, fie pornește și înrăutățește situația. Acolo se scalează pe metrica reală.”

„Nu. E o împărțire logică — nume, cote de resurse, drepturi. Dar traficul de rețea trece liber între namespace-uri, dacă nu pui NetworkPolicy, iar unele lucruri sunt la nivel de cluster oricum. Confuzia asta e frecventă și duce la clustere în care mediul de test poate vorbi cu producția.”

„Mașina virtuală are propriul nucleu și propriul sistem de operare, deci pornește în minute și ocupă gigaocteți. Containerul e un proces obișnuit pe mașina gazdă, izolat prin mecanismele nucleului, care împarte nucleul cu toate celelalte. Pornește în milisecunde și ocupă cât aplicația. Consecința practică: izolarea e mai slabă decât la o mașină virtuală, de aceea nu pui într-un cluster comun sarcini cu niveluri de încredere foarte diferite.”

„Imaginea e șablonul — straturi în citire, imutabile. Containerul e imaginea pornită, cu un strat de scriere deasupra. Dintr-o imagine pornești o sută de containere. Ce scrii în container dispare când îl oprești, de aceea datele merg pe volum și logurile merg la ieșirea standard.”

„Ordonez instrucțiunile de la cele care se schimbă rar la cele care se schimbă des. Copiez întâi fișierul de dependențe și le instalez, și abia apoi copiez codul — așa stratul cu dependențe rămâne în memoria tampon și nu se reinstalează la fiecare modificare de cod. Inversul, adică COPY . . înainte de instalare, invalidează totul la fiecare commit și e greșeala cea mai des întâlnită.”

„Într-o primă etapă folosesc o imagine mare, cu compilator și unelte, și construiesc aplicația. În a doua etapă pornesc de la o imagine minimă și copiez din prima doar rezultatul. Câștig dublu: imaginea finală e de zeci de ori mai mică, și nu duc în producție compilatoare și unelte care sunt, de fapt, suprafață de atac.”

„Imagine de bază minimă, ideal distroless, fixată pe versiune, nu pe latest. Rulare cu utilizator fără drepturi, nu root. Sistem de fișiere doar în citire unde se poate. Niciun secret la construire — dacă a ajuns într-un strat, rămâne recuperabil chiar dacă îl ștergi într-un strat următor. Și scanare automată în conductă, cu Trivy sau echivalent.”

„Pentru că nu e o versiune, e un indicator care se mută. Două livrări identice pot duce imagini diferite, și când ceva se strică nu mai poți spune ce rula acum o oră. Folosesc eticheta cu hash-ul commitului: e unică, imutabilă, și îmi spune exact ce cod e înăuntru.”

„La ieșirea standard, niciodată într-un fișier în container. Fișierul dispare cu containerul, umple discul nodului și nu e văzut de nimeni. La ieșirea standard îl preia platforma și ajunge unde trebuie.”

„Discul. df -h. E banal și e cauza cea mai des întâlnită — un disc plin oprește aproape orice, și adesea în moduri care par fără legătură: baza de date nu mai scrie, logurile se opresc, procesele se blochează. Durează o secundă și elimină cel mai probabil vinovat. După aia mă uit dacă procesul rulează, dacă ascultă pe port, ce zice jurnalul, și ce s-a schimbat recent.”

„ss -ltnp — arată porturile ascultate, cu procesul. lsof -i :443 face același lucru altfel. Dacă nimic nu ascultă, problema e în aplicație sau în serviciu, nu în rețea, și mă duc în journalctl -u.”

„du -sh /* | sort -h și cobor din director în director. Dar întâi verific ceva ce prinde mulți: un fișier șters de care încă ține un proces deschis nu eliberează spațiul. lsof | grep deleted îl arată, și se rezolvă repornind procesul, nu ștergând altceva.”

„-e oprește scriptul la prima comandă eșuată. -u dă eroare la o variabilă nedefinită, ceea ce prinde greșelile de scriere înainte să facă pagubă. -o pipefail face ca o conductă să eșueze dacă oricare element din ea eșuează, nu doar ultimul. Fără ele, un script care a picat la jumătate continuă și poate lăsa sistemul într-o stare mai proastă decât dacă nu-l rulai deloc.”

„Pentru că fără el, curl întoarce cod de succes și la un răspuns 500 — a descărcat pagina de eroare cu succes. Cu -f eșuează la coduri de eroare HTTP, deci set -e chiar oprește scriptul. Adaug și --max-time, altfel un apel poate atârna la nesfârșit într-un job de cron.”

„Că rulat de două ori dă același rezultat ca rulat o dată. Contează pentru că în operațiuni nu ai niciodată garanția că s-a rulat o singură dată — o reîncercare, un job pornit de două ori, un om care apasă iar. Un script care adaugă o linie în configurație de fiecare dată când rulează e o bombă cu ceas.”

„flock pe un fișier. E o linie și rezolvă complet problema joburilor din cron care se suprapun când unul durează mai mult decât intervalul.”

„Înseamnă că infrastructura e descrisă în fișiere ținute în Git, nu creată cu mâna în consolă. Câștigi trei lucruri: poți reface mediul identic, vezi în istoric cine a schimbat ce și de ce, și poți revizui o modificare înainte să se întâmple. Diferența de fond față de un script e că Terraform e declarativ — descrii ce vrei să existe, nu pașii.”

„E evidența a ce a creat Terraform și cum se leagă de resursele reale. Fără ea, nu poate ști ce să modifice și ce să șteargă. Trei reguli: stă la distanță, nu pe laptop, ca toată echipa să lucreze pe aceeași; are blocare, altfel două rulări simultane o corup; și conține valori sensibile în clar, deci se tratează ca un secret.”

„Când cineva schimbă ceva direct din consolă, realitatea nu mai corespunde cu codul. terraform plan îl arată ca diferență. Ce fac practic e să elimin cauza: acces de scriere doar din conductă, oamenii au citire. Dacă driftul e deja acolo, ori îl aduc în cod, ori îl las pe Terraform să-l corecteze — dar decizia se ia conștient, nu prin apply pe fugă.”

„Regula pe care o țin e că nu rulez apply fără să citesc planul până la capăt, și mă uit în primul rând la ce e marcat cu «destroy» sau «replace». O redenumire aparent inofensivă poate însemna, în plan, distrugerea și recrearea unei resurse. La resursele cu date pun prevent_destroy, ca sistemul să refuze chiar dacă omul greșește.”

„Da — Terraform pe AWS și pe Azure, în paralel, la RapidBid, plus Google Cloud la DISH, pe GKE și Cloud SQL. Ce am reținut e că diferența e mai mică decât pare din afară: se schimbă furnizorii, denumirile serviciilor și modul de autentificare, dar fluxul plan–apply, disciplina stării și felul în care împarți în module rămân identice. Serviciile se corespund aproape unu la unu.”

„Cel mai mare câștig, aproape mereu, e din resurse cerute mult peste ce se folosește efectiv — se plătește rezervarea, nu consumul. Pe urmă: medii de test oprite noaptea și în weekend, discuri și adrese IP rămase orfane după ștergeri, trafic între zone de disponibilitate care se plătește și adesea se poate evita. Și etichetarea resurselor, fără de care nu poți nici măcar să spui cine cheltuie.”

„Cele patru semnale de aur: latență, trafic, erori, saturație. Pentru latență mă uit la p95 și p99, nu la medie — media ascunde exact utilizatorii afectați. Poți avea o medie de 200 de milisecunde și un procent de utilizatori care așteaptă opt secunde, și ăia sunt cei care sună.”

„SLI e ce măsori — de exemplu procentul de cereri sub 300 de milisecunde. SLO e ținta internă pe acel indicator. SLA e promisiunea contractuală către client, întotdeauna mai relaxată decât SLO-ul, ca să ai marjă. Din SLO iese bugetul de erori: cât ai voie să greșești. Dacă mai ai buget, echipa livrează agresiv; dacă l-ai consumat, se oprește și repară. Decizia o dă măsurătoarea, nu cine vorbește mai tare în ședință.”

„Alertez pe simptom, nu pe cauză — rata de erori, nu procesorul la 90%, care poate fi perfect normal. Fiecare alertă care sună noaptea trebuie să ceară o acțiune umană imediată; dacă poate aștepta până dimineață, e tichet, nu alertă. Și fiecare alertă are un runbook. Când primești patruzeci de alerte pe zi și treizeci și nouă nu cer nimic, o ratezi pe a patruzecea.”

„Întâi restabilesc, apoi caut cauza. Confirm că preiau incidentul, ca să nu lucrăm doi pe același lucru. Verific ce s-a schimbat recent — livrare, configurație, certificat — pentru că acolo e cauza în majoritatea cazurilor. Dacă e o livrare recentă, revin la versiunea anterioară fără să caut mai departe; diagnosticul îl fac după ce oamenii au din nou serviciu. Și comunic din proprie inițiativă, la intervale, ca nimeni să nu întrerupă echipa ca să întrebe cum merge.”

Aici e terenul tău. Leagă imediat de Metro: „e exact ordinea pe care am folosit-o ani de zile în control de producție.”

„E analiza de după incident în care cauți cauza în sistem, nu în om. Dacă o comandă greșită a putut șterge producția, problema nu e omul care a scris-o, e că sistemul a acceptat-o fără confirmare și fără cale de întoarcere. Contează pentru un motiv foarte practic: dacă în analiză apar nume, data viitoare oamenii ascund incidentele, și pierzi exact informația de care ai nevoie.”

„MTTR e timpul mediu până la restabilire, MTBF e timpul mediu între căderi. În sisteme distribuite, ceva pică mereu — nu poți duce MTBF la infinit. Ce poți controla e cât de repede îți revii. De aceea se investește în revenire rapidă, în livrări mici și în posibilitatea de a întoarce o schimbare în câteva minute, nu în promisiunea că nu va mai cădea nimic.”

Folosește povestea Metro de la capitolul 4.2. Nu improviza alta — asta e repetată și rezistă la întrebări, pentru că e a ta.

Întrebarea asta nu caută greșeala, caută dacă ești în stare să o recunoști. Un candidat care spune „nu-mi amintesc să fi greșit” se descalifică singur. Structura: ce am făcut, ce s-a stricat, ce am făcut imediat, ce am schimbat ca să nu se mai poată întâmpla. Accentul cade pe ultima parte — acolo se vede maturitatea.

Se caută dacă poți fi în dezacord fără să transformi în conflict. Structura care funcționează: care era dezacordul, ce argument aveam eu, ce argument avea el, cum am decis, și ce am făcut după ce s-a decis altfel decât voiam. Ultima parte e cea evaluată. „Am spus ce cred, s-a decis altfel, am susținut decizia și am pus o măsură de siguranță pe riscul de care mă temeam” e un răspuns foarte bun.

„După impact asupra clientului, nu după cine a cerut mai tare. Dacă ceva afectează producția, are prioritate absolută și restul așteaptă — și le spun celorlalți că așteaptă, nu îi las să creadă că lucrez la ele. Anii de control de producție m-au învățat că a comunica ce nu faci e la fel de important ca a face.”

Răspunde concret, nu cu „citesc mult”. Ce anume, cât de des, și ultimul lucru pe care l-ai învățat și l-ai folosit. Un exemplu concret valorează cât zece afirmații generale.

„Scriu ce fac, ca să nu depindă nimeni de prezența mea pe un canal de discuții. Documentez ce am stricat și ce am reparat. Și anunț devreme când ceva durează mai mult decât am estimat — o întârziere spusă la timp e o informație, spusă târziu e o problemă.”

Nu inventa un plan de carieră spectaculos. „Tot pe partea de infrastructură și fiabilitate, cu mai multă adâncime pe Kubernetes și pe automatizare, într-o echipă în care pot să și dau mai departe ce știu. Nu am ambiție de management.” E scurt, credibil și nu te expune.

„Pentru că îmi lipsește ce am avut acolo: o echipă, o scară mai mare și proceduri serioase. Pe cont propriu am făcut toate rolurile și am învățat mult, dar lucrez singur. Vreau înapoi într-un mediu în care sistemele sunt mari și pot să mă specializez în loc să acopăr tot.”

Răspunde scurt și factual, fără nicio critică la adresa lor. Nu dai vina pe nimeni, nu povestești contextul intern, nu explici de trei ori. O propoziție despre ce a fost, una despre ce ai făcut după. Orice adaugi peste asta lucrează împotriva ta.

„Am lucrat pe cont propriu în perioada asta. Am construit și am ținut în funcțiune sisteme proprii — infrastructură, automatizări, integrări. N-a fost o pauză din muncă, a fost altfel de muncă. Ce mi-a lipsit e echipa și scara, și de asta mă întorc.”

„Nu cred că sunt. Partea de operare, incidente și sisteme mari o am solidă din anii de dinainte. Partea de unelte moderne — Kubernetes, infrastructură ca și cod, conducte — o am și vreau să o adâncesc. Mă interesează rolul ăsta, nu unul de conducere, și nu mă plictisește munca tehnică.”

Întrebarea ascunsă e: „o să pleci repede?” sau „o să fii greu de condus?”. Răspunsul trebuie să liniștească exact pe astea două.

Întreabă întâi tu: „Aveți un interval alocat pentru rol? Prefer să pornim de acolo, ca să nu pierdem timpul niciunul.” Dacă insistă să dai tu primul un număr, dă un interval, nu o cifră, și adaugă „în funcție de pachetul întreg”. Nu te scuza pentru cifră și nu explica de ce ai nevoie de ea — motivele personale nu au ce căuta în negociere.

E o întrebare bună și rar pusă, iar un răspuns onest impresionează. „Kubernetes l-am operat, dar am scris mai puține manifeste decât aș vrea. Și n-am dus o organizație întreagă pe GitHub Actions. Ambele sunt la câteva săptămâni de lucru efectiv distanță, și am mai făcut trecerea asta când am intrat pe Google Cloud.” Numește exact două lucruri, nu zece, și nu alege ceva esențial pentru post.

Răspunde adevărul, scurt, fără nume. „Da, mai am câteva în discuție, dar niciunul finalizat.” Nu e o amenințare și nu e o slăbiciune — e informație normală și te așază ca pe un profesionist căutat.