--- title: "Esta semana entrevistei dez desenvolvedores. Não contratei nenhum" url: "https://www.mikefluff.com/pt/blog/hiring-after-ai" locale: "pt" author: "Mike Fluff" updated: "2026-08-05" description: "Seis resolveram o live-coding perfeito. Quatro desses seis dez minutos depois não explicaram o próprio código. Como eu faço entrevista agora — e por que o filtro antigo não filtra mais." tags: - "hiring" - "team" - "ai" alternates: - locale: "en" url: "https://www.mikefluff.com/en/blog/hiring-after-ai" markdown: "https://www.mikefluff.com/en/blog/hiring-after-ai.md" - locale: "ru" url: "https://www.mikefluff.com/ru/blog/hiring-after-ai" markdown: "https://www.mikefluff.com/ru/blog/hiring-after-ai.md" - locale: "pt" url: "https://www.mikefluff.com/pt/blog/hiring-after-ai" markdown: "https://www.mikefluff.com/pt/blog/hiring-after-ai.md" - locale: "es" url: "https://www.mikefluff.com/es/blog/hiring-after-ai" markdown: "https://www.mikefluff.com/es/blog/hiring-after-ai.md" --- # Esta semana entrevistei dez desenvolvedores. Não contratei nenhum > **Em resumo:** Com um modelo de IA na aba ao lado, live-coding e algoritmos deixaram de separar candidatos. Seis de dez resolveram a tarefa, e quatro deles não explicaram o próprio código. Agora uso problemas reais com trade-offs, mudo as restrições no meio da conversa e peço para melhorar código existente. Formular o problema, gosto arquitetural e contexto de negócio valem mais. Ontem entrevistei dez desenvolvedores. Não contratei nenhum. Era um daqueles projetos em que o cliente pede "me ajuda com a contratação" e você acaba sentado seis horas no Zoom vendo passarem senior backends, um mais ideal que o outro. Pra coisa não parar, rodei um formato de "três reuniões de manhã com intervalo pra café, mais três no almoço". Na quinta à noite tinha dez reuniões, dez fichas no Airtable e uma sensação teimosa de estar fazendo alguma coisa errada. Seis de dez resolveram o live-coding perfeito. Quatro desses seis, dez minutos depois, não conseguiram explicar **o próprio código**. "Ah… porque é padrão assim" — citação direta. Como justificativa para ter escolhido aquela estrutura de dados. Fechei a última ligação. Anotei "não" no tracker. Escrevi pro RH que seguimos buscando. E fiquei olhando para o meu café, que, reparei só então, estava frio havia umas duas horas. (Pensamento à parte — por que em 2026, com IA cuidando do meu e-mail, do calendário e às vezes respondendo por mim para vendas, eu ainda não tenho solução pra "café tem que ficar quente por quatro horas de entrevista". Pelo visto é uma daquelas tarefas que parecem bobas à primeira vista e ficam muito mais bobas quando a gente tenta pensar direito nelas.) --- Cinco anos atrás entrevista de dev era simples. Algoritmo de dificuldade média (algo com grafos, por exemplo — todo mundo sempre amou algoritmos com grafos). Case de arquitetura. Perguntas sobre SQL, cache, diferença entre CTE e subquery (que, honestamente, eu pesquiso todas as vezes). Em quarenta minutos dava pra montar um quadro aproximado. O filtro funcionava sobre **conhecimento mecânico**. Lembra a estrutura de um B-tree. Monta uma fila de prioridade em dez minutos. Explica dois-fases-commit sem dizer, em tom ofendido, "bom, essa é uma pergunta bem profunda". Em 2026 esse filtro quebrou. Não porque devs pioraram. Porque **todo mundo tem claude.ai na aba ao lado**. Qualquer aluno do segundo ano, com dois cliques, resolve o algoritmo médio em oito minutos. Não porque sabe — porque **sabe perguntar**. E o modelo devolve não só o código, mas o comentário pronto — como se fossem pensamentos dele. Não é fraude. Pelo menos não do tipo que era o diploma plagiado em 1998. Provavelmente esse mesmo candidato vai usar o modelo no trabalho também. E tudo bem — eu uso assim. O problema não é ele usar a ferramenta. O problema é que **eu estava filtrando o skill errado**. --- A segunda e a terceira entrevista daquele dia rolaram no modo "não entendo o que está acontecendo". O candidato resolveu a task em doze minutos, e a solução era… boa. Honestamente boa. Estrutura certa, casos de borda tratados, nomes de variáveis legíveis. Eu já escrevi pior na minha prática. Na quarta entrevista mudei a abordagem. O candidato escreveu a solução. Fechei a IDE. Conversamos uns cinco minutos sobre outra coisa — lembro que discutimos se Lisboa está mais barata que Barcelona agora (spoiler: não mais). Voltei ao código. Perguntei: — Por que você escolheu esse tipo de coleção em particular? — Eh… porque… é padrão. — E se N for dez milhões? — Bom, funciona igual. — O que muda se você trocar essa linha por essa outra? Pausa. Longa. Essa pausa — é agora o sinal mais honesto que consigo coletar em quarenta minutos. Porque **explicação não é lembrança**. Não dá pra pesquisar na aba ao lado enquanto estou falando. Ou se enxerga, ou não. Um modelo escreve código. Não explica esse código como sendo **seu próprio** se o seu próprio não existe. --- A partir desse momento refiz o formato inteiro. Ficou mais ou menos assim. Eu ainda dou task. Mas não LeetCode. Agora escolho algo de um problema real com que mexi um mês atrás — com contexto, com restrição, com indício de trade-off. Algo do tipo: "tem três opções de arquitetura, escolhe e explica". Não "implementa uma fila de prioridade". Porque **trabalho real é trade-off**, não LeetCode. O modelo também raciocina sobre trade-off. Mas **tira média**. Escolhe "o que a indústria faz", "o que é best practice". Candidato forte escolhe diferente, porque vê a nuance. Candidato fraco mais modelo escolhe pelo livro. E quando, no meio da conversa, eu jogo uma pedra no lago — "e se para vocês o que conta não é velocidade de escrita e sim de leitura no horário X, quando todo mundo sincroniza?" — o fraco trava, o forte reconfigura. Mais difícil forjar via chat, porque eu **quebro o ritmo**. Adiciono restrição, ajusto o contexto, mudo a pergunta. Cada ajuste tem que aparecer na resposta. Candidato com modelo na segunda aba não acompanha. Acrescentei também a pergunta sobre erro. Não o genérico "me conta um ponto fraco seu" — o concreto. "Me conta de uma decisão técnica que você tomou e se arrependeu. O que tirou dali?" Funcionário forte lembra dos detalhes: aquele projeto, aquele banco, aquela história de três dias atrás de uma memory leak que, no fim, estava numa biblioteca infeliz que ninguém suspeitava. Fraco — responde em generalidade. Ou parafraseia caso de Medium que eu já li. E, por último, parei com live-coding puro. O formato "escreva do zero" eu praticamente não uso mais. No lugar — "aqui tem um trecho existente, bora melhorar junto". Bem mais difícil de forjar via IA, porque o ritmo sou eu, o foco sou eu, e os ajustes aparecem em tempo real. O candidato tem que **pensar**, não gerar. --- O que **deixou de importar** — acho óbvio, mas vou dizer claro. Velocidade de escrever código não filtra. Hoje é igual pra todo mundo, porque é propriedade do modelo. Certificados — "assisti 20 minutos de vídeo e cliquei num botão", 2026. Portfólio no GitHub — também não é garantia, porque metade dos commits é gerada, e a outra metade, honestamente, também. O que **ficou mais caro**: Formular o problema. Metade do trabalho é traduzir "quero que funcione" em spec. Na era da IA esse skill passou a valer mais que o código. Sem ele, a pessoa com modelo produz um monte de bonito não-funcional. Gosto arquitetural. O modelo oferece três opções. A pessoa forte **sabe qual encaixa aqui e por quê**. Isso não cabe em prompt, porque se forma em anos de "a gente tentou desse jeito e deu ruim no terceiro mês". Contexto de negócio. "Por que a gente faz X e não Y". É a parte que o modelo não pega nem com RAG, porque não está em nenhuma fonte pública. Está na cabeça das pessoas que seis vezes viram uma venda específica cair no mesmo ponto. --- Na sexta-feira entreguei o relatório pro cliente. Não contratei ninguém. Recomendei refazer o formato — não procurar o sênior que resolve o algoritmo perfeito, mas alguém que consegue explicar código alheio passo a passo. Esse, curiosamente, é em 2026 um skill raro e bem mais caro. O cliente aceitou. Reescrevemos a vaga. A primeira entrevista depois disso — uma mulher que não se apressava, fazia perguntas de volta, uma vez disse abertamente "não sei", e depois foi investigar no Google no modo "me mostra a bagunça, eu desembaraço". Contratamos. Ela está lá há três meses, e o projeto ficou **diagnosticamente melhor**. Bons candidatos em 2026 não são os que decoraram APIs — são os que **pensam sistemicamente e sabem usar a ferramenta**. Filtrar por "ele escreve código" agora é entrevistar carpinteiro pra saber se consegue levantar o martelo. Claro que consegue. Todo mundo consegue. Martelo hoje vende em qualquer supermercado. Pergunta o que ele vai construir com ele. **[Curso sobre parasitas no time](https://www.mikefluff.com/pt/parasites-course)** — Inclui: como identificar quem 'se esforça' sem entregar, e como proteger o time. 7 módulos, $19.