Engenheiro de Software
Um currículo de engenharia costuma ser lido duas vezes por duas pessoas diferentes que querem coisas diferentes. Alguém de recrutamento compara a stack com a da vaga e gasta bem menos de um minuto nisso. Depois alguém de engenharia lê procurando o tamanho e a dificuldade dos sistemas em que você trabalhou. Uma página ajustada para apenas uma dessas leituras falha na outra, e quase todas são ajustadas para a primeira.
A lista de tecnologias faz você ser lido e para de ajudar aí
O cruzamento de palavras-chave na primeira triagem é real, e fingir o contrário custa entrevistas. Se a vaga diz Kotlin e Postgres e você entregou com ambos, essas palavras precisam aparecer. Esse é todo o trabalho da seção de tecnologias.
E também todo o valor dela. Assim que alguém de engenharia começa a ler, uma lista de dezoito tecnologias atrapalha: sugere que a maioria foi tocada uma vez e torna impossível achar as duas em que você é realmente forte. Separe aquilo sobre o que você ficaria confortável em uma entrevista técnica do que apenas usou, ou corte o segundo grupo.
Números de versão, tabelas de anos por linguagem e barras de proficiência autoavaliadas leem como enchimento para quem vai entrevistar você. Nenhuma sobrevive à primeira pergunta técnica.
Descreva o sistema, não a tarefa
«Desenvolvi novas funcionalidades com React e Node.js» está em milhares de currículos e não diz nada sobre dificuldade. O que alguém de engenharia quer saber é escala e restrição: quanto tráfego, quantos dados, quantos serviços, o que não podia cair e quem mais dependia de você.
«Responsável pelo serviço de pagamentos — 400 requisições por segundo no pico, retentativas idempotentes em três provedores — e reduzi as retentativas por cobrança falha de 11% para 3%» diz em uma linha que tipo de engenheiro você é. Também entrega a pergunta de entrevista que fariam de qualquer forma, o que joga a seu favor.
Incidentes também cabem aqui. Algo que você quebrou e consertou, ou uma queda que diagnosticou, é lembrado de um jeito que trabalho de funcionalidade não é, e demonstra o senso operacional que separa pleno de sênior muito melhor do que um título.
Senioridade aparece no raio de impacto
Títulos são ruído entre empresas: um sênior em uma startup de doze pessoas e um em um banco não são a mesma afirmação, e quem lê sabe disso. O que viaja é o raio das suas decisões: quantas outras pessoas tiveram de conviver com elas, e por quanto tempo.
Documentos de design adotados, uma migração que outros times tiveram de seguir, uma interface chamada por uma dúzia de serviços, uma cultura de revisão que você mudou. Isso lê como senioridade em qualquer organização. «Mentorei desenvolvedores juniores» não, porque aparece em todo currículo de pleno para cima e nunca é detalhado.
Se você foi a pessoa que os outros consultam antes de mexer em determinada área, essa é a frase a escrever — e vale ser específico sobre a área.
Onde esses currículos costumam ser cortados
O padrão mais nocivo é uma página de responsabilidades que poderia descrever qualquer desenvolvedor de qualquer empresa: participei de revisões de código, trabalhei em ambiente ágil, colaborei com times multidisciplinares. Tudo verdade, tudo compartilhado com os demais candidatos, e no conjunto uma página inteira de nada.
O segundo é uma seção de projetos pessoais pesando mais que a profissional, em um currículo que tem experiência profissional. Projetos em formato de tutorial convidam à comparação com o seu trabalho remunerado e perdem. Mantenha um se for realmente incomum, e só se você gostaria de ser questionado sobre ele.
O terceiro é o silêncio sobre por que você saiu quando as datas gritam. Passagens curtas e lacunas são comuns e só viram problema quando a página parece desviar delas. Quatro palavras — «fim de contrato», «time dissolvido», «voltei a estudar» — eliminam a pergunta por completo.
Termos que aparecem em quase toda vaga.
- Linguagens e frameworks citados
- Um filtro literal na primeira triagem. Inclua o que é verdade e o que a vaga cita; não encha além disso.
- Design de sistemas
- Tráfego, volume de dados, modos de falha. «Escalável» não é evidência.
- Nuvem e infraestrutura
- Se você operava ou consumia. São trabalhos diferentes e a entrevista pergunta.
- Testes e integração contínua
- O que você mudou na forma de o time entregar, não que existiam testes.
- Plantão / produção
- Um incidente que você diagnosticou diz mais sobre senioridade do que qualquer título.
Acrescente um termo apenas quando a sua própria experiência o sustentar. A ApplySpan sinaliza os requisitos que você não pode comprovar em vez de escrevê-los por você.
Perguntas
Qual deve ser o tamanho de um currículo de engenheiro de software?+
Uma página até cerca de oito anos, duas depois disso. Menos uma regra do que uma observação: a primeira triagem é curta, e só se chega à segunda página quando a primeira mereceu.
Preciso de link para GitHub ou portfólio?+
Só se houver algo sobre o qual você gostaria de ser questionado. Um perfil abandonado de forks e tutoriais é pior que nenhum link, porque quem avalia julgará pelo mais fraco que encontrar.
Devo listar tecnologias que usei pouco?+
Não no mesmo grupo dos seus pontos fortes. Quem entrevista escolhe da sua lista, e não há ganho em uma pergunta sobre algo que você tocou uma vez há dois anos.