O que Colocar no README do Take-home

O problema

Tem muita entrega boa que parece pior porque o avaliador precisa cavar informação básica.

Como roda?

O que foi implementado?

O que ficou de fora?

Quais decisões foram intencionais?

Sem README, ou com README ruim, você força a outra pessoa a gastar energia desnecessária.

E esse atrito costuma jogar contra você.

Modelo mental

README de take-home não existe para provar que você sabe escrever markdown.

Ele existe para reduzir atrito e deixar seu julgamento visível.

Se quiser resumir:

O README é a interface da sua entrega para quem vai avaliar sob tempo curto.

Ele não precisa ser longo.

Precisa ser útil.

Quebrando o problema

Comece pelo operacional

O avaliador precisa entender rápido:

• pré-requisitos
• como instalar
• como rodar
• como testar, se houver teste

Isso deve ser simples de achar.

Sem floreio.

Depois diga o que foi implementado

Uma lista curta ajuda muito.

Exemplo:

• fluxo principal
• tratamento de loading e erro
• testes principais
• responsividade básica

Essa parte ajuda a pessoa a não adivinhar cobertura da entrega.

Explique decisões relevantes

Não precisa transformar isso em ADR formal.

Mas vale explicar escolhas que mudam leitura do projeto:

• por que a estrutura foi feita assim
• por que certo trade-off foi aceito
• por que uma dependência entrou

O importante é mostrar critério, não volume de texto.

Diga o que ficou de fora

Aqui muita gente erra o tom.

Ou some com o assunto.

Ou escreve uma lista de desculpas.

O jeito melhor é simples:

• o que faltou
• por que não entrou
• como você seguiria

Isso mostra priorização, não fragilidade.

Exemplo simples

Um README enxuto e forte costuma ter algo como:

1. visão rápida do projeto
2. instruções de setup e execução
3. o que foi implementado
4. decisões principais
5. trade-offs e próximos passos

Perceba que nada aí é enfeite.

Tudo reduz atrito ou aumenta sinal.

Erros comuns

• Não explicar como rodar.
• Fazer README marketing demais e técnico de menos.
• Jogar uma lista enorme de detalhes irrelevantes.
• Esconder limitações por medo de parecer fraco.
• Não registrar decisões que o código sozinho não deixa óbvias.

Como um senior pensa

Quem tem mais maturidade costuma perguntar:

• o que a pessoa avaliadora precisa entender em poucos minutos?
• o que o repositório não explica sozinho?
• qual decisão pode ser mal interpretada se eu não contextualizar?

Isso produz README mais claro e mais honesto.

Senioridade aqui não é escrever bonito.

É comunicar com economia e utilidade.

O que o entrevistador quer ver

Ele quer ver se você:

• se preocupa com experiência de quem vai avaliar
• sabe documentar o essencial
• explicita trade-offs sem drama
• reduz ambiguidades operacionais e técnicas

Se o README deixa claro como rodar, o que olhar e como você pensou, ele já está trabalhando a seu favor.

README de take-home bom não impressiona pelo tamanho. Ajuda pela precisão.

Quando a pessoa entende rápido sua entrega, sobra mais espaço para ela notar seu critério.