Como Explicar Decisões no PR em Entrevista de Code Review

O problema

Muita gente entra em entrevista de code review achando que precisa provar esperteza.

Aí aparecem dois comportamentos ruins:

• caçar qualquer detalhe para mostrar volume
• dar opinião com tom de sentença final

Isso costuma soar pior, não melhor.

Porque revisão madura não é coleção de pitacos.

É leitura de risco com comunicação útil.

Modelo mental

Um comentário bom de code review geralmente responde três perguntas:

1. o que me preocupa aqui?
2. por que isso importa?
3. o que eu faria em vez disso?

Se quiser uma versão curta:

Em review, a qualidade do raciocínio pesa mais do que a quantidade de comentários.

Você não está ali para performar severidade.

Está ali para mostrar julgamento.

Quebrando o problema

Primeiro diferencie tipo de comentário

Nem tudo tem o mesmo peso.

Algumas observações são:

• bug provável
• risco de comportamento futuro
• problema de legibilidade
• preferência de estilo

Misturar tudo no mesmo tom enfraquece sua revisão.

Se preferência e bug parecem ter o mesmo peso, o avaliador perde sinal sobre sua priorização.

Depois explique impacto

Dizer “isso está errado” ajuda pouco.

Melhor dizer algo como:

• isso pode quebrar quando a lista vier vazia
• isso duplica regra e dificulta manutenção
• isso abre risco de chamada redundante

Impacto claro faz o comentário soar técnico e útil.

Proponha direção viável

Nem sempre você precisa escrever a solução inteira.

Mas vale apontar a direção:

• mover validação para mais perto da entrada
• separar responsabilidade
• evitar efeito colateral dentro de render
• cobrir edge case com teste

Isso mostra que você não só detecta problema.

Você ajuda a resolver.

Priorize antes de detalhar

Numa revisão ao vivo, normalmente é melhor falar primeiro dos pontos mais graves.

Algo como:

• um problema funcional
• um risco de manutenção
• um detalhe menor opcional

Essa ordem costuma soar mais madura do que despejar observação em ordem aleatória de leitura.

Exemplo simples

Imagine um PR em que:

• a função faz fetch sem tratar erro
• mistura transformação de dado com render
• tem um nome de variável ruim

Uma revisão fraca pode gastar tempo demais no nome da variável.

Uma revisão boa provavelmente começaria assim:

1. “Meu ponto principal é que falta tratamento de erro e isso pode deixar a tela em estado inconsistente.”
2. “Também notei que a transformação está acoplada ao render, o que tende a dificultar teste e manutenção.”
3. “Por fim, eu talvez renomeasse esta variável para deixar a intenção mais clara.”

Perceba a diferença:

não é só apontar.

É hierarquizar.

Erros comuns

• Dar o mesmo peso para bug sério e preferência pessoal.
• Comentar muito e priorizar pouco.
• Soar agressivo ou absoluto em vez de colaborativo.
• Apontar problema sem explicar impacto.
• Falar só de estilo quando existe risco funcional mais importante na frente.

Como um senior pensa

Quem revisa bem costuma ler com perguntas como:

• isso pode quebrar comportamento?
• isso pode criar custo futuro?
• isso é importante agora ou é só preferência?
• qual comentário realmente melhora o PR?

Esse filtro faz diferença enorme.

Senioridade em review não é achar mais defeito.

É achar o defeito certo, explicar bem e manter a conversa útil.

O que o entrevistador quer ver

Ele quer ver se você:

• sabe priorizar observações
• distingue risco real de gosto pessoal
• comunica impacto com clareza
• mantém tom de colaboração

Se seus comentários soam como “este ponto me preocupa por causa disso, eu sugeriria aquilo”, você já está mostrando o tipo de revisão que ajuda um time de verdade.

Code review forte não é o mais afiado. É o mais útil.

Em entrevista, seu tom de colaboração diz tanto sobre você quanto a qualidade técnica da observação.