Desafio de código (take-home) no Brasil: formato, avaliação e erros comuns
Teste técnico para dev no Brasil quase sempre significa um destes formatos: um desafio de código para fazer em casa (take-home), entregue por repositório Git, ou uma avaliação em plataforma como HackerRank ou Codility. Para o take-home, o avaliador costuma olhar primeiro se o projeto roda, se o README explica as decisões e se o código está organizado para a senioridade da vaga. Não existe critério universal publicado; abaixo está o que relatos e guias brasileiros indicam, com o que não consegui confirmar marcado como tal.
Os formatos de teste técnico mais citados
Um guia de recrutamento tech brasileiro lista, entre os formatos usados no mercado: testes de programação online (em linguagens como Python, PHP e Java), problemas de lógica, FizzBuzz como filtro inicial, revisão de código (você recebe um trecho de sistema para analisar), uma tarefa implementável em tempo determinado, live coding e plataformas de desafios (HackerRank, Codility, Testdome e outras). Ou seja, "teste técnico" é um guarda-chuva. Antes de se preparar, descubra qual deles é o seu.
- Take-home / desafio de código: descrição do que construir, entrega por repositório. Você tem dias, não minutos.
- Plataforma com casos de teste ocultos: tempo curto, nota automática. Veja HackerRank, Codility e CodeSignal.
- Live coding com pessoa: veja o guia de live coding e o de pair programming.
Como costuma funcionar o take-home
Relatos de candidatos brasileiros descrevem o desafio como uma segunda fase, geralmente depois da conversa com o RH. Um relato publicado na DIO conta um teste com prazo de 7 dias, em que o enunciado exigia NestJS no backend e Angular no frontend, deixava o banco de dados livre, e a entrega era um pull request em um repositório forkado. A autora diz que, apesar do prazo "parecer suficiente", aprender enquanto desenvolvia apertou o tempo, e que vale entregar o que foi feito mesmo sem concluir tudo. É um relato individual, não uma regra do mercado.
O que você pode inferir com segurança: o formato varia (prazo, stack, forma de entrega), então tudo isso é definido no enunciado. Leia as especificações inteiras antes de escrever uma linha, como a própria autora fez antes de dividir as tarefas.
O que o avaliador olha primeiro
Nenhuma empresa que consultei hoje publica uma planilha de critérios. O que aparece de forma recorrente nos textos brasileiros que li:
- O projeto roda? Se o avaliador não consegue subir o projeto seguindo o README, o resto raramente importa. Teste do zero em uma máquina limpa (ou em um contêiner) antes de enviar.
- README. Um artigo da DIO sobre READMEs para recrutadores diz que, na maioria dos casos, o README decide se o avaliador continua analisando o repositório. Ele recomenda: visão geral do problema, objetivo, decisões técnicas (o porquê da stack, alternativas, trade-offs), tecnologias de forma objetiva, como executar (pré-requisitos e passos claros), aprendizados e próximos passos.
- Legibilidade e organização. Outro texto da DIO argumenta que plataformas que só conferem a resposta (um
assertem um arquivo de teste) não medem se o código é legível e fácil de manter, e que quem programa deve pensar em quem vai ler. Em take-home, é exatamente isso que o avaliador humano vê. - Testes automatizados. Não encontrei regra oficial de cobertura mínima; mas testes com nomes claros e foco nas regras de negócio comunicam cuidado. Não invente um percentual para se justificar.
- Aderência ao enunciado. Se o enunciado proíbe mexer em determinados arquivos ou pede uma tecnologia específica, cumpra. Seguir instruções é parte da avaliação.
Um README que responde ao avaliador
Use uma estrutura curta. Exemplo de esqueleto (ilustrativo, adapte ao enunciado):
## O que é
Uma frase sobre o problema resolvido.
## Como rodar
1. Pré-requisitos 2. Comando de instalação 3. Comando de testes
## Decisões
- Por que X em vez de Y (e o que ficou de fora)
## Limitações e próximos passos
- O que faria com mais tempoA seção de decisões é a que mais mostra seu raciocínio: o DIO a descreve como uma das mais importantes. A de limitações transforma lacunas em maturidade: dizer "não implementei paginação por falta de tempo; faria assim" é melhor que deixar o avaliador descobrir sozinho.
Erros comuns
- Superengenharia. Camadas e padrões demais para um problema pequeno. O autor do texto da DIO lembra que princípios de design não devem ser aplicados em todo lugar; um "Hello World" não precisa de abstrações extras.
- Subengenharia. Tudo em um arquivo, regra de negócio dentro do controller, nenhuma validação.
- Ignorar partes do enunciado por ter lido pela metade.
- Entregar sem testar a instalação. "Na minha máquina funciona" não vale.
- Commits bagunçados. Um histórico com mensagens claras mostra seu processo (hipótese minha; não há regra publicada).
- Estourar o prazo em silêncio. Se precisar de mais tempo, peça antes. Entregar algo funcional e documentado, mesmo parcial, tende a ser melhor que nada.
Perguntas para fazer ao recrutador antes de começar
- Qual o prazo e como entrego (repositório, pull request, arquivo zip)?
- Posso usar qualquer biblioteca e consultar documentação?
- É permitido usar assistentes de IA nesta etapa? Se sim, preciso declarar?
- Haverá uma conversa depois para revisar o código? (Muitas empresas pedem para você explicar suas decisões: esteja pronto para isso.)
A pergunta sobre IA importa: as regras variam por empresa e por desafio. Se for permitido, declare o que usou; se for proibido, não use. E lembre que, se há uma conversa de revisão depois, você precisa entender cada linha que entregou. Para treinar essa explicação em voz alta, o plano gratuito do Interview Copilot (sem cartão) serve de ensaio; veja a página do plano gratuito. Em entrevistas reais, pergunte ao recrutador o que é permitido; no macOS e no Windows a janela pede ao sistema para não aparecer na captura de tela, no Linux ela fica visível, e o resultado depende do programa de compartilhamento. Detalhes em assistente de entrevista invisível. Se o teste exigir resolver problemas de código em tela, veja também o assistente para entrevista de código.
Fontes
- DIO — Como escrever um README que torna seu portfólio legível para recrutadores
- DIO — Teste técnico no processo seletivo: uma oportunidade para aprender (relato individual)
- DIO — Por que só entregar desafios não nos torna bons candidatos
- GeekHunter — Teste para desenvolvedor: formatos usados no mercado
Verificado em 13/11/2026. Os textos são blogs e relatos, não regras oficiais de empresas.
FAQ
O que é um teste técnico take-home para desenvolvedor?
É um desafio de código feito em casa, com prazo de dias, entregue por repositório Git ou pull request. Relatos brasileiros o descrevem como segunda fase após a conversa com o RH. O enunciado define prazo, stack e forma de entrega; leia-o inteiro antes de começar.
O que o avaliador olha primeiro em um desafio de código?
Não há critério oficial universal. Os textos brasileiros que li apontam: se o projeto roda, a qualidade do README (decisões, como executar), a legibilidade e organização do código e a aderência ao enunciado. Quem avalia costuma ser um humano, então clareza pesa.
Quanto tempo se costuma ter para entregar?
Depende da empresa. Um relato de candidata fala em 7 dias, mas é um caso individual. Confirme o prazo no enunciado e, se precisar de mais tempo, peça antes do vencimento em vez de atrasar em silêncio.
Preciso fazer testes automatizados no desafio?
Não achei regra oficial de cobertura. Testes claros nas regras de negócio comunicam cuidado e costumam ser bem vistos; se o enunciado pedir, é obrigatório. Evite prometer um percentual que você não cumpre.
O que colocar no README do desafio?
Visão geral, objetivo, decisões técnicas (por que essa stack, alternativas e trade-offs), como rodar e testar, aprendizados e próximos passos. A seção de decisões mostra seu raciocínio; a de limitações mostra maturidade.
Posso usar IA no teste técnico?
Depende da empresa e do desafio; pergunte ao recrutador antes. Se for permitido, declare o que usou; se for proibido, não use. Se há conversa de revisão depois, você precisa explicar cada trecho do que entregou.