Além de "3 Anos de Ruby" | Guia Completo para Avaliar Engenheiros por Portfólio GitHub

Limitações da avaliação por anos de experiência

Você consegue realmente contratar engenheiros excepcionais avaliando "3 anos Ruby, 3 anos JavaScript"? Após 5 anos em RH e transição para engenharia, descobri o problema fundamental: anos de experiência com linguagem correlacionam fracamente com capacidade real de execução. Como CTO contratando 200+ engenheiros anualmente, provei que avaliação de portfólio GitHub revela verdadeira capacidade muito melhor que anos no currículo.

Três verdades que experiência em linguagens não mostra

1. Repetir mesmo ano 3 vezes: Engenheiros presos mesmo nível sem aprender novos padrões. 30%+ candidatos "Ruby 5 anos" ainda escrevem código estilo Rails 4.2.

2. Apenas manutenção, zero experiência design: "3 anos experiência" pode significar apenas consertar código existente, nunca projetar do zero.

3. Stack tecnológica obsoleta: Parou em Ruby 2.2 (2015), completamente inconsciente de recursos Ruby 3.x.

Contraste: autodidata 6 meses virou top performer

Melhor engenheiro contratado: zero experiência profissional, mas 50+ projetos pessoais no GitHub mostrando velocidade aprendizado excepcional, resolução problemas, 90%+ cobertura testes, README detalhado, refatoração contínua.

5 pontos-chave avaliação portfólio GitHub

Framework usado para 200+ contratações anuais (100 pontos total):

1. Qualidade histórico commits (20pts)

Histórico commits visualiza processo pensamento. Avaliar clareza mensagem, granularidade, fluxo trabalho. Excelente: "feat: Adicionar filtro categoria busca produtos - Índice FTS PostgreSQL - Velocidade busca 50ms→15ms". Fraco: "fix", "update". Bandeiras vermelhas: todos commits mesmo timestamp (suspeita copy-paste), lacunas 3+ meses, todos arquivos em 1 commit.

2. Qualidade código & design (25pts)

Mais crítico. 15min revela 80% capacidade. ①Estrutura diretórios (5pts): separação controllers/services/repositories. ②Tratamento erros (5pts): classes erro personalizadas, logging apropriado, classificação tipos erro. ③Manutenibilidade (10pts): números mágicos como constantes, funções DRY, comentários Why, segurança tipos. ④Código teste (5pts): casos normal/borda/erro cobertos, 80%+ cobertura.

3. Operações Git (20pts)

Iniciante (5pts): todos commits diretamente para main. Intermediário (12pts): branches feature/fix, PRs básicos. Avançado (20pts): Git Flow, descrições PR detalhadas, evidência auto-revisão, histórico resolução conflitos. PR excelente inclui: resumo mudanças, resultados testes, decisões técnicas, breaking changes, pontos revisão.

4. Documentação (15pts)

README.md indica capacidade comunicação. Requerido (2pts cada): resumo projeto (por que construído), stack técnica, configuração, execução. Bônus (1.5pts cada): declaração problema, lições aprendidas, URL demo/capturas, melhorias futuras (consciência débito técnico).

5. Velocidade aprendizado & resolução problemas (20pts)

①Amplitude tecnológica (7pts): Full-stack+infra=7pts, especializado=4pts, tech única=2pts. ②Adoção nova tech (7pts): adoção última tech=7pts, versões estáveis=4pts, apenas legacy=2pts. ③Evidência resolução problemas (6pts): discussões técnicas Issue/PR, registros troubleshooting, medição quantitativa problema→identificação causa→solução→avaliação resultado.

Perguntas aprofundamento entrevista

Sobre projetos

1. "Por que construiu isso?"→capacidade definição problema
2. "Parte mais desafiadora e como resolveu?"→processo resolução problemas
3. "O que mudaria se reconstruindo?"→consciência débito técnico, mentalidade crescimento
4. "(apontando commit) Por que dividiu assim?"→granularidade pensamento, julgamento design

Sobre tecnologia

5. "Considerações performance/segurança?"→consciência requisitos não funcionais

Folha avaliação prática

Critérios contratação: 70+ para entrevista, 80+ para alta avaliação

Pontos foco PMEs

1. Conjunto habilidades amplo: cobertura Frontend/backend/infra. 2. Autonomia: criação Issues, refatoração autodirigida. 3. Comunicação clientes: README compreensível não-engenheiros.

Casos sucesso & fracasso

✅Sucesso: 0 anos→Líder equipe em 6 meses

800 commits/ano, React/TypeScript/Node.js/Docker/AWS, TDD/CI-CD, auto-resolve problemas desconhecidos→promovido em 6 meses, melhoria performance 3x.

❌Fracasso: 5 anos→renúncia em 3 meses

50 commits/ano, Ruby 2.x/Rails 4.x, sem testes, sem interesse nova tech→enganado por anos experiência, incompatibilidade.

10 bandeiras vermelhas

1. Todos commits mesmo timestamp
2. Sem README/template inalterado
3. Sem .gitignore
4. Todos arquivos em 1 commit
5. Dependências 3+ anos antigas
6. Zero código teste
7. Mensagens commit apenas "update"
8. Lacunas 3+ meses
9. Todos projetos incompletos
10. Código copy-paste por todo lado

FAQ

Q1. Sem portfólio GitHub?

A. Dar desafio código: "Construir app Todo em 2 dias, publicar no GitHub" avalia todos pontos.

Q2. Avaliação demora muito?

A. Revisão inicial 15-20min suficiente. Lista verificação scoring mecânico para eficiência.

Q3. Ignorar anos perigoso?

A. Usar como info suplementar. Focar em "o que aprendeu e como cresceu durante esses anos".

Resumo

"3 anos Ruby, 3 anos JS" é relíquia era currículo. GitHub tesouro processo-pensamento permite avaliação capacidade essencial. Prática framework produz: ①ver através anos para verdadeira capacidade②descobrir sem experiência alto potencial③melhorar precisão entrevista reduzir incompatibilidade. Contratação determina futuro empresa. Escapar avaliação obsoleta, ganhar poder identificar engenheiros verdadeiramente excelentes.