O sinal que já não mede nada
Imagine a entrevista clássica de software, do jeito que rodou milhões de vezes. Um quadro branco ou um editor compartilhado, um problema com um toque algorítmico caprichado, um cronômetro correndo. Pede-se à candidata que digite, sob observação, uma função que inverte um array, inverte uma árvore, encontra o caminho mais curto. O que se avalia é a rapidez e a limpeza com que ela sai do arquivo em branco até a solução funcionando. Durante décadas isso foi um sinal razoável: quem fazia aquilo com fluência costumava produzir código no trabalho também.
Esse mesmo sinal, hoje, mede a coisa errada. Quando um modelo escreve a maior parte do código – e em muitos times ele já escreve –, "digitar código limpo rápido de cabeça" deixou de ser a habilidade escassa. Virou o ingrediente mais barato de todo o processo. O que continuou escasso é justamente o que a entrevista clássica nunca testa: discernimento. Ler, decompor, verificar – e, acima de tudo, saber o que construir em primeiro lugar.
Ou seja: seguimos contratando com base num sinal que mede uma habilidade que a ferramenta do outro lado da mesa domina melhor do que qualquer candidato. Isso não é um pequeno problema de calibragem. É um instrumento quebrado.
Por que a entrevista clássica quebra
Vamos começar pela verdade incômoda: LeetCode e HackerRank são triviais de resolver com IA. Não "com esforço", não "nos problemas fáceis" – triviais. O gênero inteiro das perguntas-quebra-cabeça algorítmicas, o nível hard incluído, é exatamente o tipo de artesanato bem delimitado, presente milhões de vezes no material de treino, em que os modelos são excelentes. Um modelo atual resolve o problema mediano de entrevista de forma correta, comentado, com tempo de execução ótimo, em segundos. Um teste cujas questões a ferramenta mais barata da sala resolve sem erro não mede mais o talento do humano. No melhor dos casos, mede se o humano decorou a capacidade da ferramenta.
Com isso cai a suposição tácita sobre a qual o formato inteiro se apoiava: a de que velocidade de codificação é o gargalo. Foi, por muito tempo. Quem digitava código limpo mais rápido entregava mais rápido, e a entrevista era um proxy razoável disso. Só que o gargalo se deslocou. Produção não é mais o estrangulamento – é abundante, rápida, barata. O que trava um time não é mais a rapidez com que alguém escreve a primeira versão, e sim se alguém percebe que essa versão faz a coisa errada, contém um buraco de segurança ou resolve um problema que ninguém tinha.
E piora: a entrevista clássica premia ativamente o instinto errado. Ela recompensa o reflexo de sair digitando na hora – "me mostre que você produz código". Na era da IA, esse reflexo é um antipadrão. O primeiro movimento valioso não é a digitação, e sim a pausa: interrogar a tarefa, cutucar as bordas, decidir se o problema está sequer formulado corretamente. Um processo que recompensa gente por pular esse passo seleciona a mentalidade errada.
E o ritual do quadro branco sempre testou uma habilidade que quase não aparece no trabalho real: produção impecável do nada, sem consultar nada, sem iterar, sem as ferramentas que você usa de fato todo dia. Essa artificialidade já foi um compromisso perdoável. Hoje é absurda: proibimos a candidata justamente da ferramenta com que ela vai realmente fazer o trabalho, e depois a avaliamos numa disciplina que essa ferramenta já assumiu.
Para que contratar em vez disso
Quando digitar fica barato, o valor de uma pessoa se desloca para tudo o que cerca a digitação. Não a capacidade de produzir código, mas a capacidade de reger, escrutinar e responder pelo código produzido. Concretamente, isso se resume a um punhado de qualidades que a entrevista clássica nunca testou a sério:
- Bom gosto. A capacidade de enxergar, entre duas soluções que funcionam, qual é a melhor – a mais simples, a mais robusta, a que o time ainda vai entender daqui a dois anos. Bom gosto não é luxo; é o filtro que separa um fluxo de código gerado do lixo.
- Pensamento sistêmico. Modelos constroem coisas localmente sensatas e globalmente inconsistentes. Contrabandeiam um segundo padrão, concorrente, sem perceber. O que se busca ao contratar é a pessoa que enxerga como uma mudança se encaixa no todo – ou não.
- Revisar código gerado sem piedade. A habilidade central. Ler código plausível, de aparência limpa, confiantemente errado, e achar a falha sutil: o caso de borda nunca tratado, a chamada de API inventada, a suposição silenciosa que não se sustenta.
- Depurar código quebrado dos outros. Não o seu próprio código recém-escrito, mas um sistema que outra pessoa – ou outra coisa – construiu e que cai às três da manhã. Esse é o trabalho real, e ele exige exatamente o oposto do reflexo de quadro branco.
- Discernimento de produto. Saber o que construir. O código pode ser impecável e ainda assim resolver o problema errado. A pessoa que percebe que uma funcionalidade nem é necessária economiza mais do que qualquer digitador veloz jamais produziu.
- Especificação e comunicação. Um modelo só é tão bom quanto a intenção que você lhe entrega. Quem consegue traduzir um requisito nebuloso numa especificação precisa e testável já fez a verdadeira engenharia – o resto é geração.
Dá para ver o padrão: cada uma dessas é uma habilidade de discernimento, não de produção. Nenhuma pode ser delegada ao modelo, porque são exatamente o ponto em que "o código roda" vira "entendemos o que ele faz e respondemos por isso".
Como testar isso de verdade
A boa notícia: uma vez que você sabe para que está contratando, os formatos de avaliação são óbvios – eles simplesmente se parecem com o trabalho real. Três formatos substituem o quadro branco com elegância.
Peça uma revisão de PR defeituoso ao vivo. Você dá à candidata um pull request realista de duzentas, trezentas linhas, no qual embutiu de propósito um punhado de defeitos: um off-by-one na borda, uma checagem de autorização que esquece exatamente um caminho, uma suposição de que a resposta vem ordenada. Aí você observa como ela lê. Ela acha as coisas sutis ou só o erro de digitação óbvio? Ela prioriza por raio de dano – lógica de pagamento primeiro, nome de variável por último? Consegue explicar por que algo está errado, não apenas que parece estranho? Essa entrevista de revisão em par mede mais sobre a aptidão real em quarenta minutos do que qualquer pergunta algorítmica.
Peça para depurar um sistema quebrado. Você a senta diante de uma aplicaçãozinha rodando com um bug genuíno – um que não cede a ficar encarando, só a hipóteses, logs, decomposição. Como ela procede quando não escreveu o código e não o entende? Formula uma teoria e testa, ou chuta a esmo? Depuração é o teste mais honesto de discernimento que existe, porque não dá para decorar o caminho.
Um take-home COM IA permitida. Essa é a inversão decisiva, a "entrevista com IA permitida". Em vez de proibir a ferramenta que a candidata vai usar de qualquer jeito, você a entrega explicitamente – e então avalia não o código, mas o discernimento. Que prompts ela escreveu? Onde ela contrariou o modelo? O que descartou da primeira versão gerada, e por quê? Você a faz percorrer as próprias decisões. Dois candidatos entregam o mesmo código funcionando; um o aceitou às cegas, a outra pegou três bugs silenciosos e tomou uma decisão de arquitetura. A entrevista clássica não conseguia distinguir os dois. Esse formato não enxerga outra coisa.
O denominador comum: você para de testar a produção a partir do arquivo em branco e passa a testar a interação com o código que já existe – ler, julgar, melhorar, responder por ele. Isso é o trabalho.
O problema do júnior
Aqui fica incômodo, e análise honesta não pode se esquivar. Tudo o que foi dito até agora desemboca numa qualidade que chamamos de discernimento – e discernimento é adquirido, não inato. A pergunta óbvia é: como um júnior o adquire se nunca escreve o primeiro rascunho?
O caminho tradicional pelo qual desenvolvedores construíam discernimento era brutal, mas eficaz: você escrevia mil linhas de código ruim, via-as serem despedaçadas na revisão, entendia por que eram ruins e, disso, construía uma intuição ao longo de anos. O escrever-e-falhar era o currículo. Quando um modelo assume o primeiro rascunho, é justamente esse caminho que desaparece. O júnior passa a ver só código pronto, de aparência plausível – e código de aparência plausível não ensina nada, porque esconde os erros dos quais você teria aprendido.
Esse é o iminente colapso do funil de júniores. Se os times só contratam por discernimento, mas discernimento só cresce por anos de escrever-e-falhar, então ninguém mais contrata as pessoas nas quais esse discernimento poderia crescer. Você consome um estoque de sêniores que um sistema anterior, mais lento, produziu e, ao mesmo tempo, desliga a fábrica que constrói a reposição. Não dói neste trimestre, mas dói.
A saída não é nostalgia, e sim um aprendizado (apprenticeship) construído de propósito. Alguns contornos já se desenham:
- Leitura profunda obrigatória. Se os júniores não aprendem mais escrevendo, precisam aprender por leitura estruturada e guiada. Não passar código gerado batendo o carimbo, mas desmontá-lo: por que essa estrutura? O que acontece com entrada vazia? Onde isso quebraria? Leitura-como-treino, deliberada e acompanhada.
- Levar o aprendizado a sério de novo. O sênior olhando por cima do ombro de um júnior enquanto ele desmonta um PR gerado deixou de ser luxo – é o único canal que restou para transmitir discernimento. Times que fazem isso de forma sistemática terão sêniores daqui a cinco anos. Os outros terão que comprá-los, caro.
- Fabricar atrito de propósito. Às vezes aprendizado significa deixar o júnior escrever o primeiro rascunho sozinho – sem modelo – não porque é eficiente, mas porque a falha é a matéria a ser aprendida. Eficiência e formação puxam para lados diferentes aqui, e é preciso sustentar a tensão conscientemente.
Ignore o problema do júnior e você se otimiza para um beco sem saída: produtividade máxima de curto prazo, funil de talentos ressecado.
O outro lado: os fundamentos importam mais, não menos
Agora a contra-argumentação honesta, senão a tese tomba para o oposto e fica igualmente errada. A tentação de concluir, de tudo isso, que "saber programar não importa, o que conta são bons prompts" é real – e é uma armadilha.
O motivo é simples e duro: não dá para revisar código que você não entende. Cada uma das habilidades de discernimento listadas acima pressupõe fundamentos técnicos profundos. Para flagrar a chamada de API inventada, você precisa saber como a API real se comporta. Para ver a race condition silenciosa, precisa ter concorrência no estômago. Para sentir que uma estrutura de dados é a errada, precisa ter visto mil estruturas de dados em uso. O "revisor implacável" não é uma alternativa ao engenheiro profundo – ele é o engenheiro profundo, só que sua alavanca não é mais a digitação, e sim o discernimento.
É por isso que o puro prompt jockey – alguém que opera modelos com destreza mas não consegue realmente ler o código que eles cospem – não é um substituto aceitável, e sim o perfil mais perigoso de todos. Ele produz código de aparência plausível rápido e não tem como saber quando esse código está confiantemente errado. Ele transforma a organização numa máquina que acumula dívida de compreensão mais rápido do que qualquer um consegue pagar.
Então não se pode supercorrigir para o oposto e contratar gente que nunca construiu nada. Quem nunca carregou um sistema do arquivo em branco até a produção nunca colecionou as cicatrizes de que o discernimento é feito. A leitura correta não é "os fundamentos ficaram sem importância", e sim uma mais incômoda: a régua da profundidade sobe, não desce. Antes, um engenheiro mediano de alto volume podia ser útil – afinal, produzia muito. Esse nicho desaparece, porque o modelo assume o volume. O que resta é a exigência de entender fundo o bastante para contrariar o modelo. Isso é uma régua mais alta, não mais baixa.
Conclusão
Por décadas a entrevista clássica mediu uma habilidade real: produzir código limpo rápido. Essa habilidade não ficou sem valor, mas deixou de ser escassa – a ferramenta mais barata da sala a domina melhor do que qualquer candidato. Continue contratando com base nela e você estará medindo com um instrumento quebrado, e se espantando com os resultados.
O que ficou escasso é o que o quadro branco nunca conseguiu testar: bom gosto, pensamento sistêmico, a capacidade de revisar código gerado sem piedade, de depurar sistemas quebrados dos outros, de identificar o problema certo e formular uma especificação precisa. Você avalia isso fazendo as pessoas realizarem trabalho real – revisar um PR defeituoso, depurar um sistema, pensar por inteiro um take-home com IA permitida – e avaliando não o código, mas o discernimento por trás dele. E você reconstrói o aprendizado, ou resseca justamente o funil que produz discernimento.
É exatamente para isso que contratamos na NH Labs. Não por velocidade de digitação nem pelo número de quebra-cabeças resolvidos, mas por discernimento e pela disposição de carregar responsabilidade – por cada linha submetida, não importa quem ou o que a digitou. Buscamos as pessoas que leem código gerado como um editor lê um manuscrito: rápido, cético, com faro para onde a superfície lisa esconde uma falha. É por isso que nossos clientes podem confiar no resultado – não porque uma IA foi rápida, mas porque um humano com bom discernimento responde por ele.