--- title: "Debrief de teste técnico junior: como revisar depois da entrega ou reprovação" url: "https://eu.dev.br/carreira/debrief-teste-tecnico-junior/" markdown_url: "https://eu.dev.br/carreira/debrief-teste-tecnico-junior.MD" description: "Aprenda a transformar teste técnico entregue, reprovação ou ghosting em ajuste concreto para a próxima vaga junior sem cair em culpa infinita." date: "2026-06-04" author: "" --- # Debrief de teste técnico junior: como revisar depois da entrega ou reprovação Aprenda a transformar teste técnico entregue, reprovação ou ghosting em ajuste concreto para a próxima vaga junior sem cair em culpa infinita. Você terminou o teste técnico, enviou o link e agora está naquele limbo ruim: relendo o repositório, lembrando de uma função que podia estar melhor, pensando se o README ficou claro, imaginando se a pessoa avaliadora abriu o projeto do jeito certo. Ou pior: a reprovação chegou. Sem feedback. Com uma frase genérica. Ou com silêncio depois de dias. Para quem está buscando vaga junior, teste técnico costuma parecer veredito. Se passou, "talvez eu sirva". Se não passou, "talvez eu não seja bom". Esse peso atrapalha porque mistura três coisas diferentes: a qualidade da sua entrega, a qualidade do processo da empresa e o encaixe da vaga naquele momento. Um debrief serve para separar essas coisas. Debrief não é autópsia emocional de madrugada. É uma revisão curta, objetiva e reaproveitável. Você olha para o teste como evidência: o que funcionou, o que quebrou, o que ficou mal explicado, o que a próxima candidatura precisa corrigir. Se você ainda está antes da entrega, leia primeiro o guia de [teste técnico para vaga junior](/carreira/teste-tecnico-junior/). Este texto é para o depois: quando já existe um repositório, uma resposta, um silêncio ou uma reprovação para aprender. ## faça o debrief no tempo certo Não revise o teste cinco minutos depois de enviar. Sua cabeça ainda está no modo "encontrar defeito". Também não espere três semanas, porque você esquece decisões, atalhos e dúvidas reais. Use uma regra simples: - se você acabou de entregar, faça uma revisão leve no dia seguinte; - se recebeu reprovação, espere a emoção baixar e revise em até 48 horas; - se a empresa sumiu, faça o debrief quando o processo completar o prazo que você registrou na [planilha de candidaturas](/carreira/planilha-candidaturas-junior/); - se recebeu feedback, registre no mesmo dia antes de tentar interpretar demais. O objetivo não é sofrer de novo. É capturar informação enquanto ela ainda está fresca. Limite de tempo: 30 a 45 minutos. Passou disso, provavelmente você saiu de análise e entrou em ruminação. ## comece pelo que era avaliado, não pelo que você queria mostrar Junior costuma revisar teste técnico pela régua errada: > "Usei arquitetura boa?" > "Meu código parece profissional?" > "Será que deveria ter colocado Docker?" Essas perguntas podem importar, mas vêm depois. A primeira pergunta é mais simples: **o teste avaliava o quê?** Volte no enunciado e marque os sinais: - fluxo principal funcionando; - leitura de requisito; - organização do projeto; - clareza de README; - tratamento de erro; - testes mínimos; - consumo de API; - modelagem de dados; - comunicação de decisões; - limite de tempo. Depois compare com sua entrega. Não com a entrega perfeita da sua cabeça. Com o que foi pedido. Exemplo: ```text Teste: API simples de tarefas Pedido explícito: criar, listar, atualizar status, deletar Critérios citados: código organizado, README, testes seriam diferencial Minha entrega: criar/listar/atualizar ok, delete sem validação boa, README ok, sem testes Sinal principal: núcleo entregue, mas faltou teste mínimo e validação de erro ``` Isso é muito mais útil do que "sou ruim em backend". ## separe bug, escopo e apresentação Depois de uma entrega, quase todo incômodo cai em uma destas três caixas. **Bug** é algo que deveria funcionar e não funcionou: projeto não roda, endpoint quebra, formulário não envia, teste falha, instrução do README está errada. **Escopo** é algo que você queria fazer, mas ficou fora: filtro avançado, autenticação, responsividade melhor, testes extras, paginação, deploy. **Apresentação** é o jeito como a entrega foi entendida: README confuso, commits bagunçados, decisão não explicada, limitação escondida, nome de variável ruim, ausência de screenshot. Misturar as três caixas gera culpa. Separar gera ação. Se o problema foi bug, seu próximo treino é confiabilidade: rodar do zero, testar fluxo principal, revisar instruções. Se o problema foi escopo, seu próximo treino é corte: definir entrega mínima antes de codar, proteger tempo e dizer o que ficou fora. Se o problema foi apresentação, seu próximo treino é comunicação: README, mensagem de entrega, comentários de decisão e organização do repositório. Para vaga junior, apresentação pesa muito. Um projeto simples e fácil de avaliar costuma ir melhor do que um projeto ambicioso que só roda na sua máquina. ## revise o README como se você fosse a pessoa avaliadora Abra seu repositório em uma janela anônima ou peça para alguém abrir sem contexto. A pergunta é brutal: > Uma pessoa ocupada consegue entender e rodar isso em cinco minutos? Confira: - o objetivo do projeto aparece no começo? - tem versão da linguagem ou runtime? - os comandos de instalação e execução estão completos? - existe `.env.example` quando necessário? - o fluxo principal está descrito? - você explica decisões importantes? - você lista limitações conhecidas sem parecer desculpa? - tem próximos passos realistas? Se a resposta for não, o problema talvez não fosse o código. Talvez fosse avaliabilidade. Use o guia de [README de projeto para junior](/carreira/readme-projeto-junior/) como checklist. A pessoa avaliadora não deveria precisar adivinhar por que você fez determinada escolha. Um trecho útil de README depois de teste técnico: ```text Priorizei o fluxo de cadastro/listagem porque era o núcleo do enunciado. Não implementei autenticação porque não estava no escopo e extrapolaria o limite de tempo. Com mais tempo, adicionaria testes de integração para os fluxos de edição e remoção. ``` Isso não diminui sua entrega. Mostra maturidade. ## transforme feedback em evidência, não em sentença Quando a empresa dá feedback, mesmo curto, copie a frase exata para sua planilha antes de interpretar. Exemplo: ```text Feedback recebido: "Sentimos falta de testes e de uma explicação melhor sobre as decisões técnicas." Interpretação útil: preciso incluir pelo menos teste do fluxo principal e uma seção de decisões no README. Interpretação inútil: não sei testar, meu projeto é fraco, ninguém vai me contratar. ``` Feedback genérico também ensina, mas menos. Se veio "seguimos com outro perfil", registre como feedback fraco. Não invente motivo. Se a empresa apontou algo específico, escolha no máximo dois ajustes para a próxima semana. Não transforme uma frase em lista de 17 cursos. Boa ação: - adicionar teste mínimo no projeto principal do portfólio; - refazer o README de um projeto; - treinar explicação de trade-off para entrevista técnica; - estudar uma lacuna repetida em dois ou mais processos. Má ação: - abandonar sua stack inteira; - apagar o portfólio; - passar um mês sem aplicar porque "precisa ficar pronto"; - decidir que toda empresa reprova por motivo justo. Feedback é dado. Dado precisa de contexto. ## quando não existe feedback, procure padrões Ghosting e reprovação genérica são comuns. Irritam, mas não podem virar investigação infinita. Sem feedback, olhe para sinais que você controla: - o projeto rodava do zero? - você respeitou o prazo? - a entrega respondia ao enunciado? - tinha instrução clara? - você explicou limitações? - o teste era proporcional a uma vaga junior? - a vaga já parecia [fake junior](/blog/fake-junior-como-identificar/)? Depois olhe para padrão, não para caso isolado. Se três testes técnicos diferentes apontam para falta de teste, isso é sinal. Se uma empresa sumiu depois de pedir um projeto enorme, isso pode dizer mais sobre a empresa do que sobre você. O guia de [reprovação em processo seletivo junior](/carreira/reprovacao-processo-seletivo-junior/) ajuda a separar etapa, evidência e ajuste sem transformar cada não em identidade. ## salve uma versão reaproveitável do aprendizado Nem todo teste pode virar portfólio. Cuidado com código proprietário, enunciado confidencial, dados privados e regras do processo. Mas quase todo teste pode virar aprendizado reaproveitável: - um checklist de README; - uma função reescrita com testes; - uma anotação sobre escopo; - uma versão genérica do projeto; - um post curto no LinkedIn explicando aprendizado sem expor a empresa; - uma melhoria em um projeto já público. Se o teste foi uma API de tarefas, talvez você não publique o desafio original. Mas pode publicar um projeto próprio com problema parecido, README melhor e decisões claras. Isso conecta com o guia de [portfólio com 3 projetos certos](/carreira/portfolio-3-projetos/) e com a página de [vagas tech no Brasil](/vagas/), onde você consegue comparar stacks e exigências reais. Também dá para usar outros sites do portfólio como apoio específico. Se o desafio foi em Python, por exemplo, vale estudar uma trilha mais focada em teste técnico Python em vez de procurar conselho genérico. ## use uma ficha simples de debrief Copie este modelo para sua planilha, Notion, arquivo Markdown ou caderno: ```text Empresa / vaga: Tipo de teste: Tempo gasto: Entrega enviada: O que o enunciado pedia: - - - O que funcionou: - - O que ficou fraco: - bug: - escopo: - apresentação: Feedback recebido, se houve: Um ajuste para o próximo teste: Um ajuste para meu portfólio/CV/README: Data para revisar de novo: ``` Repare que o modelo força escolha. "Um ajuste". Não dez. Junior procurando emprego precisa de ciclo, não de paralisia. ## não refaça o teste inteiro por vergonha Depois da reprovação, dá vontade de refazer tudo para provar que você conseguiria. Às vezes isso ajuda. Muitas vezes é fuga. Refaça só se houver um motivo claro: - o teste revelou uma lacuna técnica repetida; - o projeto pode virar portfólio genérico; - você quer treinar um conceito específico; - o feedback apontou algo que vale praticar. Não refaça para tentar apagar a sensação de reprovação. Isso não escala. Você precisa de energia para aplicar, conversar, estudar e descansar. Uma regra prática: se for refazer, defina limite de duas horas e um objetivo específico. Exemplo bom: ```text Vou adicionar testes para os dois endpoints principais e melhorar o README. Tempo máximo: 2h. ``` Exemplo ruim: ```text Vou reconstruir tudo perfeito do zero. ``` Perfeição depois do processo não muda a decisão. Aprendizado muda os próximos processos. ## feche o ciclo com uma próxima ação pequena Debrief só vale se termina em ação. Escolha uma: - atualizar o README do projeto principal; - adicionar teste mínimo em um fluxo; - ajustar a seção de projetos no CV; - preparar explicação curta sobre uma decisão técnica; - revisar uma base específica por 30 minutos; - aplicar para três vagas melhores filtradas; - pedir feedback com uma mensagem educada; - registrar o processo na planilha. Se você não sabe qual escolher, escolha a que reduz atrito na próxima avaliação. Para muita gente junior, isso é README e instrução de execução. O ciclo fica assim: 1. entregou ou recebeu retorno; 2. esperou a emoção baixar; 3. revisou enunciado contra entrega; 4. separou bug, escopo e apresentação; 5. registrou feedback ou ausência dele; 6. escolheu um ajuste; 7. voltou para candidaturas melhores. Esse processo não garante aprovação. Nada garante. Mas evita que cada teste técnico vire um buraco emocional sem aprendizado. ## a regra final Teste técnico não é só uma chance de conseguir uma vaga. É também uma amostra de como você trabalha sob requisito, prazo e incerteza. Depois da entrega, revise como profissional: com evidência, limite e próximo passo. Não como juiz da própria carreira. Você não precisa transformar toda reprovação em crise. Precisa transformar algumas reprovações em ajustes concretos. Isso já muda a qualidade da próxima candidatura, da próxima conversa técnica e do próximo projeto que alguém vai abrir para avaliar você.