Pentru roluri de architect (solution/software/enterprise), certificările sunt de obicei un “bonus” și nu un substitut pentru experiență. Ajută mai ales când:
- rolul este puternic orientat pe un vendor stack (Azure/AWS),
- e o poziție enterprise unde se caută framework-uri și vocabular comun (ex. TOGAF),
- vrei să semnalizezi că ai acoperit “fundamentals” (networking, IAM, cost, availability).
Ce contează în practică: deciziile și justificarea lor. Un architect bun poate explica trade-off-uri, riscuri, costuri și alternative, nu doar “diagrama”.
TL;DR
- Uită-te la mențiunile explicite din anunțuri (coduri/nume).
- Alege certificarea în funcție de tipul rolului: cloud solution vs enterprise architecture.
- Pregătește 2–3 exemple: decizie + constrângeri + alternative + rezultat.
Ce certificări apar în anunțuri (din joburile active)
Lista de mai jos e construită din mențiuni explicite în rolurile de Architect din platformă.
Certificări menționate în rolurile de Architect
Pe baza anunțurilor publicate în ultimele 365 zile.
Numărătoarea folosește mențiuni explicite de certificări din anunțuri din ultimele 365 zile.
Cum alegi (rapid)
Solution Architect (cloud-heavy)
Certificările cloud ajută dacă sunt aliniate cu joburile la care aplici. În interviuri se caută:
- availability și resiliency (SLO, failover, DR),
- security-by-default (IAM, secrets, network boundaries),
- cost awareness (trade-off-uri între managed services vs self-hosted),
- observability (ce măsori, cum alertezi, cum investighezi).
Enterprise Architect
Aici contează:
- alignment între business capabilities și systems,
- governance (standarde, “guardrails”, platform choices),
- comunicare și influență (stakeholders, prioritizare).
Ce proiecte/artefacte “validează” cel mai bine
Nu ai nevoie de proiecte “gigant”. Ai nevoie de artefacte clare:
- un architecture decision record (ADR) pentru o decizie reală,
- o diagramă + un text scurt cu constrângeri și riscuri,
- un exemplu de “security posture” (threat model, data flow),
- un plan de rollout/rollback și criterii de succes.
Exemple bune de subiecte:
- “Monolith vs microservices” într-un context concret (latency, team size, delivery).
- “Build vs buy” și cum calculezi cost/riscuri.
- “Multi-region” vs “single-region + DR” și ce alegi pentru un produs.
Greșeli frecvente
- “Arhitectură = diagramă”: fără justificare, diagrama nu spune nimic.
- Fără cost: multe decizii sunt cost-driven, chiar și în product.
- Prea multe buzzwords: fii specific despre constraints și trade-offs.
Checklist rapid (ca să “conteze” în CV și interviu)
- Include 2–3 ADR-uri (chiar și pe proiecte personale) unde explici decizia, alternativele și de ce ai ales varianta finală.
- Fă o diagramă simplă (C4 level 1–2) și adaugă 5–10 rânduri despre constrângeri (security, latency, cost, team size).
- Pregătește 2 exemple de incident/învățare: ce s-a întâmplat, ce ai schimbat în arhitectură după.
- Dacă certificarea e cloud, leag-o de un exemplu concret: IAM model, networking boundaries, logging/alerting.
- Când discuți “scalability”, spune exact ce măsori (RPS, p95 latency, error budget) și ce presupui.
Întrebări frecvente (și ce urmăresc)
Dacă nu am “Architect” în titlu, merită pagina asta?
Da. Multe roluri senior (backend, platform, staff) cer thinking de architect: decizii, trade-off-uri, ownership pe sisteme.
Ce ar trebui să pun primul: certificarea sau proiectele?
Proiectele. Certificarea e un semnal; proiectele arată că poți lua decizii și le poți susține.
Cum e construită lista (pe scurt)
- Scanează titlul + descrierea joburilor de Architect din platformă.
- Numără doar mențiuni explicite (coduri/nume), nu tehnologii generale.
- Arată câte anunțuri menționează fiecare certificare, într-o perioadă recentă.
Următorii pași
- Vezi joburi de Architect: /ro/cariere-it/rol/architect
- Model CV Architect
