Tem muita discussão sobre IA em desenvolvimento que fica presa em ferramenta. Qual editor, qual modelo, qual agente, qual benchmark.
O que fez um debate recente no Hacker News valer a pauta foi outra coisa: ele foi direto na parte desconfortável. Se o trabalho real mudou com ajuda de IA, a entrevista técnica também precisa mudar. Mas mudar para quê?
A pergunta apareceu depois que um post de contratação da HackerRank descreveu um novo pacote de avaliação: tarefas em repositórios reais, fluência com IA em vez de correção pura e uma experiência de entrevista mais próxima de IDE agentic do que de editor cru. A reação foi imediata. Um gerente perguntou em voz alta como ainda dá para identificar gente boa quando a ferramenta muda todo mês e parte do resultado já vem acelerada por modelo.
O valor do fio está justamente em não tratar isso como detalhe operacional. A comunidade discutiu quais sinais ainda importam quando gerar código ficou mais fácil, quando brute force com agente já entra no fluxo e quando uma entrevista aberta demais pode acabar medindo familiaridade com um produto específico — e não julgamento técnico de verdade.
O gatilho do debate
O post da HackerRank resume bem o espírito do momento. A empresa diz que o trabalho de dev está virando cada vez mais um papel de orquestração de agentes e afirma que já está ajudando clientes a repensar seleção técnica em três frentes: tipo de tarefa, critério de avaliação e ambiente de execução.
No papel, faz sentido. Se o trabalho do dia a dia não parece mais uma prova estilo LeetCode isolada, muita empresa acha natural aproximar entrevista de repositório real, contexto real e uso real de IA.
O problema é que isso abre uma dúvida nova. Se você libera ferramentas demais, talvez a avaliação comece a capturar menos engenharia e mais intimidade com hacks de ferramenta, gasto de token e repertório de prompt.
Foi exatamente aí que a discussão no Hacker News ficou boa.
O primeiro alerta: entrevista com IA pode inverter o sinal
Um dos comentários mais fortes veio de um gerente que relatou ter visto várias empresas irem fundo em entrevistas com IA assistida e depois voltarem atrás. O motivo não foi saudosismo nem apego automático a processo antigo.
Segundo esse relato, a entrevista aberta demais começou a produzir sinal invertido. Quem parecia melhor nem sempre era quem entendia melhor o problema, mas quem dominava melhor os truques da ferramenta específica usada no teste. Em vez de clareza de raciocínio, apareciam candidatos tentando brute force com subagentes paralelos, gastando contexto e ficha de modelo para cercar o problema até alguma solução sair.
Esse ponto é importante porque ele separa duas habilidades diferentes:
- usar IA como extensão de trabalho;
- terceirizar o pensamento para a interface que estiver disponível.
Para a comunidade, tratar isso como a mesma coisa é um erro de contratação.
O que a discussão sugeriu medir no lugar
O consenso do fio não foi “voltar ao quadro branco” nem “proibir IA para sempre”. O que apareceu com mais força foi uma mudança de foco.
Em vez de medir só produção de código do zero, vários comentários puxaram a entrevista para um tipo de trabalho que já ficou comum no dia a dia: receber código gerado ou acelerado por IA e julgar o que está certo, o que está sobrando, o que está faltando e quais trade-offs foram empurrados para baixo do tapete.
Teve gente defendendo preparar um trecho de código gerado por IA a partir de um requisito propositalmente meio vago. A partir daí, o candidato não precisa “vencer” a máquina. Precisa mostrar se consegue:
- delimitar o problema;
- revisar o que a IA produziu;
- apontar excesso, fragilidade e ausência;
- explicar trade-offs;
- limpar o que ficou convincente na superfície, mas fraco por dentro.
Esse deslocamento faz sentido porque conversa melhor com o trabalho real. Em muito time, o gargalo já não é abrir arquivo vazio e digitar tudo manualmente. É saber se a resposta acelerada pode entrar num sistema vivo sem cobrar a conta depois.
Fluência com IA não apareceu como atalho para fundamento
Outro ponto recorrente no debate foi a ideia de que IA amplifica mais do que substitui. Em bom português: profissional forte tende a usar melhor a ferramenta porque sabe pedir, revisar, desconfiar e corrigir. Profissional fraco consegue produzir mais volume, mas nem sempre percebe quando entregou “AI slop” com cara de solução elegante.
Esse pedaço apareceu de formas diferentes nos comentários, mas a essência foi parecida. O que continua valendo como sinal de engenharia não é só chegar a uma resposta. É conseguir defender por que ela presta, onde ela quebra e o que foi sacrificado para ganhar velocidade.
Por isso, a comunidade não tratou “AI fluency” como uma nova versão chique de prompt engineering. O termo foi puxado para algo mais concreto: saber escopar tarefa, orientar ferramenta, revisar saída e assumir responsabilidade pelo resultado final.
O que ainda ficou de pé como sinal forte
Mesmo num debate bastante focado em IA, alguns critérios clássicos continuaram aparecendo com força.
O primeiro foi curiosidade aplicada. Um comentário resumiu bem: com a barreira de construir tão baixa quanto hoje, GitHub morto e ausência total de projetos laterais começam a soar mais como desinteresse do que falta de oportunidade. Não porque side project prove tudo, mas porque ele ajuda a mostrar iniciativa, repertório e vontade real de explorar tecnologia fora do script mínimo.
O segundo foi capacidade de conversar sobre o que construiu. Em vez de só resolver puzzle, vários participantes preferiram ver candidato explicando sistema real, escolha técnica, limite assumido, erro corrigido e trade-off enfrentado.
O terceiro foi fundamento suficiente para perceber quando a IA errou com confiança. Esse talvez tenha sido o ponto mais repetido do fio inteiro.
O que isso revela para quem está contratando
A parte mais útil do debate não é uma receita fechada. É o mapa do erro que muita empresa corre risco de cometer agora.
Se a entrevista continuar presa no formato antigo, ela pode medir uma habilidade cada vez mais periférica para certos times. Mas se ela liberar IA sem desenho nenhum, pode acabar premiando só quem sabe operar uma ferramenta específica sob alta combustão.
O meio-termo que apareceu com mais maturidade foi este:
- 1. aproximar a tarefa do trabalho real;
- 2. limitar o ambiente o suficiente para evitar brute force cego;
- 3. avaliar revisão, julgamento e explicação, não só output bruto;
- 4. observar se a pessoa entende o sistema que está mexendo, e não apenas o atalho.
Na prática, isso parece mais difícil de aplicar do que simplesmente mandar um desafio ou liberar um agente e “ver no que dá”. Mas talvez seja justamente esse o ponto: contratar bem ficou menos automático.
O recado útil para quem está do lado do candidato
Para quem está buscando vaga, o fio também deixa um aviso claro. Não basta dizer que usa IA no fluxo. O mercado parece começar a valorizar melhor quem consegue mostrar como usa.
Isso inclui saber explicar quando a ferramenta ajudou, onde ela atrapalhou, que decisão continuou humana e que erro você conseguiu evitar porque conhecia o problema por baixo da interface.
Se a entrevista técnica está mudando, o sinal que parece sobreviver não é pose de “vibe coder” nem nostalgia de pureza manual. É algo menos chamativo e mais valioso: discernimento.
No fim, o debate do Hacker News não diz que entrevista com IA é inútil. Diz que, se ela for mal desenhada, vira só um campeonato de ferramenta. E empresa nenhuma quer descobrir tarde demais que contratou a pessoa que parecia mais rápida — quando na verdade ela só era a mais eficiente em terceirizar o raciocínio.
