Para apresentar um projeto de programação, explique qual problema ele resolve, o que você fez, como conferir o funcionamento e quais decisões tomou. Um link para código, sozinho, deixa essas perguntas em aberto. Um README organizado e uma demonstração com dados fictícios ajudam a pessoa que avalia a entender o trabalho e seus limites.
Este guia foi elaborado pela Nort, plataforma de recrutamento para desenvolvedores com modelo de recrutamento reverso. É uma orientação de preparação de portfólio, não uma rubrica de pontuação da plataforma nem uma promessa de entrevista ou contratação.
Escolha um projeto que você consiga explicar
Comece por um trabalho relacionado ao tipo de oportunidade que procura. Pode ser um projeto de estudo, uma contribuição autorizada a código aberto ou um trabalho de equipe que você tenha permissão para apresentar. Não precisa inventar clientes ou usuários para torná-lo relevante.
O ponto de partida é conseguir responder: o que funciona hoje, o que ficou incompleto e onde está sua contribuição? Um projeto pequeno permite discutir uma decisão com profundidade. Já uma coleção de tecnologias, sem contexto, não explica por que elas foram usadas.
Se partiu de um tutorial, informe a referência e separe a base original das suas alterações. Se o projeto foi coletivo, descreva sua parte sem atribuir a si entregas de colegas. Não confunda participação com autoria de todo o sistema.
Organize a apresentação em seis partes
1. Problema e contexto
Descreva quem usaria a solução e o que essa pessoa precisa fazer. Identifique se é estudo, protótipo ou produto em uso. Em vez de “sistema completo e escalável”, prefira uma descrição que alguém possa conferir: “protótipo para cadastrar livros e registrar empréstimos, executado localmente”.
Explique o escopo escolhido e o que ficou de fora. Isso evita que uma demonstração seja interpretada como um serviço pronto para produção.
2. Sua contribuição
Liste as partes que implementou ou revisou. Quando permitido, associe a explicação a arquivos, pull requests ou decisões documentadas. Em um trabalho de equipe, diga também com quem dividiu as responsabilidades, sem expor dados pessoais desnecessários.
Se usou IA ou outra ferramenta para gerar código, explique em que etapa e como verificou o resultado. Em uma seleção, respeite as regras específicas sobre ferramentas; este guia não autoriza seu uso em avaliações.
3. Como executar ou conferir
Inclua requisitos, versões relevantes, preparação do ambiente, comandos e um caminho curto de uso. Teste suas próprias instruções em um ambiente limpo quando possível. Informe dependências pagas ou serviços indisponíveis antes de a pessoa tentar executar.
Para um projeto sem demonstração hospedada, uma gravação ou capturas autorizadas podem ilustrar o fluxo. Elas não substituem a explicação de como o sistema funciona e devem corresponder à versão apresentada.
4. Decisões e alternativas
Escolha uma ou duas decisões importantes: como organizou os dados, tratou erros, separou responsabilidades ou priorizou acessibilidade. Explique a necessidade, a solução escolhida, uma alternativa e o custo da escolha.
Por exemplo, usar armazenamento em memória pode simplificar um protótipo, mas perde os dados ao reiniciar. Reconhecer esse limite é mais informativo do que chamar a solução de robusta sem demonstrar o comportamento.
5. Verificação e evidências
Mostre como você verificou o fluxo principal e pelo menos um cenário de erro relevante. Registre comandos de teste, resultado esperado e o que não foi coberto. Uma captura de testes aprovados precisa de contexto: versão do código e quais comportamentos a suíte verifica.
Só apresente métricas que realmente mediu. Se falar em desempenho, informe ambiente, método e limites da comparação. Não transforme um teste local em número de usuários atendidos ou resultado comercial.
6. Limitações e próximo passo
Liste problemas conhecidos e diga qual melhoria faria primeiro, com uma razão. Separe uma ideia futura de uma funcionalidade existente. Essa seção ajuda a conduzir uma conversa técnica sem esconder partes incompletas.
Modelo de README para adaptar
O guia de README do GitHub orienta a apresentar a finalidade do projeto e como começar a usá-lo. A estrutura abaixo acrescenta perguntas úteis para contextualizar autoria e decisões em uma conversa de recrutamento. É uma proposta editorial da Nort, não um padrão obrigatório do GitHub.
Copie os campos para seu README, substitua as instruções pelas informações reais e remova o que não se aplica:
- Projeto: nome e uma frase sobre o problema resolvido.
- Contexto e estado: estudo, protótipo ou produto; o que funciona na versão apresentada.
- Minha contribuição: partes sob minha responsabilidade e referências verificáveis, quando autorizadas.
- Como executar: requisitos, versões, preparação, comandos e resultado esperado, sem credenciais reais.
- Como conferir: um fluxo de uso, um cenário de erro e como rodar os testes disponíveis.
- Decisão técnica: necessidade, escolha, alternativa considerada e consequência.
- Limitações: o que ainda não funciona, não foi testado ou depende de outro serviço.
- Próximo passo: melhoria priorizada e motivo.
- Créditos e ferramentas: base de tutorial, contribuições externas, licenças aplicáveis e uso de IA, se houver.
Evite preencher cada campo com frases genéricas. “Adicionei validação” diz pouco; “a API rejeita empréstimos de livros indisponíveis, com um teste para esse caso” aponta um comportamento que pode ser examinado.
Exemplo ilustrativo: um projeto de biblioteca
Imagine um protótipo pessoal de empréstimo de livros. O exemplo é fictício: não representa candidato, cliente ou resultado de contratação da Nort.
Uma apresentação possível seria: “Implementei as rotas de cadastro e empréstimo. Usei armazenamento em memória para concentrar o estudo nas regras de negócio; os registros desaparecem ao reiniciar. O teste de empréstimo duplicado verifica se um livro indisponível é recusado. Ainda não implementei autenticação nem persistência”.
Para sustentar essa descrição em um projeto real, a pessoa precisaria apontar as rotas, o teste e as instruções de execução correspondentes. A apresentação não exige fingir que o protótipo está pronto para uma biblioteca real.
Um roteiro de conferência para quem abrir o projeto
Além dos comandos de instalação, descreva uma sequência pequena com começo, resultado e limite. No protótipo fictício de biblioteca, ela poderia ser:
1. Iniciar o aplicativo com uma base de demonstração que contenha dois livros fictícios disponíveis. Informar como recriar essa base sem tocar em dados reais.
2. Registrar o empréstimo de um dos livros. Conferir que ele passou de disponível para emprestado e indicar onde essa informação aparece.
3. Tentar emprestar o mesmo livro novamente. Mostrar a mensagem esperada e confirmar que o primeiro registro não foi alterado.
4. Reiniciar o aplicativo. Se os dados estiverem apenas em memória, explicar que os registros desaparecem: esse é um limite conhecido, não uma demonstração de persistência.
Adapte o roteiro ao comportamento que existe no seu código. Não copie resultados que não verificou. Se uma etapa falhar, registre a falha e explique como ela limita a demonstração, em vez de apresentar a sequência como aprovada.
Inclua também o identificador da versão usada, os requisitos que testou e a data da conferência. Por exemplo: “Verifiquei os passos 1 a 3 na versão indicada no repositório; não testei a instalação no Windows”. Esse registro distingue uma observação concreta de uma promessa de compatibilidade.
Transforme uma escolha técnica em uma explicação verificável
No mesmo exemplo, a decisão poderia ser registrada assim:
| Pergunta | Resposta possível no protótipo fictício |
|---|---|
| Qual era a necessidade? | Estudar a regra que impede dois empréstimos simultâneos do mesmo livro. |
| O que escolhi? | Armazenar os registros em memória durante a execução. |
| Que alternativa considerei? | Persistir os registros em um banco local. |
| Qual foi o custo? | Perder os dados ao reiniciar e não demonstrar durabilidade. |
| Qual seria o próximo passo? | Implementar persistência e verificar recuperação após reinício. |
O valor da explicação está na relação entre necessidade, escolha e evidência. Citar um banco conhecido sem mostrar como foi usado não resolve essas perguntas. Também não é necessário apresentar toda decisão como ideal: reconhecer uma restrição ajuda a delimitar o que o projeto demonstra.
Revise antes de compartilhar
- Permissão: tenho autorização para mostrar código, telas e informações do projeto?
- Privacidade: removi dados reais de clientes, participantes e colegas das demonstrações?
- Segredos: revisei arquivos e histórico para não expor senhas, tokens, chaves ou configurações privadas?
- Acesso: os links abrem para quem vai avaliar, sem depender da minha sessão pessoal?
- Execução: as instruções correspondem à versão que estou apresentando?
- Autoria: diferenciei minha contribuição, trabalho da equipe, tutorial e ferramentas utilizadas?
- Evidência: cada resultado citado pode ser conferido, sem números inventados?
- Limites: deixei claro o que é protótipo, o que falha e o que não foi testado?
Se uma credencial já foi exposta, apenas apagar o arquivo não resolve necessariamente o problema. O GitHub orienta revogar ou rotacionar o segredo como primeiro passo; o histórico e outras cópias também podem exigir tratamento. Não publique um repositório confidencial para completar um portfólio.
Como isso se conecta à busca por emprego
Preparar um projeto ajuda a organizar exemplos para currículo, portfólio e conversas técnicas. No recrutamento reverso, a empresa pode encontrar um perfil e iniciar contato; ter uma explicação clara do seu trabalho pode apoiar a conversa que vier depois.
Na Nort, criar perfil e fazer testes é gratuito para candidatos. Este guia não promete importação de repositórios, pontuação por portfólio ou substituição de avaliações por projetos. Cada empresa pode definir etapas adicionais.
Veja como começar seu percurso na Nort ou crie seu perfil gratuitamente. Complete os campos disponíveis com informações que você pode compartilhar e confira as regras de cada avaliação antes de começar.
Perguntas frequentes
Preciso ter experiência profissional para apresentar um projeto?
Não para aplicar este roteiro. Um projeto de estudo também pode demonstrar decisões e aprendizados, desde que seja identificado como tal. Isso não significa que ele atende aos requisitos de experiência de qualquer vaga.
Posso usar um projeto de curso ou tutorial?
Pode servir como ponto de partida, respeitando as condições de uso do material. Cite a origem, explique o que você alterou e prepare-se para discutir o funcionamento. Não apresente uma cópia como criação integralmente sua.
E se meu trabalho estiver em um repositório privado?
Não exponha código ou informações sem autorização. Pergunte à empresa quais alternativas aceita: uma explicação sem detalhes confidenciais, material previamente autorizado ou outro exercício podem ser possibilidades. Não presuma que tornar o repositório público seja obrigatório.
Um bom portfólio dispensa o teste técnico?
Não necessariamente. Portfólio e avaliações fornecem informações diferentes; a empresa define as etapas do processo. Este roteiro não altera as regras dos testes da Nort nem garante proposta ou contratação.
Revisão editorial
Guia elaborado pela Nort. Referências conferidas em 18 de outubro de 2026. Exemplo fictício e modelo editorial, sem dados de participantes ou clientes. Correções: general@nortjobs.com