Exemplo de CV de DevOps Engineer

Porque é que um CV de DevOps engineer é lido de forma diferente

O recrutamento em DevOps tem as suas próprias prioridades, e são elas que explicam cada escolha abaixo. Um platform lead ou um recrutador técnico lê depressa à procura da prova de que constróis sistemas fiáveis e automatizados, não de uma lista de todas as ferramentas em que já tocaste:

• A automação vence o trabalho manual: conhecer uma ferramenta não prova nada, mas construir um pipeline que reduziu o tempo de deployment de duas horas para oito minutos é exatamente o sinal que um responsável de recrutamento procura primeiro
• A fiabilidade é o título principal: qualquer prova de que aguentaste um SLO, reduziste o mean-time-to-recovery ou sobreviveste a um incidente sem sobressaltos pesa mais do que todas as certificações da página juntas
• A infraestrutura como código mostra como pensas: nomear Terraform, Ansible ou CloudFormation sinaliza que geres sistemas como código reproduzível, não consolas configuradas à mão que ninguém consegue reconstruir
• És dono de todo o caminho até produção: os teus pontos devem mostrar que ligaste build, testes, deployment e monitorização — não apenas que 'usaste o Jenkins' isoladamente
• O custo e a escala são diferenciadores discretos: um engenheiro que reduziu uma fatura de cloud ou escalou um serviço sem downtime destaca-se de um que só manteve as luzes acesas

Lê o teu CV como o fará um platform lead: não 'esta pessoa conhece as ferramentas?' mas 'posso confiar-lhe o pipeline, manter a produção no ar e automatizar o trabalho repetitivo para a equipa entregar mais depressa?'. Cada secção abaixo responde a isso com provas.

A estrutura que funciona num CV de DevOps

Mantém-no em uma ou duas páginas limpas e começa pelos teus sinais mais fortes de fiabilidade e automação. Para a maioria das candidaturas de DevOps engineer, esta ordem funciona melhor:

O recrutamento em DevOps premeia a clareza em vez da decoração, por isso mantém o layout simples e seguro para leitores automáticos. Se tens experiência real de plataforma ou SRE, começa por aí; se estás a entrar na área, sobe na página os projetos, a automação e as certificações para que a prova apareça primeiro.

O resumo: stack, escala e um resultado de destaque

Três ou quatro linhas por baixo do teu nome — a parte mais lida do CV. Para um DevOps engineer deve responder a: que stack usas, a escala em que já operaste, e um resultado com que vale a pena abrir:

• Abre com a stack e o nível: «DevOps engineer com 4 anos a gerir produção em AWS e Kubernetes, responsável por CI/CD e infraestrutura como código para uma plataforma de 30 serviços»
• Nomeia os ambientes em que trabalhaste mesmo: AWS, Azure ou GCP; contentores; e as ferramentas de pipeline e de IaC que operas de facto — não uma sopa de palavras-chave
• Abre com um resultado concreto: «reduzi o tempo de deployment de 2 horas para 8 minutos e aumentei a frequência de releases 5x» diz mais do que qualquer adjetivo e enquadra-te como alguém que entrega
• Sinaliza como trabalhas: menciona automação, fiabilidade ou on-call para que se veja um engenheiro que é dono da produção, não um que só escreve YAML isolado
• Corta o enchimento vazio: «apaixonado por automação e cloud» não diz nada por si só — substitui-o por uma stack, uma escala e um número que sustente a afirmação

Um bom resumo de DevOps lê-se como o de alguém a quem um platform lead poderia entregar o pager de on-call já no próximo mês. Se o teu podia descrever qualquer engenheiro, acrescenta o detalhe concreto — uma cloud, uma escala, um número de deployment ou de uptime — que o torna inconfundivelmente teu.

A secção de competências: cloud, automação e observabilidade

Agrupa as tuas competências para que um responsável de recrutamento as percorra em segundos, e lista só o que sabes mesmo operar. Num DevOps engineer dividem-se em blocos claros:

Sê honesto quanto ao teu nível — se listas Kubernetes ou Terraform, conta que a entrevista o ponha à prova ao vivo. Uma lista de competências curta, precisa e específica em ferramentas vence uma longa e genérica, porque um platform lead consegue imaginar de imediato o tipo de sistema que te confiaria.

As experiências: liga cada mudança a velocidade, fiabilidade ou custo

Os melhores pontos de DevOps ligam uma automação ou mudança de plataforma a uma melhoria mensurável. Compara uma linha vaga com uma que dá a um responsável de recrutamento provas reais:

• Fraco: «Construí e mantive pipelines de CI/CD e geri infraestrutura cloud» — nenhuma escala, nenhum método, nenhum resultado, e nada que te distinga de qualquer outro engenheiro
• Forte: «Reconstruí o pipeline de CI/CD em GitHub Actions com testes paralelizados, reduzindo o tempo de deployment de 2 horas para 8 minutos e subindo a frequência de releases de semanal para 5x por dia»
• Forte: «Migrei 30 serviços para Kubernetes com infraestrutura gerida por Terraform, reduzindo o provisionamento de ambientes de 3 dias para 20 minutos e eliminando o configuration drift»
• Forte: «Introduzi SLOs e alerting em Prometheus que reduziram o mean-time-to-recovery de 90 para 25 minutos e diminuíram os incidentes Sev-1 em 40% ao longo de dois trimestres»
• Padrão a aplicar: verbo de ação + o sistema ou problema + a ferramenta ou método + o resultado (tempo de deployment, frequência de releases, MTTR, uptime, custo de cloud)

Os números não precisam de ser enormes — precisam de ser reais e defensáveis. «Reduzi a fatura mensal da AWS em 22% ao ajustar o tamanho das instâncias e adicionar autoscaling» é uma linha forte, porque prova exatamente o que um platform lead quer: um engenheiro que melhora o sistema, não apenas um que o mantém a funcionar.

Certificações e as ferramentas que provam o teu nível

DevOps é uma área em que as certificações de cloud e Kubernetes movem mesmo um CV, porque correspondem a uma fasquia partilhada em que os recrutadores confiam. Mas lista-as como credenciais, não como uma lista de desejos — e junta-lhes prova prática:

Coloca as certificações numa secção própria e curta, e mantém-nas exatas — um responsável de recrutamento sabe distinguir entre passar a CKA e 'familiarizado com Kubernetes'. A honestidade importa, porque a entrevista vai testar tudo o que afirmares.

Entrar em DevOps a partir de desenvolvimento, sysadmin ou redes

A maioria dos DevOps engineers chega de uma função próxima, e os responsáveis de recrutamento sabem-no — contratam engenheiros júnior e em transição pela aptidão, pela prova de automação e por qualquer exposição real a produção. Um título de DevOps vazio no currículo não é um problema se preencheres a página com a prova certa:

• Reformula a experiência próxima em termos de DevOps: um developer que montou o CI da equipa, um sysadmin que fez scripting do provisionamento de servidores, ou um engenheiro de redes que automatizou configurações já está a fazer trabalho próximo de DevOps — descreve-o assim
• Abre com a automação que construíste: um pipeline, um módulo Terraform, ou um script que eliminou trabalho manual prova melhor o instinto central da função do que qualquer linha de resumo do tipo 'aspirante a DevOps'
• Mostra o percurso de aprendizagem: uma certificação de cloud, uma CKA em curso, ou um homelab sinalizam que és sério e autodidata, exatamente o que uma equipa que aposta num júnior quer ver
• Aponta às vias de entrada: existem funções júnior de DevOps, de plataforma e de cloud support para quem muda de área, por isso adapta o CV a como essas funções filtram, em vez de enviares uma versão genérica
• Abre com capacidade, não com desculpas: nunca abras com a experiência que te falta — abre com algo que automatizaste, um sistema que mantiveste no ar, ou um projeto que consegues explicar linha a linha

Um CV de transição para DevOps vence pela prova de automação e aprendizagem autodidata, não pelos anos com o título. Preenche a página com um projeto real, uma certificação em curso, e qualquer trabalho próximo de produção reformulado corretamente, e vais destacar-te de candidatos que enviam um CV genérico de developer que ignora o que uma equipa de plataforma realmente procura.

ATS, palavras-chave e a triagem do recrutador

As funções de DevOps em empresas maiores passam quase sempre as candidaturas por software e por uma triagem rápida do recrutador antes de chegarem a um platform lead, por isso mantém o CV limpo e alinhado com o anúncio:

• Espelha a linguagem do anúncio: se diz 'CI/CD', 'Kubernetes', 'infraestrutura como código' ou 'observabilidade', usa essas frases exatas onde forem verdadeiras para ti
• Inclui as palavras-chave das ferramentas: AWS, Terraform, Docker, Jenkins, Prometheus, e as tuas certificações ajudam tanto o software como o recrutador a situar-te depressa
• Usa um título de função claro: colocar «DevOps Engineer» ou «Site Reliability Engineer» como título ajuda o software e o recrutador que lê por alto a categorizar-te corretamente
• Mantém o layout seguro para leitores automáticos: tipos de letra padrão, títulos claros, e nada de gráficos, tabelas ou colunas que se desconfigurem num ATS ou escondam o teu melhor trabalho de automação da triagem
• Guarda em PDF salvo indicação em contrário: mantém o teu layout intacto ao longo do sistema de candidatura, permanecendo legível para a maioria dos leitores automáticos modernos

O teste é simples: alguém conseguiria ler o teu CV do início ao fim num editor de texto simples e continuar a ver a stack, os pipelines e os resultados? Se sim, o leitor automático também consegue. Uma formatação limpa mais as palavras-chave do próprio anúncio levam-te a passar o filtro e a chegar ao platform lead.

Erros comuns num CV de DevOps

A maioria dos CVs de DevOps é rejeitada por razões corrigíveis e não por falta de capacidade. Evita estes erros e destacas-te de imediato:

• Uma parede de siglas sem prova: listar 40 ferramentas sem um único ponto que mostre que usaste alguma delas lê-se como revisão de matéria, não como experiência — liga as principais a uma mudança real que fizeste
• Nenhuma métrica em lado nenhum: um CV de DevOps sem um único número lê-se como alguém que não mede o próprio impacto, por isso junta um valor real — tempo de deployment, MTTR, uptime, custo de cloud — aos teus pontos mais fortes
• Listar tarefas em vez de resultados: 'mantive pipelines e infraestrutura' não diz nada a um platform lead — diz o que automatizaste e a velocidade, fiabilidade ou custo que mudaste
• Esconder a responsabilidade em produção: um CV que é só ferramentas e nenhum on-call, incidente ou SLO falha a mostrar a fiabilidade pela qual a função paga — mostra que és dono de sistemas em produção
• Um CV genérico para cada função: um DevOps engineer, um SRE e um cloud engineer são empregos diferentes — adapta o resumo, as competências e os pontos de abertura à equipa e ao anúncio à tua frente

Faz o teste do platform lead: em 30 segundos, consegue ver a stack que geres, um pipeline que construíste, um sistema em produção do qual és dono, e uma métrica que mudaste? Se sim, estás à frente da maioria. As correções são quase sempre as mesmas — prova as siglas, junta números, mostra responsabilidade em produção, e adapta à função.