Pensar Como Senior / Resolução de Problemas

Quebra de Problemas

Como Quebrar Problemas Sem Entrar em Pânico

Uma forma simples de transformar um ticket confuso ou uma pergunta de entrevista em decisões menores e mais confiáveis.

O problema

Chega um ticket confuso ou uma pergunta de entrevista e a vontade é correr para o código.

O problema é que, quando você faz isso cedo demais, quase sempre resolve a versão errada do problema.

Você gasta energia com sintaxe antes de fechar o que entra, o que sai e o que realmente importa.

Modelo mental

Pense no problema como algo que precisa ganhar forma antes de ganhar código.

Antes de implementar, organize quatro pontos:

  • o que entra
  • o que precisa sair
  • o que não pode quebrar
  • o que ainda está ambíguo

Quando isso fica claro, metade da dificuldade já caiu.

Quebrando o problema

Uma forma simples de começar é esta:

  1. diga com suas palavras o que o problema pede
  2. separe entrada, saída e restrições
  3. nomeie a dúvida principal
  4. reduza até a menor versão que já seria útil

O objetivo aqui não é parecer brilhante. É reduzir ruído até sobrar um problema que dá para confiar.

Exemplo simples

Imagine este pedido:

Construa um endpoint para retornar os 10 clientes com maior receita.

Uma reação apressada seria:

Acho que preciso de uma query com ordenação.

Uma reação melhor seria:

  • entrada: intervalo de datas, tenant e talvez filtros
  • saída: top 10 clientes com o valor da receita
  • restrições: precisão importa, tempo de resposta importa, empate precisa de regra
  • falhas: dado faltando, filtro inválido, consulta lenta

Agora você não tem mais um pedido solto. Você tem uma decisão pequena e clara.

Erros comuns

  • começar pela implementação antes de entender o formato do problema
  • ignorar restrições até perceber tarde demais que elas mudavam tudo
  • tentar resolver futuros cenários que ninguém pediu
  • tratar ambiguidade como licença para adivinhar

Como um senior pensa

Um senior forte não corre para parecer rápido.

Ele reduz ambiguidade antes de gastar energia.

Normalmente isso soa assim:

Antes de codar, eu quero fechar entrada, saída e principal restrição. Aí eu resolvo a versão certa do problema.

O que o entrevistador quer ver

Em entrevista, isso sinaliza três coisas rápido:

  • você entendeu o problema
  • você sabe reduzir incerteza
  • você consegue explicar seu raciocínio sem se perder

Quem faz isso bem costuma transmitir mais maturidade do que alguém que abre o editor cedo demais.

Não tente resolver tudo de uma vez. Dê forma ao problema primeiro e só depois escolha a implementação.

Se você ainda não consegue dizer entrada, saída e restrição principal, ainda não é hora de codar.

Proximas leituras