CARREIRA / PORTFÓLIO

portfólio de dados para dev junior: um dashboard simples que mostra maturidade

@ eu.dev.br 25 mai 2026 9 MIN

Portfólio de dados para junior não precisa prever bolsa, fazer IA generativa ou copiar notebook famoso do Kaggle.

Na maioria das vagas de entrada, um projeto forte é muito mais simples: pegar uma base pública, limpar os dados, fazer 5 perguntas boas, montar uma visualização legível e explicar as decisões no README. Isso já mostra mais maturidade do que um repositório cheio de gráfico bonito sem contexto.

O objetivo não é parecer cientista de dados sênior. É provar que você sabe transformar dado cru em uma resposta útil.

Se você ainda não tem a base do portfólio, comece pelo guia de 3 projetos certos para junior. Se já tem um projeto, arrume o README antes de mandar CV. Este guia é o recorte para quem quer mostrar dados, BI, analytics, backend com dados ou produto com métrica.

o que conta como projeto de dados

Projeto de dados junior pode ser:

dashboard de vagas tech por stack, senioridade e remoto;
análise de preços de combustível por estado;
mapa de notas do ENEM por município;
comparação de aluguéis por bairro usando dados públicos ou raspagem limitada;
pipeline simples que baixa CSV, limpa, salva e gera relatório;
notebook explicando uma pergunta de negócio com gráficos;
app estático que atualiza uma métrica todo dia.

O que não conta muito:

notebook copiado sem pergunta própria;
gráfico solto sem conclusão;
dataset famoso usado do mesmo jeito que todo mundo usa;
modelo de machine learning sem baseline, sem explicação e sem utilidade;
dashboard bonito que ninguém entende como foi gerado.

A diferença está na pergunta. Dado por dado vira decoração. Dado respondendo pergunta vira evidência de trabalho.

escolha uma pergunta pequena

Junior costuma começar grande demais:

Quero analisar o mercado de tecnologia no Brasil.

Isso é amplo. Você vai se perder.

Melhor:

Quais stacks aparecem com mais frequência em vagas junior remotas publicadas nesta semana?

Ou:

O preço médio da gasolina mudou mais no Norte ou no Sul nos últimos 90 dias?

Ou:

Quais bairros têm aluguel anunciado acima da renda média local?

Pergunta boa tem recorte:

período;
região ou público;
métrica;
comparação;
decisão possível.

Se não dá para escrever a pergunta em uma frase, o projeto ainda está grande demais.

use dado público e cite a fonte

Para portfólio junior, fonte confiável pesa muito. Algumas boas opções no Brasil:

dados.gov.br;
IBGE;
INEP;
Banco Central;
ANP;
prefeituras com portal de dados abertos;
APIs públicas bem documentadas;
dados próprios pequenos, quando você explica coleta e limite.

Evite raspar site sensível, dados pessoais, página protegida por login ou conteúdo que proíba uso automatizado. Você quer demonstrar maturidade, não dar sinal de risco.

No README, coloque:

## Fonte dos dados

- Fonte: ANP — Série histórica de preços de combustíveis
- Período usado: janeiro a março de 2026
- Última atualização manual deste projeto: 2026-05-25
- Limitações: preço médio por região, sem análise de posto individual

Isso parece detalhe. Não é. Recrutador técnico vê que você sabe de onde veio o dado e qual limite ele tem.

pipeline mínimo que vende bem

Um projeto de dados forte pode ter só quatro etapas:

coleta -> limpeza -> análise -> apresentação

No repositório, isso pode virar:

/data/raw/           dados originais pequenos ou instrução de download
/data/processed/     dados limpos gerados pelo script
/notebooks/          exploração opcional
/src/                scripts reutilizáveis
/dashboard/          app, HTML, relatório ou imagens
README.md            explicação do projeto

Se quiser manter ainda mais simples:

src/download.py
src/clean.py
src/build_report.py
report/index.html
README.md

O ponto é mostrar caminho reproduzível. Pessoa técnica precisa entender: se eu rodar os comandos, chego no mesmo resultado?

stack simples é vantagem

Você não ganha ponto por enfiar 12 ferramentas.

Para Python:

pandas ou polars;
matplotlib, seaborn ou plotly;
streamlit, quarto, jupyter-book ou HTML estático;
pytest para uma ou duas funções de limpeza.

Para JavaScript/TypeScript:

script Node para transformação;
d3, Observable Plot, Vega-Lite ou chart simples;
Astro/Hugo/Next só se fizer sentido.

Para BI:

Power BI ou Looker Studio pode ser válido, mas exporte prints e explique transformação;
se usar SQL, coloque as queries versionadas;
se usar planilha, explique fórmula e origem.

Um projeto pandas + HTML estático + GitHub Pages bem explicado é melhor que um projeto com Airflow, Spark e Docker que não roda.

perguntas que viram seções do relatório

Monte o relatório com 4 a 6 perguntas. Exemplo para vagas tech:

## Perguntas respondidas

1. Quais stacks aparecem mais em vagas junior?
2. Quais vagas são realmente remotas e quais são híbridas disfarçadas?
3. Quais empresas repetem vagas toda semana?
4. Quais requisitos aparecem como "diferencial" mas viram filtro na prática?
5. Que tipo de candidatura merece prioridade nesta semana?

Cada pergunta deve ter:

um gráfico ou tabela;
3 a 6 linhas de interpretação;
um limite claro.

Exemplo de interpretação boa:

Python aparece menos que JavaScript no recorte desta semana, mas as vagas de Python têm mais menções a dados, automação e backend interno. O recorte é pequeno: 83 vagas coletadas entre 20 e 25 de maio de 2026. Não dá para chamar isso de tendência nacional; dá para usar como priorização de candidatura da semana.

Isso mostra raciocínio, não só ferramenta.

coloque uma decisão no final

Todo projeto de dados deveria terminar com “então o que eu faria?”.

Exemplo:

## Decisão prática

Se eu fosse candidato junior esta semana, priorizaria:

1. vagas remotas com stack JavaScript + SQL e descrição objetiva;
2. empresas que publicam email ou pessoa responsável;
3. candidaturas em até 48h após publicação;
4. vagas com teste técnico pequeno e escopo claro.

Eu evitaria vagas "junior" pedindo 4 anos, inglês avançado obrigatório e lista de 15 tecnologias sem stack principal.

Essa seção transforma análise em julgamento. É isso que trabalho real pede.

adicione testes pequenos

Teste em projeto de dados não precisa ser sofisticado. Teste o que costuma quebrar:

coluna obrigatória existe;
data foi convertida;
valor numérico não virou texto;
categorias foram normalizadas;
linhas duplicadas foram removidas.

Exemplo conceitual:

def test_normaliza_senioridade_junior():
    assert normaliza_senioridade("Júnior") == "junior"
    assert normaliza_senioridade("Estágio") == "estagio"

Um teste assim mostra que você pensou em qualidade. Poucos juniores fazem isso.

README que passa confiança

Estrutura boa:

# Dashboard de vagas junior no Brasil

Análise semanal de vagas tech junior e estágio, com foco em stack, remoto/híbrido e sinais de vaga fake junior.

## Pergunta

Quais vagas merecem prioridade para quem busca o primeiro emprego tech esta semana?

## Resultado principal

Resumo em 3 bullets.

## Fonte dos dados

Origem, período, tamanho da amostra e limitações.

## Como rodar

Comandos do zero.

## Como atualizar

Comando ou passo manual.

## Estrutura do projeto

Pastas e scripts.

## Limitações

O que o projeto não prova.

Se o projeto tem dashboard online, coloque o link no primeiro bloco. Se não tem, coloque screenshot.

cuidado com conclusão exagerada

Erro comum:

Python está morrendo no Brasil.

Com base em 80 vagas de uma semana, isso é chute.

Melhor:

Neste recorte pequeno, JavaScript apareceu mais que Python em vagas de entrada. A amostra não prova tendência nacional, mas ajuda a priorizar estudo e candidatura nesta semana.

Maturidade em dados é saber o que não dá para afirmar.

checklist antes de mandar no CV

Antes de colocar o projeto no currículo ou LinkedIn:

a pergunta principal aparece no README;
a fonte dos dados está citada;
existe pelo menos um comando para reproduzir;
o relatório tem 4 a 6 perguntas respondidas;
cada gráfico tem interpretação, não só imagem;
há uma seção de limitações;
existe screenshot, demo ou relatório HTML;
as credenciais e dados sensíveis não estão no repositório;
pelo menos um teste ou validação automática roda;
o projeto está pinado no GitHub se for um dos melhores.

Se você fizer isso, não precisa chamar o projeto de “data science end-to-end”. Chame de análise reproduzível. É mais honesto e vende melhor.

onde isso entra no portfólio

Para quem busca vaga de dados, este pode ser o projeto principal.

Para quem busca backend, ele pode ser o projeto que mostra pipeline, SQL, rotina e clareza.

Para quem busca frontend, ele pode virar dashboard público bem feito.

Para quem busca primeira vaga genérica, ele mostra uma habilidade rara: pensar com evidência.

No fim, portfólio junior não é sobre provar genialidade. É sobre reduzir dúvida. Um projeto de dados simples, reproduzível e honesto reduz muita dúvida.