Portfolio Projects for Data Engineer

Você tem certificados, mas nenhum projeto que sobreviva a uma olhada de trinta segundos de um recrutador técnico. Essa é a situação mais comum entre quem está entrando em engenharia de dados agora, e ela tem uma solução direta: três projetos bem construídos, com código público e decisões documentadas.

Certificado mostra que você estudou. Projeto mostra que você decide. E engenharia de dados é, antes de tudo, um trabalho de decisão: qual formato armazenar, quando particionar, o que fazer quando a fonte muda de esquema, como reprocessar sem corromper o que já existe. Ninguém contrata pela sua pontuação em prova.

O que avaliadores realmente olham#

Antes de escrever qualquer linha, vale entender o filtro. Quem revisa portfólio de engenharia de dados, tech lead, engenheiro sênior, gerente de plataforma, quase nunca roda o seu código. Ele lê o README, olha a estrutura de pastas, abre dois ou três arquivos e forma uma opinião.

Três perguntas guiam essa leitura. Você entende o problema de dados, ou só copiou um tutorial? Você tomou decisões com motivo, ou usou a stack da moda sem justificar? Você pensou em falha, ou só no caminho feliz?

Reparar em detalhes pequenos: tem teste? Tem como eu reexecutar o pipeline? Tem um exemplo de dado de entrada e saída? Se a resposta for não em todas, o projeto vira decoração de perfil.

Os três projetos que valem por vários certificados#

A ideia é que cada projeto mostre uma camada diferente da engenharia de dados. Juntos, eles cobrem ingestão, transformação, orquestração, qualidade e documentação, que é exatamente o pacote que aparece nas descrições de vaga.

Projeto 1: pipeline de ingestão incremental com tratamento de mudança de esquema

Pegue uma fonte de dados pública que muda com frequência, por exemplo abertos de prefeituras, registros de transações financeiras em datasets públicos ou a API de um serviço que você já usa. Construa um processo que baixa apenas o que é novo, registra o que mudou e resiste quando a fonte adiciona ou remove um campo.

Esse projeto é valioso porque ensina o problema mais caro da área: dados que não param quietos. Mostre um log de execuções, uma tabela de controle de partições e uma decisão explícita sobre como você lida com schema drift, se rejeita, se aceita com colunas anuláveis, se escreve em formato colunar com tipagem flexível.

Projeto 2: camada de transformação com testes de qualidade de dados

Aqui você mostra que pensa em confiança. Pegue os dados do primeiro projeto e construa uma camada de tabelas analíticas, em dbt ou em SQL puro com views materializadas. O ponto não é a ferramenta. O ponto é o que você valida.

Escreva testes que falhem quando aparecer valor nulo em chave primária, quando a contagem diária cair mais que o esperado, quando uma categoria nova surgir sem cadastro. Documente o que cada teste protege e o que a pessoa deve fazer quando ele quebra. Esse tipo de detalhe separa quem automatizou de quem opera.

Projeto 3: orquestração com reprocessamento e recuperação de falha

O terceiro projeto fecha a porta da dúvida sobre senioridade. Coloque os dois anteriores sob um orquestrador, Airflow, Dagster, Prefect ou até um agendador simples com controle de estado, e implemente uma rotina de backfill. Mostre que você consegue reprocessar um mês inteiro sem duplicar dados.

Inclua no README um cenário de falha real: o job cai no meio, o que acontece com os dados que já foram gravados? Como você retoma? Esse projeto responde à pergunta que todo entrevistador tem na ponta da língua sobre o que fazer quando o pipeline quebra às três da manhã.

Como apresentar no GitHub#

O README é o seu currículo dentro do repositório. Comece com uma frase que diga o problema, não a tecnologia. Depois, mostre arquitetura em texto simples, com blocos de código mostrando o fluxo, e um exemplo curto de como executar localmente.

• Descreva o problema de dados em duas frases, com a fonte e o volume esperado
• Liste as decisões de projeto e o motivo de cada uma, em uma tabela curta
• Inclua um exemplo de entrada e de saída, com dados falsos se os reais forem sensíveis
• Documente como rodar o projeto do zero, incluindo variáveis de ambiente
• Explique o que quebra e como você detecta a quebra
• Mantenha o histórico de commits legível, com mensagens que digam o que mudou

Um repositório com trinta arquivos soltos na raiz e nenhum README diz mais sobre a sua organização do que qualquer descrição de projeto. Pastas separadas por ingestão, transformação e infraestrutura ajudam quem lê a se localizar.

Como colocar no currículo#

No currículo, trate cada projeto como uma experiência real, com contexto, ação e resultado. O resultado em projeto próprio não é receita, é propriedade técnica: latência, volume, redução de retrabalho, cobertura de testes. Seja honesto, nunca invente números de negócio que você não tem.

Um exemplo de reescrita:

Antes: "Criei um pipeline de dados com Python e Spark".

Depois: "Construí pipeline incremental que ingere registros de fonte pública com mudança de esquema, processando cerca de 2 milhões de linhas por execução, com controle de partições e reprocessamento idempotente; reduzi o tempo de carga diária de 40 para 8 minutos".

A segunda versão mostra escala, decisão e efeito. Se você não tem o número exato, dê uma ordem de grandeza e diga que é estimativa. Honestidade não enfraquece o texto, invenção enfraquece na primeira pergunta técnica.

Ajuste cada projeto à vaga antes de enviar. Vale a pena cruzar as palavras da descrição da vaga com o seu texto, e existe uma ferramenta gratuita de leitura de vagas que ajuda a entender o que a empresa realmente está pedindo.

Erros que fazem o projeto parecer tutorial#

O erro mais comum é copiar o projeto do vídeo e mudar o nome do dataset. Quem revisa portfólio conhece os tutoriais populares de memória. Se o seu README tem a mesma estrutura e as mesmas escolhas do vídeo, isso aparece.

Outros erros frequentes:

• Escolher uma fonte de dados estática e limpa demais, que não ensina nada sobre engenharia
• Usar Spark para um dataset de 5 mil linhas, só para colocar a tecnologia no currículo
• Deixar credenciais ou chaves no repositório, o que reprova na hora
• Não versionar as dependências, com um arquivo de ambiente que ninguém consegue recriar
• Escrever um README longo sobre a ferramenta e curto sobre o problema
• Não mostrar nenhuma decisão de tradeoff, como custo contra latência ou consistência contra disponibilidade

Se você tem dúvida sobre se um projeto está genérico, tente explicá-lo para alguém da área em trinta segundos, sem citar a stack. Se não sobrar um problema de dados claro, o projeto ainda está raso.

Como falar dos projetos na entrevista#

Na entrevista, não descreva o que você instalou. Conte a decisão difícil e o que você faria diferente hoje. Essa é a pergunta que separa quem construiu de quem acompanhou.

Um roteiro curto que funciona: "A fonte mudava de esquema sem aviso, então precisei decidir entre rejeitar a carga ou aceitar colunas novas como anuláveis. Escolhi aceitar e registrar a mudança em uma tabela de controle, porque o time de análise precisava continuar funcionando. Hoje eu adicionaria um alerta quando a taxa de mudança passar de um limite, porque descobri tarde demais que silêncio não é estabilidade".

Esse formato, contexto, escolha, arrependimento, é o que entrevistadores querem ouvir. Ele mostra critério, e critério é o que falta em currículo cheio de certificado.

Quando for procurar vagas para testar esse discurso, o mercado brasileiro tem bastante variação de faixa salarial para engenheiro de dados júnior e pleno, com valores que mudam por região e por porte de empresa, então confira sempre a fonte oficial ou o site da vaga antes de negociar. A busca de vagas no jobrise ajuda a comparar o que está sendo pedido em cada nível.

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#

Preciso ter certificado se já tenho os projetos?

Não. Projeto bem documentado resolve mais objeção que certificado, porque mostra decisão e execução. Certificado ajuda em processos que usam filtro automático por palavra-chave, então vale ter se for barato e rápido, mas não substitui portfólio.

Quantos projetos eu preciso para começar a aplicar?

Três projetos que mostrem camadas diferentes resolvem a maior parte das dúvidas de quem revisa. É melhor ter três com README decente e decisões escritas do que dez rasos. Comece a aplicar enquanto termina o terceiro.

Posso usar dados de empresa onde trabalhei?

Não, a não ser que você tenha autorização explícita e anonimização real. Use fontes públicas ou gere dados sintéticos que imitem o padrão de volume e sujeira dos dados reais. Dado sensível no GitHub é motivo de reprovação imediata.

Quanto tempo leva para construir os três projetos?

Depende da sua rotina, mas quem já conhece SQL e Python costuma levar de um a três meses somando os três. O que mais consome tempo não é código, é escrever README, testes e o cenário de falha. Reserve tempo para isso desde o começo.

Como saber se meu projeto está bom o suficiente?

Peça para alguém da área ler só o README e te dizer qual problema de dados ficou claro e qual ficou confuso. Se a pessoa não souber explicar o que o projeto resolve em uma frase, volte e reescreva. Feedback curto de quem já trabalha com dados vale mais que autoavaliação.#