O que Entrevistadores Olham em Exercício Prático além do Código

O problema

Quando alguém recebe exercício prático, é comum reduzir a missão a uma pergunta só:

“como eu escrevo o melhor código possível?”

Essa pergunta é importante.

Mas é incompleta.

Porque o avaliador raramente está olhando apenas para:

• correção
• estilo
• arquitetura

Ele também está tentando inferir como você trabalha.

Modelo mental

Exercício prático é uma amostra comprimida de comportamento profissional.

O código continua sendo central.

Mas, ao redor dele, existe muito sinal:

• como você entendeu o problema
• como priorizou
• como organizou a entrega
• como explicou decisões
• como lidou com limite de tempo

Um bom resumo seria:

O exercício não mede só se você sabe implementar. Mede se você sabe escolher, comunicar e fechar a entrega com critério.

Quebrando o problema

O código é o núcleo, não o todo

Claro que o avaliador olha:

• se funciona
• se é legível
• se o raciocínio faz sentido

Mas ele também percebe se você gastou energia onde mais importava.

Escopo revela maturidade

Uma entrega pode ter menos features e ainda assim sinalizar melhor.

Isso acontece quando fica claro que você soube:

• proteger o fluxo principal
• evitar complexidade vaidosa
• deixar extras fora por escolha, não por acidente

Comunicação muda a leitura do código

README, comentários úteis, estrutura do repositório e notas de trade-off ajudam o avaliador a entender seu julgamento.

Sem isso, parte do trabalho fica invisível.

Acabamento operacional também pesa

Muita gente esquece que fricção para rodar a solução joga contra.

Coisas simples contam:

• instruções claras
• comandos funcionando
• organização mínima
• teste ou validação onde faz sentido

Exemplo simples

Imagine duas entregas para o mesmo take-home.

A primeira tem mais feature, mas:

• README fraco
• setup confuso
• algumas decisões sem explicação
• fluxo principal meio inconsistente

A segunda tem menos escopo, mas:

• fluxo principal sólido
• projeto fácil de rodar
• decisões bem explicadas
• lista clara do que ficou fora e por quê

Muitas vezes a segunda gera mais confiança.

Não porque tem menos código.

Mas porque parece trabalho profissional mais controlado.

Erros comuns

• Achar que só funcionalidade importa.
• Esconder limitação em vez de explicitar trade-off.
• Usar complexidade para tentar parecer senior.
• Entregar algo difícil de rodar ou entender.
• Ignorar o valor de README, estrutura e explicação.

Como um senior pensa

Quem tem mais maturidade costuma olhar para o exercício como um pacote completo de sinais.

O raciocínio fica perto de:

• o que preciso provar aqui?
• o que aumenta confiança sem explodir escopo?
• o que pode ficar simples sem prejudicar a leitura do meu julgamento?
• como deixo a entrega fácil de entender para alguém com pouco tempo?

Essa cabeça faz a pessoa otimizar para confiança, não para volume.

O que o entrevistador quer ver

Ele quer ver se você:

• entendeu o problema certo
• priorizou bem
• construiu algo coerente
• comunicou decisões
• tratou restrição de forma madura
• deixou a entrega utilizável por outra pessoa

O código ainda é parte principal.

Mas o que convence mesmo é o conjunto.

Exercício prático forte não mostra só implementação. Mostra julgamento visível do começo ao fim.

Quando a entrega é clara, priorizada e fácil de avaliar, o código trabalha a seu favor em vez de lutar por atenção.