La mejor prueba de Power BI para contratar analistas de datos
Por qué la mayoría de las pruebas de Power BI no captan el trabajo real
Muchos tests son carreras de construcción de dashboards. Crea un dashboard. Añade tres visualizaciones. Listo en 45 minutos. Pero no es así como trabaja una analista.
El trabajo real con Power BI es:
- Entender datos fuente sucios y decidir qué limpiar
- Elegir entre columnas calculadas, medidas y lógica DAX
- Diseñar dashboards para audiencias específicas (ejecutivas quieren KPI, operaciones quiere drill-down, finanzas quiere audit trail)
- Tunear rendimiento cuando un informe llega a 100 K filas
- Saber cuándo Power BI es exagerado y Excel o SQL son más rápidos
Una buena prueba evalúa esas dimensiones, no solo «sabes hacer clic en los botones de visualización».
Test de cribado: ¿sabe modelar datos?
Empieza con un escenario de 30 minutos. Envía un CSV exportado y desordenado y pídele:
- Cargar los datos en Power BI
- Identificar problemas obvios de calidad
- Limpiar dos columnas (que tengan problemas reales)
- Crear tres medidas (ventas totales, ticket medio, crecimiento mes a mes)
- Explicar por qué usó medida en lugar de columna calculada en una de ellas
Esto evalúa:
- Comprensión conceptual de tablas de hechos, dimensiones y star schema
- Conciencia de calidad de datos
- DAX básico (SUM, DIVIDE, división segura)
- Juicio sobre columnas vs. medidas (clave para distinguir júnior de mid)
Puntuación:
- Datos cargados y limpiados: aprueba/no aprueba
- Las medidas funcionan: sí/no
- Explicación columna vs. medida: superficial vs. matizada
Esto filtra a quienes nunca han modelado datos.
Test take-home: diseño real de dashboard
Quienes pasen el cribado van a una take-home de 2–3 horas:
«Tienes un CSV con 6 meses de transacciones: fecha, ID cliente, categoría, importe, región, segmento (nuevo/recurrente).
Construye un dashboard de Power BI que responda a:
- Ingreso total y número de clientes por región
- Cómo se comparan clientes nuevos frente a recurrentes en gasto medio
- Qué categorías están al alza mes a mes
- Para un ID concreto (input), su historial completo y LTV.
Diseña para una VP de Ventas. Lo mira a diario. Una sola página. Que sea accionable».
Esto evalúa:
- Modelado: ¿estructura los datos para consultas eficientes?
- Selección de visuales: ¿elige el gráfico adecuado? (ingreso por región = barra/mapa, no línea)
- Conciencia de audiencia: ¿el dashboard está abarrotado o focalizado?
- Interactividad: ¿usa slicers y drill-through con sentido o añade ruido?
- Rendimiento: ¿entiende qué hace lento un modelo? (relaciones, DAX, medidas no optimizadas)
Entrega:
- Fichero
.pbix - Documento de 1 página: «por qué elegí estos visuales, cómo lo usaría una VP, qué falta».
Esto separa quien apila gráficos de quien piensa en impacto.
Conversación de evaluación: 30 minutos
Lleva el dashboard a una videollamada. Pregunta:
- «Cuéntame el modelo de datos. ¿Por qué lo estructuraste así?» Espera explicaciones tipo hechos/dimensiones, o un «puse las transacciones aquí y crucé regiones». Cualquiera revela su modelo mental.
- «¿Cómo rendiría con 2 años en lugar de 6 meses? ¿Qué se rompería?» Separa quien ha desplegado en producción de quien solo ha hecho prototipos.
- «La VP pide una nueva columna: rentabilidad por cliente (ingreso menos coste). Cuéntame cómo lo añadirías». Comprueba si lo metería en el origen (mal), como nueva medida (mejor) o si piensa en bordes (lo mejor).
- «¿Qué no puede decirte este dashboard?» ¿Reconoce los límites del dato transaccional o cree que responde a todo?
- «¿Has usado Power BI en producción?» La autoevaluación honesta importa.
Qué evaluar y qué saltarte
Sí (diferencian):
- Modelado básico
- Juicio DAX (medidas vs. columnas, división segura)
- Diseño visual para audiencia (no bonito; funcional)
- Intuición de rendimiento (pregunta por tamaño? cardinalidad?)
- Pensamiento de calidad de datos
No (no diferencian):
- Funciones DAX exóticas. Una analista usa SUM, DIVIDE, DISTINCTCOUNT, RELATED — eso cubre el 95 %.
- Formato y colores. Subjetivo y de baja señal.
- Funciones de admin. RLS, pipelines de despliegue, gateway. Son infraestructura.
- SQL o data warehouse. Salvo si construye ETL.
Errores comunes
1: dataset perfecto. El dato real es sucio. Añade formatos de fecha inconsistentes, nulos, duplicados, espacios.
2: medir tiempo. «Lo hizo en 1 hora, es rápido». No, igual copió un tutorial. La calidad del razonamiento manda.
3: demasiada libertad. «Construye lo que quieras». Da audiencia y preguntas concretas.
4: probar Tableau/Looker en lugar de pensamiento analítico. Si te importa Power BI, prueba Power BI. Pero la mayor parte de la habilidad es analítica, no sintaxis específica.
Por rol
Analista de negocio
Énfasis en diseño para no técnicos. ¿Sabe explicar tendencias con simplicidad?
Analista de datos / analytics engineer
Modelado a fondo. Rigor DAX. Diferenciar agregación de filtro separa júnior de experimentada.
Manager de analytics
Estrategia de dashboards. Dada una pregunta, ¿cómo estructuraría la analítica? ¿Cuándo diría «esto no encaja en Power BI»?
Integración con tu proceso
La evaluación de Power BI encaja en una estrategia más amplia de habilidades de software:
- Cribado (30 min): modelado + medidas. Aprueba/no.
- Take-home (2–3 h): dashboard real. Pasan al interview.
- Conversación (30 min): razonamiento, rendimiento, autoevaluación honesta.
- Ronda comportamental (30–45 min): proyectos reales. ¿Cómo gestionó requisitos ambiguos? ¿Qué falló?
Juntos evalúan capacidad y juicio.
Meta-evaluación: elección de herramienta
Una analista fuerte podría decir: «He usado Tableau y Looker, pero aprendo herramientas rápido. Mi habilidad es pensar con datos, no la sintaxis».
Es correcto. Evalúa el pensamiento. La herramienta es implementación.
Pero si el puesto requiere Power BI específicamente, evalúalo. Adapta la prueba al trabajo real.
Un test de dashboard que mida pensamiento analítico real — calidad de datos, diseño para audiencia, intuición de rendimiento — gana siempre a una carrera de formato.