O que eu procuro em um engenheiro

Já revisei o trabalho de muitos engenheiros ao longo de mais de 600 projetos, e já contratei para o meu próprio estúdio. Com o tempo, o que eu procuro foi ficando mais simples. Não é a stack. Não são os anos de experiência. É um conjunto pequeno de hábitos que aparece na primeira hora de trabalho com alguém e prevê a maior parte do que vem depois.

Leem primeiro, e admitem o que não sabem

A primeira coisa que observo é o que um engenheiro faz quando recebe um sistema desconhecido. O sinal fraco é abrir o editor e começar a digitar. O sinal forte é abrir os logs, o README, o histórico do git, o schema, e perguntar quem construiu isso e por quê. Engenheiro que lê primeiro faz menos mudanças, e melhores. Também encontra as falhas que ninguém mais encontra, porque a maioria das falhas está visível no histórico, se você olhar.

Depois faço perguntas que sei que são difíceis. Não estou testando conhecimento. Estou testando o que acontece na borda do conhecimento. O engenheiro que quero diz "não sei, deixa eu verificar", verifica, e volta com a resposta e a fonte. O que evito chuta com confiança. Em um sistema de produção, um chute confiante é mais perigoso do que uma lacuna honesta, porque a lacuna é preenchida e o chute vai para produção.

Percebem a coisinha errada

Um campo chamado user_id que guarda um e-mail. Um timeout definido no arquivo de configuração mas nunca lido pelo código. Um teste que passa porque a asserção foi comentada. Me importa se um engenheiro enxerga isso, não porque cada item seja importante, mas porque o hábito de enxergar é o que impede a falha grande. A falha grande é sempre uma coisinha errada que ficou visível por meses. Obcecado por detalhes é um elogio que levo a sério, e é o traço que procuro primeiro.

Terminam

Começar é comum. Terminar é raro. Terminado quer dizer em produção, documentado, entregue a quem vai manter, e observado em produção por tempo suficiente para saber que funciona. Olho o histórico de alguém procurando coisas que foram concluídas, principalmente as sem glamour. Quem termina uma migração chata termina o projeto interessante. Quem tem dez repositórios empolgantes pela metade vai ter onze ano que vem.

Explicam uma decisão para quem não programa

Em algum momento todo engenheiro precisa dizer a um fundador, a um gerente de produto ou a um cliente por que a coisa que ele quer é má ideia, ou por que o atraso é real. Quem consegue fazer isso em linguagem simples, sem jargão e sem condescendência, vira a pessoa em quem o negócio confia. Quem não consegue acaba isolado, certo e ignorado. Peço aos candidatos que me expliquem uma decisão técnica passada como se eu fosse um cliente. A qualidade dessa explicação me diz mais do que o código.

O que pesa pouco, e como mostrar o que pesa

Me importo menos do que a maioria com o framework específico. Prefiro Next.js e TypeScript no meu próprio trabalho, mas um engenheiro com os hábitos acima aprende a stack em um mês. Me importo pouco com o diploma; não terminei o meu. Me importo pouco com o tamanho da empresa anterior. Algumas das pessoas mais afiadas com quem trabalhei vieram de chão de fábrica ou de bancada de conserto, e já tinham o hábito de ler e o hábito de perceber antes de encostar num compilador.

Se você está sendo avaliado, é assim que se mostra isso numa entrevista ou numa semana de teste. Leia o sistema antes de mexer e diga o que encontrou. Diga "não sei" em voz alta pelo menos uma vez e depois volte com a resposta. Aponte uma coisinha errada que você notou. Fale de algo que terminou, incluindo a última milha chata. Explique uma decisão passada em palavras que sua avó acompanharia.

Se você é quem avalia, pare de perguntar trivia. Entregue algo real, observe a primeira hora, e ouça como a pessoa se explica. Todo o resto é ruído.