Esta semana entrevistei dez desenvolvedores. Não contratei nenhum
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.
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.