teste técnico pra vaga junior: quando aceitar, como fazer e como entregar

Teste técnico assusta porque parece prova. Mas em vaga junior boa, ele não deveria medir se você já trabalha como pleno. Deveria medir se você consegue entender um problema pequeno, fazer escolhas simples, comunicar trade-offs e pedir ajuda do jeito certo.

O problema é que nem todo teste técnico é bom.

Tem desafio honesto de 3 horas. Tem case aberto demais. Tem empresa que pede projeto de 30 horas sem pagar. Tem vaga que diz junior, mas manda um take-home com arquitetura, autenticação, deploy, teste, fila, observabilidade e documentação como se fosse contratação de senior.

Você precisa de dois filtros: quando aceitar e como entregar sem se destruir.

antes de aceitar: o teste é proporcional?

Um teste técnico pra junior precisa caber na vida real de uma pessoa que estuda, trabalha, pega transporte, faz faculdade ou tá procurando emprego em paralelo.

Antes de começar, leia o enunciado e pergunte:

• Dá pra entregar uma versão honesta em até 4 horas?
• O escopo tem começo e fim ou é “faça um sistema completo”?
• A empresa explicou o que será avaliado?
• O teste parece conectado com a vaga?
• Existe prazo razoável?
• A vaga já passou pelo seu filtro de fake junior?

Se o teste exige 12, 20 ou 30 horas, acende alerta. Pode até valer se a empresa é muito boa, o processo está avançado e a vaga encaixa muito bem. Mas não trate isso como obrigação normal. Tempo de junior procurando emprego é recurso escasso.

Um bom teste junior costuma pedir algo como:

• consumir uma API e mostrar dados numa tela simples;
• criar uma pequena API CRUD;
• limpar uma base de dados e explicar descobertas;
• corrigir bugs num projeto pequeno;
• modelar uma página a partir de um layout simples;
• escrever testes para uma função ou endpoint.

Um teste ruim pede “clone o Trello”, “crie um marketplace”, “faça um app completo com login, pagamento e painel administrativo” ou “resolva esse problema aberto sem limite de escopo”. Isso não mede junior. Mede tolerância a trabalho gratuito.

combine uma regra de tempo antes de abrir o editor

O maior erro é começar sem limite. Você abre o projeto às 20h, promete “só adiantar”, e quando vê são 2h da manhã, a tela ainda tá quebrada e você odeia a vaga.

Antes de começar, defina:

• tempo máximo: por exemplo, 4 horas;
• entrega mínima: o que precisa funcionar pra ser uma submissão decente;
• extra opcional: o que você só faz se sobrar tempo;
• ponto de parada: horário em que você vai parar mesmo incompleto.

Escreva isso num bloco de notas. Parece bobo, mas muda o comportamento. Você deixa de perseguir perfeição e começa a gerenciar entrega.

Exemplo:

Tempo máximo: 4h
Entrega mínima: tela lista itens da API, estado de loading, erro simples, README com como rodar
Extra: filtro por texto, teste unitário, responsivo melhor
Ponto de parada: 23h30

Se passar do tempo, pare. Junior bom não é quem faz tudo. É quem entende escopo.

leia o enunciado como se fosse requisito de produto

Não vá direto pro código. Primeiro traduza o enunciado.

Separe em três blocos:

1. Obrigatório: sem isso, a entrega não responde ao teste.
2. Desejável: melhora a avaliação, mas não é essencial.
3. Ambíguo: precisa de suposição ou pergunta.

Se o enunciado diz “crie uma API para cadastrar tarefas com título, descrição e status”, o obrigatório é cadastrar/listar/editar status. Autenticação, Docker, dashboard bonito e CI não são obrigatórios, a menos que o enunciado peça.

Junior costuma perder teste porque tenta impressionar com coisa lateral e deixa o básico instável. Melhor uma API simples que roda do que um projeto com Docker, Redis e frontend quebrado.

faça uma versão pequena funcionando primeiro

A primeira meta não é arquitetura bonita. É um caminho feliz funcionando.

Se for frontend:

• renderize a tela principal;
• carregue dados mockados;
• depois conecte a API;
• depois trate loading e erro;
• só então melhore visual.

Se for backend:

• suba o servidor;
• crie uma rota simples;
• conecte o banco ou armazenamento em memória;
• valide o fluxo principal;
• depois adicione testes ou organização.

Se for dados:

• carregue o arquivo;
• limpe colunas óbvias;
• gere uma primeira tabela/resumo;
• depois aprofunde análise e visualização.

Essa ordem protege você. Se faltar tempo, você entrega algo que funciona. Se começar pela arquitetura ideal, pode acabar com pasta bonita e zero comportamento validável.

documente as decisões enquanto faz

O README é parte do teste. Em vaga junior, ele vale muito porque mostra como você pensa.

Inclua:

• como rodar o projeto;
• versão da linguagem/runtime;
• o que foi implementado;
• o que você priorizou;
• o que faria com mais tempo;
• limitações conhecidas;
• decisões técnicas importantes.

Não escreva um romance. Escreva como alguém que respeita quem vai avaliar.

Exemplo bom:

Priorizei o fluxo de criação/listagem/edição porque era o núcleo do enunciado.
Deixei autenticação fora porque não estava no escopo e passaria do limite de tempo.
Com mais tempo, adicionaria testes de integração e paginação.

Isso é muito melhor do que fingir que nada ficou faltando. Maturidade técnica começa em saber nomear limite.

se travar, mande uma pergunta boa

Você pode perguntar. Perguntar não te desqualifica. Pergunta ruim é “não entendi nada, o que faço?”. Pergunta boa é específica e mostra tentativa.

Formato:

Oi, [nome]. Ao ler o enunciado, fiquei em dúvida sobre [ponto específico].
Estou assumindo [sua interpretação] para manter o escopo em [limite].
Faz sentido seguir assim?

Se a empresa não responder, siga com a suposição e registre no README.

Exemplo:

Assumi que autenticação não fazia parte do escopo porque o enunciado não mencionava usuário/login. Foquei no CRUD de tarefas e deixei a API pronta para receber autenticação depois.

Isso protege sua avaliação. Quem lê entende que você não ignorou o problema; você tomou uma decisão.

como entregar parcialmente sem parecer desculpa

Às vezes não dá tempo. Ou você encontrou bug. Ou percebeu que o escopo era grande demais. A entrega parcial ainda pode ser boa se for clara.

Não escreva:

“Não consegui terminar porque estou sem tempo.”

Escreva:

“Entreguei o fluxo principal de listagem e criação. A edição está modelada, mas ficou fora do tempo definido. Priorizei deixar o projeto rodando com instruções claras e registrar o próximo passo no README.”

A diferença é postura. A primeira frase parece abandono. A segunda mostra decisão.

Se o teste era realmente grande demais, você também pode dizer:

“Limitei a entrega a 4 horas para manter o teste proporcional a uma vaga junior. Dentro desse tempo, priorizei o núcleo do enunciado.”

Isso filtra empresa ruim também. Empresa que reprova só porque você não trabalhou de graça por um fim de semana inteiro provavelmente não é um bom lugar pra começar.

checklist antes de enviar

Antes de mandar o link, faça uma revisão fria:

• O projeto roda do zero seguindo o README?
• O repositório não tem chave, token, .env real ou dado sensível?
• O nome da pasta e do repo está limpo?
• Tem commit com mensagem minimamente clara?
• O fluxo principal funciona?
• Você removeu arquivo temporário, log gigante e comentário de desespero?
• O README explica limitações?
• O link está público ou acessível para a empresa?

Esse checklist evita reprovação boba. Muito teste técnico não cai por código ruim; cai porque a pessoa esqueceu instrução de instalação, subiu segredo ou mandou projeto que só roda na própria máquina.

como usar o teste pra próxima candidatura

Mesmo se você não passar, o teste pode virar ativo.

Depois do processo, revise:

• o que você aprendeu;
• qual parte travou;
• que trecho poderia virar projeto público;
• que pergunta apareceu na entrevista;
• que tecnologia vale estudar mais.

Registre isso na sua planilha de candidaturas. Se o projeto ficou bom e não contém código proprietário da empresa, você pode transformar uma versão genérica em item de portfólio. Se a entrevista técnica veio depois, prepare a narrativa com o guia de entrevista técnica junior.

O objetivo não é romantizar teste técnico. É fazer cada teste trabalhar por você, não só pela empresa.

a regra final

Aceite teste técnico que mede aprendizado, comunicação e execução proporcional. Desconfie de teste que tenta extrair produto completo de candidato junior.

Quando aceitar, faça pequeno, funcional, documentado e honesto.

Junior não precisa entregar sistema perfeito. Precisa mostrar que sabe ler um problema, cortar escopo, pedir ajuda, explicar decisão e terminar algo usável. Isso já separa você de muita candidatura perdida.

E quando for procurar o próximo processo, comece por uma fila limpa de vagas junior e estágio em tech, filtre as vagas ruins cedo e proteja sua energia para os testes que realmente merecem tempo.