Desafio técnico de programação — o que fica escondido atrás da nota "aprovado"
O desafio técnico não é só sobre o código funcionar. É sobre o que sua solução revela nas escolhas que ninguém pediu explicitamente — e é aí que a maioria dos candidatos perde pontos sem perceber.
Quase todo processo seletivo de TI no Brasil tem uma etapa de desafio técnico — um projeto pequeno pra entregar em alguns dias, com prazo e escopo definidos. A maioria dos candidatos foca só em fazer funcionar. É o critério errado: "funciona" é o mínimo esperado, não o que decide se você avança.
"O código passa nos testes, mas foi rejeitado — por quê?"
O que a maioria assume: que passar nos requisitos funcionais é suficiente.
O que realmente é avaliado: as decisões que você tomou nos pontos que o enunciado deixou em aberto de propósito. Como você tratou um input inválido que não estava no exemplo? Criou algum teste além do óbvio? Um desafio bem desenhado deixa lacunas exatamente pra ver o que você faz quando ninguém está mandando.
"Por que investir tempo em código limpo se é só um teste?"
O que a maioria faz: escreve rápido, sem se preocupar com organização, porque "é só um teste".
O que realmente é avaliado: como você trabalharia no dia a dia, sem estar sob os olhos de ninguém. Um avaliador experiente lê a estrutura do projeto antes de rodar uma linha — nomes de variável, separação de responsabilidades, se existe algum commit intermediário fazendo sentido. Isso substitui, em parte, meses de acompanhamento que a empresa não tem tempo de fazer antes de contratar.
"Devo usar uma biblioteca pronta ou implementar na mão?"
O que a maioria assume: que implementar tudo na mão demonstra mais conhecimento técnico.
O que realmente é avaliado: se você sabe reconhecer quando reinventar a roda é desperdício. Usar uma biblioteca estabelecida pra resolver um problema já resolvido, e guardar o esforço próprio pra parte que realmente é o núcleo do desafio, é a decisão mais próxima do que acontece num time de verdade — onde ninguém tem tempo de reescrever tudo do zero.
"O README importa mesmo, ou é só formalidade?"
O que a maioria faz: um README de duas linhas, ou nenhum.
O que realmente é avaliado: se você consegue explicar decisões técnicas pra alguém que não estava no seu processo mental. Um README que justifica por que você escolheu essa abordagem — não só como rodar o projeto — é o primeiro sinal de como você vai se comunicar com o time depois de contratado.
"Recebi feedback de que 'faltou pensar em escala' — o que isso quer dizer num teste pequeno?"
O que a maioria acha: que escala só importa em sistemas grandes de verdade, não num desafio de teste.
O que realmente é avaliado: se você consegue nomear o próximo gargalo antes de alguém perguntar — mesmo sem implementar a solução pra ele. Um comentário tipo "essa query ficaria lenta com muitos registros, resolveria com paginação ou índice" mostra a mesma capacidade de raciocínio que resolveria de verdade, sem gastar o tempo limitado do desafio implementando algo que não era o foco.
O padrão por trás de tudo isso
Nenhuma dessas perguntas é sobre o código rodar. Todas são sobre o que suas escolhas revelam quando o enunciado não te obriga a nada específico — e é exatamente aí, nas decisões não pedidas, que o avaliador decide se você pensa como alguém do time ou como alguém que só queria terminar a tarefa.
O Prepair treina a etapa de entrevista técnica falada — perguntas de cargo e nível, com resposta avaliada na hora — não o desafio prático em si, que é avaliado por código real. Mas a mesma disciplina de explicar decisões em voz alta, sem enrolação, é o que se pratica aqui. Experimente uma entrevista grátis — 3 por mês, sem cadastro.