Mock interview de data analyst — practique con IA

Las entrevistas de data analyst parecen fáciles sobre el papel — SQL, algo de estadística, un gráfico o dos — y emboscan a la gente en la sala. Las preguntas son cortas. Las expectativas no. Un screen de SQL con tres problemas puede llevar 45 minutos; una sola discusión de test A/B puede durar una hora. Practicar el formato con mocks de IA convierte las preguntas emboscada en preguntas rutinarias.

La forma de un proceso de data analyst

La mayoría de los procesos de analyst tienen cuatro piezas móviles. Un screen del recruiter. Un screen técnico de SQL (en vivo o take-home), normalmente de 45–60 minutos con dos o tres problemas de dificultad creciente. Una ronda de case de producto/negocio, donde el entrevistador le entrega una pregunta de métrica ambigua y observa cómo razona. Y una ronda behavioral/cross-funcional, que comprueba si puede hablar con personas no técnicas sin hacerlas sentir tontas.

Los procesos de analyst senior y de analytics engineer añaden una quinta ronda: una pregunta de diseño de sistema o de experimentación. «Diseña un framework de testing A/B para nuestro equipo de recomendaciones» o «diseña una capa de métricas para nuestra organización financiera». Estas son las preguntas de mayor varianza de todo el proceso — recompensan el pensamiento estructurado y castigan a quienes saltan a los dashboards antes de haber definido las métricas.

Los mocks con IA gestionan bien tres de las cuatro. Los screens de SQL debería practicarlos en un editor de SQL real con un dataset real (LeetCode SQL, StrataScratch, los tutoriales de Mode son todos buenos). Todo lo demás — explicaciones verbales de SQL, case studies, razonamiento de tests A/B, behavioral — es exactamente para lo que se crearon los mocks con IA.

Screens de SQL: donde la mayoría de los candidatos pierden puntos

El screen de SQL filtra más candidatos que cualquier otra ronda, y no filtra por la razón que la mayoría supone. El listón no es «¿sabes escribir un join?». Es «¿sabes escribir una consulta limpia, correcta y eficiente para un problema ligeramente ambiguo, y sabes explicar lo que escribiste en voz alta mientras otra persona observa?». La segunda mitad es donde ayudan los mocks.

Temas que sin duda saldrán

• Window functions — row_number, rank, lag, lead, agregados particionados.
• CTEs y CTEs recursivas (con menos frecuencia, pero aparecen para senior).
• Los cuatro tipos de join, con casos límite (NULLs en cualquiera de los lados, self-joins, anti-joins mediante NOT EXISTS).
• Agregaciones con GROUP BY + HAVING, incluyendo agregados condicionales (COUNT(CASE WHEN ...)).
• Aritmética de fechas — últimos 7 días, cohortes de retención, comparaciones semana contra semana.
• Patrones de deduplicación (qué fila conserva, por qué).

Patrones de preguntas clásicos: «encuentra el top N por alguna métrica dentro de cada grupo», «calcula la retención semana contra semana», «encuentra usuarios que hicieron X pero no Y», «encuentra el segundo evento más reciente por usuario». Si esos no le salen por memoria muscular automática, practíquelos durante una semana antes de cualquier entrevista real.

Razonamiento de tests A/B

Las preguntas de tests A/B deciden si pasa a la siguiente ronda. Son lo más parecido al «criterio de producto» que el entrevistador puede probar en 45 minutos. El formato siempre es similar: una función vaga, un objetivo vago, su tarea es diseñar el experimento con limpieza en voz alta.

La cadena que necesita recorrer

1. Defina el cambio. ¿Qué es exactamente el tratamiento? «Vamos a mostrar un nuevo banner» es demasiado vago. «Vamos a mostrar un banner en la página de inicio que enlaza a la página de upgrade, para usuarios que llevan más de 30 días en gratuito» es preciso.
2. Enuncie la hipótesis. Dirección y magnitud. «Esperamos que la tasa de upgrade aumente 2 puntos porcentuales entre los usuarios tratados.» Específica. Falsable.
3. Elija la métrica primaria. Una. No tres. «Tasa de upgrade dentro de los 7 días posteriores al tratamiento.» Defienda por qué esa y no las alternativas obvias.
4. Elija las métricas de guardrail. Lo que no debe empeorar. «Engagement de usuarios gratuitos, duración de sesión, volumen de tickets de soporte.» Si el tratamiento mueve la primaria pero revienta un guardrail, no se lanza.
5. Estime el tamaño de muestra y la duración. Basándose en la tasa base, el efecto mínimo detectable, el alfa y la potencia. No necesita hacer las cuentas en vivo — solo demuestre que entiende las entradas.
6. Enuncie la regla de decisión. Qué umbral de evidencia lanza la función. Qué hace si los resultados no son concluyentes.

Los entrevistadores harán preguntas de seguimiento con trampas: efectos de novedad, efectos de red (especialmente en productos sociales), interferencia entre experimentos concurrentes, peeking. Esté listo para nombrar cada uno por su nombre y explicar por qué importa.

Dashboards y case studies

Los case studies son rondas de conversación sin datos en pantalla. Un planteamiento típico: «el DAU cayó un 5 % la semana pasada. ¿Qué haces?». El entrevistador no busca la respuesta (no la hay sin datos). Busca: ¿descompone el problema con limpieza?, ¿hace las preguntas aclaratorias correctas?, ¿prioriza las hipótesis por probabilidad e impacto?, ¿sabe qué datos sacaría y qué consulta ejecutaría?

Un marco limpio: empiece con preguntas aclaratorias (qué producto, qué definición de DAU, qué segmentos, ¿es un problema conocido del pipeline de datos?), luego segmente las hipótesis en externas (estacionalidad, marketing, lanzamiento de un competidor), internas de producto (despliegue reciente, cambio de función, test A/B) e instrumentación (bug de logging, cambio de esquema). Ordénelas por probabilidad. Para las dos o tres principales, diga qué sacaría y qué miraría.

Las preguntas de diseño de dashboards son más concretas. «Estás construyendo un dashboard para el head of growth — ¿qué hay en él?». No liste 40 métricas. Elija 5–8 que mapeen a decisiones que el head of growth realmente toma (adquisición, activación, retención, monetización, referidos — el bucle AARRR o la variante de su empresa). Para cada una, diga qué umbral dispara una acción.

Cómo configurar un mock con IA para roles de analyst

Fije el rol a «Data Analyst» o pegue la JD si la tiene. Para la primera sesión, elija el modo «Screening técnico» y 10 preguntas — eso le da un reparto más o menos equitativo de explicaciones de SQL, razonamiento A/B y uno o dos case studies. Para sesiones de práctica más profundas, use el modo standalone y dígale a la IA que se centre en un área: «dedica toda la sesión a window functions de SQL y agregados condicionales» o «dedica toda la sesión al diseño de tests A/B con trampas».

Un patrón útil específicamente para analysts: tras el mock con IA, tome las preguntas de SQL y escriba realmente las consultas en un playground de SQL. El mock revela si puede explicar el enfoque; el playground confirma que puede enviar el código. Ambas cosas importan.

Preguntas frecuentes