Uma avaliação de código tem dois trabalhos e eles puxam em direções opostas. Precisa dizer algo sobre como a pessoa trabalha, e precisa valer a pena para quem tem outras ofertas. A maioria dos testes é desenhada como se só o primeiro trabalho existisse.
Por que o teste tradicional perde gente
O formato conhecido é um quebra-cabeça de algoritmo com cronômetro, numa plataforma que leva o código embora no fim. É barato de administrar, que é por que se espalhou, e seleciona quem treinou para entrevista recentemente mais do que quem sabe engenharia.
O custo cai de forma desigual. Quem está entre empregos aguenta. Quem está empregado, bem avaliado e discretamente curioso sobre você não aguenta, e esse segundo grupo é o que você esperava alcançar.
Teste o trabalho, não a entrevista
Work samples, ou seja, tarefas tiradas do trabalho real, se sustentaram em décadas de pesquisa sobre validade, ainda que a meta-análise atualizada coloque seu poder preditivo de forma mais modesta que a literatura antiga.
A maior parte do trabalho de engenharia é leitura antes de ser escrita: entender código que alguém deixou, achar onde a mudança cabe, fazê-la sem quebrar o que está em volta. Um teste que começa num arquivo vazio pula tudo isso.
- Dê um código pequeno que já existe e uma mudança para fazer nele.
- Inclua uma coisa levemente errada, e não avise. Se a pessoa percebe é mais informativo que se ela termina.
- Peça uma nota curta sobre o que faria em seguida com mais tempo. É aí que o julgamento aparece.
- Permita documentação, busca e assistente de IA. Você está contratando alguém que vai trabalhar com os três.
Seja honesto sobre o tempo
Declare um limite, desenhe para ele, e diga com todas as letras que não espera trabalho além dele. Depois confira se a tarefa cabe mesmo, fazendo você, ou pedindo para alguém do time fazer. A diferença entre o tempo declarado e o tempo real é o jeito mais rápido de perder a boa vontade de quem você quer.
Se leva um fim de semana, não é avaliação
É trabalho não remunerado com efeito de seleção. As pessoas que podem te dar um fim de semana não são as mais difíceis de contratar.
A pergunta que não dá mais para evitar
Candidatos têm assistente de IA. Todo mundo no seu time também tem, e quem você contratar vai ter, no primeiro dia. Uma avaliação de código desenhada para detectar ajuda está medindo obediência a uma regra que não existe no trabalho.
O movimento útil é desenhar uma tarefa em que a ajuda não responde a pergunta. Qualquer modelo produz uma função plausível a partir de um prompt claro. Nenhum consegue te dizer por que este código faz algo do jeito estranho, ou qual de duas abordagens cabe na restrição que você não escreveu. Coloque o julgamento na tarefa e o assistente vira o que ele é no trabalho: um teclado mais rápido.
- Peça o raciocínio junto com o código. Uma nota curta sobre o que a pessoa descartou e por quê é a parte que não autocompleta.
- Baseie a tarefa em código com história. Restrições reais moram nas partes que parecem esquisitas.
- Aprofunde uma decisão específica na entrevista. Quem tomou a decisão defende; quem aceitou uma sugestão normalmente não.
- Diga explicitamente que assistentes são permitidos. Senão os candidatos honestos se prejudicam e os outros não.
Take-home ou ao vivo
Um take-home respeita fusos e nervosismo, e custa horas não remuneradas ao candidato. Uma sessão ao vivo custa uma hora dele e uma sua, e mostra como a pessoa trabalha quando o plano encontra a realidade.
O erro comum é escolher um e fingir que a troca não existe. Um take-home curto seguido de uma conversa ao vivo sobre ele é a versão que mantém quase tudo dos dois: o candidato trabalha no tempo dele, e você gasta sua hora síncrona com algo que já leu, em vez de com setup.
Revisar com consistência
Escreva o que uma boa entrega contém antes de enviar a primeira. Revise contra essa lista, não contra o candidato anterior. Pontue as dimensões separadamente: correção, estrutura, e a qualidade da nota sobre o que vem depois.
Revisar todo mundo numa dimensão antes de passar para a próxima é mais chato de organizar e consideravelmente mais difícil de enviesar, que é a troca que vale fazer.
O que uma boa entrega realmente contém
Times costumam ter dificuldade de pontuar uma tarefa que eles mesmos desenharam, porque "código bom" não é critério, é sensação. Quebrar em coisas que dá para apontar deixa a revisão mais rápida e as discordâncias mais curtas.
- Funciona, e a pessoa sabe que funciona. Evidência de ter conferido vale mais que passar por sorte.
- Combina com o código existente. Uma mudança escrita no idioma do código em volta é uma mudança que a próxima pessoa consegue manter.
- O escopo está certo. Resolver exatamente o problema declarado é uma habilidade; uma refatoração que ninguém pediu é um aviso.
- As partes obscuras estão nomeadas. Uma entrega que diz "assumi X porque o enunciado não falava" está mostrando como a pessoa vai agir numa tarefa real.
- A nota sobre o que vem depois é específica. "Mais testes" não diz nada. "Sem teste para o caso vazio, que é o que vai acontecer" diz muito.
Repare que só o primeiro item é sobre o código estar correto. Quando alguém chega num take-home, correção é o mínimo; a razão de olhar trabalho real é tudo que vem depois disso.
O que você deve ao candidato
Ele gastou horas reais. Diga o resultado rápido, e diga a quem foi bem o que se destacou. Custa um parágrafo e é o que a pessoa repete para outros engenheiros, que é o canal que você não consegue comprar.