Perguntas de entrevista para engenheiro de suporte técnico

Descreva seu processo de diagnóstico quando um cliente relata "não está funcionando".

Comece transformando uma reclamação vaga em um fato reproduzível: o que a pessoa estava fazendo, o que esperava, o que aconteceu de fato e se você mesmo consegue ver isso. Depois reduza o espaço de busca isolando variáveis — outro navegador, outra conta, outra rede — antes de mexer em logs ou código. Só depois de conseguir reproduzir, ou de conseguir explicar claramente por que não consegue, é que você parte para a causa raiz, porque tentar adivinhar uma correção para um problema não delimitado desperdiça o tempo de todo mundo.

Um usuário envia um print de um erro e nada mais. O que você faz?

Primeiro extraia do print tudo o que ele realmente contém — código de erro, horário, URL, algum ID de requisição — antes de pedir mais informações, porque metade do que você precisa muitas vezes já está ali. Depois faça perguntas de acompanhamento específicas em vez de um genérico "me manda mais detalhes": o que estava fazendo logo antes, se acontece sempre, qual navegador e sistema operacional. Uma pergunta específica traz uma resposta útil mais rápido do que uma aberta, e mostra ao cliente que você já olhou.

Qual é a diferença entre um código de status HTTP 4xx e um 5xx, e por que isso importa para a triagem?

4xx significa que a própria requisição estava errada — autenticação inválida, parâmetro ausente, não encontrado —, o que geralmente aponta para o cliente ou para os dados informados. 5xx significa que o servidor falhou ao processar uma requisição válida, o que aponta para o seu lado e é um sinal mais forte de que algo está realmente quebrado, e não mal utilizado. Ver um 5xx em um ticket geralmente é motivo para escalar para engenharia mais rápido do que um 4xx, que mais frequentemente se resolve com instruções.

Como você escreve um relatório de bug com o qual um desenvolvedor consiga trabalhar sem precisar te fazer perguntas de acompanhamento?

Inclua os passos exatos de reprodução em ordem, o resultado esperado, o resultado real e o ambiente — navegador, conta, horário, ID de requisição ou pedido, se relevante. Anexe o texto bruto do erro ou um trecho do log em vez de uma paráfrase, porque o desenvolvedor precisa da string exata para buscar. Um relatório acionável imediatamente é a diferença entre uma correção no mesmo dia e uma semana de idas e vindas no Slack.

Como você explica uma interrupção técnica para um cliente sem conhecimento técnico sem mentir nem afogá-lo em jargão?

Descreva o que está quebrado em termos do que o cliente não consegue mais fazer, não do que falhou internamente — "o checkout está falhando agora para alguns usuários" é melhor do que "nosso gateway de pagamento está retornando timeout". Dê um status honesto e um horário concreto para a próxima atualização, mesmo que a atualização seja "ainda não há novidades", porque o silêncio é percebido pior do que más notícias. Deixe a causa interna de fora, a menos que perguntem, e mesmo assim resuma em uma única frase simples.

Um cliente está irritado e ameaçando cancelar. Como você conduz a conversa?

Deixe-o terminar de falar sem interromper nem defender o produto de cara — a maior parte dos escalonamentos vem da sensação de não ser ouvido, não do problema técnico em si. Reconheça especificamente o que deu errado em vez de um pedido de desculpas genérico, e depois dê um próximo passo concreto com prazo em vez de garantias vagas. Se você realmente não conseguir resolver nessa ligação, diga isso claramente e explique exatamente o que acontece a seguir, em vez de deixar a conversa em aberto.

O que você procura em um sistema de tickets como Zendesk ou Intercom além de simplesmente responder tickets?

Tags e categorias que tornem padrões visíveis depois — o mesmo webhook mal configurado aparecendo em vinte tickets fica invisível se nenhum deles for marcado da mesma forma. Macros e respostas prontas para os 80% recorrentes, o que libera tempo para os 20% que realmente exigem julgamento. E um histórico limpo de notas internas e escalonamentos, porque um ticket repassado três vezes sem contexto faz todo mundo perder tempo diagnosticando de novo.

O que é first response time, e por que uma primeira resposta rápida não garante um bom tempo de resolução?

First response time é quanto tempo o cliente espera até ouvir de um humano, e é em torno disso que a maioria dos SLAs é construída, porque o silêncio é o que leva as pessoas a cancelar ou escalar publicamente. Mas um rápido "já estamos analisando" sem progresso real por trás só adia a frustração em vez de resolvê-la, então times que otimizam apenas o FRT podem acabar com confirmações rápidas e resoluções lentas e não medidas. O tempo de resolução e o CSAT precisam ser acompanhados junto, ou a métrica acaba sendo manipulada.

Sua fila tem cinquenta tickets abertos e três estão marcados como urgentes. Como você decide o que atacar primeiro?

Gravidade primeiro, não ordem de chegada — uma interrupção total que afeta muitos clientes ou bloqueia pagamento sempre passa na frente do bug cosmético de um único usuário, independentemente de quem abriu o ticket antes. Dentro da tag urgente, verifique se os três realmente atingem esse critério ou se alguém marcou um problema menor como urgente para furar a fila, porque isso acontece o tempo todo e precisa de uma definição real para contestar. O resto é trabalhado na ordem do SLA, e se a fila estiver genuinamente grande demais para uma pessoa, isso em si é um sinal para reportar, não algo para absorver em silêncio.