Rodadas de debugging

O problema

Muita gente vai bem em teoria e trava feio em rodada de debugging.

Não porque não saiba depurar.

Mas porque, na entrevista, o caos vem comprimido:

• pouco contexto
• pressão de tempo
• sintoma incompleto
• expectativa de raciocinar ao vivo

Aí a resposta degrada para um de dois extremos:

• lista aleatória de ferramentas
• solução precoce sem investigação de verdade

Nenhum dos dois transmite senioridade.

O que essa rodada realmente mede

Em geral, o entrevistador não está perguntando:

“Você sabe usar Datadog, Kibana, Sentry ou o painel X?”

O que ele quer saber é algo mais estrutural:

• você consegue criar ordem no meio da bagunça?
• você distingue sintoma de causa?
• você reduz o espaço de busca?
• você sabe qual pergunta responder primeiro?
• você muda de direção quando a hipótese cai?

Em outras palavras:

rodada de debugging mede método sob incerteza

Modelo mental

Uma resposta forte costuma seguir esta lógica:

1. definir o sintoma
2. reduzir o escopo
3. formar uma hipótese inicial
4. escolher o sinal mais útil para validá-la
5. dizer qual seria o próximo passo dependendo do resultado

Isso parece simples.

E é esse o ponto.

Resposta boa de debug quase nunca parece mágica. Parece organizada.

Como estruturar a resposta

1. Comece pelo que está quebrado

Antes de falar de ferramenta, diga o que você entende do sintoma.

Exemplos:

• aumento de erro 500
• lentidão em um fluxo específico
• job duplicando processamento
• falha só para parte dos usuários

Esse começo mostra que você não está tratando “debug” como um verbo genérico.

Você está começando pelo comportamento observável.

2. Reduza o escopo o mais cedo possível

Depois, estreite o problema.

Perguntas úteis:

• desde quando acontece?
• aconteceu depois de deploy, flag ou mudança de configuração?
• afeta todo mundo ou só um segmento?
• ocorre em um fluxo ou em vários?
• é intermitente ou constante?

Boa resposta de debug não tenta abraçar o sistema inteiro cedo demais.

Ela vai tirando variáveis da mesa.

3. Declare a hipótese atual

Esse ponto muda muito a percepção da resposta.

Em vez de falar:

“Eu abriria logs, depois veria o banco, depois olharia a fila”

fale algo como:

“Se o problema começou após deploy e está concentrado só no checkout com cartão, minha hipótese inicial é regressão nesse fluxo ou em uma dependência ligada a ele.”

Agora existe uma linha de investigação.

Não é checklist. É raciocínio.

4. Escolha o primeiro sinal, não a ferramenta favorita

Ferramenta importa.

Mas o que mais comunica maturidade é o critério.

Exemplos de sinais:

• taxa de erro por endpoint
• correlação com deploy
• erro concentrado em um provedor
• latência subindo em uma etapa específica
• requests que falham com um mesmo padrão

O entrevistador quer ouvir:

“eu consultaria esse sinal porque ele me ajuda a confirmar ou derrubar esta hipótese”

Esse “porque” pesa muito.

5. Diga o que faria você mudar de direção

Resposta fraca parece apaixonada pela primeira hipótese.

Resposta forte mostra critério de abandono.

Exemplo:

“Se eu visse que a falha também acontece em fluxos sem essa integração, eu descartaria essa linha e voltaria para algo mais transversal, como config, autenticação ou infraestrutura.”

Isso mostra flexibilidade sem parecer perdido.

Exemplo simples

Pergunta:

“Uma funcionalidade crítica começou a falhar em produção. Como você investigaria?”

Resposta fraca:

“Eu abriria logs, veria métricas, talvez desse rollback e depois olharia o banco.”

Nada disso é necessariamente errado.

Mas a resposta ainda está solta.

Resposta mais forte:

“Eu começaria definindo o sintoma com mais precisão: erro, lentidão ou duplicação? Depois reduziria o escopo para entender quando começou, se coincide com deploy ou mudança recente e se afeta todos os usuários ou um segmento. Com esse recorte, eu formularia a hipótese inicial mais provável e escolheria o sinal mais útil para confirmá-la antes de mudar o sistema. Se o impacto estivesse alto e houvesse mitigação segura e reversível, eu também avaliaria contenção em paralelo.”

Isso já comunica:

• ordem
• critério
• noção de impacto
• investigação antes de chute

O erro mais comum

O erro mais comum em rodada de debug é responder como se o objetivo fosse impressionar pela quantidade de coisas citadas.

Mas debug não é buffet.

Se você fala de:

• logs
• traces
• filas
• banco
• cache
• restart
• rollback
• timeout

tudo ao mesmo tempo, a impressão não é profundidade.

É ansiedade técnica.

Como um senior responde diferente

Quem responde melhor costuma passar esta sensação:

“Eu não sei a causa ainda, mas sei exatamente como reduzir a incerteza sem bagunçar mais o sistema.”

Esse é o sinal.

Não é onisciência.

É controle.

Senioridade em rodada de debug aparece quando a resposta:

• prioriza o que precisa ser entendido primeiro
• evita mudar tudo ao mesmo tempo
• separa investigação de mitigação
• deixa claro por que o próximo passo é o próximo passo

Um framework curto para guardar

Se quiser um formato simples para usar ao vivo:

1. “Primeiro eu definiria melhor o sintoma.”
2. “Depois eu reduziria o escopo.”
3. “Com isso, eu formaria a hipótese inicial.”
4. “Eu buscaria o sinal mais útil para confirmar ou derrubar essa hipótese.”
5. “Dependendo do resultado, eu decidiria entre seguir investigando, mitigar ou mudar de direção.”

Isso já resolve boa parte da rodada.

Ângulo de entrevista

Quando esse tipo de pergunta aparece, o entrevistador está vendo se você consegue:

• pensar com contexto incompleto
• manter clareza sob pressão
• criar sequência de investigação
• comunicar trade-off entre investigar e conter

Por isso, vale lembrar:

em rodada de debugging, parecer metódico vale mais do que parecer heroico

Ferramenta você aprende.

Ordem mental é o que faz a resposta subir de nível.