Pular para o conteudo principal

Arrays e Hashmaps: os Padrões que Aparecem em 80% das Perguntas

Muitas entrevistas de código viram busca, contagem, agrupamento ou acesso rápido por chave. Quase sempre array e hashmap estão no centro disso.

Andrews Ribeiro

Andrews Ribeiro

Founder & Engineer

O problema

Muita gente estuda entrevista como se cada pergunta viesse de um planeta diferente.

Na prática, uma parte enorme delas é variação do mesmo núcleo:

  • percorrer uma sequência
  • lembrar algo que já apareceu
  • contar frequência
  • achar complementar
  • agrupar por chave

O nome da pergunta muda.

O coração dela, muitas vezes, não.

É por isso que array e hashmap aparecem tanto.

Não porque o entrevistador tenha fetiche por estruturas básicas.

Mas porque muitos problemas úteis de lógica e estrutura de dados cabem exatamente nesse espaço.

Modelo mental

Array é a estrutura natural quando você está trabalhando com sequência, posição, ordem e varredura.

Hashmap entra quando a solução precisa responder rápido a uma pergunta por chave.

Exemplos clássicos:

  • “já vi esse valor?” → Set
  • “quantas vezes esse caractere apareceu?” → Hash Map de frequência
  • “em qual índice vi esse número?” → Hash Map de valor para índice
  • “quais itens pertencem ao mesmo grupo?” → Hash Map para agrupamento

Se quiser resumir:

Muita pergunta de entrevista é só uma sequência mais alguma memória auxiliar bem escolhida.

Quebrando o problema

Primeiro veja se o problema é de sequência

Se a entrada principal é:

  • array
  • lista
  • string

você já está, na prática, lidando com uma sequência.

Isso costuma significar:

  • um ou mais percursos
  • comparação entre posições
  • manutenção de janela
  • prefixo, sufixo ou contagem acumulada

O array puro já resolve bastante coisa.

Depois pergunte o que a solução precisa lembrar

Essa pergunta separa solução lenta de solução eficiente muito rápido.

Se a resposta for “preciso lembrar do que já apareceu”, Set entra na conversa.

Se for “preciso saber quantas vezes apareceu”, entra um mapa de frequência.

Se for “preciso achar o índice anterior”, entra um mapa de valor para índice.

Se for “preciso juntar por categoria”, agrupamento por chave.

Essa é a parte realmente importante.

Não é decorar Two Sum.

É perceber que o problema quer busca rápida sobre coisas que foram vistas no caminho.

Os três formatos mais comuns

1. Presença

Perguntas como:

  • existe duplicado?
  • já vi esse valor?
  • esse elemento pertence ao conjunto?

Costumam pedir Set.

2. Frequência

Perguntas como:

  • qual caractere mais aparece?
  • duas strings são anagramas?
  • qual número aparece k vezes?

Costumam pedir Hash Map de contagem.

3. Índice ou complementar

Perguntas como:

  • existe par que soma alvo?
  • onde apareceu o complemento?
  • qual foi a última posição desse valor?

Costumam pedir mapa de valor para informação associada.

Não pule a baseline

Mesmo quando você reconhece o padrão cedo, vale dizer a versão simples primeiro.

Por exemplo:

“Daria para resolver com dois loops, mas aí eu repetiria trabalho. Como a pergunta precisa de busca rápida por valor já visto, eu troco para Hash Map.”

Isso mostra evolução de raciocínio.

Não só por reflexo condicionado.

Exemplo simples

Pegue a pergunta clássica:

Dado um array de inteiros e um alvo, encontre dois índices cuja soma dá o alvo.

Baseline

Comparar cada elemento com todos os outros.

Isso funciona.

Mas custa O(n²).

Versão com hashmap

Percorra o array uma vez.

Para cada número:

  1. calcule o complemento que falta
  2. veja se ele já apareceu
  3. se apareceu, você encontrou a resposta
  4. se não apareceu, guarde o número atual com seu índice

Agora o raciocínio vira:

  • sequência: array
  • memória necessária: valor já visto com índice
  • estrutura escolhida: Hash Map

Tempo médio: O(n).

Espaço: O(n).

O padrão por trás da pergunta não é “lembre a solução de Two Sum”.

É:

Preciso consultar rapidamente algo que apareceu antes no percurso.

Erros comuns

  • Usar Hash Map sem conseguir explicar o que a chave representa.
  • Pular para estrutura sofisticada quando um Set simples resolve.
  • Esquecer que array ainda é importante para ordem, posição e varredura.
  • Tratar problema de frequência como se fosse só busca de presença.
  • Decorar solução pronta e travar quando a pergunta muda um detalhe.

Como um senior pensa

Quem tem mais repertório quase nunca começa pelo nome famoso do problema.

Começa pela forma do dado e pela pergunta dominante.

O raciocínio costuma ser:

  • estou percorrendo uma sequência
  • preciso lembrar o quê?
  • por quanto tempo preciso lembrar?
  • basta presença, ou preciso contar, indexar ou agrupar?

Isso reduz muito a quantidade de “truques” que você acha que precisa decorar.

No trabalho real, essa mesma habilidade aparece em parser, analytics, deduplicação, feed, validação e transformação de dados.

Então não é repertório de entrevista isolado do mundo.

É raciocínio básico de estrutura de dados.

O que o entrevistador quer ver

Ele quer perceber que você:

  • enxerga o padrão estrutural do problema
  • sabe construir uma baseline
  • melhora a solução por motivo claro
  • escolhe a estrutura certa para o tipo de memória que precisa

Se você diz “essa pergunta parece de sequência com consulta rápida ao que já passou, então faz sentido usar Hash Map”, sua resposta já começou madura.

Muitos problemas parecem diferentes na superfície. Por baixo, eles só pedem memória bem escolhida.

Quando você entende o padrão, para de caçar truque e começa a tomar decisão.

Resumo rápido

O que vale manter na cabeça

Checklist de pratica

Use isto ao responder

Você concluiu este artigo

Próximo artigo Strings: Manipulação e Padrões Frequentes em Entrevistas Artigo anterior Reconhecer padrões em problemas

Continue explorando

Artigos relacionados