Take-home test: como se destacar (aprendi entregando errado)

O take-home que mais me doeu foi um que eu tecnicamente acertei. Uma API de tarefas com autenticação, dois dias de trabalho, código que eu mostraria pra qualquer um. Entreguei o repositório sem README. Nem instrução de como rodar, nem uma linha sobre as decisões. A resposta veio educada: "we couldn't get the project running locally." O código nunca foi lido. Anotei no caderno, apertando a caneta: o avaliador não te deve esforço nenhum.

Fiz uma boa quantidade de take-homes depois desse. Passei a tratar cada um como produto, não como prova. O que mudou:

README primeiro, código depois

Hoje eu escrevo o README antes da primeira linha de código. Quatro blocos:

• Como rodar em até três comandos. Se precisa de mais que instalar dependências e subir o projeto, simplifique até caber.
• Decisões e tradeoffs. Duas ou três frases: por que esse framework, por que essa estrutura.
• O que eu faria com mais tempo. Seção de ouro: mostra que você enxerga o que falta sem precisar construir tudo.
• Escopo assumido. O que você entendeu do enunciado e o que deixou de fora de propósito.

O avaliador tem pouco tempo e uma pilha de candidatos. O README decide se o seu código vai ser lido de bom humor, de mau humor, ou não vai ser lido, como o meu.

Testes: poucos, bons, no lugar certo

Ninguém espera 100% de coverage num exercício de fim de semana. Mas zero teste vira comentário na devolutiva. Meu padrão passou a ser: testar a regra de negócio central do enunciado e um ou dois casos de borda. Cinco a dez testes bem escolhidos dizem "eu sei testar", que é o que essa etapa quer descobrir.

Commits pequenos contam a história

O git log é parte da entrega. Um commit único chamado "final version" joga fora a chance de mostrar como você trabalha. Passei a commitar em passos pequenos, mensagem em inglês, no imperativo:

• "Add task model and migrations"
• "Implement JWT authentication"
• "Add validation for overdue tasks"

Quinze commits assim contam um raciocínio. É a diferença entre entregar o bolo e entregar a receita junto.

Respeite o escopo: o gold-plating me custou uma vaga

Noutro take-home, pediram uma API. Entreguei a API, mais um front, mais cache, tudo pela metade, porque o prazo era o mesmo. O feedback: "the core requirements were not fully met." Doeu e ensinou. Extra pela metade vale menos que o pedido inteiro. Se o enunciado pede X, entregue X redondo. Extras viram uma linha no README: "with more time, I'd add caching here". Custa uma frase, não custa o escopo.

Prazo é requisito, não sugestão

Entregar no prazo é parte da avaliação: é um ensaio de como você trata deadline. Se a semana explodiu, pedir prorrogação cedo é aceitável: "Would it be okay if I submitted by Sunday evening? I want to give it proper attention." Pedir na véspera, não. Sumir e entregar atrasado sem avisar, nunca. Empresa gringa lê isso como prévia de como você vai se comportar remoto, a milhares de quilômetros de distância.

Meu checklist antes de enviar

• README com "como rodar" testado do zero: clonei meu próprio repo numa pasta limpa e segui as instruções
• Testes rodando com um comando
• git log legível, sem commit gigante no final
• Escopo do enunciado inteiro coberto; extras só anotados no README
• Enviado antes do prazo, com mensagem curta agradecendo

O take-home costuma aparecer no meio do funil, antes ou no lugar do código ao vivo. Mapeei isso nas etapas do processo seletivo gringo. E o que você escreve no README volta depois: já usei minha própria seção de tradeoffs como colinha na etapa de system design, porque as perguntas eram as mesmas. Se a etapa seguinte for código ao vivo, o jogo muda, mas o hábito de narrar decisões continua valendo.

Take-home é a etapa mais controlável do processo inteiro. Sem nervosismo, sem sotaque, sem plateia. Você, o enunciado e o tempo. Foi onde eu mais virei reprovação em aprovação, porque todo erro dessa etapa é evitável com lista. A minha está aí em cima.