¿Qué evalúan realmente las entrevistas para analista de ciberseguridad?

Quién está realmente en la sala

Para un puesto de analista de ciberseguridad, la primera entrevista rara vez es solo con RR.HH. Espera que el responsable del SOC o un analista senior esté en la llamada desde el inicio, porque las preguntas que importan no las puede hacer alguien que no haya clasificado una alerta. En empresas pequeñas podrías encontrarte directamente con el CISO. En las grandes suele haber primero una evaluación técnica (un analista senior o líder de equipo, 30-45 minutos, centrada en escenarios) seguida de un panel que incluye al responsable de contratación y a veces alguien de operaciones IT o de un equipo de plataforma con el que trabajarías — porque gran parte del trabajo es escalar y transferir, no solo detectar.

Si la empresa gestiona un SOC maduro, también podrías reunirte con quien gestiona el SIEM (Splunk, Microsoft Sentinel, QRadar, Elastic) y quien gestiona el EDR (CrowdStrike, Defender for Endpoint, SentinelOne). Hacen preguntas distintas porque les preocupan modos de fallo diferentes: el responsable del SIEM quiere saber si puedes escribir una búsqueda que no sea basura; el del EDR quiere saber si perseguirás un script de PowerShell benigno durante dos horas porque no verificaste primero el proceso padre.

El ejercicio técnico: cómo se ve

La mayoría de evaluaciones técnicas para este puesto no son pruebas de programación. Son ejercicios de clasificación, porque clasificar es el trabajo. Formatos comunes:

• Clasificación de alertas en un SIEM aislado o un paquete de capturas de pantalla. Te dan un puñado de alertas — un inicio de sesión desde una geografía inusual, un pico en consultas DNS salientes, una detección EDR marcada como "sospechosa" en lugar de "maliciosa" — y te piden decir cuáles escalarías, cuáles cerrarías y por qué. El entrevistador observa tu orden de razonamiento, no tu respuesta final.
• Un pcap o extracto de logs. Podrían entregarte salida de Wireshark o logs de firewall en bruto y pedirte que reconstruyas lo que pasó: ¿es un escaneo de puertos, un intento de fuerza bruta fallido, comunicación C2 con un intervalo extraño? Algunos sustituyen esto por un correo de phishing con cabeceras y te piden leer la cadena Received y evaluar los resultados SPF/DKIM/DMARC.
• Un escenario de incidente de simulación. "Aparece una nota de ransomware en un portátil de finanzas a las 4pm un viernes. Explícame la próxima hora." Esto verifica si conoces la forma del ciclo de vida de incidentes de NIST 800-61 — identificación, contención, erradicación, recuperación, lecciones aprendidas — sin recitarlo como una lista. Los buenos candidatos aíslan el equipo antes de empezar a preguntar quién es responsable.
• Un trabajo para casa, menos frecuente ahora que hace unos años. Normalmente un informe de incidente escrito a partir de un conjunto de logs, o un modelo de amenazas breve para un sistema hipotético. Si recibes uno, los entrevistadores verifican si puedes escribir para alguien que no estuvo en la sala — porque los informes de incidentes los leen personas que no estuvieron en la llamada.

Lo que rara vez se evalúa, a pesar de lo que sugieren las guías genéricas de entrevistas, es si puedes recitar el modelo OSI o definir "confianza cero" de memoria. Eso aparece como preguntas de calentamiento como mucho. El ejercicio existe para ver qué haces cuando la alerta es ambigua, porque la mayoría de las alertas son ambiguas.

Las preguntas que realmente evalúan competencia

Algunas preguntas suenan como charla informal pero no lo son. Esto es lo que realmente verifican:

"Explícame el último falso positivo que cerraste." Esto no es una prueba de memoria. Verifica si entiendes por qué era un falso positivo — el mecanismo, no solo la etiqueta — y si ajustaste algo después, o simplemente hiciste clic en cerrar. Un analista que no puede describir el ajuste de una regla de detección o la supresión de una fuente ruidosa no ha hecho el trabajo el tiempo suficiente para reducir el ruido que genera.

"¿Cuál es tu proceso cuando recibes una alerta que no entiendes?" Escuchan una secuencia: verificar el activo (¿es un controlador de dominio o el portátil de alguien?), verificar el comportamiento normal de la cuenta, extraer eventos relacionados en una ventana a ambos lados de la alerta, verificar si el IOC aparece en otro lugar, luego decidir. Si la respuesta salta directamente a "lo escalaría", eso es una señal de alarma para un entrevistador experimentado, porque escalar todo es lo que hace alguien cuando no sabe investigar.

"Cuéntame sobre una vez que te equivocaste en un incidente." Esto es deliberadamente incómodo. Los analistas que solo han trabajado tickets, no incidentes reales, a menudo no tienen respuesta, porque equivocarse requiere haber tomado una decisión bajo incertidumbre. Los entrevistadores usan esto para separar a quienes siguieron un manual de quienes han tenido que hacer un juicio a las 2am con información incompleta.

"¿Cómo mantienes actualizada la inteligencia de amenazas, y cómo cambia lo que observas?" No "¿lees blogs?". Quieren saber si puedes nombrar un feed o fuente específica (investigación de amenazas de un proveedor, un ISAC, una lista IOC interna de un incidente previo) y, más importante, dar un ejemplo de una detección o búsqueda que construiste por algo que leíste — no solo que te suscribiste a una lista de correo.

Las preguntas sobre MITRE ATT&CK normalmente no piden que recites IDs de tácticas. Verifican si lo usas como herramienta de trabajo: ¿puedes mapear una técnica observada (digamos, T1053 para abuso de tareas programadas) a lo que esperarías ver después en la cadena, y si lo reconocerías al verlo?

Cómo suena una respuesta superficial

Para alguien que realmente gestiona un SOC, estos son los indicadores:

• Describir la detección enteramente en términos de herramientas ("usamos Splunk y CrowdStrike") sin mencionar qué buscabas o cuál era la lógica de la consulta. Nombrar el SIEM no es lo mismo que demostrar que puedes usarlo.
• Responder "¿cuál es el proceso de respuesta a incidentes?" listando las fases NIST en orden sin ningún ejemplo adjunto. Cualquiera puede memorizar seis palabras. El entrevistador quiere un incidente donde la contención fue más difícil de lo que el libro de texto hace parecer — porque un sistema de producción que no puedes simplemente desconectar, o una cuenta comprometida que también es la cuenta que ejecuta un servicio crítico, es donde está el juicio real.
• Tratar cada escenario como si la respuesta fuera "escalar al equipo de respuesta a incidentes", sin demostrar que sabes qué querría ese equipo que les entregues primero: alcance, equipos afectados, hora del primer indicador, si la contención ya ha comenzado.
• Confundir gestión de vulnerabilidades con detección. Que te pregunten sobre un CVE y solo poder decir "lo parchearíamos" sin mencionar controles compensatorios, exposición o explotabilidad en tu entorno sugiere que no has participado en una reunión de priorización de parches.
• Hablar de certificaciones (Security+, CySA+, GCIH, OSCP) como logros en lugar de evidencia de capacidad específica. Un entrevistador que tenga GCIH preguntará qué hiciste en los laboratorios, no si aprobaste.

Qué hacer antes de tu próxima entrevista

Elige dos incidentes o investigaciones de tu propio trabajo — reales, incluso pequeños — y prepárate para describirlos con suficiente detalle técnico para que otro analista pueda seguir el razonamiento: qué desencadenó la alerta, qué descartaste y cómo, qué harías diferente. Esa es una preparación más útil que cualquier lista de preguntas genéricas, porque es lo que el entrevistador realmente intenta conseguir que produzcas.

Si estás postulando a varios puestos de SOC o analista a la vez y los anuncios piden combinaciones de herramientas ligeramente diferentes (Sentinel aquí, QRadar allá, una plataforma SOAR que solo tocaste una vez), jobmarket.pro lee cada anuncio completo y prepara una solicitud desde tu experiencia real, sin inventar familiaridad con herramientas que no has usado.