Data Analyst

EspañaIntermedio

Preguntas de entrevista estructuradas para Data Analyst, con lo que revela una buena respuesta en cada una.

  1. 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 respuesta

    Conexió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.

  2. 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 respuesta

    Humildad 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.

  3. 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 respuesta

    Independencia 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.

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).

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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

CompetenciaPor debajoEn el nivelPor encima
Fundamentos SQL y modeladoSe 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 negocioEntrega 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ónSin 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 negocioPresenta 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 iniciativaSe 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)
Actualizado
Cubra este puesto con JoinSourcing, filtrado y entrevistas en un solo lugar.
Contratar

Hablar con Join