Contratação na Era dos Agentes: Como Entrevistar Devs Quando a IA Escreve o Código

Semana passada eu estava numa entrevista técnica do outro lado da mesa, avaliando um candidato para uma vaga de pleno-sênior. O desafio era um clássico: inverter uma árvore binária e depois otimizar. O candidato resolveu em quatro minutos, com uma solução limpa, nomes de variáveis impecáveis e até um comentário explicando a complexidade assintótica. Fiquei impressionado por uns dois minutos, até perceber que era exatamente o tipo de solução que qualquer agente de IA cospe em três segundos quando você cola o enunciado. Passei a próxima meia hora tentando entender se aquela pessoa realmente sabia programar ou só sabia copiar e colar bem.

Esse não é um caso isolado. Se você lidera contratação técnica hoje, provavelmente já sentiu esse desconforto: o processo que funcionou bem por quinze anos simplesmente não discrimina mais quem sabe o quê. Quando todo mundo tem acesso a um copiloto que resolve algoritmo de quadro branco e monta um take-home decente em vinte minutos, continuar usando os mesmos filtros é like medir a maré com uma régua — a régua não mudou, mas o oceano inteiro subiu.

Este post é sobre redesenhar esse processo. Não é sobre proibir IA na entrevista (spoiler: isso não funciona e nem deveria), mas sobre entender o que realmente precisa ser avaliado quando a ferramenta que escreve código está disponível para todo mundo, o tempo todo, inclusive durante a entrevista.

---

O problema: entrevistas que pararam de medir o que importa

O modelo clássico de entrevista técnica nasceu numa época em que escrever código era o gargalo. Se alguém resolvia um problema de algoritmos em tempo real, isso correlacionava razoavelmente bem com "essa pessoa programa bem". O take-home assignment também partia da mesma lógica: dar um problema de tamanho médio, um prazo de alguns dias, e ver o que a pessoa entrega sem pressão.

O problema é que os dois formatos testam principalmente a capacidade de produzir código correto a partir de um enunciado — e é exatamente isso que os agentes de IA fazem hoje com uma competência assustadora. Um candidato mediano, com acesso a um bom modelo, entrega um take-home melhor do que um candidato excelente entregava em 2021. A distribuição de resultados colapsou: todo mundo parece bom no papel, porque o papel não mede mais a pessoa, mede a ferramenta.

Isso cria dois riscos concretos para quem contrata. O primeiro é falso positivo: aprovar alguém que sabe operar um agente mas não teria a menor ideia de como debugar um problema de produção às três da manhã sem chat de IA disponível, ou que aceita qualquer sugestão do Cursor ou do Copilot sem questionar. O segundo, menos falado, é o falso negativo: reprovar candidatos sênior de verdade porque eles não performam bem em cenários artificiais de "resolva sozinho, sem ferramentas, em quarenta minutos" — um cenário que não existe mais no dia a dia de trabalho de ninguém. Já escrevi antes sobre como o papel do desenvolvedor mudou, e boa parte da mudança é exatamente essa: o valor se deslocou de "escrever código" para "decidir o que escrever e validar o que foi escrito". Se o processo de entrevista não acompanha essa mudança, ele está otimizando para a habilidade errada.

---

O que continua importante (e não tem atalho)

A boa notícia é que nem tudo mudou. Só mudou onde está o gargalo. Hoje, a habilidade que separa um dev sênior de verdade de alguém que só sabe prompar bem está em quatro lugares específicos, e nenhum deles é substituível por um agente.

O primeiro é a revisão crítica de código gerado por IA. Qualquer agente comete erros sutis: uma condição de borda esquecida, um índice off-by-one escondido dentro de uma função aparentemente correta, uma race condition que só aparece sob carga. Saber ler um bloco de código gerado, entender a intenção por trás dele e identificar onde ele quebra é uma habilidade totalmente diferente de saber escrevê-lo do zero. Eu já cobri esse tema com mais profundidade no post sobre PRs de agentes rejeitados por devs seniores, e o padrão se repete: os melhores engenheiros que conheço não são os que geram mais código, são os que rejeitam mais código — os que enxergam o problema que o agente não viu porque o agente não tinha contexto do sistema inteiro.

O segundo é julgamento arquitetural. Um agente pode implementar uma feature de dez jeitos diferentes, todos sintaticamente corretos, mas só um ou dois fazem sentido dado o contexto do sistema, o time, o prazo e a dívida técnica acumulada. Escolher entre "resolve rápido e paga o preço depois" e "investe mais agora para não travar em três meses" é uma decisão que exige entender o negócio, não só a sintaxe.

O terceiro é saber quando não seguir a sugestão do agente. Isso parece óbvio mas é raro na prática. Muita gente confia demais na primeira resposta plausível porque ela compila e passa nos testes que existem — não nos testes que deveriam existir. Reconhecer que uma sugestão está sutilmente errada, ou está certa tecnicamente mas errada para aquele contexto específico, é a habilidade mais difícil de fingir numa entrevista.

O quarto é comunicação: explicar trade-offs em voz alta, de um jeito que outro humano entenda e possa discordar. IA não substitui isso porque a decisão final ainda precisa ser defendida para um time, um PM, ou um cliente.

---

Formatos de entrevista que realmente funcionam agora

Se o problema é que a entrevista tradicional mede a ferramenta e não a pessoa, a solução óbvia é redesenhar o exercício para que o uso da ferramenta seja parte esperada — e o que se avalia é o comportamento ao redor dela.

O formato que tenho visto funcionar melhor é o pair programming ao vivo com IA liberada. O candidato pode usar Copilot, Cursor, Claude, o que quiser, mas com uma regra clara: toda sugestão aceita precisa ser narrada. Por que você aceitou essa sugestão? O que você mudaria? Você testou a condição de borda que o agente ignorou? Isso desloca a avaliação de "a pessoa consegue escrever esse código" para "a pessoa entende o código que está entrando no sistema". Um candidato fraco aceita sugestões em silêncio e torce para funcionar. Um candidato forte narra decisões o tempo todo, questiona o agente, e às vezes reescreve manualmente um trecho que o agente sugeriu porque "isso vai gerar N+1 query lá na frente".

Outro formato poderoso é o code review de um PR real, com bugs plantados de propósito — incluindo alguns que são exatamente o tipo de erro que agentes de IA cometem com frequência: nomes de variáveis reaproveitados incorretamente, tratamento de erro genérico demais (aquele catch que engole a exceção), ou uma função que parece genérica mas na verdade só cobre o caso feliz. Pedir para o candidato revisar esse PR como se fosse revisão de um colega de time testa exatamente a habilidade que mais importa hoje: ler código criticamente, não escrevê-lo.

Por fim, uma pergunta simples e direta que revela muito: "me conta uma vez em que um agente de IA sugeriu algo e você discordou, ou corrigiu depois." Peça exemplo real, com detalhe técnico. Quem trabalha de verdade com esses agentes tem uma resposta na ponta da língua, geralmente cheia de nuance. Quem nunca questionou uma sugestão de IA — ou usa agentes de forma passiva — hesita, generaliza, ou conta uma história vaga que não tem substância técnica nenhuma.

---

O que descartar de vez

A tentação mais comum de quem lidera contratação é simplesmente proibir IA durante a entrevista, como se isso resolvesse o problema. Não resolve. Primeiro porque é praticamente impossível de fiscalizar numa entrevista remota — e mesmo presencial, boa parte dos modelos hoje roda embutido no editor sem nenhum indício visual óbvio. Segundo, e mais importante, porque proibir IA testa uma habilidade que não existe mais no trabalho real. Ninguém no time do candidato, se ele for contratado, vai programar sem IA no dia a dia. A grande maioria dos times de engenharia já trabalha assim, e simular um ambiente artificial "sem ferramentas" só mede quem decorou mais sintaxe, não quem entrega mais valor.

Da mesma forma, vale descartar o take-home assignment tradicional de tamanho médio sem contexto de acompanhamento. Ele virou um teste de "quem tem mais tempo livre e melhor acesso a um bom modelo", não um teste de competência. Se for manter algum tipo de exercício assíncrono, ele precisa vir acompanhado de uma sessão de discussão ao vivo depois, onde o candidato defende as decisões que tomou — inclusive as decisões que a IA tomou por ele e que ele aceitou sem questionar.

Também vale abandonar a ideia de que "resolver rápido" é sinal de competência. Com um agente, resolver rápido é fácil para qualquer um. O que separa as pessoas é a qualidade do julgamento por trás da velocidade.

---

Um mini-roteiro de entrevista adaptado

Para tornar isso mais concreto, um roteiro de noventa minutos que tenho aplicado e recomendado:

Primeiros 10 minutos: contexto e alinhamento de expectativas. Deixe explícito que o uso de IA é bem-vindo e esperado, e que o foco da avaliação é o processo de decisão, não a velocidade de digitação.

30 minutos — pair programming com IA liberada: um problema de tamanho médio, ligeiramente subespecificado de propósito (força o candidato a fazer perguntas de esclarecimento, algo que agentes não fazem sozinhos). Peça para narrar cada aceite ou rejeição de sugestão do agente.

25 minutos — code review de PR com bugs plantados: inclua pelo menos um bug de padrão típico de IA (tratamento de erro genérico, função que ignora um caso de borda óbvio, nome de variável reaproveitado). Avalie o que o candidato encontra e como prioriza os achados.

15 minutos — pergunta comportamental técnica: "me dê um exemplo real de quando você discordou de uma sugestão de um agente" e "conta uma vez que confiar demais numa sugestão de IA custou caro pro seu time." Aqui é onde a experiência real se separa da encenação.

10 minutos finais: espaço para o candidato perguntar sobre como o time usa IA no dia a dia — isso também revela maturidade, porque quem já pensou sobre orquestrar agentes no trabalho, como discuti no post sobre a carreira de dev como orquestrador de agentes, costuma fazer perguntas mais afiadas sobre processo, revisão e responsabilidade do que sobre stack tecnológica.

---

Conclusão

A conclusão incômoda é que, quando todo mundo tem acesso à mesma ferramenta, o diferencial de senioridade real fica mais difícil de enxergar à primeira vista — mas não desaparece, só se desloca. Ele deixa de estar em "consegue escrever esse código" e passa a estar em "sabe o que perguntar ao agente, sabe quando parar de confiar nele, e sabe explicar por que a resposta que recebeu está certa ou errada para aquele contexto específico". Isso é mais difícil de medir do que um algoritmo de quadro branco, mas é infinitamente mais próximo do que a pessoa vai realmente fazer no time.

Se você lidera contratação técnica, o trabalho de casa não é encontrar um jeito de bloquear IA na entrevista. É redesenhar o exercício para que o uso de IA seja parte do teste, e a avaliação recaia sobre o julgamento, a comunicação e o ceticismo saudável do candidato. Isso exige mais preparo de quem entrevista, mas é o único jeito de contratar com confiança num mundo onde o código, sozinho, já não diz muita coisa sobre quem o escreveu. Vale trazer os próprios engenheiros seniores do time para ajudar a desenhar os bugs plantados e validar se o roteiro reflete o trabalho real — porque é esse time que vai conviver com a decisão de contratação por muito tempo depois que a entrevista terminar.

---

Fontes:

• LeadDev — Rethinking technical interviews for the AI era
• The Pragmatic Engineer — How AI coding tools are reshaping hiring
• Stack Overflow Blog — Interviewing developers when everyone codes with AI