Reconhecer padrões em problemas

O problema

Muita gente tenta decorar uma lista enorme de truques para entrevista.

Sob pressão, a pessoa até reconhece um nome conhecido, mas não sabe explicar por que ele cabe ali.

O resultado é depender de memória fraca em vez de entender o formato do problema.

Isso gera dois problemas clássicos:

• usar técnica errada só porque o nome parecia familiar
• acertar a técnica certa, mas não conseguir justificar a escolha

Modelo mental

Padrão não é atalho mágico.

É um formato recorrente para resolver um gargalo estrutural específico.

Em vez de perguntar:

Qual truque resolve isso?

A pergunta melhor é:

Que tipo de estrutura este problema está pedindo?

Quando você troca a pergunta, sai de memória decorada e entra em decisão justificada.

O nome do padrão vira consequência.

Não ponto de partida.

Quebrando o problema

Primeiro localize o atrito principal

Antes de pensar em técnica, pergunte:

• estou buscando rápido?
• estou agrupando?
• estou ordenando?
• estou tentando reduzir comparações?
• estou acompanhando uma janela ou prefixo?

O padrão costuma nascer daí.

Pergunte o que precisa ser lembrado

Essa pergunta é muito útil.

Se o problema pede lembrar rápido o que já passou, normalmente alguma estrutura de acesso rápido aparece:

• Hash Set
• Hash Map
• cache por chave

Se precisa sempre do menor ou maior atual, heap começa a fazer sentido.

Se precisa andar em ordem sem voltar toda hora, two pointers ou sliding window podem começar a encaixar.

Veja se a ordem importa

Muita escolha muda por causa disso.

Exemplos:

• posso ordenar sem estragar o problema?
• preciso preservar índice original?
• posso reprocessar os dados?

Ignorar isso faz muita gente usar técnica correta no problema errado.

Não pule a baseline

A baseline simples ainda importa porque ela mostra o gargalo real.

Sem isso, você corre o risco de dizer “sliding window” ou “two pointers” como se o nome se autoexplicasse.

E nome de técnica, sozinho, não compra confiança de ninguém.

Exemplo simples

Imagine a pergunta:

Dado um array enorme de transações, retorne true se existe um par que soma um valor alvo.

Uma reação júnior costuma ser ir de loop duplo.

Uma reação decorada costuma ser falar “isso é Two Sum”.

Uma reação madura olha para a estrutura do problema:

• preciso percorrer muitos itens
• preciso lembrar o que já vi
• preciso achar complemento rápido

Isso pede Hash Set ou Hash Map.

Não porque você decorou o nome famoso.

Mas porque o problema exige busca rápida sobre dados já vistos.

Erros comuns

• Forçar algoritmo complexo só porque foi o último que você estudou.
• Falar o nome da técnica sem explicar o mecanismo.
• Pular a baseline e perder a chance de mostrar o gargalo real.
• Achar que dizer “sliding window” já resolve a entrevista.

Como um senior pensa

Quem tem mais experiência não joga o nome do algoritmo e espera que a conversa acabe.

Justifica qual restrição obrigou aquela escolha.

O tom costuma ser este:

Como preciso verificar rápido se já vi esse valor antes, loop duplo estoura custo. Para ganhar busca O(1), troco memória por velocidade com Hash Map.

Isso é melhor porque mostra:

• problema
• gargalo
• troca
• motivo

Essa ordem importa porque o entrevistador não quer só saber se você lembra a ferramenta.

Quer saber se você sabe por que tirou aquela ferramenta da caixa.

O que o entrevistador quer ver

Em entrevista de algoritmo, isso mostra profundidade.

O entrevistador quer ver se você:

• enxerga o formato do problema por baixo do enunciado
• escolhe estrutura de dados para atacar o gargalo principal
• justifica o custo da escolha

Reconhecer padrão não é lembrar nome famoso. É perceber qual estrutura derruba o atrito real do problema.

Quando a justificativa aparece, o padrão deixa de ser truque e vira engenharia.