Currículo polido, teste automático e agente de código aberto na outra aba mudaram o começo do funil. O que não mudou foi a parte cara: descobrir se a pessoa realmente entende sistema, toma boa decisão e consegue explicar o que está fazendo sem se esconder atrás da ferramenta.
Esse deslocamento apareceu de forma bem clara num Ask HN recente sobre como as empresas estão entrevistando engenheiros na era agentic. Em vez de falar em “proibir IA” ou voltar para o leetcode por reflexo, o fio puxou outra direção: entrevistas mais práticas, mais contextualizadas e menos dependentes de memorização.
O ponto faz sentido porque a pressão já mudou dentro do próprio trabalho. A Stack Overflow resumiu isso bem ao mostrar que agentes de código aceleraram a produção, mas empurraram mais carga para revisão, julgamento e contexto. Quando o código nasce mais rápido, a parte difícil deixa de ser digitar e passa a ser aprovar, manter e entender impacto.
O teste de verdade ficou mais perto do trabalho real
No fio do Hacker News, uma resposta resume a virada melhor do que muita tese pronta: em vez de leetcode ou decoreba acadêmica, faz mais sentido testar conhecimento de sistemas, trade-offs e raciocínio de projeto.
É uma mudança importante porque o mercado está começando a separar duas coisas que pareciam iguais no hype inicial:
- usar IA para ganhar velocidade;
- depender dela para mascarar entendimento fraco.
Quando o entrevistador pede opinião sobre API vs. fila, orquestração, tipagem estática vs. dinâmica ou prós e contras de JWT, ele não está procurando uma resposta perfeita de manual. Está tentando ver repertório, limite, clareza e maturidade técnica.
Isso vale ainda mais quando o código agora pode sair pronto demais cedo demais.
A nova entrevista quer contexto, não performance de palco
Outro comentário do mesmo fio mostrou um formato ainda mais revelador: empresas pedindo para o candidato usar Claude Code para entender uma base, explicar um bug ou apontar a causa provável de um problema.
Esse tipo de teste é mais justo do que parece.
Ele não mede só se a pessoa sabe “usar IA”. Mede se ela sabe:
- dar contexto suficiente;
- desconfiar da primeira resposta;
- navegar numa base que não escreveu;
- transformar saída de ferramenta em explicação humana.
No trabalho real, é exatamente isso que está acontecendo. O engenheiro não é mais avaliado só pelo quanto escreve na mão. Ele é cobrado pelo quanto consegue reduzir ambiguidade, revisar com critério e tomar decisão boa com mais velocidade ao redor.
O gargalo saiu da digitação e foi para o julgamento
Esse é o pedaço que muita empresa ainda não encaixou no processo seletivo.
Na reportagem da Stack Overflow sobre decision fatigue, a tese central é simples: a IA aumentou a densidade do trabalho. O dia não ficou maior, mas ficou cheio de mais revisão, mais contexto e mais microdecisões. Em vez de aliviar tudo, o fluxo novo deslocou o peso para quem aprova, integra e responde pelo resultado final.
Se o trabalho mudou desse jeito, a entrevista técnica também precisa mudar.
Ficar preso em teste artificial, pergunta descolada da vaga ou live coding ansioso demais pode filtrar gente boa pelo motivo errado. O que começa a importar mais agora é a capacidade de:
- explicar escolha técnica;
- ler código que veio de outro lugar;
- identificar risco de manutenção;
- manter padrão num código que pode ter sido acelerado por agentes.
O RH não precisa virar engenheiro para melhorar o filtro
A GeekHunter bateu num ponto útil para o mercado brasileiro: avaliação técnica boa não depende de improviso. Depende de critério claro, roteiro e prova compatível com a vaga.
Isso continua valendo na era dos agentes, com um detalhe extra: ficou mais perigoso confundir velocidade de resposta com profundidade real.
Se a empresa quer contratar melhor, a régua precisa sair do “parece bom ao vivo” e ir para perguntas e exercícios que revelem como a pessoa pensa. Portfólio, revisão de solução, bug realista, trade-offs de arquitetura e explicação de decisões tendem a dizer mais do que um teatro de pressão de 40 minutos.
Para o candidato, isso também muda a preparação. Não basta decorar framework, lista de perguntas ou prompt bonito. O diferencial começa a aparecer quando você consegue:
- justificar por que escolheu um caminho;
- mostrar onde a IA acelerou e onde você precisou frear;
- explicar limitações, não só acertos;
- falar de manutenção, teste e impacto, não só de entrega rápida.
O problema não é usar agente na entrevista
O problema é usar mal.
Se a empresa libera agente sem contexto, ela pode premiar quem só sabe operar interface. Se proíbe tudo e volta para prova irreconhecível do trabalho real, também erra a mão. O caminho mais promissor parece estar no meio: deixar a ferramenta aparecer, mas exigir leitura crítica, explicação e responsabilidade sobre a resposta.
É aí que a entrevista volta a parecer trabalho de verdade.
No fim, a régua boa de 2026 não está em descobrir quem programa “sem ajuda”. Está em descobrir quem consegue produzir com ajuda sem terceirizar o próprio julgamento. E isso, para muita vaga de TI, vale mais do que qualquer performance de decoreba.
Fontes
- Ask HN: How are you interviewing engineers in this agentic era?
- Coding agents are giving everyone decision fatigue
- Building shared coding guidelines for AI (and people too)
- Avaliação técnica: o que é, como aplicar e como garantir contratações mais assertivas em TI
- Preparação para entrevistas de emprego: Como recrutadores podem melhorar o processo seletivo
