Esta guía le da a {{Nombre de la empresa}} un proceso estructurado para roles de datos: analistas de datos, científicos de datos e ingenieros de analítica. Las entrevistas de datos derivan fácilmente en trivia; este proceso evalúa en cambio las habilidades que predicen el éxito: escribir SQL correcto en condiciones realistas, razonar sobre métricas ambiguas y convertir el análisis en decisiones que alguien realmente toma.

Plan de etapas

Mapa de competencias

• Dominio de SQL y datos — escribe consultas correctas y legibles y manipula datos desordenados sin necesitar acompañamiento.
• Rigor estadístico — sabe cuándo una diferencia es señal, cuándo es ruido y cuándo los datos no pueden responder la pregunta.
• Encuadre de negocio — parte de la decisión a tomar, no de los datos que casualmente existen.
• Comunicación de hallazgos — convierte el análisis en una recomendación clara sobre la que un stakeholder no técnico puede actuar.
• Criterio de calidad de datos — detecta pipelines rotos, deriva de definiciones y agregaciones engañosas antes de publicar.

Bancos de preguntas por etapa

Filtro con reclutador

• ¿Qué partes del trabajo con datos le dan más energía — construir pipelines, análisis, experimentación o reportes?
• ¿Cuál es su stack diario — warehouse, transformación, BI, notebooks?
• Cuénteme del equipo con el que trabajó: ¿quién consumía su trabajo?
• ¿Qué busca que su rol actual no le ofrece?
• ¿Cuáles son sus expectativas de compensación y su disponibilidad?

Entrevista con el hiring manager

• Descríbame el análisis del que está más orgulloso. ¿Qué decisión cambió?
• Cuénteme de un análisis que resultó estar equivocado. ¿Cómo se dio cuenta y qué hizo?
• ¿Cómo decide cuándo un análisis está listo para entregarse en vez de necesitar otra semana?
• Describa una métrica que definió desde cero. ¿Qué casos límite tuvo que resolver?
• Cuénteme de un stakeholder que pedía dashboards que nadie usaba. ¿Qué hizo?
• ¿Cuál es el gráfico o métrica más engañosa que ha visto en producción, y por qué era engañosa?

Filtro técnico

Use un dataset realista de varias tablas — órdenes, usuarios, eventos — y deje que el candidato use su dialecto de SQL preferido y la documentación. Evalúe el proceso, no la memorización.

• Escriba una consulta que una tres tablas para calcular una tasa mensual de retención o de recompra.
• Encuentre y explique un problema de calidad de datos plantado en el dataset — duplicados, nulos, un desfase de zona horaria.
• Refactorice una consulta deliberadamente enredada en algo que un colega pueda mantener.
• Calcule una métrica con funciones de ventana: totales acumulados, ranking por grupo o un promedio móvil.
• Explique la diferencia entre dos estrategias de join para este esquema y cuándo diferirían los resultados.
• Verifique un resultado: ¿el número pasa una estimación rápida, y cómo lo comprobaría?

Caso de analítica

• Una métrica clave cayó doce por ciento de una semana a otra. Descríbame su primera hora.
• ¿Cómo descompondría la caída — por segmento, plataforma, cohorte o causa en el pipeline de datos?
• Diseñe un experimento para probar la hipótesis principal. ¿Cuál es la unidad de aleatorización y la métrica guardarraíl?
• El experimento muestra una mejora del dos por ciento con un intervalo de confianza amplio. ¿Qué recomienda?
• ¿Qué monitorearía después del lanzamiento, y cuándo revisaría la decisión?

Entrevista de stakeholders y valores

• Explique un análisis técnicamente complejo que entregó a una audiencia no técnica. ¿Cómo lo estructuró?
• Cuénteme de una vez que un stakeholder quería datos para confirmar una decisión ya tomada. ¿Qué hizo?
• ¿Cuándo ha rechazado una solicitud porque los datos no podían sostener la conclusión?
• ¿Cómo maneja que dos equipos definan la misma métrica de forma distinta?
• ¿Qué significa para usted, en la práctica, el uso responsable de los datos?

Anclas de puntuación

Califique cada competencia de 1 a 4 con evidencia escrita, inmediatamente después de cada etapa. Para candidatos senior, dé mayor peso al filtro técnico y al caso de analítica.

• 1 — Debajo del estándar: los errores de SQL pasan inadvertidos, salta a conclusiones sin revisar la calidad de los datos, sus respuestas describen herramientas en lugar de decisiones.
• 2 — Cerca del estándar: consultas competentes con ayuda; enmarca el análisis en términos de entregables, no de decisiones.
• 3 — En el estándar: trabajo correcto y verificable; declara sus supuestos; conecta cada análisis con la decisión que informó.
• 4 — Sobre el estándar: anticipa trampas en los datos, cuantifica la incertidumbre con naturalidad y reformula preguntas vagas en preguntas contestables y listas para decidir.