¿Qué evalúan realmente las entrevistas para técnico de soporte IT?

Quién está realmente en la sala

Para la mayoría de puestos de soporte de primera o segunda línea, no te encontrarás con un entrevistador profesional. Te encontrarás con el jefe del equipo de servicio o el responsable de IT que actualmente gestiona los tickets que tú recogerías, a veces con un técnico en activo presente para hacer las preguntas técnicas porque es quien tiene que confiar en tus soluciones. En empresas más pequeñas puede ser el único administrador de sistemas, que te entrevista en parte porque está cansado y quiere alguien que pueda quitarle tickets sin crear nuevos.

A menudo hay primero un filtro breve de RR.HH. o reclutador, principalmente para comprobar expectativas salariales, permiso de trabajo y período de preaviso. Esa conversación no está evaluando tu criterio técnico y no deberías leer demasiado en cómo va. La entrevista que decide el resultado es la que haces con la persona que se sentará cerca de ti.

La evaluación práctica, y qué está comprobando realmente

Muchas entrevistas de técnico de soporte incluyen algo práctico, porque hablar sobre resolución de problemas y hacerlo son habilidades diferentes. Cómo se ve esto varía según el empleador, pero las versiones habituales son:

• Un portátil o escritorio frente a ti con un fallo introducido — sin conexión de red, un perfil de usuario corrupto, una impresora que no se pone en cola, una máquina que no pasa de la pantalla de inicio de sesión — y te piden que lo encuentres y arregles mientras explicas tus pasos.
• Un escenario de pizarra o verbal: "un usuario llama y dice que su PC no puede acceder a la unidad compartida, cuéntame qué haces".
• Ocasionalmente una prueba breve escrita o en línea que cubre cosas como subnetting, números de puerto comunes o leer una salida de ipconfig /all e identificar qué está mal.
• A veces una llamada simulada o juego de rol, donde alguien interpreta a un usuario frustrado no técnico y tienes que sacarle información útil y explicar una solución sin jerga.

Lo que están comprobando no es si llegas a la respuesta correcta inmediatamente. Es si tienes un método. Un fallo de red, por ejemplo, tiene un orden bastante estándar de eliminación: ¿está el cable conectado?, ¿está el adaptador habilitado?, ¿muestra ipconfig una IP válida o una dirección APIPA (169.254.x.x, que te dice que falló el DHCP)?, ¿puedes hacer ping a la puerta de enlace?, ¿puedes hacer ping por IP pero no por nombre (lo que apunta a DNS)?, ¿puedes resolver externamente pero no internamente (lo que apunta a un servidor DNS específico o problema de split-tunnel VPN)? Un candidato que empieza ahí, en voz alta, está mostrando algo que un candidato que dice "intentaría reiniciarlo, luego reinstalar el controlador de red, luego reimaginar" no está mostrando. La segunda respuesta podría funcionar eventualmente. No es diagnóstico, es una secuencia de conjeturas, y cualquiera que haya dirigido un servicio de atención puede notar la diferencia en menos de un minuto.

Las preguntas que realmente están sondeando competencia

Un puñado de preguntas aparecen una y otra vez, y están haciendo más trabajo del que parece.

"Cuéntame cómo resolverías [X]." Esta es la pregunta central. No quieren el destino, quieren el orden de operaciones y el razonamiento en cada ramificación. Una respuesta sólida reduce el problema sistemáticamente — hardware versus software, local versus red, un usuario versus muchos — y dice qué le diría cada prueba antes de ejecutarla. Una respuesta débil salta directamente a la solución que funcionó la última vez en algo similar.

"Cuéntame de una vez que tu primera solución no funcionó." Esto está comprobando dos cosas: si realmente trabajas tickets de forma independiente en lugar de siempre escalar, y si documentas y vuelves a probar en lugar de intentar cosas al azar hasta que una funcione. Si tu respuesta no menciona comprobar el registro de eventos, volver a probar tras cada cambio o actualizar el ticket con lo que habías descartado, es una laguna que notarán.

"¿Cómo priorizas tu cola?" Los servicios de atención reales funcionan con alguna versión de prioridad y SLA — un usuario VIP bloqueado no es el mismo ticket que un atasco de impresora, y una incidencia P1 que afecta a toda una planta tiene preferencia sobre ambos. Si hablas de niveles de prioridad, impacto versus urgencia, o cómo manejarías un P1 que llega mientras estás a mitad de solucionar otra cosa, estás respondiendo desde la experiencia. Si dices "simplemente los trabajo en orden", eso les dice que o no has trabajado en un sistema de tickets con SLAs reales, o no lo has pensado.

"Explica [algún fallo técnico] a alguien que nunca ha usado un ordenador." Esta no es una pregunta de relleno de habilidades blandas. Los técnicos de soporte pasan la mayor parte del día traduciendo, y alguien que no puede hacerlo en la sala de entrevistas, sin presión real, no va a hacerlo bien en una llamada con un usuario enfadado a las 16:45. Observa candidatos que recurren a una analogía y la mantienen breve, versus los que simplifican el vocabulario pero mantienen la misma explicación extensa.

Preguntas de directorio y acceso. Dependiendo del entorno, espera algo concreto: cómo desbloqueas una cuenta de Active Directory, cuál es la diferencia entre restablecer una contraseña y forzar un cambio en el siguiente inicio de sesión, cómo añadirías un usuario a un grupo de seguridad versus un grupo de distribución, qué compruebas antes de conceder acceso elevado a alguien que lo ha pedido. Estas no son preguntas trampa. Están comprobando que realmente has usado Usuarios y Equipos de AD, o Intune, o lo que sea que use la empresa, en lugar de solo leer sobre ello.

Una pregunta de seguridad, casi siempre. Algo como "un usuario te envía un correo diciendo que ha hecho clic en un enlace y ahora su máquina actúa de forma extraña, ¿qué haces primero?" Quieren aislamiento antes de investigación — desconectar de la red, no reiniciarlo todavía si hay alguna posibilidad de seguimiento forense, reportarlo, no solo ejecutar un escaneo de virus y seguir adelante. Y en algún sitio sondearán si alguna vez te han pedido tu contraseña de administrador alguien que afirmaba ser un gerente con prisa, y qué hiciste.

Cómo suena una respuesta superficial

Las personas que contratan normalmente pueden notar en una o dos frases cuándo una respuesta está memorizada en lugar de vivida. Algunos patrones aparecen a menudo:

• Nombrar la solución sin el diagnóstico. "Lo reimaginaría" como primera línea de una respuesta, sin mencionar qué te diría que reimaginar es realmente necesario.
• Tratar el sistema de tickets como papeleo en lugar de un registro. Si no puedes decir qué escribirías en las notas del ticket, o describes cerrar tickets sin confirmar la solución con el usuario, eso se nota.
• Recitar contenido de certificación sin una historia adjunta. Saber que DNS funciona en el puerto 53 no es lo mismo que haber perseguido realmente un problema de DNS. Si tienes CompTIA A+ o Network+, o un certificado ITIL Foundation, espera que surja — pero el entrevistador ya sabe que mucha gente aprueba esos exámenes sin poder arreglar nada. Harán una pregunta de seguimiento que requiere que realmente hayas hecho la cosa, no solo estudiado.
• Lenguaje de propiedad vago. "Lo arreglamos" o "el equipo lo resolvió" cuando te preguntan qué hiciste personalmente.
• Sin mencionar al usuario en absoluto. Una respuesta técnicamente correcta que nunca menciona comprobar con la persona que levantó el ticket se lee como alguien que arregla máquinas, no problemas de personas.

Qué preparar realmente

Ten dos o tres tickets reales listos para hablar en detalle — no la interesante incidencia una vez al año, sino ordinarios: una impresora que no se ponía en cola, una caída de VPN para un usuario, un bloqueo de cuenta que resultó ser una credencial en caché en un teléfono. Estate listo para declarar, sin que te lo pidan, qué comprobaste y en qué orden, y qué habrías hecho después si lo primero no hubiera funcionado. Si tu trabajo actual o más reciente usa una pila específica — ServiceNow, Zendesk, Intune, SCCM, una estructura AD particular — conoce los términos reales que usas para las cosas allí, porque la descripción vaga se lee igual que la inexperiencia incluso cuando no lo es. Y si te preguntan un escenario que genuinamente no has manejado, dilo y razona en voz alta de todos modos; eso está más cerca de lo que el trabajo realmente es que acertar cada respuesta.

Si estás enviando solicitudes y no recibes respuesta antes incluso de llegar a esta etapa, jobmarket.pro lee el anuncio completo, lo coteja con tu experiencia real y prepara la solicitud desde ahí en lugar de un CV genérico.