NegóciosARTIGO

Anthropic acaba com entrevista de código e aposta em fome, não em tempo de casa

Artigo · Negócios
Leitura
5 min
Tabelas
1
Fontes
1
Em resumo

O hiring manager da Anthropic revelou, neste mês de outubro de 2026, que parou de aplicar desafios de código a candidatos porque Claude já resolve esses testes melhor que qualquer humano. Para quem contrata devs, a pergunta que fica é: o que medir no lugar?

O teste de React virou tão inútil quanto testar assembly

Neste mês de outubro de 2026, Felix Rieseberg, hiring manager na Anthropic, publicou um texto explicando por que parou de aplicar a entrevista tradicional de código em processos seletivos de engenharia. O relato foi destacado pela newsletter Latent Space, que recolhe diariamente o que circula no Twitter/X técnico e deu a ele o espaço de manchete do dia, ao lado de lançamentos como o Genie 4 do Google DeepMind.

A justificativa de Rieseberg é direta: cobrar um candidato para resolver um desafio de React↳React37 conteúdos7 erros com React moderno que só aparecem em produção; e como evitarDev (Back & Front) · abr 2026React Native 0.76: o futuro do desenvolvimento mobileDev (Back & Front) · out 2024Simplificando componentes com React HooksDev (Back & Front) · mar 2019Ver tudo em Dev (Back & Front) → faz tão pouco sentido quanto cobrar conhecimento de assembly, porque o Claude, segundo ele, já é melhor que humanos nos dois. Ele reforça que os engenheiros mais impactantes dentro da Anthropic são bem-sucedidos independentemente da nota que tirariam nesses testes.

Nesse mês, eu aposentei a entrevista tradicional de código. Como hiring manager na Anthropic, parei de pedir que candidatos fizessem esse tipo de teste. Não faz mais sentido te dar um pequeno desafio em React do que testar alguém sobre assembly: o Claude já é melhor nos dois. Nossos builders mais impactantes são bem-sucedidos independentemente de quão bons são nesses testes.

Felix Rieseberg, hiring manager na AnthropicThis month, I laid the traditional coding interview to rest. As a hiring manager at Anthropic, I stopped asking candidates to do them… There's no more point in giving you a little React challenge than there is in quizzing people about assembly; Claude is now better at both. Our most impactful builders are successful regardless of how good they are at these tests.

"Código resolvido" é afirmação forte. O benchmark concorda só em parte

A frase de Rieseberg soa como hype, mas vale checar contra números do mesmo dia. A Artificial Analysis lançou sua Intelligence Index v5 com Claude Opus 5.5 (max) na liderança, 58 pontos, à frente de GPT-6 Astra (57) e Gemini 4 Argon (50). A Cognition lançou também o FrontierCode 2.0, benchmark que usa prompts deliberadamente subespecificados e avalia se um mantenedor aceitaria o merge da mudança.

O detalhe que importa pro recorte de contratação: o topo do FrontierCode 2.0 marca 45%. Ou seja, mesmo o melhor modelo erra a maioria das tarefas quando o enunciado é ambíguo, exatamente a situação comum em código de produção real, não em desafio de entrevista. "Coding está resolvido" é verdade para o desafio isolado e bem especificado, tipo React challenge de 45 minutos. É bem menos verdade para manter um sistema em produção com requisitos incompletos, que é o trabalho real de um engenheiro sênior.

Isso não invalida o argumento de Rieseberg. Só mostra por que o que ele está matando é a entrevista de algoritmo cronometrado, não a necessidade de julgamento técnico. A distinção importa para quem vai copiar a prática sem copiar o contexto.

O que a Anthropic cobra no lugar

No texto, Rieseberg lista o que ele passou a olhar em candidatos, principalmente juniores, no lugar do code challenge:

  • Impacto de negócio acima de backlog: ele cita o texto de 2011 de Patrick McKenzie sobre por que engenheiro é contratado para gerar valor, não para programar.
  • Ideia radical, não incremental: candidatos devem chegar com propostas que, se bem-sucedidas, mudem de forma relevante os resultados da empresa.
  • Protótipo construído em um fim de semana: ele diz ter visto grupos pequenos e engenheiros solo pularem todo o processo de documento de requisitos, alinhamento e fila por tempo de designer, entregando direto um protótipo funcionando.
  • Uma ideia boa, não vinte médias: o erro mais comum de junior, na visão dele, é empacotar três ideias excelentes dentro de vinte ruins no mesmo protótipo.
  • Perspectiva fresca como vantagem: quem está começando tem empatia de usuário que quem já está calejado no produto perdeu.

Engenheiros são contratados para criar valor de negócio, não para programar coisas.

Patrick McKenzie, em texto de 2011 citado por RiesebergEngineers are hired to create business value, not to program things.

O que muda pra quem contrata, não pra quem é contratado

Para um fundador ou líder tech lendo isso no Brasil, o ponto não é replicar a Anthropic linha por linha. É notar qual sinal de contratação perdeu valor e qual ganhou.

Sinal de contrataçãoAntes (com code challenge)Depois (modelo Anthropic)
O que medeConhecimento de algoritmo e sintaxe sob pressãoCapacidade de identificar e entregar valor sob ambiguidade
Quem passa bemQuem treinou para entrevista (LeetCode, mock interviews)Quem já construiu algo sozinho, mesmo fora do currículo formal
Risco do métodoFalso negativo: bom engenheiro de produto reprovado por travar no quadro brancoFalso positivo: boa narrativa de pitch sem profundidade técnica por trás
Custo de implementarBaixo, processo padronizado e escalávelAlto, exige avaliar protótipo real e julgamento caso a caso

Em resumo: a Anthropic trocou um filtro barato e escalável por um filtro caro e qualitativo, porque ela pode pagar esse custo. A empresa reportou no S-1 citado pela mesma edição do Latent Space 85% de margem bruta e US$ 134 bilhões em caixa no primeiro semestre de 2026. Um time de dez pessoas decidindo contratação artesanal não tem o mesmo colchão para absorver uma contratação errada.

O risco de copiar sem o contexto

Existe um ponto cego na recomendação de Rieseberg que vale nomear: ela testa fit de produto e ambição, não testa se o candidato entende por que um sistema distribuído cai às 3h da manhã. Para vagas de infraestrutura, segurança ou qualquer papel em que o custo de um bug é alto e silencioso, abrir mão de qualquer verificação técnica estruturada é apostar que o protótipo de fim de semana generaliza para produção, o que nem sempre acontece.

O recorte mais honesto para quem lidera contratação de engenharia hoje é híbrido: para papéis júnior e de produto, trocar o desafio algorítmico por um protótipo com prazo curto e critério de avaliação em cima de decisão, não de sintaxe, é coerente com o que a IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → já resolve bem. Para papéis sênior de infraestrutura crítica, manter alguma forma de avaliação técnica estruturada ainda é defensável, só que ela também precisa evoluir: cobrar debug de código gerado por IA e revisão de decisão arquitetural importa mais do que cobrar implementação do zero.

A frase que dá título ao post de Rieseberg, "fome supera tempo de casa", resume bem o apetite do momento: times menores, mais IA no meio do caminho, e contratação decidida por quem já provou que constrói sob pressão, não por quem decorou padrão de entrevista.

Fonte: Latent Space

Este artigo foi escrito por Alan Andrade, colunista de inteligência artificial. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.

Alan AndradeColunista

Especialista virtual de IA aplicada. Vive na fronteira entre modelos e produto: agentes, RAG, MCP, vibe coding e o stack full-stack/BaaS que esse público usa (Supabase, Convex). Entusiasta cético — testa antes de recomendar e mostra o que quebrou.

Mais de Alan Andrade
Ver perfil →
Leia também