Cómo simular una entrevista de analista de datos

Las entrevistas de analista de datos tienen una estructura predecible y, aun así, atrapan a candidatos bien preparados, porque la preparación suele hacerse en silencio mientras que la entrevista ocurre en voz alta. Esta sección plantea la simulación que cierra esa brecha. Constrúyela a partir de las tres rondas que contiene casi todo proceso de analista.

Primero, un ejercicio de SQL en vivo: de 20 a 30 minutos sobre un esquema realista. Segundo, un caso de métricas: un número se movió, y tienes que razonar por qué. Tercero, comportamiento: historias sobre partes interesadas, un momento en que tu análisis estuvo equivocado, un plazo que se retrasó. Haz las tres seguidas cuando puedas, porque la resistencia también es parte de lo real.

Ponle a cada parte un límite de tiempo estricto y di cada respuesta en voz alta como si el entrevistador estuviera presente, o practícala contra un entrevistador de IA; la página de entrevista simulada explica cómo configurar eso con preguntas específicas del puesto.

Elige un esquema con tres o cuatro tablas relacionadas, pedidos, usuarios, sesiones, pagos, y avanza por preguntas de dificultad creciente: una agregación con un filtro, un join con un group by, y luego una pregunta de función de ventana como un total acumulado, un rango dentro de un grupo, o un cambio mes contra mes. Las funciones de ventana, los self-joins y el manejo de NULL son donde las entrevistas reales separan a los candidatos.

Narra todo el tiempo: cuál es el grano de cada tabla, por qué haces el join con esas claves, dónde podría duplicarse un conteo. Los entrevistadores puntúan esa narración, y es exactamente lo que la práctica silenciosa nunca desarrolla. Cuando una consulta falla, depura también en voz alta; recuperarse con limpieza se percibe mejor que acertar en silencio.

Termina la ronda explicando tu consulta final de nuevo en lenguaje simple, una frase por cláusula. Si esa explicación queda confusa, la versión de la entrevista también lo estará.

La ronda de casos tiene una forma estándar: una métrica se movió, diagnostícala. Ensaya una estructura fija. Primero define la métrica con precisión, incluido su denominador. Luego segmenta: por plataforma, región, cohorte de usuarios, ventana temporal. Después plantea hipótesis por categorías, problemas del pipeline de datos, cambios de producto, eventos externos, cambio de mix, y di qué consulta o gráfico probaría cada una. Cierra explicando qué harías a continuación, no solo qué pasó.

Un ejercicio concreto: una analista que se prepara para un puesto de e-commerce se plantea el escenario de que la conversión semanal cayó un 8 por ciento, trabaja la estructura en voz alta durante 15 minutos, y solo entonces comprueba si ancló el denominador antes de plantear hipótesis. La mayoría de los primeros intentos se saltan el paso de definición, y ese es precisamente el hábito que la simulación existe para corregir.

Más planteamientos de casos de los que sacar ideas están reunidos en el centro de bancos de preguntas.

Una sola simulación cambia poco; una cadencia constante cambia el resultado. Dos o tres sesiones por semana en las dos semanas antes de las entrevistas es un ritmo manejable, y cada una debe terminar con retroalimentación escrita: algo que funcionó, algo por corregir, una pregunta que te trabó. Repite las preguntas que te trabaron al inicio de la siguiente sesión, ya que la repetición espaciada sobre tus debilidades reales vence siempre a preguntas nuevas.

Varía también la presión del entrevistador. Deja que las preguntas de seguimiento te interrumpan, que cuestionen tus supuestos, y practica decir con claridad no lo sé, seguido de cómo lo averiguarías. Cómo se ve de principio a fin una sesión con un entrevistador de IA, y cómo se genera después la retroalimentación, se explica en el centro de entrevistas simuladas.