Data Analyst
Preguntas de entrevista estructuradas para Data Analyst, con lo que revela una buena respuesta en cada una.
ConductualImpacto de negocio Describa el análisis del que se sienta más orgulloso·a. ¿Qué decisión de negocio cambió como consecuencia y cómo se midió el impacto?
Lo que revela una buena respuestaConexión clara entre análisis y decisión: pregunta de negocio explícita, método de análisis adecuado, comunicación a stakeholders, decisión efectivamente tomada y resultado medido a posteriori. Bonus: la persona candidata cita el plazo entre la entrega del análisis y la decisión, y reconoce si la decisión final difirió de su recomendación. Quienes describen un dashboard bonito sin decisión asociada revelan postura de reporting más que de analítica.
ConductualRigor y verificación Cuénteme un análisis que entregó y del que más tarde descubrió un error. ¿Cuál era, cómo lo detectó y qué hizo a continuación?
Lo que revela una buena respuestaHumildad técnica y rigor de verificación. Bonus: la persona candidata describe el proceso de comunicación del error a stakeholders (rápido, transparente, con corrección documentada) y la mejora de proceso que instaló después (revisión cruzada, tests de datos, documentación de supuestos). Quienes afirman no haber cometido nunca un error de análisis mienten o no han trabajado el tiempo suficiente con datos reales.
ConductualIndependencia analítica Describa una situación en la que un·a stakeholder le pidió un análisis con una conclusión ya esperada. ¿Cómo reaccionó?
Lo que revela una buena respuestaIndependencia analítica: capacidad de mantener el rigor frente a la presión, comunicar resultados que contradigan la hipótesis inicial, proponer alternativas en lugar de fabricar el resultado esperado. Quienes describen haber buscado el ángulo que confirmara la hipótesis muestran una debilidad crítica de integridad analítica que envenena la confianza en datos a medio plazo.
SituacionalGestión del legado de datos Descubre en una revisión que su predecesor·a definió la métrica de activación de forma inconsistente entre dos dashboards en producción. ¿Cómo reacciona?
Lo que revela una buena respuestaPostura constructiva: documentar las dos definiciones, validar cuál refleja la intención de negocio actual con la persona PM o de dirección, alinear los dashboards y comunicar el cambio de forma transparente al equipo. Quienes corrigen en silencio o critican abiertamente el trabajo previo muestran debilidad en la gestión de la deuda de datos heredada.
SituacionalComunicación con negocio Una persona Product Manager le pide un análisis urgente para mañana sobre un segmento de usuarios que nunca ha analizado. La instrumentación es incompleta. ¿Cómo reacciona?
Lo que revela una buena respuestaClarificación de la necesidad antes de prometer: ¿qué decisión depende del análisis?, ¿qué nivel de confianza es suficiente? Propuesta de opciones: análisis exploratorio rápido con limitaciones explícitas en 24 horas frente a análisis sólido con instrumentación adicional en 1 semana. Quienes prometen lo imposible (un análisis sólido en 24 horas sobre datos sucios) o se niegan en bloque muestran falta de pragmatismo y de comunicación con producto.
SituacionalComunicación con negocio Le encarga un dashboard para el comité de dirección. Tres directivos·as le piden indicadores parcialmente solapados. ¿Cómo lo encuadra?
Lo que revela una buena respuestaCapacidad de unificar antes de fragmentar: entrevista corta con cada stakeholder para entender la decisión que cada indicador alimenta, identificación de la métrica madre frente a las métricas derivadas, propuesta de un dashboard consolidado con vistas filtrables en lugar de tres dashboards paralelos. Quienes ejecutan los tres encargos por separado revelan postura ejecutante sin postura editorial sobre los datos.
Caso prácticoInvestigación y diagnóstico Investigación: la activación a 7 días ha caído un 12 por ciento de una semana a otra. No ha habido despliegue de producto. ¿Cómo investiga en las próximas 24 horas?
Lo que revela una buena respuestaMétodo estructurado: (1) verificar primero la instrumentación y la calidad del dato (causa frecuente: pipeline roto, evento renombrado, cambio de schema), (2) segmentar (cohorte nueva frente a antigua, por dispositivo, por canal de adquisición, por geografía), (3) ordenar hipótesis (cambio en marketing aguas arriba, caída de un tercero, estacionalidad, bug silencioso de tracking). Bonus: la persona candidata menciona la importancia de comunicar resultados parciales en lugar de esperar al análisis completo. Quienes saltan a una conclusión sin investigar (seguro es marketing) revelan sesgo.
Caso prácticoDiseño de métricas Diseño: tenemos que medir la calidad del onboarding de un nuevo producto. ¿Qué métricas propone y por qué?
Lo que revela una buena respuestaCapacidad de proponer una pirámide de métricas: indicador adelantado (completar paso 1, paso 2, paso 3 del onboarding) e indicador retardado (retención a 7, 30, 90 días, activación de la feature clave). Distinción entre métrica funcional (completion rate) y métrica de valor (uso recurrente posterior). Bonus: la persona candidata propone un instrumento de medición concreto (evento tracking, encuesta in-app, NPS post-onboarding) y reconoce las trampas (vanity metrics, sesgo de supervivencia). Quienes proponen solo conversion rate sin matiz se quedan en superficie.
Caso prácticoComunicación con negocio Comunicación: tiene 5 minutos para presentar a la dirección general una caída de retención del 8 por ciento al mes 3. ¿Cómo estructura el mensaje?
Lo que revela una buena respuestaEstructura piramidal: (1) titular en una frase con cifra y dirección clara, (2) las 2-3 causas principales identificadas con peso relativo, (3) recomendación accionable con plazo y propietario·a. Bonus: la persona candidata anticipa la pregunta más probable de la dirección (¿cuál es el impacto en ARR a 12 meses?) y prepara la respuesta. Quienes empiezan con metodología o con un gráfico complejo pierden a la audiencia ejecutiva.
TécnicaFundamentos SQL Diferencia entre INNER JOIN, LEFT JOIN y FULL OUTER JOIN. ¿En qué caso usaría cada uno?
Lo que revela una buena respuestaComprensión sólida de los joins: INNER JOIN devuelve solo las filas con coincidencia en ambas tablas; LEFT JOIN preserva todas las filas de la tabla izquierda añadiendo NULL cuando no hay coincidencia; FULL OUTER JOIN preserva todas las filas de ambas tablas. Bonus: la persona candidata menciona el caso clásico del falso INNER JOIN que descarta usuarios·as sin pedidos en un análisis de retención. Quienes confunden los tres mecanismos producirán análisis sesgados sin darse cuenta.
TécnicaFundamentos SQL Explíqueme las window functions. ¿En qué caso preferiría una window function sobre un GROUP BY clásico?
Lo que revela una buena respuestaLas window functions calculan agregaciones sobre una partición de filas conservando cada fila individual (a diferencia de GROUP BY, que colapsa las filas). Casos típicos: ranking (ROW_NUMBER, RANK, DENSE_RANK), running totals (SUM OVER), comparaciones intra-partición (LAG, LEAD), percentiles (NTILE, PERCENT_RANK). Bonus: la persona candidata cita un caso concreto donde una window function evita un self-join costoso. Quienes desconocen las window functions o nunca las han usado en producción están limitados al análisis básico.
TécnicaRigor y verificación ¿Cuál es su enfoque sobre la calidad de los datos? Describa cómo construye o mantiene un pipeline con calidad de datos verificable.
Lo que revela una buena respuestaPráctica de tests de datos (dbt tests, Great Expectations, Soda o equivalente): tests de unicidad, no-nulidad, integridad referencial, rangos de valores plausibles. Documentación de supuestos. Monitoring de freshness y volumen. Bonus: la persona candidata cita un caso real donde un test de calidad evitó una decisión basada en datos erróneos. Quienes responden hago controles visuales en Excel sin matizar revelan postura artesanal frente al rigor de pipeline.
ValoresIndependencia analítica ¿Cómo reacciona cuando un·a stakeholder de negocio rechaza una conclusión del análisis porque no le encaja?
Lo que revela una buena respuestaPostura de partenariado, no de oposición: capacidad de escuchar la objeción (¿qué información tiene la otra persona que yo no tengo?), revisar el análisis si procede, defenderlo con rigor si la objeción es injustificada. Bonus: la persona candidata cita una vez en que el rechazo le hizo descubrir un sesgo en su propio análisis. Quienes describen haber bajado la cabeza para evitar el conflicto revelan debilidad de coraje analítico.
ValoresPedagogía y transmisión ¿Qué papel juega en la transmisión de cultura de datos a perfiles no técnicos del equipo?
Lo que revela una buena respuestaPostura activa de pedagogía: documentación accesible de métricas clave, formación informal a PMs y dirección sobre lectura de dashboards, simplificación del vocabulario técnico, ayuda a personas no técnicas a formular preguntas de datos accionables. Quienes responden ayudo cuando me lo piden sin más concreción muestran postura pasiva. En pyme con equipo de data reducido (1-3 personas), la pedagogía es clave para escalar el impacto del equipo.
ValoresJuicio de datos ¿Cuál es su lectura del oficio de Data Analyst en 2026? ¿Qué ha cambiado en los últimos años?
Lo que revela una buena respuestaReconocimiento de las evoluciones: subida de la analytics engineering (dbt, modern data stack), separación creciente entre data analyst y data engineer, llegada de la IA generativa para acelerar tareas de SQL y exploración, presión creciente sobre el impacto de negocio frente a la entrega de dashboards. Quien responde solo con herramientas o buzzwords sin reflexión sobre el oficio señala una postura superficial; quien habla de tensión entre rigor y velocidad, de la deuda de datos en pyme y de la disciplina de instrumentación está al día.
Manual de evaluación
El puesto de Data Analyst se evalúa en cinco etapas. El ejercicio de SQL en vivo (etapa 3) es la prueba más predictiva: revela en 45 minutos la fluidez real con datos que dos horas de preguntas conceptuales no captarán. Acote el tiempo y prefiera consultas que se parezcan al día a día (joins, agregaciones, window functions, depuración de duplicados).
Etapa 1: Lectura del CV
Busque coherencia de stack (un·a perfil SQL más Python más dbt no se reinventa de la noche a la mañana en SAS legacy), naturaleza de los proyectos previos (product analytics frente a reporting financiero frente a marketing mix modelling) y señales de autonomía (proyectos públicos en GitHub, charlas en meetups, posts técnicos en Medium o blog propio). Una titulación específica (estadística, matemáticas, economía) tranquiliza en perfiles entry-level pero pierde peso a partir de 3 años de experiencia operativa real. Las certificaciones aisladas (Google Data Analyst, IBM) sin proyectos concretos detrás aportan poca señal.
Etapa 2: Phone screen (30 min)
Solo tres preguntas: (1) Describa el análisis o dashboard del que se sienta más orgulloso·a; ¿qué decisión de negocio cambió como consecuencia?, (2) ¿Qué métrica que haya construido le sigue generando dudas? (humildad y reflexión sobre el oficio), (3) ¿Por qué un cambio ahora? Salida: go o no-go en 5 minutos de debrief. Evite las preguntas técnicas tipo trampa en esta fase; busque la conexión entre datos y negocio en bruto.
Etapa 3: Ejercicio de SQL en vivo (45-60 min)
Pair coding sobre una base de datos real anonimizada (esquema de 4-6 tablas tipo e-commerce o SaaS): 3-4 preguntas crecientes que van de un select con filtros hasta una window function con CTE y depuración de duplicados. Evalúe la capacidad de razonar en voz alta, de pedir aclaraciones sobre el esquema, de detectar inconsistencias en los datos y de iterar. Acepte soluciones imperfectas si el razonamiento es sólido. Las personas que se bloquean en un join con 3 tablas o que no saben distinguir un INNER de un LEFT JOIN no operarán en autonomía.
Etapa 4: Caso de análisis (presentación de 30 min más Q&A de 30 min)
Caso real anonimizado: aquí tiene una caída del 12 por ciento en la activación de la semana pasada; investigue y proponga un plan de acción. La persona candidata recibe el dataset y el contexto 48 horas antes, prepara un análisis corto (3-5 láminas o un notebook) y presenta en 30 minutos seguidos de 30 minutos de preguntas. Pondere mucho esta etapa: revela la capacidad de encuadrar un problema, segmentar hipótesis, comunicar resultados a una audiencia mixta (técnica y de negocio) y reconocer zonas de incertidumbre. Quienes solo presentan métricas descriptivas sin hipótesis ni recomendación se quedan en la capa reporting.
Etapa 5: Referencias (verificación estructurada)
Llame a dos referencias: una persona ex-responsable directo·a (head of data, CTO o CPO) y un·a antiguo·a stakeholder de negocio (PM, marketing, finanzas) que haya consumido sus análisis. Plantee a ambas las mismas cuatro preguntas: ¿En qué destaca más?, ¿Para qué contrataría a una persona complementaria?, ¿Volvería a contratarle mañana y por qué?, ¿Un ejemplo concreto en el que su análisis cambió una decisión de negocio? La cuarta pregunta es la que revela el impacto real frente al trabajo invisible.
Cómo reconocer una gran contratación
| Competencia | Por debajo | En el nivel | Por encima |
|---|---|---|---|
| Fundamentos SQL y modelado | Se bloquea en un join con 3 tablas o con un GROUP BY con HAVING. No distingue INNER de LEFT JOIN. Desconoce las window functions. Modela datos por copia y pega sin pensar en la estructura. | Domina SQL operativo: joins múltiples, agregaciones, subconsultas, window functions básicas (ROW_NUMBER, LAG, LEAD). Sabe leer un esquema relacional y diseñar una consulta legible y mantenible. Comprende los principios de modelado (star schema, normalización frente a denormalización). | Referente SQL del equipo: window functions avanzadas, optimización de consultas costosas (EXPLAIN, índices, particionado), patrones de modelado en dbt o equivalente. Forma a perfiles junior y revisa PRs SQL con feedback técnico claro. |
| Impacto de negocio | Entrega dashboards o informes sin pregunta de negocio explícita asociada. No mide el efecto de sus análisis en decisiones tomadas. Habla de actividad (entregables) en lugar de impacto (decisiones cambiadas). | Cada análisis arranca con una pregunta de negocio clara. Sabe traducir una intención difusa de stakeholder en una pregunta analítica precisa. Comunica resultados orientados a decisión, no a metodología. | Operador·a estratégico·a: anticipa preguntas que el negocio no ha formulado todavía, propone análisis proactivamente sobre palancas de impacto, mide el efecto de sus recomendaciones a posteriori. Referente para PMs y dirección sobre cómo plantear preguntas de datos accionables. |
| Rigor y verificación | Sin estrategia clara de verificación: confía en la primera consulta que devuelve un número plausible. No documenta supuestos. Sin tests de calidad de datos. Errores frecuentes detectados aguas abajo por stakeholders. | Verifica sistemáticamente cifras clave antes de entregar: control de orden de magnitud, comparación cruzada con otra fuente, sanity checks sobre valores extremos. Documenta supuestos. Conoce los principios de tests de datos (dbt tests, Great Expectations). | Disciplina de pipeline: tests automatizados sobre fuentes y modelos, monitoring de freshness y volumen, documentación versionada de modelos y métricas. Detecta errores aguas arriba antes que los stakeholders. Construye el andamiaje de calidad que el equipo hereda. |
| Comunicación con negocio | Presenta análisis en formato técnico (gráficos densos, métricas brutas, jerga) sin adaptar al público. Empieza por la metodología y pierde a la audiencia ejecutiva. No anticipa las preguntas más probables. | Adapta el formato al público: titular y recomendación claros para dirección, detalle técnico disponible bajo demanda. Anticipa las 2-3 preguntas más probables. Estructura en pirámide invertida (conclusión primero). | Comunicador·a de datos referente: visualizaciones limpias y accionables, narrativa que conecta dato y decisión, dominio de los formatos (one-pager, dashboard, presentación oral, memo escrito). Stakeholders de negocio le piden análisis antes incluso de formular la pregunta porque saben que recibirán una respuesta útil. |
| Autonomía e iniciativa | Se bloquea en cuanto la pregunta es ambigua. Espera instrucciones precisas. No propone análisis ni señala oportunidades de mejora del stack o de los procesos. | Trabaja en autonomía sobre temas familiares. Pide aclaraciones cuando la pregunta es ambigua pero propone alternativas. Señala oportunidades de mejora (dashboard a refactorizar, métrica a redefinir, pipeline a estabilizar). | Iniciativa estructurante: propone proyectos transversales (migración a dbt, definición de un layer semántico, plan de gobernanza de datos), pilota su ejecución y los argumenta ante la dirección. Construye y mantiene la cultura de datos en autonomía. |
Plan de 30/60/90 días
Día 30
- Setup completo del entorno (acceso a base de datos, dbt o equivalente, BI tool, repositorios) y entrega de una primera consulta SQL productivizada
- Lectura y comprensión de los 3 dashboards y 3 modelos de datos más críticos del negocio
- Primer 1:1 documentado con la persona responsable sobre métricas clave, deuda identificada y prioridades del trimestre
- Primera entrevista con 3-5 stakeholders de negocio (producto, marketing, finanzas) para mapear sus preguntas de datos recurrentes
Día 60
- Entrega autónoma de un análisis ad hoc completo (pregunta de negocio, datos, resultados, recomendación, presentación a stakeholder)
- Primera revisión de un dashboard o modelo de datos existente con feedback estructurado y propuesta de refactor
- Documentación redactada o actualizada sobre una métrica clave o un modelo de datos tocado recientemente
- Primera propuesta de mejora de proceso (test de calidad de datos, alerta de freshness, alineación de definición de métrica)
Día 90
- Cadencia regular de entrega (1-2 análisis sustantivos por semana, cierre de tickets ad hoc en menos de 48 horas)
- Primera contribución estructurante al stack de datos (refactor de modelo dbt, nueva métrica documentada, pipeline estabilizado)
- Pedagogía instalada: al menos una sesión de formación informal a un equipo no técnico (PMs, marketing, dirección) sobre lectura de dashboards o formulación de preguntas de datos
- Balance formal con la persona responsable: rampa validada, plan de progresión sobre 1-2 ejes prioritarios (analytics engineering, product analytics, comunicación ejecutiva)