Como escrever um CV para um trabalho tech (engenheiros de software, programadores, data)

O CV tech é lido de forma diferente — o que muda

Antes das táticas, a diferença estrutural. Os CVs tech são avaliados através de uma lente diferente dos CVs corporativos, e a diferença molda cada secção:

• O hiring manager de engenharia lê o CV juntamente (ou após) com uma rápida varredura do teu GitHub, do teu site pessoal se tens um e do teu LinkedIn. O CV não é o único sinal; é um sinal numa avaliação multi-fonte
• A secção de competências técnicas é lida primeiro tanto por recrutadores como por engenheiros, mas eles procuram coisas diferentes. Os recrutadores escaneiam por correspondências de palavras-chave contra o JD; os engenheiros escaneiam se profundidade e amplitude correspondem à seniority do papel
• Os projetos frequentemente importam mais do que o historial de empregos nos níveis junior e mid. Um projeto auto-guiado que entregou algo real sinaliza iniciativa e execução de uma forma que um estágio ou primeiro emprego não conseguem
• O historial de trabalho é lido para scope, impacto e seniority do contexto — não apenas para nomes de empresa. Trabalhar na equipa de auth numa startup de 50 pessoas é diferente de trabalhar na equipa de auth numa empresa de 50.000 pessoas; o CV deve tornar o scope legível
• A presença no GitHub é verificada. Um candidato com perfil GitHub ativo (commits reais, múltiplos repositórios, gráfico de contribuição mostrando atividade recente) é tratado como engenheiro mais credível do que um sem — mesmo que a competência subjacente seja idêntica
• O CV é de uma página até não poder ser. Duas páginas são aceitáveis para engenheiros com 8+ anos de experiência, mas a segunda página deve conter substância real, não enchimento
• A educação importa a nível junior (especialmente para novos licenciados), torna-se menos importante a nível mid e torna-se quase irrelevante a nível senior+. Ajusta a proeminência em conformidade
• As certificações importam para papéis cloud específicos (AWS, GCP, Azure) e especialidades específicas (segurança, networking) mas são em grande parte irrelevantes para papéis gerais de engenharia de software

O resto deste guia é construído à volta destes factos estruturais. Cada secção aborda o que escrever, como organizar, o que enfatizar e o que cortar — calibrado especificamente para papéis de engenharia em vez de papéis corporativos genéricos.

A secção de competências técnicas — como organizá-la

A secção de competências técnicas é a secção mais escaneada num CV tech. Tanto recrutadores como engenheiros olham primeiro para ela. Como está organizada determina se transmite competência ou ruído:

• Organiza por categoria, não como uma única lista plana. Linguagens, frameworks, bases de dados, infraestrutura/cloud, ferramentas, metodologias — cada uma como o seu próprio grupo. Uma parede de 40 tecnologias separadas por vírgulas lê-se como um despejo de buzzwords; as mesmas 40 organizadas por categoria leem-se como um mapa estruturado de competências
• Lista tecnologias que podes discutir com confiança numa entrevista técnica. O entrevistador escolherá desta secção para desenhar perguntas técnicas; se listas Rust porque o usaste para um tutorial há três anos, falharás a entrevista
• Ordena cada categoria por proficiência genuína, não pelo que desejas que fosse verdade. Se és mais forte em Python e mais fraco em Go, põe Python primeiro — a ordem é lida como sinal de confiança
• Evita rótulos de nível de competência (Iniciante / Intermédio / Especialista / 8 em 10). São subjetivos, frequentemente imprecisos e criam perguntas estranhas em entrevistas. Ou listas uma tecnologia porque podes discuti-la com confiança, ou deixa-a de fora
• Faz correspondência com o vocabulário técnico na descrição do emprego. Se o JD diz 'React, Node.js, PostgreSQL, AWS', usa esses termos exatos — não 'frameworks JavaScript, servidores web, bases de dados relacionais, plataformas cloud'. O ATS keyword matching é literal
• Lista versões ou dialetos específicos quando relevante: 'Python 3.x', 'PostgreSQL 14+', 'React 18 com hooks'. A especificidade sinaliza profundidade
• Salta os básicos que se presume que todos têm. Listar 'HTML, CSS, Git, linha de comando' num CV de senior engineer é enchimento que expulsa o sinal real
• Se tens expertise especializado (compiladores, sistemas distribuídos, infraestrutura ML, sistemas em tempo real), cria uma linha separada 'especialidades' ou 'domínios' que o faça emergir. A especialização é mais valiosa do que a amplitude a nível senior

O teste para a secção de competências técnicas: um engenheiro a lê-la deveria poder prever como o teu trabalho diário realmente se parecia. Se a secção é uma nuvem de palavras genérica que poderia corresponder a qualquer candidato, está a falhar. Se está organizada, calibrada e honesta, faz a maior parte do trabalho do screening técnico antes do screening técnico acontecer.

Mostrar projetos — quando os projetos contam mais do que os empregos

Os CVs tech frequentemente incluem uma secção Projetos para além da Experiência Profissional. Para alguns candidatos a secção Projetos é a parte mais forte do CV. Quando incluir uma e como usá-la:

• Engenheiros junior e novos licenciados: a secção Projetos é essencial. Com historial laboral limitado, os projetos são a prova primária de que podes entregar código. Coloca esta secção acima ou logo após Educação
• Mudanças de carreira entrando em engenharia: a secção Projetos é essencial. É a ponte entre a tua experiência anterior e a tua capacidade de engenharia — e a única prova de que efetivamente construíste alguma coisa
• Engenheiros mid-level com historial laboral forte: a secção Projetos é opcional. Inclui-a se tens projetos paralelos que demonstram competências que o teu historial laboral não demonstra (open source, experiências ML paralelas, uma biblioteca publicada, uma extensão Chrome popular)
• Engenheiros senior e acima: a secção Projetos é geralmente desnecessária. O historial laboral a este nível deveria carregar o peso. Exceção: manutenção notável de open source, trabalho publicado bem conhecido ou contribuições comunitárias significativas
• Cada entrada de projeto deveria ter: nome do projeto (com link para o repo ou URL ao vivo), descrição de uma linha do que faz, o stack tech usado e 1-2 bullet points sobre o que foi não-trivial em construí-lo
• Prefere 2-4 projetos fortes a 8 fracos. Uma aplicação todo seguindo um tutorial não ajuda; um projeto que resolveu um problema real e sobre o qual podes discutir em profundidade, sim
• Se o projeto é um clone ou follow-along de tutorial, não o listes como projeto. Lista-o como 'exercício de aprendizagem' se mais, ou omite
• Os links ao vivo contam mais do que os links para o repo para projetos orientados ao utilizador. Um site deployado em que o hiring manager pode clicar é dramaticamente mais convincente do que um repo que ele tem de clonar
• Se o projeto teve colaboradores, nomeia-os e o teu papel específico. 'Construí API backend e camada de base de dados para projeto de equipa de 4 pessoas' é honesto e específico; reclamar autoria única de um projeto de equipa é o tipo de coisa que é apanhada na entrevista

O CV tech mais forte a nível junior/mid frequentemente tem 2-3 projetos substanciais sobre os quais o candidato pode falar em profundidade, com demos ao vivo. Isto frequentemente supera um historial laboral mais longo mas menos diferenciado. Constrói os projetos deliberadamente para serem a prova mais forte do teu CV.

GitHub, portfolio e trabalho demonstrável

Os links que incluis no teu CV tech são lidos como prova de que és um engenheiro praticante em vez de um titular de credenciais. Que links incluir e como apresentá-los:

• GitHub: inclui para quase todos os papéis de engenharia. Assegura-te que o perfil para o qual fazes link é real (commits recentes, múltiplos repos, readme de perfil populado). Um GitHub vazio ou estagnado linkado no teu CV é pior do que nenhum link
• Site pessoal: inclui se tens um e está atualizado. O site não precisa ser fancy; um portfolio simples com links para projetos, uma bio curta e informação de contacto é suficiente. Um site partido ou da era 2019 é pior do que nenhum site
• LinkedIn: inclui. Mesmo que penses que o LinkedIn é maioritariamente ruído, os recrutadores verificam-no e um perfil vazio sinaliza falta de profissionalismo
• Perfil Stack Overflow: inclui apenas se tens reputação significativa e respostas de alta qualidade. Um perfil de 50 reputação não sinaliza nada; um perfil de 50.000 reputação sinaliza expertise real
• Blog pessoal ou escrita técnica: inclui se escreves conteúdo técnico regularmente. Os posts de blog de engenharia demonstram capacidade de comunicação, profundidade técnica e hábito de reflexão — todos sinais que os hiring managers valorizam
• Talks em conferências, podcasts, aparições em vídeo: inclui se tens algum. Funcionam como validação de terceiros que podes comunicar ideias técnicas
• Torna todos os links clicáveis no PDF (Word e Google Docs ambos suportam isto quando 'Inserir hiperlink'). Os recrutadores clicarão; links partidos ou não-clicáveis custam-te o click-through
• Cura antes de linkar. Antes de adicionar o teu link de GitHub, olha para o teu perfil com olhos frescos. Pinna os teus melhores 4-6 repos no perfil. Assegura-te que os READMEs dos repos estão escritos. Apaga ou arquiva repositórios que existem apenas como tutoriais a meio. O hiring manager formará uma impressão em 30 segundos a olhar para o teu perfil — assegura-te que é a impressão que queres

Cada link no teu CV tech é uma promessa — clicar nele revelará mais provas da tua capacidade de engenharia. Se clicar revelar menos do que o CV sugeriu, a candidatura enfraquece. Os links são líquido-positivos apenas se o material subjacente está à altura do que o CV implica.

ATS para papéis tech — o keyword matching que importa

A maioria da contratação tech em grandes empresas ainda passa por sistemas ATS que filtram em palavras-chave. As dinâmicas do matching ATS para papéis de engenharia:

• ATS para papéis tech frequentemente executa matching literal de palavras-chave contra o JD. Se o JD diz 'React' e o teu CV diz 'React.js', alguns sistemas não corresponderão. Usa a ortografia exata do JD onde possível
• Lista tecnologias em múltiplas secções, não apenas na secção Competências. Um engenheiro senior que usou Kubernetes em produção em três empresas diferentes deveria ter 'Kubernetes' a aparecer nessas três descrições de emprego mais a secção Competências — o algoritmo de matching pondera as ocorrências
• Frameworks e ferramentas específicos contam mais do que categorias gerais. 'React, Vue, Angular' é melhor do que 'frameworks JavaScript'. 'PostgreSQL, MongoDB, Redis' é melhor do que 'bases de dados'
• Acrónimos e formas completas: inclui ambos. 'Machine Learning (ML)' cobre tanto as queries 'ML' como 'machine learning'. 'Continuous Integration (CI/CD)' faz o mesmo
• Variações comuns: 'Node.js' e 'Nodejs' e 'Node' são todos a mesma tecnologia mas os sistemas ATS podem não o saber. Se o JD diz 'Node.js', faz correspondência com essa forma exata
• Certificações e frameworks específicos da indústria: inclui se relevantes. 'PCI DSS', 'HIPAA', 'SOC 2', 'RGPD' se trabalhaste com eles. 'Agile', 'Scrum', 'Kanban' se executaste estes processos
• Evita o keyword-stuffing que parte a legibilidade. O CV é lido por humanos depois de passar ATS; se o leitor humano vê uma parede de nomes de tecnologia sem contexto, a candidatura falha no screening humano mesmo que tenha passado o screening ATS
• Adapta por candidatura. A lista de palavras-chave que passa um CV através do ATS da Google é diferente da lista de palavras-chave que o passa através do Greenhouse de uma startup. Faz correspondência com o JD específico

O matching ATS é um primeiro obstáculo necessário para papéis tech na maioria das grandes empresas. Trata-o como um exercício literal de matching: faz correspondência com o vocabulário do JD, lista tecnologias em contexto (em descrições de emprego, não apenas na lista Competências) e presume que o matching é parvo. Uma vez passado ATS, o leitor humano toma o controlo e o conteúdo importa mais do que a densidade de palavras-chave.

Quantificar o impacto de engenharia

Os CVs tech frequentemente sofrem do mesmo problema de afirmações genéricas que os CVs corporativos: 'desenvolvi features', 'melhorei performance', 'trabalhei na plataforma'. O impacto específico quantificado é o que separa um CV tech forte de um genérico:

• Performance: 'reduzi latência API p99 de 850ms para 120ms' bate 'melhorei performance API'. Os números específicos são credíveis; as afirmações vagas não são
• Escala: 'geri 50K req/sec no pico' ou 'processei 2B eventos/dia' ancora o trabalho em escala real. Sem números, o leitor tem de imaginar; com números, entende
• Custo: 'reduzi custo de infraestrutura AWS em 180K$/ano através de otimização de base de dados e tier-rightsizing' é a linguagem que aterra com a liderança de engenharia. A redução de custos é frequentemente a métrica de engenharia de maior alavancagem
• Fiabilidade: 'reduzi taxa de incidentes de produção de 8/mês para 1/mês' ou 'melhorei SLO do serviço de 99,5 % para 99,95 %' são métricas concretas de fiabilidade
• Equipa e scope: 'tech lead para equipa de 6 engenheiros' ou 'possuí design end-to-end e implementação do serviço de pagamentos' diz ao leitor o teu scope de responsabilidade. Sem isto, o trabalho poderia ser qualquer coisa de 'escrevi uma feature' a 'projetei o sistema inteiro'
• Entrega: 'entreguei 12 releases de produção em 18 meses com zero incidentes maiores' ou 'entreguei projeto 3 semanas antes do cronograma paralelizando infraestrutura e trabalho de feature' conta uma história de entrega
• Adoção: 'biblioteca interna usada por 15+ equipas' ou 'projeto open source com 8K estrelas no GitHub' quantifica o impacto do trabalho que não tem métricas orientadas ao cliente
• Quando não tens números específicos, dá descrições específicas. 'Migrei o serviço de pagamentos de monolito para arquitetura event-driven, com zero downtime durante o cutover' é concreto mesmo sem um número

O padrão: cada bullet deveria responder a 'e depois?' Se um bullet diz 'desenvolvi features', o e-depois é invisível. Se diz 'desenvolvi fluxo de checkout que conduziu o aumento de conversão de 2,1 % para 3,2 % durante a experiência de 6 semanas', o e-depois está mesmo ali. Reescreve bullets genéricos até terem ou um número ou um resultado específico concreto.

Open source, side projects, hackathons

A contratação de engenharia valoriza as contribuições fora do trabalho pago como prova de envolvimento genuíno com o ofício. Como geri-las no CV:

• Contribuições open source: inclui se substanciais. 'Maintainer de X (descrição do projeto, 8K estrelas)' é sinal alto. 'Contribuí bug fix para a biblioteca popular Y' é sinal médio. 'Submeti PR para o projeto Z' é sinal baixo a menos que o PR tenha sido substancial
• Lista a natureza da contribuição: maintainer, contribuidor regular, contribuidor ocasional, contribuidor uma vez. A distinção importa e o enquadramento honesto constrói credibilidade
• Se criaste uma biblioteca ou ferramenta open source popular, lidera com ela no CV. Um projeto open source amplamente usado é um dos sinais mais fortes possíveis de capacidade de engenharia
• Side projects: inclui 2-3 dos mais fortes numa secção Projetos. Salta side projects que são follow-alongs de tutorial, a meio terminados ou existem apenas como repos privados
• Hackathons: inclui apenas se ganhaste ou ficaste colocado num notável. Um 2º lugar num hackathon universitário ou industrial maior vale a pena listar; participação num hackathon universitário não, a menos que sejas muito junior
• Projetos internos da empresa: geralmente não contam como 'open source' mesmo que discutidos publicamente. Inclui-os em vez disso sob experiência laboral
• Envolvimento na comunidade: organizador de meetup, orador de conferência, convidado de podcast, escritor técnico — inclui estes se substanciais. Sinalizam um engenheiro que se envolve com a comunidade mais ampla em vez de apenas fazer o seu trabalho
• Sê honesto sobre o scope. 'Contribuí para o React' poderia significar 'abri um issue que foi fechado sem PR' ou 'escrevi 30 PRs que foram entregues'. A afirmação do CV e a prova GitHub têm de corresponder

O papel do open source e dos side projects muda com a seniority. A nível junior, são provas essenciais de ser um engenheiro praticante. A nível mid, diferenciam. A nível senior, sinalizam envolvimento continuado com o ofício para além do trabalho diário. Calibra a proeminência à tua fase de carreira.

Educação e certificações — o que importa

Os papéis tech ponderam educação e certificações muito diferentemente de outras indústrias. O panorama atual:

• Engenheiros junior (0-2 anos): a educação importa. Licenciatura em Ciência de Computadores ou relacionada de uma instituição conhecida tem peso. Lista educação proeminentemente, perto do topo do CV
• Engenheiros mid-level (3-7 anos): a educação importa menos. O historial laboral é o sinal primário. Move educação para o fundo do CV a menos que tenhas uma licenciatura particularmente notável (escola top-tier, licenciatura avançada em campo relevante)
• Engenheiros senior (8+ anos): a educação é quase irrelevante para a maioria dos papéis. Uma entrada de uma linha no fundo basta. A exceção são papéis que valorizam explicitamente credenciais académicas (research engineering, certos papéis ML/AI)
• Licenciados de bootcamp: lista o bootcamp. O mercado de contratação para licenciados de bootcamp amadureceu; bootcamps reputados (Hack Reactor, App Academy, Lambda School historicamente) são reconhecidos. Combina com projetos fortes para compensar o tempo mais curto de aprendizagem
• Engenheiros autodidactas sem educação CS formal: lidera com projetos e historial laboral. Lista aprendizagem auto-direcionada ('autodidacta, concentrado em desenvolvimento web full-stack desde 2019') honestamente. Não inventes credenciais, mas não te sintas obrigado a listar nenhumas se não as tens
• Certificações AWS / GCP / Azure: importam para papéis cloud-focused (DevOps, SRE, cloud architect, engenharia de infraestrutura). Lista o nível específico de certificação (Associate, Professional, etc.)
• Certificações de segurança (CISSP, OSCP, CEH): importam para papéis de segurança. Lista com data obtida
• Certificações gerais de software (Oracle Java, Microsoft .NET): em grande parte ignoradas. Listá-las num CV de senior engineer é enchimento
• Conclusões de cursos online (Coursera, Udemy, edX): geralmente não listes. Sinalizam que podes completar um curso, não que podes fazer o trabalho. Exceção: completar um programa especializado (Stanford ML, especialização de deep learning do Andrew Ng) poderia justificar uma menção de uma só linha
• PhD: lista no topo se recente e relevante; move para baixo com a seniority. PhD é um sinal forte para papéis orientados à investigação e um sinal neutro (às vezes ligeiramente negativo por perceção 'demasiado académico') para papéis de engenharia de produto

O padrão: a educação é um sinal de junior engineer que se desvanece com o tempo. As certificações são sinais de papéis especializados que importam quando são relevantes e são enchimento quando não são. Calibra a proeminência destas secções para onde estás na tua carreira.

CV tech remote-friendly — a nova norma

Uma parte significativa dos papéis de engenharia em 2026 são remotos ou híbridos. O CV deveria sinalizar remote-readiness, que agora é uma consideração de contratação por si só:

• Se tens experiência de trabalho remoto, marca-a: 'Senior Engineer (remoto), Acme Corp, 2022-2025'. Os recrutadores escaneiam por isto; a experiência remota é um sinal positivo para papéis remotos
• Localização: inclui cidade e país atuais, mas sinaliza flexibilidade se relevante. 'Lisboa, Portugal (aberto a remoto, fusos horários UE)' ou 'San Francisco, CA (aberto a remoto nos US)'. 'Aberto a relocação' vago é mais fraco do que disponibilidade específica
• Fuso horário: lista-o se aplicas para papéis remotos numa geografia diferente. 'Fuso horário: WET (UTC+0)' torna a programação mais clara
• Experiência com ferramentas de comunicação: num contexto relevante para remoto, mencionar experiência com Slack, Notion, Linear, Figma, pair programming baseado em vídeo e workflows async-first sinaliza fit para a cultura de engenharia remota
• Linguagem de auto-direção: 'liderei o projeto end-to-end da spec ao deployment' sinaliza a autonomia que o trabalho remoto requer. 'Trabalhei com a equipa para entregar X' é neutro; 'conduzi X do conceito ao lançamento independentemente' é mais forte para remoto
• Documentação e escrita: destaca qualquer escrita técnica, autoria de design docs ou contribuições RFC. As equipas remotas dependem excessivamente da comunicação escrita; os engenheiros que escrevem bem são mais fáceis de contratar remotamente
• Sinais de sobreposição de fuso horário: se trabalhaste explicitamente através de fusos horários (um engenheiro US a trabalhar com uma equipa em Berlim, ou vice-versa), menciona-o. A capacidade de colaboração assíncrona é não-trivial
• Evita sinalizar inflexibilidade remote-only se estás aberto a onsite. O viés ainda existe em algumas empresas; se és flexível, sinaliza flexibilidade

A remote-friendliness mudou de ser uma preferência do candidato para ser um critério de contratação. Mostrar no CV que trabalhaste remotamente, comunicaste assincronamente e operaste com auto-direção é agora parte do trabalho do CV — não apenas para papéis completamente remotos mas para híbridos e mesmo alguns papéis onsite onde a remote-readiness é tratada como sinal de qualidade.

CVs para junior vs mid vs senior vs staff/principal

A ênfase do CV de engenharia muda dramaticamente através das fases de carreira. O que funciona para um CV junior afundará um CV staff e vice-versa:

A declaração de sumário para papéis técnicos

A declaração de sumário no topo de um CV tech é opcional para papéis junior e cada vez mais importante de mid-level para cima. Como escrever uma que faça trabalho:

• Comprimento: 3-5 linhas. Suficientemente longa para enquadrar a tua especialidade, suficientemente curta para que o leitor a leia realmente
• Lidera com anos de experiência e especialidade primária: 'Engenheiro backend com 7 anos de experiência a projetar sistemas distribuídos de alta escala, principalmente em Go e Python.' Isto é a primeira coisa que o leitor vê e deveria ancorar o CV inteiro
• Segue com uma frase sobre o tipo de trabalho que fazes bem: 'Concentro-me na fronteira entre design de API e infraestrutura, com experiência profunda em arquiteturas event-driven e internos de bases de dados.'
• Termina com o que estás a procurar: 'A procurar papéis senior+ onde possa liderar o design de um sistema backend crítico e crescer em scope staff nos próximos 2 anos.'
• Evita descritores genéricos: 'apaixonado', 'orientado a resultados', 'atento aos detalhes'. Estes são zero-sinal e leem-se como enchimento
• Evita resumir o resto do CV. O sumário deveria adicionar informação que o leitor não pode obter escaneando o resto — especificamente a tua área de especialidade, a tua direção de carreira e o que te torna um candidato coerente
• Adapta por candidatura. O sumário é o lugar mais fácil para sinalizar que o CV é mirado a este papel específico. Um sumário escrito para um papel de infraestrutura backend numa empresa de bases de dados deveria ler-se diferentemente do sumário da mesma pessoa escrito para um papel de backend de produto numa empresa SaaS
• Salta o sumário inteiramente se és um engenheiro junior. Nessa fase de carreira, o sumário arrisca enchimento sem adicionar sinal; deixa o teu trabalho falar por si

A declaração de sumário é real estate de alta alavancagem no topo do CV. Usada bem, diz ao leitor quem és como engenheiro em 3-5 linhas e enquadra tudo o que segue. Usada mal (adjetivos genéricos, aspirações vagas), é enchimento que expulsa o sinal real.

Escolhas de formato de CV tech — uma página vs duas páginas

A pergunta de uma página vs duas páginas é mais matizada para CVs tech do que para outras indústrias. O quadro:

• Uma página: engenheiros junior (0-3 anos), a maioria dos engenheiros mid-level (3-7 anos) e engenheiros em mercados onde uma página é a norma cultural (a maioria da indústria tech US)
• Duas páginas: engenheiros senior com experiência substancial (8+ anos), engenheiros staff/principal com scope significativo a comunicar, engenheiros em mercados onde duas páginas são normais (a maioria da Europa, especialmente Alemanha, França, UK)
• Nunca três páginas. Se não podes encaixar o teu CV em duas páginas, o problema é a edição, não o espaço. Corta papéis mais antigos para sumários de uma linha, corta detalhe de papéis de carreira precoce, apara projetos menos relevantes
• Se tens um documento mais longo de estilo CV (estilo académico, com publicações, talks, patentes), mantém-no separado. O CV é o sumário orientado ao recrutador; o documento mais longo é para pedidos de follow-up
• Formato: coluna única ou dupla? Coluna única é mais segura para ATS. Se usas duas colunas (sidebar para competências/contacto, coluna principal para experiência), testa o parsing executando o PDF através de um resume parser online antes de submeter
• Fonte: fica com fontes padrão (Calibri, Helvetica, Arial, Source Sans, Inter). Fontes designer-y podem partir o parsing ATS. Texto corpo 10-11pt, headings 12-14pt
• Cor: mínima. Uma cor de acento para os headings de secção está bem; design a cor completa é desnecessário e pode partir ATS. O conteúdo é o sinal, não o design
• Foto: não nos CVs tech US. Em países europeus onde as fotos são normais (Alemanha, França), inclui um headshot profissional
• Formato de ficheiro: PDF. Sempre PDF. Os documentos Word re-fluem em máquinas diferentes e parecem partidos; os PDFs renderizam consistentemente. Nomeia o ficheiro consistentemente: 'Nome-Apelido-CV.pdf' ou 'Nome-Apelido-SeniorEngineer-CV.pdf'

As decisões de formato deveriam servir o conteúdo, não distrair dele. Um CV tech que usa fontes padrão, estrutura simples e cor modesta é mais legível do que um que tenta parecer um portfolio de design. A exceção é engenharia de design ou papéis front-end onde alguma sofisticação visual no CV em si é um sinal relevante — mas mesmo aí, a moderação lê-se como confiança.

Coordenar CV, LinkedIn, GitHub e site pessoal

O CV tech é um documento numa presença online coordenada. Os hiring managers de engenharia olharão para múltiplas superfícies, e a inconsistência entre elas é um sinal negativo. O playbook de coordenação:

• LinkedIn: deveria contar a mesma história que o CV em termos de papéis, datas e scope. O headline pode ser mais aspiracional ('Senior Backend Engineer interessado em sistemas distribuídos e developer tooling'), mas a substância deveria corresponder. Um LinkedIn que contradiz o CV (datas diferentes, títulos diferentes, scope diferente) destrói a confiança
• GitHub: deveria estar vivo. Commits recentes, readme de perfil populado, 4-6 repositórios pinnados que representam o teu melhor trabalho, READMEs de repo limpos. Um GitHub vazio linkado do CV é pior do que nenhum link. Se o GitHub é escasso, investe um fim de semana a limpá-lo antes de enviar o CV
• Site pessoal: opcional mas poderoso quando feito bem. Uma página simples com uma bio de um parágrafo, destaques de projetos, um link de download de CV e info de contacto basta. Evita Flash, formulários de contacto partidos, links mortos, datas de última atualização de 2020
• Consistência de nome e identidade: usa o mesmo nome e headshot através de CV, LinkedIn, GitHub, site pessoal. Os recrutadores fazem cross-reference; um 'James Smith' no CV que é 'Jim Smith' no LinkedIn cria fricção
• Endereço de email: consistente através de todas as superfícies. Usa um email profissional (teunome@teudominio.com ou nome.apelido@gmail.com), não um email universitário ou um username de 2005
• Número de telefone, localização e fuso horário: consistentes através das superfícies. Sinais de localização conflituosos parecem desatenção
• Se tens um portfolio de trabalho publicado (posts de blog técnico, talks, papers), faz link do CV para a fonte canónica — o teu site pessoal ou um perfil centralizado, em vez de 10 links separados
• Audita antes de aplicar. Antes de enviar o CV, clica em cada link nele como se fosses um recrutador. Olha para o perfil LinkedIn com olhos frescos. Navega o GitHub. Se encontras alguma coisa que contradiz ou enfraquece o CV, repara-o antes de aplicar

O hiring manager constrói uma única impressão de ti das superfícies coordenadas, não impressões separadas de cada uma. O CV que aponta para uma presença online coerente lê-se como mais credível do que um com um CV forte e um LinkedIn/GitHub fraco ou contraditório. Os trinta minutos de limpeza através das superfícies são um dos usos de maior alavancagem do tempo numa busca de trabalho tech.