Teste take‑home: checklist prático — README, testes, Docker, CI e entrega

Um teste take‑home bem entregue pode ser a diferença entre seguir no processo ou ser descartado. Este guia prático assume que você já conhece conceitos básicos (git, Node/Python, testes) e foca em padrões, erros comuns e uma sequência de entregas que recrutadores e engenheiros valorizam.

1) Quando e por que usar

Quando um take‑home é apropriado

Testes take‑home são usados para avaliar mais que código: comunicação, arquitetura mínima, habilidade de priorizar e entregar. Eles aparecem quando a empresa quer balancear triagem automática (whiteboard, telefonema) com avaliação de produto. Use esse formato quando for possível entregar uma solução isolada, com tempo limitado (normalmente 2–8 horas).

Se você estiver em dúvida sobre tempo, pergunte ao recrutador. Transparência sobre disponibilidade é sinal de profissionalismo e evita falhas de escopo.

Por que acertar na apresentação importa tanto quanto o código

Recrutadores e engenheiros julgam pelo conjunto: README, instruções de execução, cobertura de testes, arquitetura, e facilidade de revisão do PR. Um código ótimo, mas com instruções ruins, frequentemente é mal avaliado porque aumenta o custo de revisão.

Considere que o avaliador pode ter 20 minutos para revisar. Reduza o tempo necessário para entender sua solução: documente o problema, o que você priorizou, e como executar os testes — isso é parte da nota.

2) Comparação com alternativas

Take‑home vs projeto de portfolio

Projetos de portfolio tendem a demonstrar amplitude e refinamento visual; take‑homes são sobre entrega rápida, escolhas arquiteturais e comunicação. No take‑home, prefira soluções pragmáticas e pequenas evidências de qualidade (testes, CI). Em um portfólio, usar frameworks e UX polido faz sentido; em take‑home, menos é mais.

Um portfólio pode conter features experimentais — no take‑home, foque nas features solicitadas e em qualidade de entrega.

Take‑home vs pair programming / entrevista técnica ao vivo

Entrevistas ao vivo avaliam pensamento em tempo real e comunicação. Take‑homes avaliam independência, organização e decisões de design. Se você prefere conversar, peça uma sessão de revisão em pair programming complementar à entrega — muitas empresas aceitam e isso mostra colaboração.

Em suma: escolha suas forças. Se o processo permite opção, use o formato que maximize suas chances de mostrar suas habilidades reais.

3) Implementação progressiva

Passo 0: comunique escopo e tempo

Antes de começar, confirme prazo e escopo. Se o teste não especificar limites, envie uma mensagem curta com o tempo que você pretende gastar e o que pretende entregar (por exemplo: "Vou implementar a API X, testes unitários, dockerização e CI em ~6h"). Isso previne expectativas irreais.

Se faltar requisito funcional, anote suposições no README em vez de adivinhar: isso mostra raciocínio.

Passo 1: crie um README mínimo e utilitário

O README é o primeiro contato do avaliador com sua entrega. Use um formato claro: objetivo, como rodar localmente, como rodar testes, decisões-chave, e o que você não fez por falta de tempo. Abaixo um template prático.

# README.md

Projeto: API de exemplo para take‑home

Objetivo
- Implementar endpoints de listagem e criação de resources com validação mínima.

Como rodar (local)
1. git clone <repo>
2. docker build -t takehome .
3. docker run -p 3000:3000 takehome

Como rodar testes
- npm test

Decisões
- Usei Express + Joi para validação; preferi simplicidade ao invés de event sourcing.
- Não implementei autenticação por limitação de tempo.

Notas
- Testes cobrem validação e lógica de negócio principal.

Contexto antes do código: este README demonstra o que o avaliador precisa saber. Depois da leitura, o avaliador deve conseguir rodar o projeto em minutos sem perguntas.

Passo 2: comece com testes

Testes forçam você a pensar na API pública. Escreva testes de contrato (não necessariamente 100% de cobertura) para as rotas principais. Tests também servem como documentação executável.

Exemplo com Jest + supertest: teste de um endpoint POST /items.

// tests/items.spec.js
const request = require('supertest');
const app = require('../src/app');

describe('POST /items', () => {
  it('cria um item com campos válidos', async () => {
    const res = await request(app)
      .post('/items')
      .send({ name: 'Caneca', price: 19.9 });

    expect(res.statusCode).toBe(201);
    expect(res.body).toHaveProperty('id');
    expect(res.body.name).toBe('Caneca');
  });
});

Contexto antes: este teste valida o contrato mínimo. Depois: ao rodar npm test, você garante que a rota responde como prometido no README.

Passo 3: código mínimo, legível e testável

Implemente a solução com foco em legibilidade. Prefira funções pequenas, injeção de dependência simples (por exemplo, passar repositório como argumento) e arquivos pequenos. Evite otimizações prematuras.

Use commits pequenos e claros. Um histórico linear com mensagens explicativas facilita revisão.

4) Integração com ecossistema real

Docker: embalagem para o avaliador

Forneça um Dockerfile que permita executar a aplicação sem precisar instalar dependências locais. Simples e reproduzível é melhor que complexo.

# Dockerfile (Node.js)
FROM node:18-alpine
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "src/server.js"]

Contexto antes: esse Dockerfile monta a imagem da aplicação. Depois: executar docker build && docker run deve expor a API no porto 3000 sem etapas extras.

CI: automação mínima que gera confiança

Configure um workflow que rode testes e linter em PRs. GitHub Actions é um padrão comum; mantenha o YAML simples: install -> test -> build Docker (opcional). Isso demonstra conhecimento de práticas de integração contínua.

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: node-version@v2
        with:
          node-version: 18
      - run: npm ci
      - run: npm test --silent

Contexto antes: este workflow valida que testes passam em cada PR. Depois: o avaliador vê checks verdes e gasta menos tempo em setup manual.

Entrega: como estruturar o PR e o artefato final

Ao abrir o PR ou enviar o repo, inclua um resumo do que foi entregue, tempo gasto, decisões e próximos passos possíveis. Se você enviar um repositório público, certifique‑se de remover credenciais e arquivos temporários.

Inclua tags no README como "tempo gasto: 6h" e "prioridades: validação, testes, docker" — isso orienta a revisão.

5) Checklist de qualidade para produção

Checklist técnico (essencial)

• README com instruções de execução e testes
• Script para rodar testes (npm test / pytest)
• Dockerfile simples que roda a aplicação
• CI que roda testes em push/PR
• Commits claros e histórico limpo

Marque cada item antes de enviar. Se algum item não for possível por limitação de tempo, documente explicitamente no README.

Checklist de qualidade humana

1. Explique decisões e trade‑offs
2. Seja honesto sobre o que ficou faltando
3. Assuma hipóteses e descreva como validaria
4. Forneça instruções para rodar a revisão em minutos

Observe: avaliadores valorizam desenvolvedores que facilitam o trabalho alheio — seu objetivo é reduzir o custo cognitivo da revisão.

Dica: coloque um badge no README com links para CI passando; isso dá sinal visual rápido de qualidade.

Erros comuns, armadilhas e dicas práticas

Erros que te fazem perder pontos

Listo os problemas que já vi custar vagas: código com dependências nativas sem instruções, falta de scripts de testes, README que não explica portas ou variáveis de ambiente, testes que acessam serviços externos sem mocks, e commits com mensagens inúteis ("ajuste").

Outro erro grave: entregar um ZIP com pastas aninhadas ou nomes confusos. Entregue um repositório clonável com uma raiz limpa.

Armadilhas de tecnologia e como evitá‑las

Evite integrar serviços externos (DBs, APIs externas) sem motivos. Se precisar, use um modo inMemory ou instruções para rodar um sqlite/docker compose. Se usar variáveis de ambiente, forneça um .env.example.

Ferramentas pesadas (ORMs complexos, frameworks fullstack) aumentam o tempo de entendimento do avaliador. Prefira ferramentas simples e bem justificadas.

Dicas práticas de produtividade

Use templates prontos para README e CI; eles salvam tempo. Escreva testes primeiro para as rotas principais — isso evita divergência entre contrato e implementação.

Ao finalizar, rode um checklist local e faça um runthrough: clone o repo em uma pasta nova e execute as instruções do README. Se algo falhar, ajuste antes de enviar.

Exemplos de entrega e scripts úteis

Script de start e test (package.json)

Contexto: scripts claros no package.json reduzem atrito. Tudo que o avaliador precisa executar deve estar ali.

{
  "name": "takehome-sample",
  "version": "1.0.0",
  "scripts": {
    "start": "node src/server.js",
    "dev": "nodemon src/server.js",
    "test": "jest --runInBand"
  },
  "dependencies": {
    "express": "^4.18.2"
  },
  "devDependencies": {
    "jest": "^29.0.0",
    "supertest": "^6.3.0",
    "nodemon": "^2.0.0"
  }
}

Depois: executar npm test deve rodar os testes citados anteriormente; npm start inicia a aplicação conforme README.

Como construir um commit final e abrir PR

Contexto: o PR é a sua apresentação final. Use um título claro e um corpo que peça ao avaliador o que você quer: revisão de arquitetura, feedback em testes, etc.

git checkout -b feat/takehome-delivery
git add .
git commit -m "feat(takehome): implement api items, tests, docker and ci"
git push origin feat/takehome-delivery
# abrir PR com descrição:
# - tempo gasto: 6h
# - o que foi priorizado
# - como rodar localmente

Depois: verifique se CI dispara e se README está visível no PR. Adicione screenshots ou gif se o teste tiver UI.

Conclusão prática

Um take‑home bem avaliado reúne três coisas: código que funciona, instruções que permitem rodar e testes que comprovam comportamento. Entregue o mínimo viável com qualidade e documente tudo.

Priorize: 1) README claro, 2) testes para contrato, 3) Docker para reprodução, 4) CI para confiança, 5) PR bem escrito. Se não conseguir tudo, documente e explique trade‑offs.

Trabalhos técnicos também são comunicação. Reduza atrito, deixe a vida do avaliador fácil, e você terá mais chances de avançar no processo.

Boa prática final: dois minutos antes de enviar, clone o repositório em uma pasta nova e siga o README. Se algo falhar, ajuste e reenvie. Detalhes desse nível fazem diferença em processos competitivos.