Portfólio de desenvolvedor júnior: o que colocar para ser chamado para entrevistas

Atualizado em 11 de outubro de 2026 · Leitura de 6 min

Edson Feitosa de Oliveira Junior Fundador e Engenheiro Líder · PruPru Digital Services

Um bom portfólio de desenvolvedor júnior não precisa de vinte projetos. Precisa de dois ou três projetos bem feitos, com código organizado, um README que explique o que foi construído e por quê, e uma forma fácil de ver o resultado funcionando. Quem avalia quer responder a uma pergunta simples: essa pessoa consegue entregar algo que funciona e explicar as decisões que tomou?

Neste guia você vai ver quais projetos mostrar, como escrever o README, como deixar o GitHub apresentável e como alinhar LinkedIn e currículo para que tudo conte a mesma história.

Quem olha o seu portfólio e o que procura

Normalmente são duas pessoas diferentes, com tempo curto:

• Recrutador ou RH: muitas vezes não lê código. Olha se as tecnologias batem com a vaga, se há projetos publicados, se o perfil está completo e se a comunicação é clara.
• Desenvolvedor da equipe: abre um ou dois repositórios e passa poucos minutos em cada. Olha o README, a estrutura de pastas, a qualidade dos commits, se existem testes e se o código tem nomes claros.

Por isso, o que está na primeira tela importa muito. Um repositório sem descrição e com o último commit chamado "final2" perde a chance antes de alguém chegar ao código bom.

Quais projetos mostrar

Prefira projetos que resolvam um problema concreto, mesmo pequeno, a clones de tutorial. Se fizer um projeto guiado, use-o como base e acrescente algo seu. Algumas ideias que funcionam bem para vagas de backend e full stack:

1. Uma API REST completa com cadastro, validação, autenticação, banco de dados relacional e tratamento de erros. Se você ainda está firmando os conceitos, veja o que é uma API REST e comece pela primeira API com Spring Boot.
2. Um sistema para um negócio real: agenda para um salão, controle de estoque de uma loja do bairro, inscrições de um evento da igreja ou da escola. Problemas reais geram decisões reais para explicar na entrevista.
3. Um projeto com integração: consumir uma API pública, enviar e-mails, processar uma fila, gerar um relatório em PDF.
4. Uma interface simples consumindo a sua API, se a vaga for full stack ou front-end.

O que costuma pesar contra: muitos repositórios pela metade, projetos idênticos aos de cursos famosos sem nenhuma alteração e código copiado sem entendimento, que aparece rapidamente na primeira pergunta técnica.

Qualidade que aparece no código

Para um júnior, ninguém espera arquitetura perfeita. Espera sinais de cuidado:

• Estrutura de pastas coerente e nomes de classes, métodos e variáveis que dizem o que fazem.
• Alguns testes automatizados, ao menos para as regras principais.
• Configurações sensíveis fora do código, em variáveis de ambiente. Nenhuma senha ou chave de API no repositório.
• Histórico de commits com mensagens claras, mostrando a evolução do projeto. O artigo Git e GitHub para iniciantes explica como escrever boas mensagens e trabalhar com branches e pull requests.
• Uma forma de rodar o projeto com poucos comandos, por exemplo com um arquivo docker compose que sobe a aplicação e o banco.

Como escrever o README

O README é a vitrine do projeto. Uma estrutura que funciona:

1. Título e uma frase dizendo o que o projeto faz e para quem.
2. Demonstração: link para a versão publicada, se houver, e uma ou duas capturas de tela ou um GIF curto.
3. Tecnologias usadas, com versões principais (por exemplo, Java 21, Spring Boot 3, PostgreSQL).
4. Como rodar localmente, passo a passo, testado em uma máquina limpa.
5. Principais funcionalidades e, para APIs, os endpoints com um exemplo de requisição e resposta.
6. Decisões técnicas: por que escolheu esse banco, como tratou autenticação, o que faria diferente com mais tempo.
7. Próximos passos e limitações conhecidas.

A seção de decisões é a que mais diferencia. Mostra raciocínio e dá assunto para a entrevista. Escrever sobre um problema que você enfrentou e como resolveu, no formato de um relato técnico, também ajuda; os posts de caso real deste blog, como o de @Cacheable que não funciona por auto-invocação, mostram esse formato: sintoma, causa e correção.

GitHub organizado

• Foto e bio com a stack que você busca, cidade e link para o LinkedIn.
• README de perfil: crie um repositório com o mesmo nome do seu usuário e um README curto se apresentando. Evite encher de badges e estatísticas automáticas.
• Repositórios fixados: fixe no perfil os dois a seis projetos que você quer que sejam vistos. É o que aparece primeiro.
• Descrição e tópicos em cada repositório fixado, além do link da demonstração no campo de site.
• Arquive ou deixe privados os exercícios soltos que não representam seu nível atual.

O gráfico de contribuições não precisa estar todo verde. Constância ajuda, mas um projeto sólido vale mais do que commits diários sem conteúdo.

LinkedIn e currículo contando a mesma história

Recrutadores costumam cruzar as informações. Garanta coerência:

• Título do LinkedIn objetivo, como "Desenvolvedor Backend Java | Spring Boot | PostgreSQL", em vez de apenas "Estudante".
• Seção de projetos no LinkedIn e no currículo com os mesmos projetos do GitHub, cada um com uma linha de resultado: o que faz e o que você aprendeu ou resolveu.
• Currículo de uma página, com links clicáveis para GitHub, LinkedIn e demonstrações. Coloque projetos antes da formação se a experiência formal na área ainda é pequena.
• Experiência anterior conta. Se você vem de outra área, mostre o que se transfere: atendimento, resolução de problemas, conhecimento do negócio. Falamos disso em transição de carreira para programação.
• Adapte para cada vaga, destacando as tecnologias que ela pede e que você realmente usou.

Checklist antes de enviar candidaturas

1. Os links do currículo abrem e levam ao lugar certo.
2. As demonstrações publicadas estão no ar.
3. Cada projeto fixado tem README completo e roda seguindo as instruções.
4. Nenhuma senha, token ou dado pessoal real está nos repositórios.
5. Você consegue explicar, sem olhar, cada decisão importante de cada projeto.

O último item é o mais importante. Na entrevista, o portfólio vira roteiro de conversa, e saber defender as próprias escolhas é exatamente o que se espera de um júnior que vai crescer.

Perguntas frequentes