Como transformar projetos pessoais em evidências no currículo de tecnologia
Um projeto pessoal vira evidência no currículo quando mostra o problema que ele resolve, as decisões técnicas que você tomou, como conferiu que funciona e o que ele ainda não faz. Escreva como projeto, nunca como emprego: sem cliente inventado, sem usuários que não existem, com o link para o código e uma frase sobre o seu papel.
O que um projeto pessoal consegue provar
Um projeto pessoal não prova que você trabalhou em equipe sob prazo de cliente. Ele prova outras coisas, e é nelas que o texto deve se apoiar: que você sabe sair de um problema e chegar a algo que funciona, que escolhe ferramentas por um motivo e que consegue testar e explicar o que fez.
Quem lê o currículo procura sinais de que a sua experiência cobre os requisitos da vaga. Quando a experiência profissional ainda não cobre, o projeto é o lugar em que você mostra a habilidade em uso. Por isso o projeto certo é o que toca nos requisitos das vagas que você quer, não o mais trabalhoso.
- Problema: o que o projeto resolve e para quem, mesmo que esse alguém seja você.
- Decisões: por que essa linguagem, esse banco, essa arquitetura, e o que você descartou.
- Validação: testes automatizados, comparação com dados conhecidos, uso por você mesmo durante semanas.
- Limites: o que ele ainda não faz e o que você mudaria. Isso mostra critério, não fraqueza.
Um antes e depois
O exemplo abaixo é inventado. Uma pessoa que quer a primeira vaga de backend fez uma API para controlar gastos de uma república de estudantes. A primeira versão do tópico só lista tecnologias; a segunda conta o projeto.
Antes: “Projeto pessoal: API de finanças em Node.js, PostgreSQL, Docker.”
Depois: “Divide Conta (projeto pessoal, 2026). API em Node.js e PostgreSQL para dividir despesas entre 5 moradores, usada pela minha república por 4 meses. Escolhi PostgreSQL pelas transações ao registrar um pagamento entre várias pessoas. 38 testes automatizados cobrem as regras de divisão. Ainda não tem autenticação por convite. Código: github.com/exemplo/divide-conta.”
| Trecho | O que mostra |
|---|---|
| “Para dividir despesas entre 5 moradores” | O problema e um uso real, com escala honesta. |
| “Escolhi PostgreSQL pelas transações” | Uma decisão técnica com motivo, assunto provável de entrevista. |
| “38 testes automatizados cobrem as regras” | Como você conferiu que funciona. |
| “Ainda não tem autenticação por convite” | O limite, dito por você antes que alguém pergunte. |
| “(projeto pessoal, 2026)” | O tipo de experiência, sem confundir com emprego. |
O que não escrever
O risco de um projeto pessoal é ele ser descrito como se fosse um emprego. Isso aparece na primeira conversa e derruba a confiança no resto do currículo.
- Não invente cliente, empresa ou cargo (“Desenvolvedor na Divide Conta”) para um projeto seu.
- Não diga “usuários” quando os usuários eram você e três amigos. Diga quem usava.
- Não copie métricas de produção (“99,9% de disponibilidade”) que você não mediu.
- Não liste como seu um projeto de curso que todos da turma fizeram igual. Se fez, diga que foi do curso e o que você acrescentou.
- Não esconda que o projeto seguiu um tutorial. Diga o que você mudou depois dele.
Onde o projeto entra no currículo
Sem experiência na área, crie uma seção “Projetos” logo depois do resumo e antes da experiência profissional. Com experiência na área, os projetos vão depois dela, e só os que acrescentam algo que o trabalho não mostra.
- Escolha dois ou três projetos. Mais que isso dilui. Fique com os que tocam nos requisitos das vagas que você quer; a página Skills mostra o que as vagas abertas pedem por área.
- Dê um nome e uma data a cada um. “(projeto pessoal, 2026)” ou “(projeto de curso, 2025)”.
- Escreva de duas a quatro linhas. Problema, decisão, validação, limite e link.
- Repita as tecnologias na seção de habilidades só se você as usou de fato no projeto.
O link ajuda, mas o currículo precisa se sustentar sem ele: muita gente decide sem clicar. O guia GitHub e portfólio no currículo mostra como escrever o resumo e o README para que digam a mesma coisa.
Qual projeto vale mais
Entre um projeto grande pela metade e um pequeno terminado, o pequeno terminado costuma servir melhor. Ele tem começo, decisão, teste e limite, e cabe numa conversa de cinco minutos.
- Projetos que resolvem um problema concreto rendem mais conversa do que clones de aplicativos famosos.
- Projetos com dados reais e públicos mostram que você lidou com dados imperfeitos.
- Contribuições a projetos de código aberto valem como projeto, com o link do pull request e o que foi aceito.
- Um projeto antigo que você não sabe mais explicar é melhor deixar de fora.
Se você está procurando a primeira vaga, o guia Primeira vaga em dados ou desenvolvimento liga a escolha dos projetos ao que as vagas de entrada pedem. Os outros guias de trajetória estão em Trajetória e carreira.
Perguntas frequentes
Projeto pessoal conta como experiência no currículo?
Conta como evidência de habilidade, não como experiência profissional. Coloque numa seção própria de projetos, com o tipo e a data, e descreva o problema, as decisões e como você validou.
Quantos projetos colocar no currículo?
Dois ou três costumam bastar. Escolha os que mais tocam nos requisitos das vagas que você quer e deixe o resto no GitHub ou no portfólio.
Posso colocar projeto feito seguindo tutorial?
Pode, se disser que partiu de um tutorial e mostrar o que você mudou ou acrescentou. Apresentar o resultado do tutorial como trabalho só seu é o que não funciona.
Preciso de usuários reais para o projeto valer?
Não. Diga com honestidade quem usou, nem que tenha sido só você, e mostre como conferiu que funciona, por exemplo com testes ou comparação com dados conhecidos.