Take-Home Test: Como Arrasar no Desafio Técnico e Conseguir a Vaga

O Que é Um Take-Home Test e Por Que É Uma Oportunidade

Take-home tests (desafios técnicos para fazer em casa) são a etapa técnica mais comum em empresas americanas de pequeno e médio porte. Ao contrário do coding challenge ao vivo (que avalia velocidade sob pressão), o take-home avalia qualidade de código em condições normais de trabalho — o que é muito mais próximo do trabalho real.

Para desenvolvedores brasileiros, o take-home é vantagem: você tem tempo para pesquisar, estruturar e escrever código limpo — sem a pressão de inglês ao vivo e raciocínio em tempo real.

O Que Os Avaliadores Realmente Buscam

A maioria dos devs foca em "fazer funcionar". Os avaliadores buscam muito mais:

• Código legível: é mais importante que ser cleverly optimized. Um dev que vai trabalhar com você precisa entender seu código em 3 meses.
• Tomada de decisão explícita: por que você escolheu estrutura X em vez de Y? Isso deve estar no README.
• Testes: código sem testes é automaticamente um sinal negativo na maioria das empresas americanas.
• Tratamento de erros: happy path funcionando não é suficiente — o que acontece quando os dados estão errados?
• Atenção ao enunciado: seguiu todos os requisitos? Interpretou corretamente os edge cases?

Quanto Tempo Dedicar

A maioria dos take-home tests sugere "2-4 horas". Interprete com cuidado:

• 2-4 horas é o mínimo esperado — não o máximo
• Dedicar 6-8 horas produzindo código de qualidade é comum e geralmente melhora a avaliação
• Mas não passe de 10-12 horas — a empresa não espera uma solução perfeita, e gastar tempo demais pode indicar dificuldade com priorização

Se o prazo é curto (24-48h) e você está ocupado, comunique: "I'll need an additional day to deliver quality work — would that be acceptable?" A maioria das empresas aceita e respeita a comunicação transparente.

Estrutura do Projeto: O Que Fazer Antes de Escrever Código

1. Leia o enunciado 3 vezes: a primeira vez para entender, a segunda para identificar requisitos explícitos, a terceira para identificar requisitos implícitos e edge cases.
2. Liste o que você VAI fazer: escreva no papel ou em um rascunho as features a implementar, ordenadas por prioridade.
3. Estruture o projeto antes de codar: defina a arquitetura, os módulos, as interfaces. Código escrito sem planejamento é reescrito.
4. Comece pelos testes: se você faz TDD, os testes guiam a implementação. Se não, pelo menos escreva os testes de integração primeiro para validar o comportamento esperado.

Checklist Antes de Entregar

Código

• Todos os requisitos do enunciado implementados?
• Testes passando? (rode pelo menos 3 vezes antes de entregar)
• Tratamento de erros para casos óbvios (input inválido, recurso não encontrado)?
• Sem secrets, credentials ou dados pessoais no código?
• Sem console.log/print de debug esquecidos?
• Lint e formatting aplicados? (ESLint, Prettier, Black, gofmt)

README (o mais importante)

• Como rodar o projeto localmente (passo a passo, assumindo ambiente limpo)?
• Como rodar os testes?
• Decisões técnicas tomadas e por quê?
• O que você faria diferente com mais tempo?
• Quais funcionalidades você não implementou e por quê (se aplicável)?

O README é sua oportunidade de conversar com o avaliador sobre seu raciocínio. Um bom README pode salvar uma implementação imperfeita. Um README ausente pode derrubar uma implementação excelente.

Erros Que Eliminam Candidatos Imediatamente

• Projeto que não roda: testar apenas na sua máquina é o erro mais comum. Use Docker ou documente todas as dependências.
• Sem testes: para vagas seniores, é automaticamente eliminatório em 70% das empresas americanas
• Não seguiu os requisitos: leu errado ou implementou features extras ignorando o pedido básico
• Código copiado de StackOverflow sem entender: avaliadores experientes identificam e pedem explicação na próxima etapa — se você não souber explicar, foi detectado
• README vazio ou genérico: "Run npm install && npm start" como único conteúdo é insuficiente

Diferenciais Que Impressionam

• Docker Compose para rodar o projeto com um único comando
• CI configurado (GitHub Actions rodando os testes no PR)
• Observabilidade básica (logs estruturados, health check endpoint)
• Documentação da API (Swagger ou Postman collection)
• Decisões arquiteturais documentadas com trade-offs explícitos

Template de README Para Take-Home Test

# [Nome do Projeto]

## How to run
Prerequisites: Node.js 20+, Docker

```bash
git clone [repo]
cd [project]
cp .env.example .env
docker-compose up -d  # starts dependencies
npm install && npm run dev
```

## How to run tests
```bash
npm test           # unit tests
npm run test:e2e   # integration tests
```

## Architecture decisions
- **[Decision 1]**: [Why this approach vs alternatives]
- **[Decision 2]**: [Trade-offs considered]

## What I would improve with more time
- [Feature/improvement 1 and why]
- [Feature/improvement 2 and why]