O que um recrutador realmente examina primeiro
Um recrutador gasta alguns segundos no terço superior de um currículo de engenheiro de software antes de decidir se continua a ler: o seu cargo mais recente, as linguagens e frameworks na linha de competências, e o primeiro tópico sob o seu cargo mais recente. Tudo o que vem depois confirma a impressão já causada pelo topo da página, ou faz o leitor perder completamente a atenção.
Isso significa que o cabeçalho e a primeira experiência profissional pesam mais do que qualquer outra parte da página. Coloque a sua linha mais forte e específica primeiro em cada cargo, em vez de a esconder como o terceiro ou quarto tópico, e mantenha a linha de competências perto do topo para que um olhar rápido a alcance antes de passar ao próximo currículo da pilha.
Um exemplo júnior: projetos no lugar da experiência
Um engenheiro júnior com um estágio e alguns projetos pessoais ainda pode escrever um currículo completo e específico tratando cada projeto como uma entrada de emprego. Sob um projeto chamado "Order Tracker", um candidato júnior poderia escrever: "Construí uma app de rastreamento de pedidos em React e Node para um café local; adicionei um filtro de pesquisa que reduziu o tempo médio de busca de 12 segundos para menos de 2." Esta é uma ilustração específica e citada do padrão, não uma afirmação sobre um resultado típico.
A entrada de estágio segue a mesma regra: nomeie o que mudou, não apenas o que lhe foi atribuído. Uma linha como "Corrigi 14 bugs reportados no fluxo de checkout durante um estágio de 10 semanas, três dos quais bloqueavam o lançamento" diz mais a um leitor do que "Auxiliei a equipa de engenharia na correção de bugs." Mantenha esta seção a dois ou três projetos, cada um com um ou dois tópicos, em vez de listar cada repositório que alguma vez publicou.
Um exemplo pleno: tópicos de impacto com um antes e um depois
Um engenheiro pleno com três a seis anos de experiência deve substituir tópicos baseados em tarefas por um número de antes-e-depois onde exista genuinamente um. Para um cargo de backend, isso pode ser: "Reduzi a latência p95 do checkout de 1,8 s para 620 ms agrupando três consultas sequenciais numa só, num serviço que trata cerca de 40.000 pedidos por dia." O número faz o trabalho de convencer; a frase à volta só dá o contexto.
Um segundo exemplo para outro tipo de contribuição: "Liderei a migração do módulo de autenticação de um monólito para um serviço separado, coordenando com outras duas equipas ao longo de seis semanas sem tempo de inatividade durante a transição." Nem todo tópico precisa de uma percentagem - uma afirmação de âmbito como "coordenando com outras duas equipas" continua concreta, porque nomeia quem esteve envolvido e quanto tempo demorou, em vez de apenas chamar ao trabalho "colaboração entre equipas."
Quando manter uma seção de projetos separada
Uma seção de projetos dedicada vale a pena quando tem trabalho paralelo que mostra algo que o seu histórico profissional não mostra: uma linguagem que usa fora do trabalho, uma contribuição open source, ou uma ferramenta pessoal que construiu e ainda mantém. Para um candidato júnior, muitas vezes faz mais trabalho do que a própria seção de experiência; para um sénior, é normalmente opcional a menos que o projeto seja invulgarmente relevante para o cargo a que se candidata.
Mantenha cada entrada de projeto numa linha de contexto e um ou dois tópicos, a mesma densidade de uma entrada de emprego, e ligue ao repositório ou a uma demonstração ao vivo, se existirem. Uma seção de projetos que lista dez itens sem detalhe lê-se como preenchimento; três itens com um tópico específico cada leem-se como evidência.
Competências e ferramentas: específicas, não exaustivas
Liste as linguagens, frameworks e ferramentas sobre as quais se sentiria realmente confortável a ser questionado numa entrevista, agrupadas de uma forma que faça sentido para o cargo - linguagens, frameworks, infraestrutura, e assim por diante. Omitir uma tecnologia que usou apenas durante uma semana não é problema; a lista deve refletir aquilo sobre o que consegue falar, não tudo o que alguma vez tocou no seu currículo.
Faça corresponder a redação ao anúncio quando for honestamente precisa: se o anúncio diz "PostgreSQL" e usou-o, escreva "PostgreSQL" em vez de apenas "bases de dados SQL", já que tanto um sistema de rastreio de candidatos como um leitor humano costumam procurar o termo exato. Não adicione uma tecnologia que não usou só porque um anúncio a menciona - essa lacuna aparece logo na primeira conversa técnica.
Perguntas frequentes
- Um currículo júnior de engenheiro de software deve listar primeiro os projetos ou a experiência?
- Projetos primeiro se tiver pouca experiência remunerada, já que é aí que está a sua evidência mais forte e específica; mova a experiência acima dos projetos assim que tiver um estágio ou emprego real para mostrar, e mantenha a seção mais forte mais perto do topo da página.
- Quantos tópicos deve ter cada projeto ou cargo?
- Dois a quatro tópicos por entrada costuma bastar para mostrar o que construiu e o que mudou como resultado. Mais do que isso começa a diluir a página, e um leitor tende a lembrar-se muito mais da primeira ou segunda linha sob cada entrada do que da quarta ou quinta.
- Tudo bem reutilizar o mesmo currículo para cada emprego de engenharia de software?
- A estrutura pode manter-se igual, mas a linha de competências e a ordem dos seus tópicos devem mudar para corresponder aos requisitos declarados em cada anúncio, já que tanto um leitor humano como um filtro automático costumam procurar os termos específicos usados por esse anúncio.
- O que deve cortar um engenheiro pleno se o currículo ultrapassar duas páginas?
- Corte cargos com mais de cerca de dez anos, a menos que sejam diretamente relevantes, reduza qualquer tópico que descreva apenas uma responsabilidade em vez de um resultado, e mantenha a seção de projetos apenas se mostrar algo que o seu histórico profissional realmente ainda não cobre.