Como quebrar problemas

O problema

Quando chega um ticket confuso ou uma pergunta agressiva de entrevista, o reflexo comum e correr para o editor.

O problema e que, quando você acelera cedo demais, aumenta muito a chance de resolver a versão errada do problema.

Você gasta energia em sintaxe antes de travar entrada, saída, restrição e critério de sucesso.

Muita gente chama isso de “ser rápido”.

Na prática, quase sempre e só pressa mal direcionada.

Modelo mental

Trate problema cru como algo que precisa ganhar forma antes de virar código.

Antes de escrever um if, você precisa organizar quatro limites:

• o que entra
• o que precisa sair
• o que não pode quebrar
• o que ainda esta ambiguo

Quando esses quatro pontos ficam claros, metade da dificuldade vai embora.

O ponto não e transformar tudo em documento.

O ponto e parar de carregar dúvida escondida para dentro da implementação.

Quebrando o problema

Uma forma prática de reduzir risco e esta:

1. Reescreva o problema com suas palavras.
2. Separe entradas, saídas e restrições.
3. Nomeie a maior dúvida aberta.
4. Reduza o escopo para a menor versão que prova o caminho.

O objetivo não e parecer genial. E diminuir ruido até o problema ficar confiavel.

1. Reescrever ajuda a expor mal-entendido cedo

Quando você repete o pedido com suas palavras, duas coisas acontecem:

• você confirma se entendeu mesmo
• a outra pessoa percebe rápido o que ficou vago

Isso evita meia hora de implementação em cima de premissa errada.

2. Entrada, saída e restrição mudam a forma da solução

Sem isso, você só tem um tema, não um problema.

Entrada define o que você recebe.

Saída define o que precisa entregar.

Restrição define o que limita a solução:

• tempo
• custo
• volume
• compatibilidade
• corretude

3. Nomeie a maior dúvida aberta

As vezes o problema não esta difícil.

Ele esta mal especificado.

Exemplos de dúvida que valem ouro:

• o ranking e global ou por tenant?
• a busca precisa ser eventual ou em tempo real?
• esse endpoint precisa ser paginado?
• qual erro e aceitavel e qual não e?

4. Resolva a menor versão honesta

Não e para fazer MVP mal feito.

E para escolher a menor fatia que prova o caminho com segurança.

Essa diferença importa bastante.

Exemplo simples

Imagine este pedido:

“Precisamos de um endpoint que devolva os 10 clientes com maior receita.”

Uma resposta afobada seria sair escrevendo SQL.

Uma resposta melhor pausa e mapeia:

• entrada: existe faixa de data? tenant? filtro escondido?
• saída: só nome ou também valor da receita?
• restrição: precisa responder em menos de quanto?
• falha: o que acontece se empatar? e se não houver cliente?

Agora o problema deixou de ser vago e virou especificacao mais segura.

Outro exemplo bem comum em entrevista:

“Desenhe um sistema de fila para enviar notificacoes.”

Antes de sair falando de Kafka, vale travar coisas como:

• estamos falando de email, push ou SMS?
• precisa garantir ordem por usuário?
• qual volume muda a arquitetura?
• pode haver reenvio?
• qual latência e aceitavel?

Sem isso, a pessoa só esta despejando ferramenta.

Erros comuns

• Começar implementação antes de entender o formato do pedido.
• Ignorar edge case até descobrir tarde demais que ele inválida a solução.
• Resolver cenario futuro que ninguém pediu.
• Assumir requisito ambiguo e torcer para o chute estar certo.
• Confundir “quebrar o problema” com listar subtarefa aleatoria.

Como um senior pensa

Quem tem mais experiência não corre só para parecer rápido.

Primeiro derruba ambiguidade.

O tom costuma ser:

“Antes de abrir o editor, eu quero travar entrada, saída e principal restrição. Só depois vale resolver.”

Essa disciplina aumenta confiança e reduz retrabalho.

O que o entrevistador quer ver

Em entrevista de sistema ou algoritmo, isso mostra maturidade logo no começo.

• Você ouviu e entendeu a forma do problema.
• Você sabe reduzir incerteza antes de codar.
• Você consegue narrar escolha e trade-off sem se perder.

Uma resposta forte costuma soar assim:

“Antes de resolver, eu quero alinhar entrada, saída, restrições e principal incerteza. Sem isso, qualquer implementação corre o risco de estar certa para o problema errado.”

Se você ainda não consegue dizer claramente entrada, saída e restrição, ainda e cedo para implementar.