Exemplo de CV para Software Engineer
Um CV de software engineer é lido por dois públicos muito diferentes, um a seguir ao outro: primeiro um sistema automático de triagem, depois um engenheiro sénior ou um recrutor técnico. Os dois procuram sinais muito diferentes na mesma página. O sistema quer correspondências exatas de palavras-chave com a descrição da função — nomes de linguagens, nomes de frameworks, os títulos certos no formato certo. A pessoa quer evidências: o âmbito do que realmente construiu, a profundidade técnica ao nível que a função exige, e resultados que provem que o seu trabalho teve impacto. Este exemplo cobre a estrutura, a secção de competências, os bullet points de experiência, a secção de projetos e os pequenos detalhes que distinguem um CV de software engineer que gera entrevistas de um que é filtrado nos primeiros 30 segundos. Tudo é editável no criador Cvida; use-o como ponto de partida e adapte ao seu stack e nível de senioridade.
Porque é que um CV de software engineer é diferente de um CV genérico
Comece pelas diferenças, porque elas explicam todas as escolhas que se seguem. O recrutamento em engenharia de software tem as suas próprias convenções:
- A especificidade técnica é o essencial do jogo: «web developer» é uma etiqueta, «TypeScript / React / Node / PostgreSQL» é uma correspondência real que o sistema consegue pontuar
- Os projetos contam tanto quanto os empregos: uma contribuição séria em open-source ou um projeto paralelo real em produção é tratado como experiência profissional por avaliadores seniores
- O stack importa mais do que o título: «Senior Engineer numa empresa pequena de que nunca ouviu falar» é julgado pelo stack utilizado e pela escala entregue, não pelo título
- A quantificação é técnica, não comercial: latência reduzida, pedidos por segundo geridos, MTTR melhorado, frequência de deploy, cobertura de testes — não «aumentei as receitas»
- A correspondência de palavras-chave no ATS é brutal em tecnologia: centenas de candidaturas por função significam que um recrutor literalmente procura os frameworks exatos mencionados no anúncio
Trate o seu CV como um documento técnico. A mesma precisão que usaria num documento de design de sistemas aplica-se aqui: nomeie as primitivas certas, mostre a escala em que operou, prove-o com resultados mensuráveis.
A estrutura de CV que funciona para funções de engenharia
A maioria dos CVs de software engineer funciona melhor nesta ordem — coloca o sinal técnico onde os avaliadores realmente olham primeiro:
- Cabeçalho: nome, título da função, localização, email, URL do GitHub, URL do LinkedIn, URL do portfólio/website — cada ligação clicável no PDF
- Resumo (3–4 linhas): anos de experiência, stack principal, uma ou duas especializações de domínio, o tipo de função que está a visar
- Competências: competências técnicas agrupadas (linguagens, frameworks, infraestrutura, ferramentas) — legível num scan de 5 segundos
- Experiência: funções em ordem cronológica inversa, cada uma com 3–6 bullet points focados no que entregou e no impacto
- Projetos (especialmente para júniores e mid-level): 2–4 projetos pessoais ou open-source com stack técnico e resultado
- Formação: grau + universidade + ano — breve, exceto se for um recém-licenciado com disciplinas relevantes
- Opcional: certificações (AWS, Kubernetes, etc.) e línguas faladas, se relevantes
Mantenha-o numa página para menos de 5 anos de experiência, duas páginas acima disso. Engenheiros staff/principal com âmbito real merecem a segunda página; todos os outros devem tratar uma página como a disciplina que os obriga a escolher os sinais mais fortes.
Os fundamentos de estrutura e extensão de CV em que este exemplo se baseiaO resumo: stack técnico primeiro, resultados depois
Três ou quatro linhas, no topo da página. É a parte mais lida a seguir ao seu nome. Deve responder a: quem é, o que entrega, que tipo de função se segue:
- Linha 1: anos de experiência + especialização principal. Exemplo: «Backend engineer com 6 anos de experiência a construir serviços distribuídos em Go na AWS.»
- Linha 2: o tipo de escala em que operou. Exemplo: «Responsável por serviços que tratam 50 mil pedidos/segundo; liderou a resposta a incidentes numa equipa de plataforma de 12 engenheiros.»
- Linha 3: sinal de amplitude técnica. Exemplo: «Sólido em Go, Kafka, Postgres; confortável em TypeScript e Python para trabalho adjacente.»
- Linha 4 (opcional): o que visa a seguir. Exemplo: «À procura de funções sénior ou staff a construir infraestrutura de plataforma à escala de consumidor.»
- O que eliminar: «apaixonado» / «team player» / «altamente motivado» — são preenchimentos que trabalham contra si. Os detalhes técnicos fazem a persuasão
Um resumo que nomeia um stack real, uma escala real e um próximo passo real supera sempre um cheio de adjetivos. Se não consegue nomear um stack específico pelo qual seria responsável, o resumo não está pronto — essa lacuna vai aparecer na entrevista de qualquer forma.
A secção de competências: sinais de profundidade, não uma parede de buzzwords
Agrupe as suas competências técnicas por tipo para que um avaliador possa fazer um scan em segundos. Dentro de cada grupo, ordene pela profundidade real — as mais fluentes primeiro:
- Linguagens: Go, TypeScript, Python, Rust (aproximadamente por ordem de fluência)
- Frameworks: React, Next.js, Node/Express, FastAPI, gRPC
- Dados / infraestrutura: PostgreSQL, Redis, Kafka, ElasticSearch, Kubernetes, Terraform, AWS (EC2, S3, RDS, Lambda)
- Práticas: design de sistemas distribuídos, observabilidade (Prometheus, Grafana, OpenTelemetry), CI/CD (GitHub Actions, ArgoCD), resposta a incidentes
- O que deixar de fora: ferramentas que usou uma vez há 5 anos, linguagens que tocou apenas num tutorial, «Microsoft Word» (a sério — os recrutadores vão revirar os olhos)
Seja honesto quanto à profundidade: se o lista, vai ser questionado sobre isso. Uma secção de competências curta e precisa supera uma longa cheia de sinais falsos — ser apanhado a mentir sobre Kafka no ecrã técnico custa-lhe a oferta.
Como construir uma secção de competências credível e específica, mapeada para a funçãoBullet points de experiência: entregou + escala + impacto, em cada linha
Os bullet points de engenharia mais fortes seguem um padrão apertado: verbo de ação → o que construiu → a escala ou impacto em números. Compare estes exemplos:
- Fraco: «Trabalhei no sistema de processamento de pagamentos» — sem stack, sem escala, sem resultado, sem âmbito de responsabilidade
- Forte: «Desenhei e entreguei um serviço distribuído de pagamentos em Go a processar 12 mil transações/segundo com 99,99% de disponibilidade em 3 regiões AWS»
- Forte: «Reduzi a latência p99 da API de 480ms para 90ms ao substituir a agregação em memória por uma vista materializada com Redis; lançado por trás de feature flag ao longo de 6 semanas»
- Forte: «Liderou a migração da equipa de um monólito Rails para 4 serviços em Go; reduziu o tempo de deploy de 35 para 6 minutos e o MTTR de incidentes de ~2h para 28 minutos»
- Forte: «Construí a plataforma interna de feature flags agora usada por 40 engenheiros em 6 equipas; integrei SDKs para Go, TypeScript e Python»
- Padrão a aplicar: comece cada bullet point com um verbo de ação (desenhei, entreguei, liderei, escalei, fui responsável, migrei, automatizei), nomeie a tecnologia, nomeie a escala ou o antes/depois
Os números não têm de ser impressionantes — têm de ser reais e específicos. «Processei 200 pedidos/segundo num pequeno checkout de e-commerce» é um bullet point forte para um engenheiro mid-level; ser honesto quanto à escala é mais persuasivo do que afirmações vagas de impacto.
Como quantificar o seu trabalho da forma como os painéis de recrutamento em engenharia o pontuamA secção de projetos: crítica para júniores, útil para todos
Uma secção de projetos forte responde à pergunta que os avaliadores têm sempre sobre candidatos cujos empregos do dia a dia não mostram toda a sua amplitude: o que consegue construir quando ninguém o impede? Tem peso sério para engenheiros em início de carreira e para quem está a fazer uma mudança de área:
- Escolha 2–4 projetos, cada um com: nome, uma linha de descrição, stack técnico, URL do GitHub ou link ao vivo, e 1–2 bullet points sobre o que é interessante na forma como o construiu
- As contribuições open-source contam: «Contribuí com uma reescrita do consumidor Kafka para {project} (merged, 30 mil downloads semanais)» é um sinal sério
- Projetos paralelos com utilizadores reais são ouro: «Construí {tool}: um CLI para X usado por ~200 programadores; escrito em Rust, empacotado via Homebrew»
- Os projetos de curso ou bootcamp são os mais fracos — inclua-os apenas se não tiver outra coisa e comece pelo que foi tecnicamente não óbvio
- Se tem 5+ anos de experiência sólida em emprego, esta secção torna-se opcional; substitua por «Contribuições open-source selecionadas» se tiver alguma
Mantenha cada ligação de projeto ativa. Um avaliador que clica no URL do GitHub e aterra num repositório real, recentemente ativo, com um README limpo, está meio convencido antes de ler os seus bullet points — coloque o sinal à frente dele com um único clique.
Formação + certificações: seja breve
Para software engineers, esta secção justifica o seu espaço apenas quando acrescenta um sinal específico:
- Se tem um grau, liste-o: tipo de grau, área, universidade, ano. Uma linha. Omita a média se não for um recém-licenciado com uma nota forte
- Recém-licenciados (0–2 anos após conclusão): acrescente disciplinas relevantes ou projetos de dissertação, mas apenas os que se mapeiam para a função que quer
- Licenciados de bootcamp: nomeie o bootcamp + o ano; destaque os projetos e o código em produção que entregou desde então, não o currículo
- Autodidatas: omita completamente a secção de formação; deixe a secção de projetos + experiência profissional fazer o trabalho
- Certificações que vale a pena listar: AWS Solutions Architect / Associate, GCP Professional Cloud Architect, CKA (Certified Kubernetes Administrator). Omita «Codecademy concluído» — os recrutadores não o contabilizam
A formação importa cada vez menos à medida que se afasta da conclusão do curso. Por volta do 5.º ano, uma secção sólida de projetos + experiência torna a linha de formação quase invisível — que é exatamente o que quer. A entrevista será sobre o seu código, não sobre o seu grau.
Otimização ATS: corresponda ao anúncio com exatidão
Mesmo ao nível sénior, o seu CV é analisado antes de um humano o ver. A pontuação ATS em engenharia é inusualmente literal quanto aos nomes das tecnologias:
- Espelhe os nomes exatos dos frameworks do anúncio. Se disser «React.js», escreva «React.js» (não apenas «React»); se disser «Node.js», escreva «Node.js»
- Escreva tanto a abreviatura como o nome completo onde diferem: «Kubernetes (K8s)», «Continuous Integration (CI/CD)» — cobre ambas as variantes de palavra-chave
- Mantenha o formato simples: tipos de letra standard, sem layouts de duas colunas, sem imagens com texto, sem separadores elaborados. Os parsers ATS estragam tudo o que é visualmente engenhoso
- Guarde como PDF exceto se o anúncio pedir Word — o layout sobrevive à conversão de forma mais fiável
- Não coloque palavras-chave numa linha «skills» oculta em texto branco. Os ATS modernos detetam isso e os recrutadores riem-se — e o ecrã técnico apanha a mentira de qualquer forma
O teste mais simples: consegue abrir o seu CV num editor de texto simples e lê-lo de cima a baixo numa ordem lógica? Se sim, o parser também o fará. Se as suas competências acabarem no meio da linha de formação, a formatação está a lutar contra o parser.
O guia completo ATS para formatação de CV segura à análise automáticaErros comuns que filtram bons engenheiros
Mesmo engenheiros tecnicamente fortes perdem entrevistas por erros de CV fáceis de corrigir:
- Listar todas as linguagens que alguma vez tocou: dilui os sinais reais e convida a perguntas de entrevista onde vai hesitar. Liste o que defenderia com confiança numa entrevista, nada mais
- Resumos cheios de buzzwords sem stack: «engenheiro full-stack apaixonado com forte capacidade de comunicação» não diz nada ao leitor. Nomeie um stack e uma escala
- Sem ligações: um CV de software engineer sem URL do GitHub ou portfólio é suspeito — os avaliadores querem ver código. Acrescente o URL mesmo que o seu GitHub seja modesto
- Bullet points parede-de-texto: bullet points com mais de duas linhas perdem o leitor em scan. Mantenha-os concisos: ação + tecnologia + resultado
- Sinais de stack desatualizados: deixar «jQuery» na lista de linguagens quando escreve TypeScript há 5 anos sinaliza que o CV não foi reescrito há muito tempo — e que talvez também não se tenha atualizado
Faça o teste do recrutor: em 30 segundos, consegue um avaliador ocupado ver o que constrói, a que escala, e para que funções é adequado? Se sim, este CV vai trazer-lhe os screens. Se não, as correções são quase sempre as mesmas — bullet points mais concisos, stack nomeado, menos adjetivos, ligações a funcionar.
O guia completo para adaptar um CV a funções em tecnologia — mapeamento de stack e sinais de senioridade