Projeto real ou fictício no portfólio?
Todo mundo diz 'faça projetos reais', mas o que isso significa na prática e se projetos fictícios bem feitos também funcionam.
"Faça projetos reais" é um conselho repetido em todo lugar. Mas a maioria de quem está começando não tem acesso a projetos reais. Isso torna o portfólio inútil? Não.
O que faz um projeto valer no portfólio
O que avaliadores de currículo realmente querem ver não é se o projeto resolve um problema real de produção: é se você tomou decisões técnicas e consegue explicar por quê.
Um projeto fictício bem construído mostra:
- Que você sabe arquiteturar uma solução
- Que você escreve código legível e organizado
- Que você conhece as ferramentas que diz conhecer
- Que você consegue entregar algo que funciona de ponta a ponta
Um projeto real mal documentado, sem testes, com commits do tipo "fix" e "ajustes", mostra muito menos.
O que diferencia um projeto fictício bom de um fraco
Fraco: clone de tutorial seguido passo a passo, sem nenhuma customização. "Fiz um to-do list com React" quando 90% do código é cópia exata do tutorial.
Bom: projeto de escopo próprio, mesmo que simples. Uma calculadora de impostos, um app de controle de gastos, um catálogo de filmes com filtros, qualquer coisa que você decidiu construir e pensou na estrutura.
A diferença está na autoria das decisões: você escolheu a stack, você estruturou o banco de dados, você resolveu o problema de autenticação. Isso aparece na entrevista quando perguntam "por que você usou X em vez de Y?"
Quando projetos reais fazem diferença de verdade
Projetos com usuários reais (mesmo que poucos), projetos open source com contribuições aceitas, ou sistemas resolvendo problemas reais têm peso extra, especialmente para vagas mais exigentes ou para se diferenciar em processos competitivos.
Mas esse nível não é obrigatório para a primeira vaga. Para o primeiro emprego, 2 a 3 projetos bem feitos e bem documentados são suficientes.
Como fazer projetos fictícios renderem mais
README caprichado. Explique o que o projeto faz, por que você construiu, a stack usada, como rodar localmente, e decisões técnicas relevantes. Um README bom compensa muito.
Deploy funcionando. Um projeto no ar (Railway, Vercel, Fly.io, Render) é mais fácil de avaliar do que um repositório que ninguém consegue rodar. Link funcionando impressiona mais.
Commits com mensagem. Histórico de commits com mensagens descritivas mostra processo, não só resultado.
Testes. Mesmo testes básicos diferenciam seu projeto da maioria dos portfólios de iniciantes.
A resposta curta
Projetos fictícios bem feitos funcionam para a primeira vaga. Projetos reais são diferencial, não requisito. O que não funciona é ter muitos projetos mediocres no lugar de poucos projetos bem executados.
- Meu projeto tem README que explica o que é e como rodar?
- Está no ar (deploy) ou pelo menos roda localmente sem dificuldade?
- Consigo explicar as decisões técnicas que tomei?