Middle Technical Support Engineer — Perguntas de entrevista para engenheiro de suporte técnico

Um erro específico apareceu em doze tickets este mês sem uma causa raiz comum visível ainda. Como você investiga?

Reúna os doze tickets e procure o que realmente é comum — navegador, plano, feature flag, horário do dia, região — em vez de assumir que não têm relação porque o sintoma aparente varia. Reproduza com a condição compartilhada mais restrita que encontrar, e depois verifique deploys ou mudanças de configuração recentes por volta de quando o padrão começou. Se não conseguir reproduzir, isso já é um dado que vale a pena repassar para engenharia em vez de fechar os tickets como casos isolados.

Como você dá um prazo para o cliente quando genuinamente não sabe quanto tempo uma correção vai levar?

Dê um horário para a próxima atualização, não para a resolução, porque prometer um prazo de correção que você não consegue cumprir é pior do que um honesto "ainda não tenho um prazo, mas volto a falar com você até as 15h". Quando engenharia der uma estimativa real, repasse com a mesma honestidade sobre a incerteza. Clientes toleram muito melhor não saber do que serem informados de algo que depois se revela falso.

Como você equilibra CSAT e tempo de resolução quando eles puxam em direções opostas?

Uma resolução apressada que na verdade não resolve o problema derruba o CSAT no contato seguinte, mesmo que pareça rápida no relatório, então velocidade sem correção é uma vitória falsa. A alavanca de verdade costuma ser a primeira resposta e o ritmo das atualizações — o cliente avalia a experiência de esperar, não só os minutos totais, então uma correção mais lenta com atualizações claras muitas vezes pontua melhor do que uma rápida que fica em silêncio depois.

Um ticket já foi repassado entre suporte e engenharia três vezes sem resolução. O que você faz?

Pare o ping-pong assumindo você mesmo como ponto único de contato — leia todo o histórico, escreva um resumo de um parágrafo do que realmente se sabe, e marque uma sincronização curta em vez de mais um repasse assíncrono. A maioria desses loops acontece porque cada lado está respondendo a uma pergunta ligeiramente diferente; fazer todo mundo falar sobre o mesmo caso de reprodução geralmente quebra o ciclo.

Sua fila de tickets está em 200 e crescendo. O que você realmente faz diferente em relação a um dia normal?

Primeiro, priorização em lote — ordenar por gravidade e risco de quebra de SLA antes de responder qualquer coisa, em vez de trabalhar de cima para baixo pela ordem de chegada. Envie respostas de espera rápidas nos tickets de menor prioridade para parar o relógio do SLA e ganhar tempo, e depois trate as verdadeiras emergências. E sinalize a fila em si para o seu líder, porque uma fila crescente costuma ser um sinal de falta de pessoal ou de um bug recorrente, não algo para absorver em silêncio.