Mock debugging round: simulação com avaliação e resposta melhorada

O problema

Round de debugging derruba muita gente boa porque parece familiar demais.

A pessoa pensa:

• “isso eu faço no trabalho”
• “debug eu sei”

Mas, na entrevista, o formato muda tudo.

Agora você precisa:

• investigar sob tempo
• falar enquanto pensa
• evitar chute técnico
• reagir a follow-up sem perder ordem

É por isso que mock de debugging vale tanto.

Ele mostra onde seu método quebra quando a pressão entra.

Como usar este mock

O uso melhor é:

1. leia só o prompt
2. responda em voz alta por 8 a 12 minutos
3. pare antes da avaliação
4. compare sua resposta com a leitura crítica
5. grave uma segunda versão melhorada

O objetivo não é acertar a causa raiz.

É soar disciplinado sob incerteza.

Prompt

Você está em um round de debugging. O entrevistador diz: “Depois do último deploy, alguns usuários começaram a relatar timeout na tela de pedidos. O problema não afeta todo mundo. Como você começaria a investigar?”

Resposta inicial do candidato

Eu olharia logs do backend e talvez do banco para ver se alguma query ficou lenta. Também checaria se o deploy mexeu em timeout de API ou em alguma integração. Se eu visse muita lentidão, talvez pensasse em rollback.

O que essa resposta tem de bom

• não pulou direto para mudar código
• já percebeu que deploy recente é pista forte
• deixou rollback como possibilidade, não reflexo automático

Onde ela ainda perde força

• ainda não delimitou o sintoma
• mistura investigação e mitigação cedo demais
• “olharia logs e banco” ainda está genérico
• não mostrou como reduziria espaço de busca

Até aqui, a resposta parece sensata.

Mas ainda não transmite muito método.

Follow-up 1

Pergunta do entrevistador:

O problema afeta mais contas grandes do que pequenas. Isso muda algo?

Resposta fraca:

Então deve ser o banco.

Resposta melhor:

Isso muda bastante meu recorte inicial. Se contas maiores sofrem mais, minha suspeita sobe para algum caminho sensível a volume de dados, cardinalidade ou combinação de filtros. Antes de supor causa, eu tentaria comparar requests de contas grandes e pequenas para ver se o timeout aparece ligado a query pesada, serialização de payload ou alguma chamada downstream proporcional ao tamanho da conta.

Aqui a resposta melhora porque:

• transformou informação nova em redução de escopo
• não tratou pista como prova
• mostrou próximo passo observável

Follow-up 2

Pergunta do entrevistador:

Os timeouts começaram logo depois de uma mudança na busca da tela, que agora permite filtrar por mais campos.

Resposta apressada:

Então eu revertia essa mudança.

Resposta melhor:

Essa mudança virou minha principal suspeita, mas eu ainda faria duas distinções antes de agir. Primeiro, se o timeout acontece na API de listagem como um todo ou só em combinações específicas de filtros. Segundo, se o problema é query, plano de execução ou payload excessivo. Se o impacto estiver alto e rollback for seguro, eu consideraria mitigação rápida. Mas, como passo de investigação, eu tentaria reproduzir a chamada com filtros problemáticos e comparar o comportamento antes e depois do deploy.

Aqui aparecem:

• noção de mitigação sem loteria
• foco em reproduzir o caminho ruim
• priorização de experimento em vez de palpite

Follow-up 3

Pergunta do entrevistador:

Você descobre que algumas requests geram uma query com LIKE em múltiplas colunas sem índice compatível. O que faz agora?

Resposta fraca:

Eu criaria índice.

Resposta melhor:

Índice pode ajudar, mas eu não trataria isso como resposta automática sem olhar a forma da busca e o padrão real das consultas. Se a combinação nova de filtros gerou um caminho que ficou caro por desenho, talvez eu precise primeiro conter dano: limitar certos filtros, reduzir combinações permitidas ou voltar temporariamente a uma busca menos flexível. Em paralelo, eu avaliaria se índice resolve de fato esse padrão ou se a própria estratégia de busca precisa ser redesenhada. O ponto é não confundir correção estrutural com mitigação imediata.

Avaliação do entrevistador

Se o candidato ficasse só na resposta inicial, a leitura provável seria:

• razoável
• não impulsivo
• ainda genérico

Quando ele melhora nos follow-ups, o sinal sobe porque começa a aparecer:

• delimitação de sintoma
• uso correto de pista
• hipótese tratada como hipótese
• separação entre investigação, mitigação e correção

Isso é exatamente o que costuma distinguir alguém que “já debugou bastante” de alguém que também sabe explicar bem o próprio processo.

Resposta melhorada

Se eu condensasse uma resposta mais forte desde o começo, ela soaria perto disto:

Eu começaria delimitando o sintoma antes de escolher causa. Quero entender desde quando o timeout aparece, em qual endpoint, para quais contas e se existe correlação forte com o último deploy. Como o problema não afeta todo mundo, eu trataria segmentação como pista útil e compararia requests de contas afetadas e não afetadas. Se o deploy mexeu em filtros da tela, isso já vira hipótese prioritária, mas ainda não prova a causa. Meu próximo passo seria reproduzir chamadas representativas, olhar tempo por etapa e isolar se a lentidão está em query, payload ou dependência downstream. Se o impacto estiver alto e rollback for seguro, eu consideraria mitigação rápida. Mas mesmo nessa decisão eu tentaria preservar clareza sobre o que estou mitigando e por quê.

Por que essa versão sobe o nível

• abre por sintoma e impacto
• usa segmentação como recorte, não como certeza
• prioriza comparação e reprodução
• separa mitigação de confirmação
• parece investigação, não lista de ferramentas

O que poderia melhorar ainda mais

Se o entrevistador empurrar mais, ainda daria para aprofundar:

• como instrumentaria melhor o endpoint
• como decidir entre rollback e feature flag
• como comunicaria status para o time
• como evitar regressão depois da correção

Mas isso vem depois.

Primeiro vem ordem mental.

Erros comuns nesse formato

• pular direto para rollback ou restart
• chamar qualquer pista de causa raiz
• listar logs, métricas e traces sem dizer o que procura
• misturar solução estrutural com contenção imediata
• responder follow-up como defesa da hipótese inicial

Ângulo de entrevista

Esse mock é útil porque simula um round muito comum hoje:

• sintoma incompleto
• mudança recente
• segmentação parcial
• follow-up que estreita a hipótese

Se você treina esse formato bem, melhora não só debugging round.

Melhora também a forma como fala de incidente, produção e investigação em geral.