¿Qué evalúan realmente las entrevistas para analista de datos?

Con quién hablas realmente en cada etapa

Un proceso para analista de datos rara vez es una sola conversación. Suele ser tres o cuatro, cada una dirigida por alguien con un trabajo diferente y verificando algo distinto.

La criba con reclutamiento no evalúa tu capacidad analítica. Confirma que puedes hablar de tu trabajo en lenguaje claro, que tu expectativa salarial y periodo de preaviso coinciden con el puesto, y que no has malinterpretado el título (analyst, analytics engineer y data scientist se usan de forma imprecisa, y a veces los anuncios quieren uno pero lo titulan como otro).

La ronda técnica normalmente la dirige alguien que hace el trabajo día a día: un analista senior o un gerente de analítica, a veces un ingeniero de datos si el rol toca mucho trabajo de pipelines. Esta es la ronda de SQL y estadística, y es la que los candidatos preparan menos porque asumen que mayor senioridad significa menos código, lo cual es al revés: cuanto más senior el puesto, más probable que se espere que escribas SQL correcto bajo presión de tiempo sin que un linter atrape tus errores.

La ronda de caso práctico o "problema de negocio" suele estar a cargo de alguien del equipo al que realmente apoyarías: un product manager, un responsable de marketing, un business partner de finanzas. No están calificando tu sintaxis SQL. Están verificando si puedes tomar una pregunta vaga como "por qué bajaron los registros el mes pasado" y convertirla en algo medible sin que te digan cómo.

Una ronda final con el hiring manager o un director suele tratar sobre criterio y encaje: cómo manejas el desacuerdo con un stakeholder, cómo priorizas cuando tres personas quieren análisis contradictorios para el viernes.

La evaluación técnica: cómo es realmente

Para la mayoría de puestos de analista de datos en tecnología, espera uno o más de:

• Una prueba de SQL en vivo o grabada. No trivialidades sobre sintaxis, sino una consulta contra un esquema con filas duplicadas, claves foráneas nullable, o un join muchos-a-muchos que inflará silenciosamente tus conteos si te equivocas. Peticiones comunes: funciones de ventana (ROW_NUMBER() OVER (PARTITION BY ...) para deduplicar o rankear), un self-join para comparar el comportamiento de un usuario periodo a periodo, y un GROUP BY con cláusula HAVING en lugar de WHERE. Si puedes escribir una consulta correcta pero no explicar por qué deduplicaste antes de agregar, esa brecha se nota.
• Una tarea para casa con un dataset real o realista. Normalmente te pedirán responder una pregunta de negocio, no solo producir gráficos. Los entrevistadores leen esto para ver si declaraste tus supuestos (¿cómo definiste "usuario activo"?), si señalaste problemas de calidad de datos en lugar de sortearlos silenciosamente, y si tu recomendación se deriva de los números que mostraste o suena como si se hubiera decidido de antemano.
• Un recorrido por herramientas. Si el trabajo lista Looker, Tableau, Power BI o Mode, puede que te pidan compartir pantalla y construir algo en vivo, o criticar un dashboard existente. Esto verifica si puedes elegir un tipo de gráfico que no engañe, no si conoces cada menú.
• Estadística básica. Para roles que tocan experimentación, espera preguntas sobre qué significa realmente un p-value, cómo dimensionarías una muestra para un test A/B, y qué pasa con tu confianza cuando ejecutas cinco métricas de un test y declaras ganador al p-value más pequeño.

Algunas empresas omiten totalmente la tarea para casa y hacen todo esto en vivo, en pantalla compartida, porque las tareas pueden subcontratarse o tomar seis horas no pagadas al candidato. Si eso es mejor para ti depende de si piensas más rápido de lo que escribes; no hay consenso entre equipos de contratación sobre qué formato es más justo, y deberías esperar cualquiera.

Las preguntas que realmente están evaluando algo

Un puñado de preguntas de sonido estándar llevan casi toda la señal. Aquí está qué verifican realmente.

"Cuéntame un análisis que cambió una decisión." Esto no pide un resumen de proyecto. Verifica si puedes trazar una línea desde un número específico, a una persona específica, a una acción específica que tomó y que de otro modo no habría tomado. Si tu respuesta termina en "y encontré que la conversión era menor en móvil", has descrito una observación, no un resultado. El entrevistador está escuchando qué pasó después de que enviaste el análisis.

"¿Cómo medirías si esta funcionalidad está funcionando?" Esto evalúa si tu defecto es ir a una métrica o interrogar primero la pregunta. Una respuesta sólida pregunta qué significa "funcionando" para el negocio antes de nombrar una métrica, señala al menos una forma plausible en que la métrica obvia podría engañar (una funcionalidad que aumenta engagement haciendo algo más difícil de encontrar no es un logro), y nombra una métrica de protección junto a la principal. Una respuesta débil salta directamente a "rastrearía usuarios activos diarios".

"Cuéntame sobre una vez que tu análisis estuvo equivocado, o lo habrías hecho diferente." Esto verifica honestidad intelectual, y es más difícil de fingir de lo que la gente piensa porque una no-respuesta ensayada ("No creo que me haya equivocado, pero si tuviera que decir algo...") es instantáneamente reconocible para quien ha enviado análisis en el mundo real. Lo que quieren es: qué estuvo mal, cómo te enteraste, y qué cambiaste en tu forma de trabajar como resultado.

Un problema SQL en vivo con un giro: filas duplicadas, un join que se expande, un campo de fecha con formatos mixtos. Esto evalúa si verificas tus conteos de filas antes y después de un join, en voz alta, sin que te lo digan. Los analistas que han sufrido por un join que se expande hacen esto automáticamente. Los analistas que no, no lo hacen, y el entrevistador normalmente sabe en treinta segundos qué tipo está observando.

Cómo suena una respuesta superficial

Para alguien que hace este trabajo, algunos patrones delatan a un candidato que no ha lidiado realmente con el desorden de datos reales.

Describir la herramienta en lugar de la decisión —"construí un dashboard en Tableau con filtros para región y fecha"— y detenerse ahí. Nadie preguntó cómo se veía el dashboard; preguntaron qué cambió por él.

Recitar la definición de un p-value sin poder decir qué no te indica. Si alguien no puede explicar, en sus propias palabras, por qué un resultado estadísticamente significativo en una muestra diminuta no es automáticamente digno de acción, ha memorizado el término en lugar de usarlo.

Saltar directamente a un gráfico o una consulta en un caso práctico sin primero preguntar qué significa realmente el negocio con el término en la pregunta —"engagement", "churn", "activo"— significan cosas diferentes en empresas diferentes, y los analistas que han trabajado con stakeholders reales saben preguntar antes de construir.

Reclamar autoría de un análisis sin mencionar que nadie lo cuestionó. El trabajo analítico real involucra a alguien en la sala que no está de acuerdo con tu número o tu enfoque. Una respuesta sin fricción es o un trabajo muy fácil o una historia editada.

Y en SQL específicamente: escribir una consulta que compila pero cuenta doble silenciosamente por un join no manejado, y no notarlo, y no verificar.

Qué hacer realmente antes de la entrevista

Elige un proyecto de tu propia historia —idealmente uno con datos genuinamente desordenados— y ensaya explicarlo en menos de un minuto: la pregunta, qué encontraste, qué cambió. Si no puedes hacerlo en menos de un minuto, probablemente no has terminado de separar el hallazgo del ruido alrededor.

Practica SQL contra un esquema con duplicados y nulos, no datos de tutorial limpios. Específicamente practica self-joins, funciones de ventana para deduplicación y ranking, y verificar conteos de filas antes y después de un join.

Prepara una historia honesta sobre haberte equivocado, con la corrección, no solo el error.

Antes de una ronda de caso práctico, escribe dos o tres preguntas que harías a un stakeholder antes de tocar los datos, y practica hacerlas en voz alta en lugar de saltar a un gráfico.

Si estás enviando muchas solicitudes y recibiendo poco retorno, la etapa de entrevista arriba normalmente no es el cuello de botella: es ser invitado a ella. jobmarket.pro lee cada anuncio contra tu perfil real y te dice dónde encajas genuinamente antes de preparar nada en tu nombre.