Como criar um portfólio de dados que recrutador abre e lê
Recrutador gasta segundos no seu portfólio. Veja o que incluir, como estruturar cada projeto, onde hospedar e os erros que fazem sua candidatura ser descartada em silêncio.
Um recrutador com dezenas de candidaturas para triar não vai ler seu portfólio com calma. Levantamentos de mercado e a experiência de quem contrata apontam na mesma direção: a primeira olhada dura segundos. Nesse tempo minúsculo, a pessoa decide se abre o seu projeto ou passa para o próximo candidato. Parece injusto, mas é também uma oportunidade enorme: quase ninguém monta o portfólio pensando nisso.
Portfólio de dados não é enfeite nem coleção de certificados: é prova. Prova de que você sabe transformar uma pergunta de negócio em análise, e uma análise em decisão. Neste artigo, você vai ver o que incluir, como estruturar cada projeto, onde hospedar tudo e quais erros fazem o recrutador fechar a aba sem te avisar.
Três projetos bons valem mais que dez rasos
O primeiro instinto de quem está começando é acumular volume: dez notebooks, quinze repositórios, todos os exercícios de curso que já fez. Na prática, isso joga contra você. Quem avalia julga pela média do que vê, não pela soma. Um projeto raso ao lado de um projeto forte enfraquece o forte. A recomendação é curadoria: três projetos completos, cada um cumprindo um papel diferente.
- Um projeto completo de ponta a ponta: da pergunta de negócio até a recomendação final, mostrando que você percorre o ciclo inteiro de uma análise.
- Um projeto do setor que você quer: se a meta é trabalhar com varejo, saúde ou finanças, tenha uma análise com dados desse universo. Isso comunica intenção e repertório.
- Um projeto que mostra domínio técnico: um dashboard bem construído, uma análise em SQL, um script bem organizado. Aqui a estrela é a ferramenta que a vaga pede.
A anatomia de um projeto que convence
O que separa um projeto de portfólio de um exercício de curso é a existência de uma pergunta que alguém pagaria para responder. Antes de abrir o editor de código, escreva a pergunta em uma frase. Se ela não interessaria a um gestor, recomece. A estrutura que funciona tem três ingredientes:
- Pergunta de negócio real: "quais clientes têm mais chance de cancelar?" ou "qual região merece o próximo investimento?" são perguntas. "Análise exploratória de um dataset" não é.
- Dados públicos e verificáveis: portais de dados abertos do governo, estatísticas oficiais, bases públicas conhecidas. Dados que qualquer pessoa pode checar dão credibilidade e evitam problemas de confidencialidade.
- Uma decisão no final: termine com uma recomendação clara, do tipo "com base nesses resultados, eu priorizaria X". Análise que não aponta caminho é relatório, não é análise.
O README que conta a história
Aqui vai uma verdade desconfortável: o recrutador raramente lê seu código. O que ele lê é o README. Se o README não contar uma história clara em poucos parágrafos, o código nunca será aberto. A estrutura que funciona é a de uma narrativa em quatro atos:
- Problema: qual pergunta de negócio motivou o projeto e por que ela importa.
- Dados: de onde vieram, o que contêm, quais limitações têm.
- Análise: o caminho percorrido em linguagem simples, com um ou dois gráficos que resumem os achados.
- Conclusão: o que você descobriu e qual decisão recomendaria a partir disso.
Escreva pensando em alguém não técnico com pressa. Se essa pessoa entender o valor do projeto em um minuto, o README cumpriu o papel.
Onde hospedar e como fazer o portfólio circular
De nada adianta um portfólio impecável que ninguém encontra. Três canais se complementam:
- GitHub: é o padrão do mercado. Capriche no README de cada projeto, fixe os melhores repositórios no perfil e dê nomes descritivos (nada de "projeto-final-2").
- LinkedIn: é onde o recrutador realmente vive. Publique um resumo curto de cada projeto com o link, e inclua o portfólio na seção em destaque do perfil.
- Site ou página pessoal: opcional, mas diferencia. Uma página simples reunindo seus projetos, com um parágrafo sobre cada um, passa profissionalismo e facilita o compartilhamento.
Erros que fazem o recrutador fechar a aba
Alguns padrões se repetem tanto que viraram sinal de alerta para quem contrata. Evite estes:
- Titanic sem contexto: o problema não é o dataset famoso, é repetir o tutorial sem uma pergunta própria. Se usar uma base conhecida, traga um ângulo seu.
- Notebook sem narrativa: quarenta células de código sem um texto explicando o que está acontecendo obrigam o leitor a decifrar. Ninguém decifra: fecham a aba.
- Código sem explicação: scripts soltos, sem comentários e sem README, dizem "eu executo comandos", não "eu resolvo problemas".
- Volume no lugar de qualidade: quinze repositórios de exercícios diluem os dois projetos que realmente mostram seu potencial.
A diferença entre um projeto que passa despercebido e um que gera entrevista costuma estar em detalhes de estrutura, não de técnica. Compare:
| Item | Projeto fraco | Projeto forte |
|---|---|---|
| Pergunta | Nenhuma, ou genérica | Pergunta de negócio clara em uma frase |
| Dados | Dataset de tutorial, sem contexto | Dado público com fonte e limitações explicadas |
| Narrativa | Só código, célula após célula | História do problema até a decisão |
| Final | Termina no último gráfico | Termina em recomendação acionável |
| README | Instruções de instalação | Resumo que vende o projeto em um minuto |
Conclusão
Portfólio bom não é o que tem mais projetos: é o que prova, em poucos minutos, que você pensa como alguém que resolve problemas com dados. Escolha três projetos, dê a cada um uma pergunta de verdade, conte a história no README e coloque tudo onde o recrutador está. Se você quer construir esse portfólio com orientação, os cursos da Data Lover incluem projetos guiados pensados exatamente para isso: você termina a trilha com prova concreta do que sabe fazer.
Perguntas frequentes
Três projetos completos e bem contados valem mais que dez rasos. Quem avalia julga pela média do que vê: um projeto fraco ao lado de um forte enfraquece o conjunto.
