GitHub e Portfolio para Vagas Internacionais: O Guia Definitivo
Seu currículo abre a porta — mas é o GitHub que a mantém aberta. Para devs brasileiros sem experiência em empresa americana, o perfil técnico é muitas vezes o único sinal de credibilidade disponível para recrutadores no exterior. Neste guia você aprende exatamente o que colocar, o que tirar, e como estruturar projetos e READMEs que impressionam do outro lado do mundo.
Por Que o GitHub Importa Mais do Que o Currículo Para Devs
No mercado americano de tecnologia, o currículo filtra — mas o GitHub decide. Quando um recrutador técnico ou engenheiro sênior avalia um candidato internacional, o currículo informa o histórico profissional, mas o GitHub mostra como você realmente escreve código.
Para devs brasileiros, isso é especialmente verdadeiro porque a maioria não tem experiência reconhecível em empresas americanas no currículo. Um candidato de São Paulo com 4 anos de experiência em uma empresa que recrutadores americanos nunca ouviram falar parte do zero em credibilidade percebida — o GitHub é o ativo que nivela esse jogo.
O que recrutadores verificam no GitHub em menos de 3 minutos:
- •Gráfico de contribuições: atividade consistente ao longo do tempo sinaliza que você programa regularmente, não apenas quando tem prazo
- •Repositórios pinados: os 6 projetos que você colocou em destaque — se forem tutoriais genéricos, já perdeu pontos
- •README do projeto principal: a qualidade do README é um proxy para a qualidade da documentação que você vai escrever no trabalho
- •Contribuições externas: PRs abertos em outros repositórios mostram que você colabora além dos seus projetos pessoais
- •Linguagens predominantes: o mapa de linguagens do perfil deve bater com o stack que você declarou no currículo
A boa notícia: diferente do currículo, você tem controle total sobre o que aparece no GitHub — e pode otimizá-lo antes de começar a aplicar. Isso não é trapaça, é profissionalismo.
Os 3 Tipos de Projeto Que Recrutadores Procuram
Não é sobre quantidade de projetos — é sobre diversidade de sinais. Um portfólio bem construído tem pelo menos um projeto de cada um desses três tipos:
Tipo 1: Produto Real que Resolve um Problema
Um projeto que você usaria (ou usa) no dia a dia, com usuários reais ou potencial real de uso. Pode ser simples, mas deve existir por uma razão além de "aprendi a tecnologia".
Exemplos que funcionam:
- •CLI que automatiza uma tarefa repetitiva do seu workflow de dev
- •App que resolve um problema local que você conhece bem (agendamento para pequenos negócios, controle de finanças pessoais)
- •Ferramenta open source que outros devs na sua comunidade já usam
Sinal para recrutador: você cria valor, não só executa tarefas.
Tipo 2: Projeto de Profundidade Técnica
Um projeto que demonstra domínio técnico em uma área específica — não necessariamente útil para usuários finais, mas que mostra que você vai fundo em conceitos. Ideal para vagas que exigem especialização.
Exemplos que funcionam:
- •Implementação de um algoritmo ou estrutura de dados do zero com benchmarks comparando com soluções padrão
- •Sistema distribuído simples (ex: Raft consensus ou consistent hashing implementado do zero)
- •Analisador de performance com profiling e resultados documentados
Sinal para recrutador: você estuda com profundidade, não apenas consome tutoriais.
Tipo 3: Contribuição a Open Source
Um PR aceito em um projeto que você não criou. Pode ser pequeno — corrigir documentação, adicionar um teste, resolver um bug de edge case. O impacto é desproporcional ao tamanho: mostra que você consegue navegar em código de outras pessoas e colaborar com comunidades.
Como começar:
- •Filtre por "good first issue" em repositórios que você usa (Next.js, FastAPI, Prisma, etc.)
- •Melhore a documentação em inglês de um projeto brasileiro que você conhece bem
- •Reporte e conserte um bug que você encontrou usando a ferramenta no seu trabalho
Sinal para recrutador: você é um membro da comunidade de desenvolvedores, não um operador solitário.
Como Escrever um README Que Impressiona em Inglês
O README é o cartão de visita do seu projeto. Um README bem escrito em inglês faz um projeto simples parecer profissional. Um README ruim faz um projeto excelente parecer amador. Aqui está a estrutura que funciona:
Estrutura de README Profissional
1. Título + Badge + Descrição de 1 linha
O que é, em uma frase. Badges de status (build passing, coverage, license) antes da descrição. Recrutadores decidem em 5 segundos se continuam lendo.
# ProjectName
  
> A lightweight CLI tool that automates Kubernetes namespace cleanup for dev environments.2. Demo / Screenshot / GIF
Visual antes de qualquer texto. Um GIF de 10 segundos mostrando o produto em uso vale mais do que 3 parágrafos de descrição. Use Loom, Asciinema (para CLIs) ou screenshots do app funcionando.
3. Why / Motivation
Por que você criou isso? Qual problema resolve? Isso diferencia seu projeto de um exercício genérico e demonstra pensamento de produto.
## Why
Every week I was manually deleting stale namespaces from our dev cluster.
This tool automates that process and saved our team ~2 hours/week.4. Tech Stack
Liste as tecnologias principais com links. Isso ajuda recrutadores a filtrar por stack rapidamente e sinaliza que você fez escolhas conscientes.
## Built With
- [Go](https://go.dev/) — for the CLI binary
- [kubectl](https://kubernetes.io/docs/reference/kubectl/) — Kubernetes client
- [Cobra](https://github.com/spf13/cobra) — CLI framework5. Getting Started
Instalação e uso em menos de 5 comandos. Se o recrutador não consegue rodar em 2 minutos, ele desiste. Teste o README em uma máquina limpa antes de publicar.
6. Architecture / How it Works (opcional para projetos complexos)
Um diagrama simples (mesmo em ASCII ou Mermaid) explicando como os componentes se conectam. Isso demonstra que você pensa em sistemas, não só em funções.
Dica de inglês para o README: use verbos no presente imperativo na documentação ("Run the CLI", "Install dependencies", "Configure your credentials"). Não use gerúndio ("Running the CLI", "Installing") — soa mais profissional e é padrão na documentação técnica americana.
O Que Não Fazer no Seu GitHub
Às vezes o que você remove é mais impactante do que o que você adiciona. Estes são os erros mais comuns que derrubam perfis tecnicamente competentes:
✗ Repositórios de tutorial pinados
"react-tutorial", "node-express-starter", "spring-boot-hello-world" — qualquer recrutador sênior reconhece esses projetos instantaneamente. Se estão nos seus repos pinados, você sinalizou que não tem nada melhor para mostrar. Arquive esses repos ou deixe-os escondidos (não é possível deletar do histórico, mas pode tirar do perfil público).
✗ CRUD sem contexto
Todo dev cria um CRUD em algum momento. O problema é quando o projeto se chama "todo-app" ou "e-commerce-project" sem nenhuma diferenciação. Se você fez um CRUD, pelo menos explique no README o problema específico que resolve, as decisões de arquitetura que tomou e o que aprendeu — isso o transforma de exercício em projeto.
✗ Repositórios vazios ou com um commit
Um repositório com 1 commit de "initial commit" e nenhuma atividade desde 2022 é pior do que não existir. Arquive projetos abandonados. O GitHub permite arquivar repos para que apareçam com badge "Archived" e não poluam seu perfil.
✗ Nenhuma atividade nos últimos 6 meses
Um gráfico de contribuições completamente vazio nos últimos meses sinaliza que você parou de codar (mesmo que não seja verdade). Se você contribui em repos privados no trabalho, considere criar repositórios de estudo públicos, contribuir com documentação de projetos open source, ou publicar scripts de automação do dia a dia.
✗ READMEs em português ou sem README
Para vagas internacionais, todo README deve ser em inglês — mesmo que o projeto seja voltado para o mercado brasileiro. Um README em português imediatamente limita quem pode avaliar o projeto. Se o projeto é local por natureza (app em português para usuários brasileiros), tenha pelo menos uma seção em inglês descrevendo o projeto para recrutadores.
Perfil GitHub Otimizado: Bio, Repos Pinados e Atividade
O perfil em si — antes de qualquer repositório — é o que recrutadores veem primeiro. Aqui estão os elementos que mais impactam a primeira impressão:
Profile README
O GitHub permite criar um repositório especial com o mesmo nome do seu usuário que aparece no topo do perfil. Use para uma apresentação profissional: quem você é, o que você faz, tecnologias que domina, como entrar em contato. Mantenha em inglês e conciso — 5 a 10 linhas. Evite "decorações" excessivas (GIFs de sprites, status de streak) que parecem imaturos para posições sênior.
Bio e Links
- •Bio: 1-2 linhas descrevendo sua especialidade e senioridade. "Senior Backend Engineer • Go, Postgres, Kubernetes • Open to remote roles"
- •Website: link para LinkedIn ou portfolio web
- •Location: coloque sua cidade + "Brazil (open to remote)" — não esconda que você é brasileiro
- •Foto: use uma foto profissional. Avatares e fotos de anime reduzem credibilidade percebida em processos seletivos formais
Repos Pinados: Os 6 Mais Importantes
Você pode pinar até 6 repositórios. Use essa curadoria estrategicamente:
- •2 projetos pessoais relevantes para a vaga que está aplicando
- •1 projeto de profundidade técnica
- •1 fork com contribuição a projeto open source (se tiver)
- •2 vagas restantes: outros projetos que mostram versatilidade de stack
Atividade Consistente
O gráfico verde de contribuições é um sinal comportamental importante. Você não precisa de commits diários — consistência semanal é suficiente. Estratégias práticas para manter atividade:
- •Publique scripts de automação do dia a dia que você usa no trabalho
- •Resolva 1 problema LeetCode por semana e commite a solução com explicação
- •Documente aprendizados técnicos como arquivos Markdown em um repo público de "til" (today I learned)
Portfolio Web vs GitHub: Quando Ter os Dois e Quando Um Basta
A questão não é qual é melhor — é qual combinação é certa para o seu perfil e as vagas que você busca.
Só GitHub é suficiente para:
- ✓Backend engineers
- ✓Engenheiros de dados e ML
- ✓DevOps e SRE
- ✓Developers de ferramentas e CLIs
Portfolio web é necessário para:
- →Frontend engineers (demonstrar habilidade visual)
- →Mobile developers (screenshots do app)
- →Full-stack com foco em produto
- →Devs freelancers ou que buscam clientes
Se você vai criar um portfolio web, mantenha-o simples: clareza e performance superam design complexo. Recrutadores técnicos não ficam impressionados com animações elaboradas — ficam impressionados com um site que carrega rápido, está no ar, e mostra claramente quem você é e o que você fez.
Stack recomendada para portfolio web de dev: Next.js + Tailwind + Vercel (deploy gratuito, domínio customizável, performance excelente). Você pode ter o portfolio no ar em menos de 2 horas e isso já é um projeto que demonstra competência frontend básica.
Perguntas Frequentes
Recrutadores americanos realmente olham o GitHub antes de entrevistar?
Sim, especialmente em empresas de tecnologia. Uma pesquisa da HackerRank mostrou que mais de 70% dos recrutadores técnicos olham o GitHub de candidatos antes de tomar decisões de entrevista. Para devs sem experiência em empresa americana, o GitHub é frequentemente o único sinal concreto de qualidade técnica disponível.
Quantos projetos devo ter no GitHub para impressionar recrutadores?
Qualidade supera quantidade. 3 projetos sólidos com READMEs completos, código limpo e demonstrações funcionando valem mais do que 30 repositórios de exercícios e tutoriais. Foque em ter pelo menos 2 projetos que resolvem problemas reais e 1 contribuição a um projeto open source conhecido.
Devo colocar projetos feitos em bootcamp ou cursos no GitHub?
Apenas se você os expandiu significativamente além do proposto pelo curso. Projetos que são cópias exatas de tutoriais ou exercícios de bootcamp não impressionam — recrutadores reconhecem esses projetos. Se você usou um projeto de curso como base e o transformou em algo seu, com funcionalidades novas e README próprio, então vale incluir.
É necessário ter um portfolio web além do GitHub?
Depende da área. Devs backend e engenheiros de dados raramente precisam de portfolio web — o GitHub é suficiente. Devs frontend, mobile e full-stack se beneficiam de um portfolio web porque ele demonstra habilidades de UI/UX que o GitHub não mostra. Designers que programam praticamente são obrigados a ter um portfolio visual.
Como conseguir minha primeira contribuição open source para colocar no GitHub?
Comece pequeno: procure issues marcadas como "good first issue" ou "help wanted" em repositórios que você usa no seu trabalho. Corrija um bug de documentação, melhore um teste, ou conserte um erro de tipagem em TypeScript. Uma contribuição aceita em um projeto popular (React, Next.js, FastAPI, etc.) vale muito mais do que 10 projetos pessoais no seu perfil.
Pronto para montar seu perfil técnico internacional?
Análise seu currículo com IA para identificar o que recrutadores americanos procuram e o que está faltando no seu perfil para a vaga que você quer.