Currículo para tecnologia: erros que afastam recrutadores
Currículo para tecnologia: conheça os erros que afastam recrutadores e veja como montar um currículo que realmente abre portas.
O recrutador passa dez segundos no seu currículo
Já participei do outro lado da mesa em mais de uma triagem técnica, e a verdade incômoda é essa: nas primeiras passadas, ninguém lê o seu currículo. A pessoa bate o olho. Em uns dez segundos, ela decide se vale a pena gastar mais um minuto ou se já vai para o próximo PDF da pilha. E a maioria dos currículos de tecnologia morre exatamente nesses dez segundos, não porque a pessoa é ruim, mas porque o documento conta a história errada. Você listou tudo que já tocou na vida e esqueceu de dizer o que de fato resolveu.
Este texto é sobre os erros que afastam recrutadores antes mesmo da entrevista, e o que colocar no lugar. Vou tratar o currículo como o que ele é: um filtro otimizado para ser descartado rápido. Em paralelo, vale fortalecer sua presença pública, porque um bom repositório costuma falar mais alto que qualquer bullet point — sobre isso escrevi em como documentar projetos no GitHub.
A parede de buzzwords não impressiona ninguém
O erro mais comum é tratar o currículo como uma lista de palavras-chave para passar no ATS. O resultado é uma parede: React, Vue, Angular, Node, Python, Go, Rust, Docker, Kubernetes, AWS, GCP, Terraform, Kafka, Redis, GraphQL. Quando vejo trinta tecnologias empilhadas, não penso "que pessoa completa". Penso "essa pessoa tocou em tudo por uma semana e não é boa em nada".
Liste o que você realmente usaria numa entrevista sem suar frio. Se você botou Kubernetes no currículo, eu vou perguntar sobre liveness probe, sobre como você debugou um pod em CrashLoopBackOff. Se a resposta for "ah, eu só fiz o deploy uma vez seguindo um tutorial", você acabou de queimar credibilidade no resto do documento. Menos tecnologias, com profundidade real, vencem a lista infinita.
"Responsável por" não diz nada
Este é o erro que mais dói. A seção de experiência vira uma lista de responsabilidades:
- Responsável por desenvolver APIs REST
- Responsável pela manutenção do sistema legado
- Responsável por code review do time
Isso descreve o cargo, não você. Qualquer pessoa naquela vaga era "responsável" pelas mesmas coisas. O que diferencia é o impacto, e impacto se mede com número e ação. Reescreva cada linha no formato verbo de ação + o que mudou + métrica:
- Reduzi a latência p95 da API de checkout de 800ms para 180ms migrando consultas N+1 para batch loading
- Cortei o tempo de build de CI de 14min para 4min com cache de camadas e paralelização de testes
- Eliminei 60% dos alertas de pager noturno corrigindo retries sem backoff no consumidor de fila
Nem tudo tem métrica bonita, e tudo bem. Mas "responsável por" nunca é a melhor versão da frase. Troque por "construí", "migrei", "reduzi", "automatizei". O verbo já carrega a ação; o número carrega a prova.
Três páginas, objetivo genérico e nenhum link
Alguns clássicos que matam o currículo de imediato:
- Três páginas ou mais. Se você não é sênior com quinze anos de estrada, currículo é uma página. Duas no limite. Ninguém vai ler a terceira, e o fato de existir uma terceira já sinaliza que você não sabe priorizar.
- Objetivo genérico. "Busco uma oportunidade desafiadora em uma empresa inovadora para crescer profissionalmente." Isso ocupa espaço e não diz nada. Corte. Se quiser um resumo no topo, faça uma linha concreta: "Backend dev focado em sistemas distribuídos, Go e Postgres, com histórico de reduzir custo de infra."
- Nenhum link. Sem GitHub, sem portfólio, sem LinkedIn. Para uma vaga técnica, o link para o seu código vale mais do que metade dos bullets. A ausência dele me faz desconfiar que não há o que mostrar.
- PDF que vira sopa de caracteres no ATS. Currículo em colunas duplas, ícones no lugar de texto, fonte exótica. O parser do ATS embaralha tudo. Layout simples, uma coluna, texto de verdade.
Adapte o currículo para a vaga
Mandar o mesmo PDF para quarenta vagas é eficiente para você e péssimo para o resultado. Cada vaga descreve o que importa: leia a descrição e reordene. Se a vaga é pesada em dados, o seu projeto de pipeline ETL sobe para o topo; aquele app mobile que você fez em 2019 desce ou some. Não estou dizendo para mentir — estou dizendo para destacar o que é relevante para aquela pessoa específica.
Isso custa cinco minutos por candidatura e muda a taxa de resposta de forma perceptível. Um currículo que parece feito para a vaga sinaliza que você leu a descrição e se importa. Um currículo genérico sinaliza que você está atirando para todo lado.
O que de fato abre portas
Vou dizer o que talvez você não queira ouvir: depois de certo ponto, o currículo importa menos que sua presença pública. Um README bem escrito, um projeto que roda quando eu clono, um perfil de GitHub que mostra commits reais — isso vence um currículo de duas páginas com facilidade. O currículo abre a porta; o seu código decide se você entra.
Por isso eu invisto mais em um portfólio enxuto e honesto do que em esticar a lista de experiências. Dois ou três projetos que você consegue explicar linha por linha valem mais do que dez repositórios mortos. E um README que explica o problema, a decisão técnica e o trade-off mostra exatamente o tipo de raciocínio que se quer numa pessoa de tecnologia.
Perguntas frequentes
Devo colocar um resumo no topo do currículo?
Pode, desde que seja concreto. Uma linha que diz o que você faz, com quais ferramentas e qual o seu diferencial. Evite frases motivacionais vazias. Se o resumo poderia estar no currículo de qualquer outra pessoa, ele não está fazendo nada por você.
Quantas tecnologias devo listar?
Liste apenas o que você defende numa entrevista com tranquilidade. Não há número mágico, mas se a lista passa de quinze itens, provavelmente há enchimento ali. Profundidade real em poucas tecnologias passa mais confiança do que uma vitrine de logos.
Vale a pena ter um currículo de uma página só?
Para a maioria das pessoas, sim. Uma página força priorização e respeita o tempo de quem lê. Sêniores com histórico longo podem ir a duas, mas raramente justifica-se passar disso. A terceira página é quase sempre um sinal de que falta foco.
Projetos pessoais contam mesmo sem experiência profissional?
Contam, e muito, quando estão bem documentados e realmente rodam. Um projeto que resolve um problema concreto, com README claro e código limpo, supre boa parte da ausência de experiência formal. É a forma mais direta de provar que você consegue construir algo de ponta a ponta.
Antes de mandar o próximo currículo
O currículo não é a sua biografia, é um anúncio com dez segundos de atenção. Corte as buzzwords, troque "responsável por" por conquistas com métrica, mantenha uma página, adapte para cada vaga e coloque o link para o seu código bem visível. E invista no que de fato decide a contratação: um portfólio honesto e um README que mostra como você pensa. O documento abre a porta, mas é o seu trabalho público que faz você entrar.
- 01 Licenças MIT, Apache e GPL: diferenças práticas para devs MIT, Apache 2.0 e GPL não são a mesma coisa. Entenda permissiva vs copyleft, proteção de patentes e compatibilidade antes de colocar código em produção.
- 02 Volumes Docker: bind mount, volume nomeado e tmpfs O filesystem do container some no docker rm e quebra dados de banco. Veja os tres tipos de volume, quando usar cada um, permissoes de UID e backup.