Algo mudou de tom essa semana nos fóruns onde engenheiros sênior discutem entre si, não no LinkedIn cheio de thought leadership, mas no lugar onde as pessoas realmente dizem o que pensam. A pergunta de sempre voltou a circular: ter projetos pessoais ainda é necessário para ser levado a sério como um bom engenheiro?
Mas a conversa foi para um lugar mais desconfortável. Se qualquer candidato pode se apoiar em um agente de IA para resolver o exercício técnico de uma entrevista, o que essa entrevista está medindo, de fato?
A pergunta que parou de funcionar
Durante anos, a entrevista técnica teve uma função simples: verificar se a pessoa conseguia resolver um problema sozinha, sem ajuda, com o quadro branco ou o editor vazio como único aliado. Isso fazia sentido. Em um mundo onde escrever código do zero, lembrar a sintaxe exata e não travar diante de algo novo eram sinais reais de capacidade, medir isso equivalia a medir o engenheiro.
Esse mundo mudou sem avisar. Hoje qualquer pessoa com acesso a um agente de código consegue produzir uma solução razoável para um problema clássico de entrevista sem entendê-lo por completo. "Você consegue resolver isso sozinho?" ainda aparece em muitos processos, mas cada vez mede menos o que diz medir.
Por que avaliar sem ajuda parou de significar algo real
O problema aqui é concreto. Esse mesmo engenheiro, assim que começar a trabalhar, vai ter um agente de IA ao lado em cada pull request, cada bug, cada feature nova. Avaliá-lo na entrevista sem essa ferramenta mede uma habilidade que ele não vai usar no dia a dia da forma como o exercício supõe.
É parecido com avaliar um piloto pela capacidade de voar sem instrumentos. Pode dizer algo sobre reflexos e conhecimento básico, mas não é o trabalho que essa pessoa vai fazer todos os dias. O trabalho real sempre incluiu as ferramentas disponíveis.
Antes e agora, duas perguntas diferentes
Antes, a pergunta que definia um bom engenheiro era: você consegue resolver isso sozinho? Media memória, velocidade de digitação e domínio fino da sintaxe da linguagem da vez. Um candidato que travava em um detalhe menor de implementação podia perder uma proposta inteira por causa disso, mesmo com um ótimo critério de design.
Essa pergunta perdeu o sentido que tinha. A que deveria substituí-la soa parecida, mas mede algo completamente diferente: essa pessoa toma boas decisões usando as ferramentas que tem disponíveis? Responder bem exige observar como alguém direciona um agente, o que pede a ele, o que corrige, e principalmente, quando decide não seguir a sugestão dele.
Critério, não memória, é o que separa um sênior hoje
Um agente de IA consegue escrever código funcional em segundos. O que ele não tem é contexto: não sabe por que aquele endpoint carrega uma exceção estranha deixada de uma migração de dois anos atrás, não estava na sala quando a decisão de arquitetura foi tomada depois de um incidente em produção, e não sabe qual parte do sistema é intocável nem por quê.
Um engenheiro sênior tem esse contexto, ou sabe como consegui-lo antes de aceitar uma sugestão. É essa a habilidade que hoje o separa de alguém que ainda não chegou lá: o critério para reconhecer quando a resposta do agente está certa, quando precisa de ajuste, e quando precisa ser descartada porque resolve o sintoma errado. Essa capacidade de identificar o erro não vem de um bom prompt, e sim de anos de ter visto sistemas falharem de formas bem específicas.
Um exemplo do tipo de erro que separa os dois
Pense em um caso simples: o agente sugere adicionar um índice para acelerar uma consulta lenta. A sugestão compila, passa nos testes e, no ambiente de desenvolvimento, a consulta realmente fica mais rápida.
Um engenheiro sem contexto suficiente aceita e segue em frente. Um sênior para um segundo antes: sabe que aquela tabela recebe escritas constantes em produção, que um índice mal escolhido pode travar cada insert, e que o problema real não está na consulta, e sim em como aquela view está sendo paginada.
A sugestão do agente não estava mal escrita. Estava mal direcionada, do tipo que você aprova no PR com um comentário tipo "funciona, mas não me convence". Essa sensação, saber quando algo está tecnicamente certo mas ainda assim errado, é exatamente o que um exercício de entrevista deveria buscar hoje.
Projetos pessoais não perderam valor, perderam o monopólio
Vale esclarecer algo antes de seguir. Ter projetos pessoais ainda diz algo real sobre um engenheiro: iniciativa, curiosidade, capacidade de terminar algo que ninguém pediu nem pagou para ele fazer. Isso não mudou.
O que mudou é que deixou de ser o único indicador válido. Antes, quem não tinha repositórios pessoais para mostrar levantava suspeita sobre o comprometimento real com a profissão.
Hoje um engenheiro pode não ter um único projeto próprio e ainda assim demonstrar, em como direciona um agente durante uma entrevista e percebe onde ele erra, exatamente o tipo de critério que antes só se via em quem programava nos fins de semana. Por muito tempo, o projeto pessoal foi a prova mais visível desse critério. Já não é mais a única forma de mostrá-lo.
O que muda para quem desenha o processo
Para as empresas que montam processos de entrevista, isso significa repensar o exercício técnico desde o desenho. Dar acesso a um agente durante a entrevista e observar quando a pessoa confia na sugestão e quando questiona ela revela mais sobre o nível real do candidato do que proibir a ferramenta e cronometrar quanto tempo leva para escrever um loop de memória, como se ainda fosse 2015. A pergunta que vale fazer ao desenhar o processo não é como impedir que o candidato use IA, e sim como desenhar um exercício em que usar mal a IA fique tão exposto quanto não usar ela.
Qualquer pessoa com o prompt certo consegue produzir código hoje, e até o próprio agente sabe disso (provavelmente melhor do que ninguém). O que separa um engenheiro sênior de alguém que ainda não chegou lá nunca foi quem escreve mais rápido, e sim quem percebe primeiro que o que acabou de ser escrito está errado.
