Como Explicar sua Solução sem se Perder

O problema

Muita gente chega na solução certa e ainda assim perde ponto na entrevista.

Não porque o código estava errado.

Mas porque a explicação saiu ruim.

Os dois jeitos mais comuns de estragar isso são:

• falar pouco demais e obrigar o entrevistador a adivinhar
• falar demais e enterrar a ideia principal em ruído

Nos dois casos, o seu critério técnico fica menos visível do que deveria.

Modelo mental

Explicar solução não é narrar tudo o que passou pela sua cabeça.

É mostrar o suficiente para a outra pessoa confiar no seu julgamento.

Na prática, quase toda boa explicação cabe em três partes:

1. qual caminho você escolheu
2. qual custo esse caminho tem
3. por que esse custo faz sentido neste problema

Se uma resposta tem esses três elementos, ela já começa a soar madura.

Quebrando o problema

Primeiro diga a versão base

Antes de falar da versão otimizada, deixe claro qual é a solução mais simples que resolve o problema.

Isso ajuda porque:

• mostra que você sabe sair do zero
• cria referência para comparar melhorias
• evita parecer que você pulou direto para truque decorado

Depois nomeie o principal custo

Toda solução cobra alguma coisa:

• tempo
• memória
• complexidade
• mudança de ordem dos dados
• pior caso ruim

Se você mesmo aponta isso cedo, a conversa fica melhor.

Porque agora o entrevistador percebe que você não está tentando vender solução perfeita.

Você está mostrando critério antes de ser pressionado.

Só então diga por que trocaria de abordagem

O salto de uma solução para outra precisa ter motivo.

Esse motivo normalmente vem de uma restrição como:

• preciso de uma passada só
• preciso preservar índice
• preciso reduzir memória
• preciso aguentar escala maior

Sem essa ponte, a resposta vira catálogo de técnica.

Fale por blocos, não por pensamento cru

Um erro comum é resolver em silêncio e depois despejar tudo de uma vez.

Outro é narrar cada microideia enquanto ainda está se achando.

O meio-termo melhor costuma ser:

1. enquadrar o problema
2. propor baseline
3. expor custo
4. justificar a melhora

Esse ritmo deixa a resposta acompanhável.

Exemplo simples

Imagine uma pergunta de soma alvo em array.

Uma resposta fraca seria:

Eu usaria two pointers.

Ela não está exatamente errada.

Mas deixa muita coisa em aberto:

• por que two pointers?
• preciso ordenar?
• isso preserva índice?
• qual foi o custo aceito?

Uma resposta melhor seria:

A versão mais simples é ordenar e usar two pointers. Isso custa O(N log N) e muda a ordem original. Se eu preciso preservar os índices e resolver em uma passada, eu troco para Hash Map, pago O(N) de memória e ganho busca rápida.

Em poucas frases você mostrou:

• baseline
• custo
• motivo da troca
• alinhamento com a restrição

E, mais importante, você poupou o entrevistador de ter que arrancar o raciocínio de você.

Erros comuns

• Descrever sintaxe em vez de arquitetura da resposta.
• Jogar buzzword e assumir que o nome da técnica já se explica.
• Esconder a fraqueza da própria solução para tentar parecer mais forte.
• Pular direto para a versão “esperta” sem mostrar por que ela é necessária.

Como um senior pensa

Quem tem mais experiência costuma explicar para gerar confiança, não para parecer brilhante.

O ritmo costuma ser este:

Minha baseline é X. O principal custo de X é Y. Se a restrição for Z, eu pivoto para W por este motivo.

Isso parece simples, mas é exatamente o que deixa a conversa limpa.

Porque mostra:

• direção
• limite
• critério

O que o entrevistador quer ver

Em entrevista técnica, o entrevistador quer ver se você consegue tornar sua decisão fácil de seguir.

Normalmente ele está avaliando se você:

• sabe estruturar a resposta e não só chegar na ideia
• aponta a limitação da solução antes de ser cobrado
• conecta técnica com restrição do problema
• mantém a conversa clara mesmo sob pressão

Explicar bem não é falar mais. É tornar sua decisão técnica fácil de confiar.

Quando a sua linha de raciocínio fica visível, a qualidade da solução aparece junto.