Exemplu de scrisoare de intenție pentru inginer DevOps

De ce majoritatea scrisorilor de inginer DevOps sunt o listă de unelte

Scrisoarea tipică de DevOps este o listă de unelte scrisă în proză. Kubernetes, Terraform, Jenkins, Prometheus, Docker, pasiune pentru automatizare. Omul care o citește are CV-ul tău deschis alături, cu exact aceleași cuvinte. Întrebarea lui este alta: cât durează la tine un deploy, de câte ori s-a stricat luna trecută și ce ai schimbat ca să nu se mai strice.

Varianta care funcționează nu enumeră tehnologii. Ia un pipeline, un incident sau o factură de cloud și spune cifra care s-a mișcat.

Exemplul de pe pagina asta este scris de Vlad Crăciun, inginer DevOps cu cinci ani la Orange România, în București, pe platforma de servicii digitale. Aplică la o poziție de inginer DevOps senior la NTT DATA Romania, în Timișoara, pe un client din zona de producție, și s-ar muta pentru post.

Deschide cu ceva concret

Vlad nu începe cu „sunt interesat de poziția anunțată". Primul paragraf spune ce administrează: 60 de servicii în trei clustere Kubernetes, cu aproximativ 40 de lansări pe săptămână, și pipeline-urile prin care trec toate.

În a doua frază spune de ce NTT DATA. Nu „pentru oportunitatea de a lucra cu tehnologii de top", ci pentru că anunțul cere migrarea unui client dintr-un centru de date propriu în cloud, iar el a făcut exact asta pe douăzeci și trei de servicii, inclusiv partea neplăcută cu bazele de date vechi. Leagă experiența de cerința cea mai grea din anunț.

Ce reții: primul paragraf dă scara infrastructurii și o cerință preluată din anunț.

Arată rezultate, nu adjective

Mijlocul scrisorii este dovada. Vlad scrie că a scurtat timpul de la commit la producție de la două zile la 35 de minute, după ce a rescris pipeline-ul în GitLab CI și a introdus lansarea progresivă pe 5% din trafic. Că a scăzut costul lunar de infrastructură cu 31%, aproximativ 18.000 de euro pe an, mutând sarcinile de procesare pe noduri temporare și ștergând patru medii de test care rulau degeaba. Că a redus timpul mediu de restabilire a serviciului de la 48 la 11 minute, după ce a legat alertele la un singur manual de intervenție scris pe un ecran.

Uită-te la ce nu scrie. Nu scrie „experiență solidă cu Kubernetes" și nu scrie „mentalitate de automatizare". Le arată prin muncă, iar cititorul trage singur concluzia.

Ce reții: înlocuiește fiecare adjectiv cu un număr. În loc de „bun în optimizarea costurilor", scrie „am scăzut factura lunară cu 31%".

Explică de ce firma asta, nu oricare

Paragraful al treilea este cel pe care aproape toți inginerii îl ratează. Vlad menționează că firma are centre în mai multe orașe din România și întreabă direct cum se împarte responsabilitatea de gardă între echipe aflate în orașe diferite, pentru că la el rotația de gardă a fost cea mai grea parte de organizat. Nu este un compliment, este o întrebare de inginer care a fost trezit la trei dimineața.

Rezolvă și mutarea, într-o frază: se poate instala în Timișoara în șase săptămâni și poate lucra hibrid de la început. Fără propoziția asta, mulți recrutori elimină candidatul din alt oraș.

Ce pui în scrisoarea de inginer DevOps

• Scara infrastructurii: servicii, clustere, lansări pe săptămână
• Un timp sau un cost pe care l-ai scăzut, cu cifre
• Un incident real și ce ai schimbat după
• Uneltele menționate în context, nu ca listă
• Disponibilitatea pentru gardă și, dacă e cazul, termenul de mutare

Ce lași afară

Scoate lista de unelte. Scoate certificările fără context, pentru că sunt în CV. Scoate „pasionat de automatizare" și „orientat spre soluții". Și nu scrie niciodată detalii care expun arhitectura internă a angajatorului actual, nume de servere sau adrese. Prima concluzie a cititorului va fi exact asta.

Nu copia fraza din anunț despre „cultura DevOps". Dacă apare identic, se vede.

Cât de lungă trebuie să fie

Scrisoarea lui Vlad are 290 de cuvinte și intră pe o pagină. Trei paragrafe: ce administrezi, ce cifră ai mutat, de ce aici. Dacă anunțul este în engleză, scrie scrisoarea în engleză, nu tradusă din română. Diferențele sunt în articolul despre CV-ul în limba engleză.

Pe scurt

O scrisoare bună de DevOps nu dovedește că știi Kubernetes. Dovedește că înțelegi ce costă o indisponibilitate și că ai făcut deja ceva măsurabil în privința asta. Scrie-o ca pe un postmortem bun: ce s-a întâmplat, ce ai schimbat, ce s-a îmbunătățit.

Structura completă este în ghidul despre scrisoarea de intenție.