Preguntas de entrevista para Analista de Datos

Respuesta modelo

En la cadena de retail donde trabajaba, la dirección comercial quería ampliar una promoción de fin de semana a todas las tiendas. Crucé en SQL el ticket medio, el margen por familia y la rotación de stock de las 78 tiendas y descubrí que la promoción subía las unidades un 12 %, pero hundía el margen un 4 % porque canibalizaba el producto de mayor rentabilidad. Lo presenté en una sola diapositiva con la comparativa entre tiendas con y sin promoción. La dirección la mantuvo únicamente en las 21 tiendas donde sí era rentable, y el margen del trimestre mejoró 1,8 puntos frente al escenario de ampliación total.

Respuesta modelo

Empiezo por escribir las definiciones que circulan y ponerlas una al lado de otra: en el caso de la «venta neta», Comercial excluía las devoluciones del mes en curso y Finanzas las imputaba al mes de la venta original, y de ahí venía un desfase del 6 %. Convoco una reunión corta con una persona de cada área, propongo una definición única con su fórmula, su granularidad y sus exclusiones, y la dejo por escrito en el diccionario de métricas. Después la implemento como una única medida en el modelo de Power BI, para que ningún informe pueda recalcularla por su cuenta, y publico la fecha desde la que aplica.

Respuesta modelo

No abro el editor de SQL todavía. Hago tres preguntas: qué decisión va a tomar con ese dato, con qué periodicidad lo necesitará y con qué cifra debe cuadrar. La respuesta cambia por completo el trabajo: si es para una reunión puntual, entrego una tabla y termino; si va a repetirse cada semana, construyo una vista y un cuadro de mando. En mi anterior puesto, ese hábito redujo un 40 % las peticiones ad hoc, porque muchas se resolvían con un informe que ya existía y que la persona no conocía.

Respuesta modelo

Sigo siempre la misma lista. Primero, cuadro los totales con una fuente independiente, normalmente la contabilidad o el sistema transaccional. Segundo, compruebo el recuento de filas antes y después de cada JOIN para descartar duplicados. Tercero, reviso los valores nulos y las fechas fuera de rango. Cuarto, comparo con el periodo anterior y me exijo una explicación para cualquier variación superior al 10 %. Quinto, se lo enseño a alguien del área de negocio antes de la publicación oficial. Con este procedimiento, la discrepancia entre el informe de ventas y la contabilidad de SAP pasó del 6 % al 0,4 % en dos trimestres.

Respuesta modelo

Porque el valor que sé aportar está en la parte descriptiva y diagnóstica, y me gusta estar cerca de la decisión. Mi trabajo consiste en que el dato sea fiable, esté bien modelado y llegue explicado a quien tiene que decidir: SQL, modelado dimensional, cuadros de mando, definición de KPI y muchas conversaciones con negocio. Conozco los fundamentos del aprendizaje automático y he colaborado con científicos de datos preparándoles conjuntos de datos limpios y documentados, pero no reivindico experiencia en entrenar ni desplegar modelos en producción. Prefiero decirlo con claridad antes que venderme para un puesto que no es el mío.

Respuesta modelo

Aplico dos criterios: fecha de la decisión que depende del dato y número de personas afectadas. Pregunto a cada solicitante cuándo se toma la decisión y qué ocurre si el dato llega un día después; con eso, dos de las tres peticiones suelen dejar de ser urgentes. Después comunico el orden por escrito a los tres, con la hora estimada de entrega de cada uno, para que nadie se quede esperando en silencio. Si el conflicto persiste, lo escalo a mi responsable con las tres peticiones y su impacto sobre la mesa, en lugar de decidir yo sobre prioridades de negocio que no me corresponden.

El INNER JOIN devuelve solo las filas con correspondencia en ambas tablas; el LEFT JOIN conserva todas las de la tabla izquierda y rellena con nulos las que no casan. En un informe de ventas por cliente, el INNER JOIN me haría perder silenciosamente los pedidos de clientes que no están en el maestro, que es justo el error que hay que evitar. Para detectar duplicados comparo el recuento de filas antes y después del cruce; si aumenta, la clave del lado derecho no es única. Lo verifico con un SELECT clave, COUNT(*) ... GROUP BY clave HAVING COUNT(*) > 1 y, según el caso, deduplico con una CTE y ROW_NUMBER() OVER (PARTITION BY clave ORDER BY fecha_actualización DESC) o corrijo la granularidad del modelo.

Uso ROW_NUMBER() con PARTITION BY para quedarme con el último registro de cada entidad, por ejemplo el último estado de cada pedido en una tabla que guarda todo el histórico de cambios. También empleo mucho SUM(...) OVER (PARTITION BY cliente ORDER BY fecha ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) para acumulados, y LAG() para calcular la variación frente al periodo anterior sin necesidad de un autojoin. La ventaja frente a un GROUP BY es que conservo el detalle fila a fila mientras añado el cálculo agregado, lo que resulta esencial cuando el cuadro de mando debe permitir el desglose hasta el ticket.

Un esquema en estrella separa una tabla de hechos, con las métricas y las claves, de varias tablas de dimensiones descriptivas: calendario, producto, tienda y cliente. Lo prefiero por tres motivos. Rendimiento: el motor VertiPaq comprime mucho mejor las dimensiones pequeñas y los filtros se propagan en una sola dirección. Mantenimiento: un cambio en la descripción de un producto se hace en un solo sitio. Corrección: la tabla de calendario marcada como tabla de fechas es la condición necesaria para que la inteligencia de tiempo de DAX funcione. En un modelo de 40 millones de filas, pasar de una tabla plana a un esquema en estrella redujo el tiempo de carga del informe de 22 s a 3 s.

CALCULATE evalúa una expresión modificando el contexto de filtro en el que se calcula. Es la única forma directa de decir «calcula esta medida, pero ignorando este filtro o aplicando este otro»: ventas del mismo periodo del año anterior con SAMEPERIODLASTYEAR, cuota sobre el total de la categoría con ALL, o ventas de una familia concreta con independencia de lo que el usuario haya seleccionado. También convierte el contexto de fila en contexto de filtro, que es lo que permite que una columna calculada evalúe una medida correctamente. En la práctica, el 90 % de los errores de DAX que he corregido eran problemas de contexto de filtro, no de sintaxis.

Primero miro el plan de ejecución y el volumen leído; en BigQuery, los bytes procesados. Después reviso lo previsible: si la tabla ha crecido, si la partición por fecha se está aprovechando o si un filtro sobre una columna transformada impide usar la partición o el clúster. Reduzco cuanto antes en la consulta, filtrando y agregando antes de los cruces en lugar de después, elimino el SELECT * y sustituyo subconsultas repetidas por una CTE materializada o una tabla intermedia. Si la consulta alimenta un informe diario, la convierto en una tabla agregada programada: el cuadro de mando no debería recalcular cada mañana lo que no cambia.

Antes de buscar una explicación de negocio, descarto el problema técnico: compruebo si el proceso de carga terminó correctamente, si el recuento de filas del día es coherente con la media y si algún cambio en el origen ha modificado un código o una categoría. Si el dato es correcto, descompongo la caída por dimensiones hasta aislarla: canal, tienda, familia de producto, dispositivo y segmento de cliente. Casi siempre la caída se concentra en una sola combinación, y eso apunta directamente a la causa: una tienda cerrada, una pasarela de pago con incidencias o una etiqueta de seguimiento eliminada en un despliegue web. Solo entonces comunico la conclusión, indicando siempre si el dato es definitivo o provisional.

Primero doy por buena su observación y le pido su fichero, porque en la mitad de los casos el error es mío. Comparo las dos cifras acotando el periodo y el perímetro, y busco dónde divergen: casi siempre es una diferencia de definición, como incluir o no las devoluciones, o un tipo de cambio distinto. Se lo explico con las dos cifras y su origen, no con argumentos técnicos. Si el error es del cuadro de mando, lo corrijo, aviso a todos los usuarios y explico qué he cambiado; si es de su fichero, se lo muestro sin dejarlo en evidencia delante de su equipo y propongo que su Excel se alimente del modelo oficial para que el problema no vuelva a plantearse.

Aviso de inmediato, sin esperar al día siguiente ni a tener la versión corregida. Envío un mensaje breve a las personas destinatarias indicando qué métrica está afectada, en qué magnitud y si alguna decisión pendiente debería esperar. Después corrijo, verifico con la lista de comprobación habitual y reenvío la versión buena con la corrección señalada. Por último, añado una regla de validación que impida que ese error concreto vuelva a pasar inadvertido. La credibilidad se pierde por ocultar un error, no por cometerlo.

Presento lo que muestran los datos, con las limitaciones incluidas, y no maquillo el resultado. Lo hago primero en privado con quien me lo ha encargado, para que no se sienta desautorizado en público, y llevo la conversación al terreno de las condiciones: en qué escenario la decisión sí funcionaría y qué habría que vigilar. Si aun así se decide seguir adelante, lo acepto, porque la decisión no me corresponde, pero propongo definir de antemano las métricas de seguimiento y la fecha de revisión. Mi responsabilidad es que se decida con información veraz, no que se decida lo que yo prefiero.

Empiezo por la conclusión y la recomendación, en una frase. Después muestro un único gráfico que la sostenga, elegido por claridad y no por vistosidad, y explico la magnitud del impacto en euros o en clientes. Reservo el método, el tamaño de la muestra y las salvedades para las preguntas y para un anexo escrito. Preparo dos respuestas de antemano: qué hago si alguien cuestiona la fiabilidad del dato y qué respondo si me piden un desglose que no traigo, en cuyo caso me comprometo a enviarlo el mismo día. Diez minutos dan para una idea bien defendida, no para tres a medias.