¿Cómo abordas una nueva solicitud de análisis?

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.

¿Cómo comunicas hallazgos de datos complejos a una audiencia no técnica?

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".

¿Cómo manejas una situación donde tu análisis produce resultados inesperados?

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.

Cuéntame sobre una vez que tu análisis llevó a una decisión de negocio significativa.

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.

Describe una vez que tuviste que trabajar con datos desordenados o incompletos.

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.

Da un ejemplo de cuando identificaste proactivamente un insight sin que te lo pidieran.

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 %.

Escribe una consulta SQL para encontrar los 5 mejores clientes por ingresos en los últimos 90 días.

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.

¿Cómo detectarías y manejarías los valores atípicos en un dataset?

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.

Explica la diferencia entre un left join y un inner join, y cuándo usarías cada uno.

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.

Analista de datos

Las entrevistas de analista de datos evalúan tu capacidad para convertir datos en bruto en decisiones. Los entrevistadores quieren ver fluidez en SQL, un enfoque estructurado del análisis y comunicación clara de los hallazgos a stakeholders no técnicos. La preparación importa en las tres áreas: los mejores candidatos combinan habilidad técnica con instinto de negocio. Esta guía cubre las preguntas más frecuentes y las respuestas que demuestran que estás listo para producir insights desde el primer día.

Para consejos generales de preparación, consulta nuestra guía sobre las preguntas de entrevista más frecuentes.

Preguntas de entrevista habituales para Analista de datos

Preguntas conductuales para puestos de Analista de datos

Preguntas técnicas para candidatos a Analista de datos

Lo que buscan los reclutadores en las entrevistas para Analista de datos

Lo que los responsables de selección buscan realmente en los candidatos a analista de datos:

Pensamiento de negocio, no solo habilidad técnica. Los mejores analistas entienden por qué importa un número, no solo cómo calcularlo.
Fluidez en SQL bajo presión. Espera preguntas de SQL en vivo: practica escribir consultas sin autocompletado.
Comunicación estructurada. ¿Puedes explicar un hallazgo complejo claramente en dos minutos? Practica en voz alta.
Conciencia de la calidad de los datos. Los analistas que señalan proactivamente los problemas de datos son mucho más confiables que los que presentan números sin advertencias.
Curiosidad intelectual. Los entrevistadores notan a los candidatos que hacen buenas preguntas sobre los datos, el negocio y las herramientas.

Preguntas que puedes hacer al entrevistador

→¿Cómo es el stack de datos aquí y qué herramientas usa el equipo día a día?
→¿Qué tan madura es la infraestructura de datos: hay modelos de datos fiables y un almacén bien mantenido?
→¿Cómo colabora el equipo de datos con los stakeholders de producto y negocio?
→¿Cómo es una solicitud de análisis típica y cómo se prioriza el trabajo del equipo?
→¿Cuál es el mayor reto de calidad o acceso a datos al que se enfrenta actualmente el equipo?

Practica estas preguntas antes de tu entrevista

El simulador de entrevista prepara una sesión de práctica basada en una oferta de empleo concreta y tu perfil, para que repases las preguntas con más probabilidad de aparecer.

Empezar a practicar

Gratis durante la beta. Sin compromiso.

Puestos relacionados

Ingeniero de software