Preguntas de entrevista Analista de datos

Empiezo por entender la pregunta de negocio detrás de la solicitud, no solo la pregunta de datos. A menudo lo que alguien pide y lo que realmente necesita son ligeramente diferentes, y una breve conversación por adelantado ahorra mucho retrabajo. Una vez que entiendo el objetivo, aclaro el alcance: qué período de tiempo, qué segmentos, qué nivel de precisión se necesita. Luego exploro los datos antes de construir nada, comprobando nulls, duplicados, valores atípicos y distribuciones inesperadas. Construyo el análisis de forma incremental, validando resultados intermedios. Antes de presentar los hallazgos me pregunto: si esto es correcto, ¿qué deberíamos hacer? Presento los hallazgos en el formato más simple que apoye la decisión.

Empiezo con el hallazgo, no con el método. Los stakeholders quieren saber qué dicen los datos y qué hacer al respecto: no necesitan entender la lógica JOIN que me llevó ahí. Estructuro las presentaciones con un hallazgo principal, dos o tres puntos de apoyo y una recomendación clara. Uso gráficos simples en lugar de tablas siempre que sea posible, porque las visualizaciones permiten captar relaciones instantáneamente. También traduzco las métricas a lenguaje de negocio: en lugar de "la tasa de retención a 30 días bajó 4 puntos porcentuales", digo "perdimos aproximadamente 400 clientes este mes que habríamos retenido el mes pasado".

Mi primera suposición es que he cometido un error, no que los datos me dicen algo sorprendente. Vuelvo a verificar la lógica de la consulta, los filtros aplicados, los rangos de fechas y si la tabla subyacente tiene problemas conocidos de calidad de datos. También busco una versión más simple de la misma pregunta: si elimino una variable a la vez, ¿el resultado sigue pareciendo incorrecto? Si el resultado se mantiene tras esa revisión, busco factores externos que puedan explicarlo. Solo una vez que he descartado errores y encontrado una explicación plausible presento el hallazgo, señalando que fue inesperado y describiendo las comprobaciones realizadas.

La IA ha cambiado cómo gestiono varias partes de mi flujo de trabajo. Para SQL, la uso para generar primeros borradores de consultas complejas con joins o funciones de ventana: suele obtener la estructura correcta, aunque siempre verifico la lógica cuidadosamente antes de ejecutar nada en datos de producción. Para scripts de Python, describo lo que necesito y obtengo un punto de partida funcional en segundos. Para presentar hallazgos, uso la IA para ayudar a redactar el comentario que acompaña a los gráficos: dado los números y el contexto, genera opciones para contar la historia que luego moldeo y edito. También la encuentro útil para tareas de limpieza de datos donde la lógica es clara pero el código es tedioso. Donde no me fío de ella es en la interpretación final: el trabajo del analista es entender qué patrones importan realmente para el negocio, y eso requiere un contexto que el modelo no tiene. Tampoco introduzco nunca datos sensibles o propietarios en interfaces de IA de consumo.

Me pidieron investigar por qué nuestra tasa de conversión de prueba a pago había bajado durante dos trimestres. Construí un análisis de embudo segmentado por canal de adquisición y encontré que la conversión desde búsqueda de pago había caído bruscamente, mientras la conversión orgánica era estable. Profundizando, encontré que la búsqueda de pago traía usuarios con títulos de trabajo muy diferentes a nuestro ICP principal. El coste por adquisición había bajado, pero también la calidad. Presenté esto al equipo de growth con una recomendación de añadir una señal de intención al targeting. Lo probaron y la conversión recuperó los niveles anteriores en seis semanas.

Heredé un dataset de reporting legacy construido fusionando tres tablas de origen con esquemas de ID inconsistentes. Alrededor del 12 % de las filas tenían valores nulos en una columna clave de join, y había eventos duplicados causados por un bug de logging. En lugar de ignorar los problemas, los documenté, estimé el impacto de cada uno en las métricas necesarias e hice elecciones explícitas sobre cómo manejar cada caso. También señalé los problemas de calidad al equipo de ingeniería, lo que llevó a una corrección en el pipeline. Cada análisis producido desde ese dataset incluía una breve nota sobre calidad de datos.

Mientras construía un informe semanal rutinario, noté que los usuarios móviles completaban nuestro flujo principal a aproximadamente la mitad de la tasa de los usuarios de escritorio. Nadie me había pedido que mirara esto. Realicé un análisis de cohorte rápido y encontré que la brecha se había ampliado en las ocho semanas anteriores, coincidiendo con un rediseño de navegación lanzado solo en móvil. Lo señalé al product manager con los datos y una hipótesis. La corrección posterior mejoró las tasas de finalización móvil en un 28 %.

Es una agregación sencilla, pero siempre aclaro primero: ¿"ingresos" significa brutos o netos? ¿Incluimos pedidos reembolsados? ¿El filtro de fecha es sobre la fecha del pedido o de pago? Asumiendo una tabla orders con customer_id, order_date y revenue, la consulta sería: SELECT customer_id, SUM(revenue) AS total_revenue FROM orders WHERE order_date >= CURRENT_DATE - INTERVAL '90 days' GROUP BY customer_id ORDER BY total_revenue DESC LIMIT 5. En la práctica también verificaría valores de ingresos negativos (reembolsos) y haría JOIN con una tabla de clientes para obtener el nombre por legibilidad.

Mi primer paso es entender si un valor atípico es un error de datos o un valor extremo real, porque el tratamiento es diferente. Para la detección uso inspección visual (scatter plots, box plots), métodos estadísticos (valores más allá de 3 desviaciones estándar, o límites basados en IQR) y comprobaciones de conocimiento de dominio. Una vez identificados, los errores de datos se corrigen o excluyen con una nota; los valores extremos reales generalmente se mantienen pero se manejan con cuidado. Para estadísticas descriptivas a menudo reporto la mediana junto a la media cuando hay valores atípicos significativos, porque la media puede estar muy distorsionada.

Un inner join devuelve solo las filas que tienen valores coincidentes en ambas tablas. Un left join devuelve todas las filas de la tabla izquierda y las filas coincidentes de la derecha: donde no hay coincidencia, las columnas del lado derecho son null. Uso un inner join cuando solo me interesan los registros que existen en ambas tablas. Uso un left join cuando necesito mantener todos los registros de la tabla principal independientemente de si existe una coincidencia: por ejemplo, unir usuarios a pedidos para encontrar usuarios que nunca han realizado un pedido. Un error común es usar un inner join cuando se necesita un left join, lo que elimina silenciosamente registros y puede sesgar las métricas.