Portfolio Projects for Backend Developer

Seu currículo tem três certificados e nenhum projeto que alguém consiga abrir e testar, é por isso que ele não recebe resposta. Recrutadores técnicos não contratam lista de cursos. Contratam evidência de que você resolve problemas de verdade, com código que outra pessoa consegue rodar.

Certificado mostra que você assistiu. Projeto mostra que você construiu. Em backend, a diferença fica ainda mais clara, porque o trabalho real envolve decisões invisíveis: modelagem de dados, tratamento de erro, concorrência, segurança, performance. Nenhuma dessas coisas aparece em um certificado.

O que avaliadores realmente olham#

Antes de escolher projeto, entenda o filtro. Quem revisa portfólio de backend geralmente passa poucos minutos em cada candidato. Nesse tempo, ele procura sinais concretos.

• O README explica o problema que o projeto resolve, não só a stack usada.
• O código tem testes, e os testes cobrem casos de erro, não só o caminho feliz.
• Existe tratamento de erro explícito, com mensagens e códigos de status coerentes.
• A modelagem de dados mostra que você pensou em relações, índices e integridade.
• O projeto tem autenticação quando faz sentido, com senhas hasheadas e tokens com expiração.
• Existe alguma evidência de observabilidade: logs estruturados, métricas ou health check.
• O deploy é verificável, com link ao vivo ou instrução clara de como rodar local.
• O histórico de commits mostra progresso real, não um único commit gigante.

Repare que nada disso depende de framework da moda. Depende de engenharia.

Projeto 1: API de gestão financeira com concorrência#

Pegue um problema cotidiano: controle de gastos pessoais com múltiplos usuários, categorias, orçamentos mensais e relatórios. Parece simples. Não é.

O desafio técnico aparece quando dois lançamentos simultâneos alteram o saldo da mesma categoria, quando um estorno precisa reverter parcialmente um pagamento, quando o fechamento mensal precisa rodar sem travar a API. É aí que você mostra que entende transações, isolamento e locks.

Construa endpoints para criar conta, registrar transação, definir orçamento por categoria e gerar relatório mensal. Use banco relacional. Implemente saldo com atualização atômica, não com leitura e escrita separadas. Adicione índices nas colunas de consulta frequente. Escreva testes que simulam duas transações concorrentes na mesma categoria.

Para ir além, coloque um job que roda o fechamento do mês, com fila ou agendamento. Trate falha do job com retry e idempotência, para que uma repetição não gere lançamento duplicado.

Projeto 2: encurtador de URL com analytics em tempo real#

Todo mundo já fez encurtador. Quase ninguém faz direito. A versão que impressiona é a que aguenta tráfego real e responde perguntas difíceis.

Crie redirecionamento com código curto, controle de expiração, bloqueio por domínio suspeito e contagem de cliques. Use cache para os links mais acessados. Faça a contagem de cliques de forma assíncrona, para não atrasar o redirect. Considere rate limit por IP para impedir abuso.

O diferencial está no analytics: cliques por hora, origem do tráfego, navegador e país. Exponha isso em endpoints protegidos por autenticação. Mostre no README como você evitou hot path lento e como o sistema se comporta sob carga.

Se quiser impressionar ainda mais, escreva um pequeno teste de carga e publique os resultados no README, com os números que você observou na sua máquina. Sem promessa de escala infinita. Só dados honestos.

Projeto 3: worker de processamento de pagamentos com retry e idempotência#

Este é o projeto que mais se parece com trabalho de backend em empresa de verdade. Pegue uma fila de eventos de pagamento e processe com garantias.

Receba eventos de um provedor fictício de pagamento. Grave cada evento antes de processar, com chave de idempotência. Processe de forma assíncrona. Em caso de falha, aplique retry com backoff exponencial. Após esgotar as tentativas, mova para dead letter queue e registre o motivo.

Adicione um endpoint de consulta do estado do pagamento, que reflita o processamento real, não um mock. Inclua logs estruturados com identificador de correlação, para que um pedido possa ser rastreado do início ao fim.

Esse projeto mostra três coisas que certificado não mostra: você pensa em falha, você pensa em repetição, você pensa em rastreabilidade. É o básico que separa código de brincadeira de código de produção.

Como apresentar no currículo#

Currículo de backend precisa mostrar resultado, não responsabilidade. Compare estas duas linhas.

Antes: "Desenvolvi uma API de pagamentos utilizando Node.js e PostgreSQL".

Depois: "Projetei API de processamento de pagamentos com fila assíncrona, retry com backoff e chave de idempotência, reduzindo duplicações de cobrança a zero nos testes de carga com 1.000 eventos simultâneos".

A segunda linha diz o problema, a decisão técnica e o efeito verificável. É isso que o avaliador procura. Se você não tem número real, não invente. Descreva o comportamento observado, sem promessa de escala.

Para cada projeto no currículo, use uma linha de contexto, uma linha de decisão técnica e uma linha de resultado. Três linhas no máximo. Link para o repositório e para o demo, se existir.

Como organizar o GitHub#

O repositório é sua vitrine. Trate o README como documentação de produto, não como nota de aula.

• Nome do repositório claro, sem "projeto-final-curso" ou "desafio-bootcamp".
• README com seções: problema, arquitetura, decisões, como rodar, como testar, o que falta.
• Diagrama simples da arquitetura, mesmo que feito à mão em ferramenta gratuita.
• Variáveis de ambiente documentadas em .env.example, nunca com segredo real.
• Histórico de commits que mostra evolução, com mensagens que explicam o porquê.
• Licença e instrução de contribuição, mesmo que você seja o único contribuidor.

Se você quer conferir se seu currículo passa por filtro automático antes de chegar a um humano, use nosso verificador de ATS grátis. Ele aponta problemas de formação que derrubam candidatos antes da leitura técnica.

Erros que fazem projeto parecer tutorial#

Alguns erros aparecem em quase todo portfólio iniciante. Vale conhecer para evitar.

O primeiro é copiar projeto de curso sem mudar nada. Mesmo que você tenha feito o curso, o avaliador reconhece a estrutura idêntica. Mude o domínio, mude as regras, adicione um caso de uso que o curso não cobriu.

O segundo é empilhar tecnologia sem motivo. Cinco bancos, três filas, Kubernetes em projeto com dez usuários. Isso sinaliza que você não sabe escolher ferramenta. Prefira escolha justificada a escolha exótica.

O terceiro é esconder o que não funciona. Se falta testes ou se o deploy está quebrado, diga no README. Honestidade técnica pesa mais que perfeição fingida.

O quarto é escrever README como se o leitor fosse você mesmo. Escreva para alguém que nunca viu o projeto e tem dois minutos. Comece pelo problema, termine com o link.

Como falar dos projetos na entrevista#

Quando perguntarem sobre seu projeto, não comece pela stack. Comece pelo problema e pela decisão difícil.

Um bom roteiro: qual era o problema, qual foi a alternativa que você descartou, qual foi a escolha que você fez, qual foi o trade-off que aceitou, o que você faria diferente hoje. Esse formato mostra pensamento, não memorização.

Exemplo de resposta quando perguntarem "me fale desse projeto":

"Eu precisava processar eventos de pagamento sem duplicar cobrança. A solução óbvia seria processar na requisição, mas isso atrasava a resposta do provedor e perdia evento em falha. Eu adotei fila com chave de idempotência e retry com backoff. O trade-off foi complexidade operacional a mais, que eu aceitei porque duplicação de cobrança custa mais caro. Hoje eu adicionaria métricas de profundidade da fila desde o começo, porque fui perceber a falta tarde."

Repare que a resposta não vende perfeição. Mostra critério. Isso é o que entrevistador técnico quer ouvir.

Se a vaga tem descrição confusa com jargão e requisitos genéricos, use nosso decodificador de vagas para entender o que realmente estão pedindo antes de preparar sua fala.

Onde encontrar vagas que valorizam projeto#

Nem toda empresa avalia portfólio da mesma forma. Startups e empresas de produto costumam abrir o GitHub. Consultorias e grandes corporações podem focar mais em processo e certificação. Busque vagas que peçam portfólio explicitamente, e adapte o que destaca para cada tipo.

Use nosso painel de vagas para filtrar oportunidades de backend que valorizam projeto prático, e leia nosso blog para acompanhar mais conteúdo sobre carreira em tecnologia.

Checklist antes de divulgar#

• Cada projeto tem README com problema, decisão técnica e instrução de execução.
• O código roda local com uma única instrução, sem passo mágico escondido.
• Existe pelo menos um teste de caso de erro por projeto.
• Nenhum segredo, token ou senha está no repositório.
• O currículo menciona o projeto com resultado ou comportamento observado.
• Você consegue explicar cada decisão de design em duas frases.
• Você sabe dizer o que faria diferente hoje, sem roteiro decorado.
• Os links do GitHub e do demo funcionam, testados em aba anônima.

Ferramentas grátis#

• jobrise.io/pt/free-ats-checker/
• jobrise.io/pt/free-jd-decoder/
• jobrise.io/pt/jobs/
• jobrise.io/pt/blog/

Perguntas frequentes#

Quantos projetos eu preciso no portfólio?

Três projetos bem feitos valem mais que dez rasos. Escolha projetos que mostrem habilidades diferentes, como modelagem de dados, processamento assíncrono e tratamento de falha. Profundidade compensa quantidade.

Posso usar projeto de curso no meu portfólio?

Pode, desde que você o modifique de forma relevante e consiga explicar cada decisão. Se o avaliador reconhecer a estrutura idêntica ao tutorial, o projeto perde valor. Mude o domínio, adicione regra de negócio nova, escreva seus próprios testes.

Preciso ter projeto deployado em produção?

Não é obrigatório, mas um demo acessível ajuda muito. Se não conseguir hospedar, deixe instrução clara de execução local com Docker ou comando único. O que não pode é exigir que o avaliador decifre dez passos para rodar.

Backend precisa mostrar frontend também?

Não, mas uma interface mínima ou documentação interativa ajuda na comunicação. Foque em backend, deixe claro que frontend não é seu foco, e invista em documentação de API que outra pessoa consiga consumir.

Como destaco projeto se sou júnior?

Destaque a decisão técnica, não a senioridade. Explique o problema, o trade-off e o que você aprendeu no caminho. Recrutadores técnicos valorizam raciocínio honesto mais do que aparentar experiência que você ainda não tem.