Preguntas de entrevista para ingeniero de soporte técnico

Explica tu proceso de diagnóstico cuando un cliente reporta "no funciona".

Empieza por convertir una queja vaga en un hecho reproducible: qué estaba haciendo, qué esperaba, qué pasó en realidad y si tú mismo puedes verlo. Luego reduce el espacio de búsqueda aislando variables — otro navegador, otra cuenta, otra red — antes de tocar logs o código. Solo después de reproducirlo, o de poder explicar con claridad por qué no puedes, pasas a la causa raíz, porque adivinar una solución para un problema que no has delimitado desperdicia el tiempo de todos.

Un usuario envía una captura de pantalla de un error y nada más. ¿Qué haces?

Primero extrae de la captura todo lo que realmente contiene — código de error, marca de tiempo, URL, algún ID de solicitud — antes de pedir más, porque a menudo la mitad de lo que necesitas ya está ahí. Luego haz preguntas de seguimiento concretas en vez de un genérico "envía más detalles": qué estabas haciendo justo antes, si ocurre siempre, qué navegador y sistema operativo. Una pregunta específica obtiene una respuesta útil más rápido que una abierta, y le muestra al cliente que ya revisaste.

¿Cuál es la diferencia entre un código de estado HTTP 4xx y uno 5xx, y por qué importa para la priorización?

4xx significa que la propia solicitud estaba mal formada — autenticación incorrecta, parámetro faltante, no encontrado —, lo que suele apuntar al cliente o a datos ingresados. 5xx significa que el servidor falló al procesar una solicitud válida, lo que apunta a tu lado y es una señal más fuerte de que algo realmente está roto y no mal usado. Ver un 5xx en un ticket suele ser motivo para escalar hacia ingeniería más rápido que un 4xx, que se resuelve más a menudo con instrucciones.

¿Cómo escribes un reporte de bug con el que un desarrollador pueda actuar sin tener que hacerte preguntas de seguimiento?

Incluye los pasos exactos de reproducción en orden, el resultado esperado, el resultado real y el entorno — navegador, cuenta, marca de tiempo, ID de solicitud o pedido si aplica. Adjunta el texto del error tal cual o un fragmento del log en lugar de una paráfrasis, porque el desarrollador necesita la cadena exacta para buscarla. Un reporte accionable de inmediato es la diferencia entre una corrección el mismo día y una semana de idas y vueltas por Slack.

¿Cómo explicas una caída técnica a un cliente sin conocimientos técnicos sin mentir ni saturarlo de jerga?

Describe la falla en términos de lo que el cliente ya no puede hacer, no de lo que falló por dentro — "el checkout está fallando ahora mismo para algunos usuarios" es mejor que "nuestra pasarela de pago está devolviendo timeouts". Da un estado honesto y una hora concreta para la próxima actualización, aunque esa actualización sea "todavía no hay novedades", porque el silencio se percibe peor que las malas noticias. Omite la causa interna por completo salvo que pregunten, y aun así, resúmela en una sola frase sencilla.

Un cliente está enojado y amenaza con cancelar. ¿Cómo manejas la conversación?

Déjalo terminar sin interrumpir ni defender el producto de entrada — la mayoría de los escalamientos vienen de sentirse ignorado, no del problema técnico en sí. Reconoce específicamente qué salió mal en lugar de una disculpa genérica, y luego da un siguiente paso concreto con un plazo en vez de vagas garantías. Si de verdad no puedes resolverlo en esta llamada, dilo con claridad y explica exactamente qué sigue, en lugar de dejar la conversación en el aire.

¿Qué buscas en un sistema de tickets como Zendesk o Intercom más allá de responder tickets?

Etiquetas y categorías que hagan visibles los patrones más adelante — el mismo webhook mal configurado apareciendo en veinte tickets es invisible si ninguno está etiquetado igual. Macros y respuestas predefinidas para ese 80% recurrente, que liberan tiempo para el 20% que realmente requiere criterio. Y un historial limpio de notas internas y escalamientos, porque un ticket reasignado tres veces sin contexto hace que cada persona lo tenga que diagnosticar de nuevo.

¿Qué es el first response time, y por qué una primera respuesta rápida no garantiza un buen tiempo de resolución?

El first response time es cuánto espera un cliente antes de escuchar a un humano, y es sobre lo que se construyen la mayoría de los SLAs, porque el silencio es lo que hace que la gente se dé de baja o escale públicamente. Pero un "ya lo estamos revisando" rápido sin progreso real detrás solo posterga la frustración en lugar de resolverla, así que los equipos que solo optimizan el FRT pueden terminar con confirmaciones rápidas y resoluciones lentas que nadie mide. El tiempo de resolución y el CSAT deben rastrearse junto con él, o la métrica se termina manipulando.

Tu cola tiene cincuenta tickets abiertos y tres están marcados como urgentes. ¿Cómo decides qué atender primero?

Primero la gravedad, no el orden de llegada — una caída total que afecta a muchos clientes o bloquea pagos siempre pasa por delante del bug cosmético de un solo usuario, sin importar quién escribió antes. Dentro de la etiqueta urgente, revisa si los tres realmente cumplen ese criterio o si alguien marcó un problema menor como urgente para saltarse la cola, porque eso pasa constantemente y necesita una definición real a la que apelar. El resto se trabaja en orden de SLA, y si la cola es genuinamente demasiado grande para una persona, eso mismo es una señal para reportar, no algo que absorber en silencio.