Projetos pessoais para conseguir emprego: quais valem e como apresentar

Você terminou o curso, fez os exercícios, montou o portfólio com três projetos e mesmo assim as candidaturas somem no vazio. O problema raramente é falta de projeto: é que os projetos que você construiu são exatamente iguais aos de milhares de outros candidatos. Um clone de to-do list, uma calculadora, uma página de portfólio que só fala do próprio portfólio. O recrutador bate o olho e não consegue extrair uma única informação útil sobre como você pensa. Este guia é sobre o oposto disso: quais projetos pessoais realmente movem a agulha numa entrevista e, principalmente, como apresentá-los para que alguém ocupado entenda o seu valor em trinta segundos.

Por que a maioria dos projetos pessoais não ajuda em nada

A verdade incômoda é que o projeto, sozinho, quase nunca consegue a vaga. O que conquista o recrutador é a evidência de raciocínio que o projeto carrega. Um CRUD bonito não diz se você sabe decidir entre duas abordagens, lidar com um caso de erro feio ou explicar por que escolheu uma biblioteca em vez de outra. E é exatamente isso que a pessoa do outro lado precisa avaliar.

Por isso, projetos de tutorial copiados linha a linha têm valor próximo de zero. Não porque sejam ruins de fazer — são ótimos para aprender —, mas porque não diferenciam você de ninguém. Quando cem candidatos enviam o mesmo clone de Netflix feito no mesmo vídeo do YouTube, o projeto deixa de ser um sinal e vira ruído.

O ponto de virada acontece quando o projeto contém uma decisão sua. Algo que você escolheu, errou, refez e consegue defender. É esse pequeno atrito — "tentei do jeito X, deu problema de performance, migrei para Y" — que transforma código em conversa de entrevista.

Os tipos de projeto que recrutadores realmente notam

Nem todo projeto pessoal pesa igual. Na prática, alguns formatos comunicam senioridade e iniciativa muito melhor do que outros.

Projeto que resolve um problema real seu. O mais subestimado e o mais forte. Um script que organiza seus downloads, um bot que te avisa quando baixa o preço de algo, uma planilha que virou app. Funciona porque tem motivação genuína: você consegue explicar o problema, a solução e por que ela importa, sem decorar nada.

Contribuição open source. Não precisa ser um pull request gigante. Corrigir um bug, melhorar uma documentação confusa ou adicionar um teste numa lib que você usa já demonstra que você sabe ler código alheio — habilidade que 90% dos juniores não treina. Recrutadores técnicos sabem ler um histórico de commits, e ver seu nome no repositório de um projeto conhecido vale mais que dez projetos solo.

Clone com uma decisão própria. Clones contam, sim, desde que você adicione uma camada de raciocínio. Refez um clone de Twitter mas implementou paginação por cursor em vez de offset? Comparou Server-Sent Events com WebSocket para o feed em tempo real? Isso deixa de ser cópia e vira estudo de caso.

Projeto de domínio específico. Se você quer entrar numa fintech, um projeto que lida com cálculo de juros, conciliação ou formatação de moeda diz mais do que um portfólio genérico. Alinhar o projeto ao nicho da vaga é um atalho enorme para parecer "encaixado".

Quantidade certa: qualidade sobre volume

Uma das perguntas mais comuns de quem está montando o portfólio é quantos projetos colocar. A resposta consistente entre recrutadores é simples: de 3 a 5 projetos bem documentados batem qualquer lista de quinze repositórios pela metade. Um portfólio com vinte projetos inacabados sinaliza o oposto do que você quer — falta de foco e dificuldade de terminar coisas.

Prefira profundidade. Três projetos com README decente, deploy funcionando e um histórico de commits que conta uma história valem infinitamente mais. Aliás, repositório com um único commit gigante chamado "first commit" é uma bandeira vermelha silenciosa: sugere que você só subiu o resultado final, sem processo.

Se você ainda está na fase de acumular base técnica antes de partir para projetos, vale alinhar essa construção a um plano maior — é mais ou menos o que eu detalho no roadmap de estudos de programação, que trata da ordem de aprendizado; aqui o foco é o passo seguinte: transformar o que você aprendeu em prova concreta.

Como apresentar: o README é o seu currículo de verdade

A maioria dos juniores investe 95% do tempo no código e 5% na apresentação. Recrutadores fazem o caminho inverso: eles abrem o README antes do código. Um README forte responde, em ordem, a quatro perguntas:

1. O que é e qual problema resolve (uma frase, no topo).
2. Como rodar (idealmente um docker compose up ou três comandos).
3. Decisões técnicas — a seção que vence a entrevista.
4. O que você faria diferente — mostra autocrítica e senioridade.

A seção de decisões técnicas é a mais negligenciada e a mais poderosa. Algo assim:

## Decisões técnicas

- **Cursor pagination em vez de offset**: o feed cresce rápido e offset
  fica lento em tabelas grandes. Cursor mantém a query O(log n).
- **Optei por SQLite no MVP**: zero infra para o recrutador rodar local.
  Em produção trocaria por Postgres (ver `docs/scaling.md`).
- **Sem framework de estado**: o app é pequeno; Context API já resolve.
  Redux seria over-engineering aqui.

Três bullets como esses dizem mais sobre sua maturidade do que mil linhas de código bem indentado. Eles provam que você sabe que toda escolha tem custo.

Outra coisa que vale ouro: deixe o projeto rodando. Um link de deploy que abre na hora elimina o atrito. Recrutador não vai clonar repositório, instalar dependência e configurar variável de ambiente — ele tem mais quarenta candidatos na fila. Vercel, Netlify, Render e Railway têm planos gratuitos que resolvem isso em minutos.

Erros que enterram um portfólio bom

Mesmo projetos sólidos morrem por detalhes de apresentação. Os mais comuns:

• Sem deploy e sem screenshot. Se o recrutador não vê funcionando em dez segundos, presume que não funciona.
• README de template. Aquele texto padrão do create-react-app ainda no repositório grita "não terminei".
• Credenciais commitadas. Uma chave de API no histórico do Git é eliminação imediata em qualquer vaga que leve segurança a sério.
• Projeto sem foco no público da vaga. Mandar um portfólio cheio de jogos para uma vaga de backend de pagamentos dispersa a atenção.
• Commits sem história. "fix", "update", "aaa", "asdf". O histórico é parte do produto que você está vendendo.

Perguntas frequentes

Quantos projetos preciso ter no portfólio para conseguir o primeiro emprego? De 3 a 5 projetos bem feitos. O foco é qualidade e clareza, não volume. Um portfólio enxuto, com README, deploy e decisões técnicas explicadas, supera com folga uma lista longa de repositórios pela metade.

Projetos de bootcamp e clones de apps conhecidos contam? Contam, desde que você adicione algo seu. Um clone copiado de um vídeo vale pouco; o mesmo clone com uma decisão técnica própria, um caso de erro tratado ou uma feature que o original não tem vira estudo de caso legítimo.

Como apresentar um projeto pessoal para o recrutador? Comece pelo README: o que resolve, como rodar, quais decisões técnicas você tomou e o que faria diferente. Tenha um link de deploy funcionando e um histórico de commits que conte o processo. O código é checado depois — a apresentação é o que abre a porta.

Vale mais contribuir para open source ou criar um projeto do zero? Os dois sinalizam coisas diferentes. Projeto do zero mostra iniciativa e capacidade de levar algo do início ao fim; open source prova que você lê e respeita código alheio e colabora em base existente. Se puder, tenha um de cada — é o combo mais convincente.

O que levar deste guia

Projeto pessoal não é prova de que você sabe programar; é prova de como você pensa ao programar. O que diferencia um portfólio que abre portas de um que some na pilha não é a quantidade de linhas, é a clareza com que você expõe suas decisões. Escolha de 3 a 5 projetos, dê a cada um um README que defenda suas escolhas, deixe tudo rodando num link e alinhe pelo menos um deles ao nicho que você quer. Faça isso e o seu portfólio para de ser mais um arquivo morto e vira o roteiro da sua próxima entrevista.