Test pentru DevOps engineer: întrebări exemplu și șablon de evaluare
De ce întrebările generice de infrastructură eșuează
Majoritatea evaluărilor DevOps pun întrebări de manual: "Ce e un container?" sau "Definește CICD." Aceste întrebări măsoară recall de trivia, nu dacă cineva poate proiecta un sistem rezilient sub presiune sau debuga un incident de producție la 2 dimineața.
Un test DevOps real ar trebui să măsoare judecata, nu faptele. Ar trebui să testeze dacă cineva înțelege trade-off-urile între automatizare și operabilitate, știe când să scaleze orizontal vs vertical, și poate raționa despre moduri de eșec.
Iată cum arată o evaluare DevOps cu semnal.
Categoria 1: design infrastructură sub constrângeri
Întrebare bazată pe scenariu:
"Ai o aplicație rulând pe o singură instanță EC2. Gestionează 1000 RPS, folosește 70% CPU și are 4GB RAM cu 60% utilizare. SLA-ul tău e 99.9% uptime. Aplicația e stateless. Ce schimbări ai face, și în ce ordine? Ce trade-off-uri faci?"
Asta testează:
- Înțelegere de scalabilitate vs redundanță (ambele necesare pentru 99.9%)
- Conștiință de cost
- Cunoaștere de secvențiere (failover înainte de optimizare)
- Articularea trade-off-urilor
O candidată care spune "adaugă un load balancer și pornește două instanțe mai mult în altă AZ" gândește clar. O candidată care spune "schimbă pe Kubernetes" ar putea face pattern-matching fără să înțeleagă constrângerea.
Categoria 2: răspuns la incidente și troubleshooting
Întrebare bazată pe scenariu:
"Pipeline-ul tău CI/CD eșuează pe build-uri aleatoare. Eroarea e 'connection timeout to Docker registry.' Problema se întâmplă aproximativ o dată la 20 de build-uri. Ce verifici primul, și ce instrumentare ai adăuga?"
Asta testează:
- Metodologie sistematică de debugging
- Înțelegere de izolare de rețea și autentificare
- Gândire de observabilitate
- Prioritizare
O candidată care începe cu "verifică pagina de status a registry-ului Docker" e mai puțin reflexivă decât una care spune "primul: e retry-able și am adăugat rate limiting? al doilea: verifică dacă token-ul registry-ului expiră la mijloc de build sau dacă config-ul de rețea s-a schimbat."
Categoria 3: revizuirea codului și configurației
Exercițiu live:
Furnizează un snippet Terraform de 30 de linii sau o configurație Docker Compose cu probleme intenționate. Cere candidatei să identifice problemele și să explice fix-ul.
Probleme Terraform exemplu:
- Security group permițând 0.0.0.0/0 pe un port de DB
- Politică de retenție backup lipsă pe RDS
- Parolă DB hardcoded în variabile
- Fără tag-uri pentru alocarea costurilor
Probleme Compose exemplu:
- Containere privilegiate fără justificare
- Health check-uri lipsă
- Logging la stdout fără limite (risc de umplere disc)
- Fără constrângeri de resurse
Asta testează dacă au livrat sisteme în producție și au învățat ce se sparge.
Categoria 4: arhitectură și selecția uneltelor
Conversație:
"Trebuie să coordonăm joburi pe 50 de microservicii. Fiecare job durează 2-30 de minute. Vrem garanții puternice de ordine. Ce ai folosi? Parcurge-mi trade-off-urile."
Răspunsuri valide:
- Temporal (orchestrare workflow, ordine puternică, complex de operat)
- Step Functions (gestionat, limitat la AWS, mai puțin flexibil)
- Pub/Sub + aplicație consumator (cuplare slabă, ordine slabă, operațional mai simplu)
- Kubernetes Jobs + controller custom (flexibil, mai mult overhead operațional)
Intervievatorul ar trebui să împingă înapoi: "Step Functions sună mai simplu." Candidata ar trebui să apere: "Până când trebuie să reîncerci un job care a reușit deja parțial, sau până când ai un job de 2 minute rulând pe SLA de 10 minute, atunci ai nevoie de state machine-ul de workflow."
Asta testează judecata și experiența, nu cunoștințele.
Categoria 5: observabilitate și monitorizare
Scenariu scurt:
"Ai deploy-at o schimbare și rata de erori a trecut de la 0.1% la 0.5%. Latența p99 e aceeași. Schimbarea a atins logging și tracing, nu gestionarea cererilor. Unde te uiți?"
Răspuns slab: "Verifică log-urile." Răspuns puternic: "Mai întâi, aș verifica dacă instrumentarea de tracing sau nivelul de logging s-a schimbat — asta ar putea crește vizibilitatea erorilor fără să crească erori reale. Apoi aș privi cardinalitatea log-urilor. Apoi aș verifica dacă logăm cazuri noi de eroare care nu erau prinse înainte."
Cum să structurezi evaluarea
- Take-home de 30 de minute: Scenariu design infrastructură + revizuire configurație. Cere-le să explice deciziile.
- Interviu sincron de 30 de minute: Conversație troubleshooting live + discuție arhitectură. Înregistrează raționamentul.
- Asociază evaluarea cu semnale de integritate de tastare. Candidatele DevOps care copiază soluții întregi din ChatGPT sau StackOverflow vor arăta pattern-uri de editare neobișnuite. ClarityHire capturează asta implicit.
Contra-punctul cinstit
Nu fiecare rol are nevoie de această adâncime. Rolurile DevOps junior sau SRE beneficiază de filtrare mai simplă. Pentru hiring senior+, această rubrică se aplică. Pentru mid-level, micșorează complexitatea dar păstrează structura bazată pe scenariu.
Pași următori
Pregătit să-ți evaluezi candidatele DevOps cu teste reale? Verifică hub-ul nostru de evaluare DevOps și Cloud Engineering pentru șabloane și ghidare despre cum să evaluezi abilitățile DevOps engineers.