37signals rejeitou a contratação de programadores baseada em quebra-cabeças e testou os candidatos na prática

Em fevereiro de 2013, a 37signals publicou "Why we don't hire programmers based on puzzles and tricks" no blog da empresa, e o post chegou ao Hacker News no mesmo dia. A discussão começou com as falhas da contratação movida a curiosidades: um entrevistado da Microsoft havia se preparado com How Would You Move Mount Fuji? e foi solicitado a escrever o strcmp() da linguagem C de memória, as entrevistas da Amazon se apoiavam na recitação de Big-O e em "conte todas as estrelas do universo", e os entrevistadores muitas vezes apenas pesquisavam "perguntas de entrevista de programação" sem perguntar o que as respostas provavam.

A contraproposta da 37signals foi rejeitar o gênero por completo: nenhuma contratação baseada em quebra-cabeças e truques. Os comentaristas descreveram a alternativa como "testá-los na prática" — colocar os candidatos diante de trabalho real em vez de charadas sintéticas. Profissionais empurraram na mesma direção com mecanismos concretos: a ITA Software considerou os questionários presenciais muito menos úteis do que ler código que alguém havia escrito offline, e um gerente de contratação estruturou as entrevistas em torno de um dia de pareamento que fazia três perguntas — a pessoa consegue fazer o trabalho, se encaixa na equipe e consegue se adaptar quando o jogo muda?

As duas triagens testam coisas diferentes. Curiosidades e charadas são treináveis — existe todo um folclore de perguntas esperadas e livros de preparação — e selecionam por memorização e compostura sob pressão artificial. Os comentaristas observaram que pensadores do tipo insight podem falhar em uma hora de questionamento procedimental e ainda assim se sair bem em uma tarefa real mais longa, e um candidato em meio a um ataque de pânico poderia falhar no FizzBuzz e continuar sendo um bom programador. O trabalho observado responde à pergunta que a curiosidade não consegue: como a pessoa lê uma base de código desconhecida, identifica erros, escreve código e trabalha com estranhos.

Abandonar a prova de obstáculos de quebra-cabeças: testar os candidatos na prática e deixar o trabalho real, não a memorização, decidir as contratações

As triagens por quebra-cabeças são treináveis: um folclore de perguntas esperadas e livros de preparação permitem que os candidatos ensaiem, de modo que o teste mede preparação e memória, não capacidade para o trabalho.

Testar os candidatos na prática observa o trabalho real — ler uma base de código real, identificar erros, escrever código e colaborar — evidência que nenhuma charada consegue produzir.

A pressão artificial distorce os resultados: candidatos do tipo insight e ansiosos podem falhar em quebra-cabeças de uma hora e ainda assim ter bom desempenho em trabalho real ao longo de um período mais longo.

A postura pública sinaliza o que a empresa valoriza e abriu um debate de 442 comentários que testou a ideia em público.

Quando uma triagem de contratação mede a preparação mais do que o trabalho, mude a evidência: teste os candidatos em trabalho real e deixe o desempenho decidir

O ensaio alcançou 648 pontos e 442 comentários no Hacker News, tornando a 37signals o ponto de referência do lado anti-quebra-cabeças. Os defensores diziam que charadas difíceis revelam resolução de problemas sob pressão; os opositores contrapunham com um dia de pareamento, o FizzBuzz como filtro negativo barato e a prática da ITA de ler código offline. A abordagem de teste foi considerada boa, mas impraticável para empregadores menos conhecidos que ainda precisam de quebra-cabeças como atrativo de talentos. Nenhum resultado medido de contratação aparece na discussão; o efeito foi normativo — "testá-los na prática" tornou-se a principal alternativa às entrevistas de curiosidades.