Preguntas de entrevista adtech de SQL y Python: guía completa

Informatec Digital » Recursos » Preguntas de entrevista adtech de SQL y Python: guía completa

Si te estás preparando para una entrevista en adtech, analítica digital o data analyst, tarde o temprano te tocará enfrentarte a la temida prueba técnica. Ahí es donde las empresas comprueban si realmente dominas lo que pones en tu CV: SQL para explotar datos, Python para procesarlos y analizarlos, y algo de criterio analítico para no perderte entre tantas tablas y scripts.

La parte buena es que las entrevistas técnicas no son magia: suelen girar siempre alrededor de los mismos bloques de SQL, Python y evaluación de modelos. Si interiorizas bien los fundamentos, practicas con ejercicios reales y aprendes a explicar tu razonamiento, tendrás una ventaja muy seria frente al resto de candidatos.

Por qué asusta la entrevista técnica (y cómo quitarle hierro)

En puestos de analista de datos o de producto en adtech es habitual que la entrevista técnica combine preguntas conceptuales y ejercicios prácticos en vivo. Te pueden pedir desde explicar qué hace una cláusula de SQL hasta resolver un caso de negocio sobre datos de campañas publicitarias programáticas.

Normalmente te van a evaluar en tres frentes: SQL a nivel intermedio (JOIN, GROUP BY, subconsultas, window functions), Python orientado a datos (pandas, limpieza, agregaciones, merges) y tu capacidad para interpretar resultados y comunicar hallazgos. No buscan que seas científico de datos senior, sino que seas capaz de trabajar con datos de forma sólida y fiable.

El error típico de muchos candidatos es centrarse en memorizar sintaxis y olvidarse de practicar ejercicios completos, similares a los que te tocarán en plataformas como HackerRank, StrataScratch o los propios tests internos de las empresas. Tu objetivo debería ser llegar al día de la entrevista habiendo resuelto ya decenas de queries y scripts muy parecidos.

Nivel de SQL que se suele exigir en entrevistas adtech y data analyst

Para un rol de analista en entornos adtech o de marketing digital, las empresas esperan que domines con soltura el SQL relacional clásico: extraer datos de varias tablas, combinarlos, agruparlos, filtrarlos y crear métricas útiles. No te van a pedir administración de bases de datos, pero sí cierta comodidad con consultas de complejidad media.

Lo habitual es que en la prueba aparezcan consultas que mezclen INNER JOIN, LEFT JOIN, filtros con WHERE, agregaciones con GROUP BY y alguna condición sobre agregados con HAVING. A partir de ahí, en posiciones un poco más avanzadas es muy frecuente que entren subconsultas y funciones de ventana para rankings, acumulados y comparaciones entre filas.

Piensa que en adtech te tocará responder preguntas de negocio como “¿qué campañas tienen mejor CTR que la media de su vertical?” o “¿qué publishers están perdiendo impresiones respecto al mes pasado?”. Resolver esto de forma eficiente suele requerir un mínimo de soltura con subconsultas correlacionadas y window functions.

Preguntas básicas de SQL que suelen caer (y cómo responderlas)

En casi cualquier entrevista técnica orientada a datos aparece un bloque de preguntas teóricas básicas de SQL. No buscan pillarte, sino asegurarse de que los cimientos están bien colocados.

Una de las más repetidas es la diferencia entre WHERE y HAVING. La forma clara de explicarlo es contar que WHERE filtra filas individuales antes de agrupar, mientras que HAVING filtra grupos ya agregados. Además puedes mencionar que las condiciones sobre funciones de agregación (COUNT, SUM, AVG…) deben ir en HAVING, no en WHERE.

Otra pregunta clásica es qué tipos de JOIN existen y cuándo se usa cada uno: INNER JOIN, LEFT JOIN, RIGHT JOIN, FULL OUTER JOIN y, en algunos casos, CROSS JOIN o self join. En análisis de datos se utiliza muchísimo el LEFT JOIN cuando quieres mantener todo el universo principal (por ejemplo, todos los usuarios) aunque en la tabla secundaria (por ejemplo, compras) no haya registros asociados.

Ejemplos de consultas SQL básicas y su lógica

Para que te hagas una idea del nivel que se considera “mínimo razonable”, piensa que deberías poder escribir de memoria consultas como seleccionar columnas concretas, filtrar filas y ordenar resultados. A nivel muy básico, preguntas típicas son: cómo sacar todas las columnas de una tabla, cómo seleccionar solo algunas, o cómo aplicar alias legibles con AS.

También es normal que te pregunten por la cláusula WHERE con varias condiciones combinando AND, OR y NOT, o cómo usar operadores de comparación (<, <=, >, >=, =) tanto para valores numéricos como para fechas. Muchas empresas hacen hincapié en los filtros por NULL, en los que no basta con usar el signo igual, sino que hay que recurrir a IS NULL o IS NOT NULL.

Otro clásico son los filtros sobre texto con LIKE y patrones utilizando los comodines % y _. Por ejemplo, localizar campañas cuyo nombre contenga una palabra concreta o usuarios cuyo email termine en determinado dominio. Conviene que expliques que LIKE ‘%texto%’ busca el patrón en cualquier posición de la cadena.

Finalmente, en este bloque básico suele caer cómo actualizar registros con UPDATE y filtrar qué filas se modifican con WHERE, así como cómo eliminar filas con DELETE FROM usando también condiciones claras. Es crítico que comentes siempre la importancia de poner un WHERE específico para no cargarte media tabla por error.

Consultas intermedias: GROUP BY, HAVING, subconsultas y UNION

En cuanto te sales del nivel junior, casi todas las empresas empiezan a valorar si dominas la combinación de GROUP BY, funciones agregadas y filtros sobre agregados con HAVING. Es lo que vas a usar a diario para generar informes de rendimiento de campañas, audiencias o creatividades.

Funciona así: GROUP BY agrupa las filas por una o varias columnas, y sobre esos grupos puedes aplicar SUM, COUNT, AVG, MIN, MAX para calcular métricas. HAVING entra después, para quedarte solo con los grupos que cumplen una condición, por ejemplo clientes con ventas superiores a cierto umbral.

Otro tema recurrente son las subconsultas: una query dentro de otra query. Se usan mucho para filtrar por valores que se calculan en un paso previo, como seleccionar clientes con ventas por encima de la media global o campañas con impresiones superiores al percentil 90.

También suelen preguntarte por la diferencia entre UNION y UNION ALL. UNION combina dos conjuntos de resultados con el mismo esquema y elimina duplicados; UNION ALL hace lo mismo pero manteniendo todas las filas, incluso si están repetidas. En análisis de datos muchas veces preferirás UNION ALL por motivos de rendimiento y porque quieres conservar todos los registros originales.

Funciones de ventana: el siguiente salto en SQL

Las window functions se han convertido en un estándar en pruebas técnicas de cierto nivel, sobre todo para roles relacionados con adtech donde hay que analizar tendencias en el tiempo, rankings de campañas o acumulados de inversión.

La idea clave es que una función de ventana calcula un valor sobre un conjunto de filas relacionadas con la fila actual, pero sin colapsar el resultado como hace GROUP BY. Es decir, sigues viendo cada fila individual, pero acompañada de un agregado calculado sobre una “ventana” de datos.

La sintaxis típica es usar la función (SUM, AVG, RANK, etc.) seguida de OVER, y dentro de OVER definir la partición (PARTITION BY) y el orden (ORDER BY). Por ejemplo, calcular el ranking de ventas por comercial o el acumulado de impresiones por día.

Si quieres demostrar soltura, conviene que manejes funciones como RANK, DENSE_RANK, ROW_NUMBER, LAG y LEAD. Son muy útiles para clasificar campañas según su performance, comparar cada periodo con el anterior o identificar variaciones interanuales en métricas clave.

CTE, totales acumulados y medias móviles

En las entrevistas modernas se valora mucho la legibilidad de tu código SQL. Por eso es frecuente que te pregunten por las CTE (Common Table Expressions). Una CTE es básicamente una especie de tabla temporal con nombre, definida con WITH, que solo vive durante la ejecución de la consulta.

Las CTE se usan para descomponer consultas complicadas en bloques lógicos y reutilizar resultados intermedios. Por ejemplo, primero calculas las métricas diarias por campaña en una CTE y luego, en la query principal, haces agregados adicionales o filtrados sobre ese resultado.

Otro tipo de ejercicio muy típico es el cálculo de un total acumulado (running total) usando SUM como función de ventana. En entornos adtech es normal que te pidan acumulados de impresiones, clics o gasto para ver cómo evoluciona una campaña a lo largo del tiempo.

Relacionado con esto están las medias móviles, en las que se aplica AVG como función de ventana sobre un marco de filas desplazado (por ejemplo, las dos fechas anteriores y la actual). Es una forma sencilla de suavizar series temporales y detectar tendencias sin depender tanto de los picos diarios.

Nivel de Python que piden normalmente para analista de datos

En la mayoría de puestos de analista de datos (incluyendo adtech) las empresas no esperan que seas un gurú del machine learning, pero sí que controles Python a nivel práctico con pandas. Lo habitual es que te pidan cargar datasets, limpiarlos, transformarlos y obtener métricas o visualizaciones sencillas.

Las pruebas de Python suelen centrarse en operaciones como lectura de datos desde CSV, inspección de nulos y tipos de columna, filtrado de filas, creación de nuevas columnas, agregaciones con groupby y joins entre DataFrames. En muchos casos, el enunciado es casi idéntico a la parte de SQL, pero en versión pandas.

No es habitual que te exijan construir modelos complejos desde cero en una prueba de analista, aunque sí pueden valorar que sepas conectar con scikit-learn para entrenar un modelo básico y, sobre todo, que conozcas las métricas fundamentales para medir su rendimiento.

Operaciones básicas de pandas que debes controlar

Para aprobar con nota cualquier ejercicio de Python para datos debes manejar sin dudar las operaciones básicas sobre DataFrames. Lo primero suele ser cargar un archivo con read_csv y explorar la estructura con métodos como head(), info() o describe().

La parte de limpieza de valores nulos también suele aparecer: contar cuántos nulos hay por columna con isnull().sum(), decidir si eliminas filas o columnas completas con dropna() o si rellenas faltantes con fillna(), por ejemplo usando la media o la mediana de la columna.

En cuanto a filtros, te pedirán que construyas condiciones sobre columnas numéricas o categóricas, algo como seleccionar ventas superiores a cierto importe o filas que cumplan varias condiciones combinadas con & y |. La clave es que sepas escribir df sin dudar.

También entra casi siempre la explicación de groupby en pandas, que es el equivalente directo del GROUP BY de SQL. Agrupas por una o varias columnas y luego aplicas agregaciones como sum, mean, count, etc. La sintaxis groupby(‘columna’).agg() es un must.

Joins y merges entre DataFrames

Igual que en SQL es esencial dominar los JOIN, en pandas es obligatorio controlar pd.merge. Las empresas querrán ver si sabes unir datasets que comparten una clave, por ejemplo, una tabla de usuarios con otra de eventos o de compras.

La función merge recibe los dos DataFrames a unir, la columna clave (on) y el tipo de unión (how), que puede ser ‘left’, ‘right’, ‘inner’ o ‘outer’, igual que en SQL. En análisis de datos se usa sobre todo el left join para conservar el universo principal y añadir atributos o métricas desde tablas secundarias.

En una entrevista es buena idea que comentes detalles como qué ocurre cuando hay claves duplicadas en cualquiera de los lados o cómo manejar conflictos de nombres de columnas con los parámetros suffixes. Eso transmite un nivel de madurez superior.

Preguntas típicas de Python más teóricas

Más allá de pandas, muchas entrevistas incluyen un breve bloque de preguntas generales sobre Python para comprobar que entiendes bien el lenguaje. Suelen ser cuestiones cortas sobre características, memoria, tipos de datos o pequeñas piezas de sintaxis.

Entre los temas que aparecen una y otra vez está la gestión de memoria automática en Python, basada en un heap privado al que el usuario no accede directamente y un recolector de basura que se encarga de liberar objetos que ya no tienen referencias.

También es recurrente que te pidan comparar Python con Java, no para que declares un ganador, sino para que demuestres que entiendes las diferencias: Python es más dinámico, con una sintaxis más concisa, perfecto para prototipar y para ciencia de datos, mientras que Java suele dominar en ecosistemas más corporativos y de alto rendimiento.

Otras preguntas típicas giran alrededor de las expresiones lambda (funciones anónimas para operaciones sencillas), los procesos de pickling/unpickling para serializar objetos a bytes y recuperarlos, o la diferencia entre listas y tuplas, donde las primeras son mutables y se definen con corchetes y las segundas son inmutables y se definen con paréntesis.

Más conceptos clave de Python en entrevistas

Es común que te pregunten cómo se elimina o copia un objeto en Python. Normalmente basta con comentar que se puede usar la sentencia del para eliminar una referencia y que las copias superficiales se hacen con copy.copy(), mientras que las copias profundas requieren copy.deepcopy().

Otro concepto que puede aparecer, sobre todo en perfiles más de backend, es el llamado efecto dogpile, que describe el escenario en el que muchos usuarios o procesos atacan a la vez un recurso (por ejemplo, una web o caché), saturando el sistema.

Relacionado con el ecosistema, también puedes encontrarte preguntas sobre bases de datos que se pueden usar con Python. Lo más sensato es mencionar algunas populares como MySQL, PostgreSQL, SQLite, MongoDB u Oracle, y comentar que en general Python se integra bien con una gran variedad de motores relacionales y NoSQL.

Finalmente, suelen aparecer cuestiones más sencillas como cómo ordenar un diccionario usando sorted sobre items, qué es un namespace y para qué sirve (asociar nombres a objetos en distintos ámbitos), o cómo lanzar un subproceso utilizando el módulo subprocess con funciones como run() o Popen().

Métricas para evaluar modelos en Python: lo mínimo que deberías saber

Aunque en muchas posiciones de analista no te van a pedir que diseñes arquitecturas de deep learning, sí es habitual que conozcas las métricas básicas de evaluación de modelos de clasificación, especialmente si el rol toca producto de datos, atribución de campañas o detección de fraude en adtech.

El punto de partida es la matriz de confusión, que resume los aciertos y errores de un clasificador binario o multiclase. En el caso binario se descompone en verdaderos positivos (TP), verdaderos negativos (TN), falsos positivos (FP) y falsos negativos (FN). Entender bien estas cuatro casillas es clave.

A partir de la matriz se derivan métricas como la exactitud (accuracy), que mide el porcentaje de aciertos sobre el total; la precisión (TP / predicciones positivas) y el recall o sensibilidad (TP / positivos reales). Estas dos últimas son especialmente importantes cuando las clases están desbalanceadas.

La F1-score combina precisión y recall mediante la media armónica, penalizando especialmente que alguno de los dos sea muy bajo. Es una métrica muy habitual en escenarios donde tanto los falsos positivos como los falsos negativos son costosos, como detección de fraude, scoring de leads o detección de enfermedades.

Otras métricas avanzadas: ROC-AUC, logloss, Jaccard y más

Para posiciones con un componente más fuerte de data science o marketing analytics, las empresas se fijan en si dominas métricas más avanzadas como ROC-AUC, que mide el área bajo la curva ROC y refleja la capacidad de un modelo para separar clases.

La curva ROC representa la relación entre tasa de verdaderos positivos (recall) y tasa de falsos positivos (1 – especificidad) para distintos umbrales de decisión. Un modelo aleatorio se quedaría en una diagonal, mientras que un buen modelo se acerca a la esquina superior izquierda. Cuanto mayor es el área bajo la curva, mejor capacidad de discriminación.

Otra métrica común es la pérdida logarítmica (logloss), que evalúa la calidad de las probabilidades predichas, castigando fuertemente estar muy confiado y equivocado. Un modelo perfecto tendría logloss 0, y en general cuanto más baja sea la pérdida logarítmica, mejor.

También pueden preguntarte por el índice Jaccard, que mide la similitud entre dos conjuntos como el tamaño de la intersección dividido por el tamaño de la unión. Se utiliza para evaluar clasificadores, segmentaciones y sistemas de recomendación, entre otros.

En algunos contextos se mencionan gráficos de ganancia y elevación, que muestran qué porcentaje de objetivos capturas usando solo una parte de la población (por ejemplo, el 20 % de usuarios mejor puntuados por tu modelo). Esto es muy usado en marketing para decidir a quién impactar primero.

Kolmogorov-Smirnov, coeficiente de Gini y evaluación en profundidad

Si la empresa está muy volcada en scoring o modelos de riesgo, es posible que aparezcan métricas como el estadístico de Kolmogorov-Smirnov (K-S), que mide el grado de separación entre las distribuciones de puntuaciones de positivos y negativos.

Un valor de K-S cercano a 100 (en porcentaje) indica que el modelo separa casi perfectamente ambas poblaciones; un valor cercano a 0 implica que el modelo no distingue mejor que el azar. En la práctica, los modelos reales se mueven en valores intermedios y se comparan entre sí para elegir el mejor.

El coeficiente de Gini es otra métrica derivada del ROC-AUC mediante la fórmula Gini = 2 × AUC – 1. Muy popular en crédito y seguros, también se interpreta como una medida de desigualdad: cuanto más alto es el Gini, mayor es la capacidad del modelo para concentrar los verdaderos positivos en las puntuaciones más altas.

En entrevistas más avanzadas pueden pedirte que expliques cómo se implementan en Python estas métricas usando scikit-learn (por ejemplo, confusion_matrix, accuracy_score, roc_auc_score, f1_score…) y que comentes cuándo utilizarías cada una en función de la naturaleza del problema y el desbalanceo de clases.

Cómo estructurar tus respuestas durante la entrevista técnica

Más allá del código que escribas, los entrevistadores prestan mucha atención a cómo piensas y cómo te explicas. Una respuesta mal estructurada puede hacerte parecer más junior de lo que realmente eres, incluso aunque sepas la solución correcta.

Un esquema muy útil para responder preguntas técnicas es el siguiente: primero explica el concepto en una frase, luego aporta un ejemplo concreto (idealmente conectado con algún proyecto real tuyo) y, si procede, menciona alternativas o matices. Esto funciona igual para SQL, Python o métricas de modelos.

Por ejemplo, si te preguntan para qué sirve una CTE, podrías decir que es una subconsulta temporal con nombre que mejora la legibilidad de queries complejas, añadir que la usas cuando necesitas reutilizar un resultado intermedio varias veces, y comentar que en algunos casos se podría sustituir por subconsultas anidadas aunque sea menos claro.

También es clave pensar en voz alta. Si te atascas, no te quedes en silencio: verbaliza qué estás intentando hacer, qué información te falta, qué supuestos estás haciendo. Eso ayuda al entrevistador a ver tu proceso mental y, a veces, incluso te dará pistas o aclaraciones que faciliten avanzar.

Errores más comunes en entrevistas técnicas de datos

Muchos candidatos se quedan fuera no porque no sepan suficiente SQL o Python, sino por una combinación de mala preparación específica y errores de comunicación. Conviene tener muy claros los fallos habituales para evitarlos.

El primero es memorizar sin entender. Saberse la sintaxis de RANK o de una lambda no sirve de gran cosa si luego no puedes explicar en qué casos usarías esas herramientas o por qué son preferibles a otras alternativas.

Otro fallo muy frecuente es no explorar la calidad de los datos en los ejercicios. Si te dan un dataset, antes de lanzarte a agregar conviene comprobar si hay nulos, duplicados o valores extremos que puedan distorsionar el análisis. Eso demuestra criterio y experiencia práctica.

También penaliza mucho no hacer preguntas aclaratorias. En un caso de negocio sobre campañas de publicidad, por ejemplo, tiene mucho sentido preguntar si hay estacionalidad, qué ventana temporal interesa, si se busca métricas por usuario o por impresión, etc. Callarse y asumir cosas suele llevar a soluciones poco alineadas con lo que el entrevistador tenía en mente.

Finalmente, hay que evitar la actitud de “sobrecodificar”: montar soluciones innecesariamente complejas cuando la query o el script podría ser más simple. En entornos de trabajo real se valora que tu solución sea clara, mantenible y eficiente, no que parezca un rompecabezas.

Plan de preparación intensivo en dos semanas

Si tienes poco tiempo antes de la entrevista, puedes seguir una planificación comprimida que ataque los tres bloques clave: SQL, Python con pandas y práctica aplicada. No harás milagros en 14 días, pero sí puedes llegar con un nivel sólido y confianza razonable.

Durante los primeros días es buena idea centrarte en SQL de 0 a intermedio: repasar sintaxis básica, JOINs, GROUP BY, subconsultas y funciones de ventana más comunes. Dedica tiempo tanto a leer ejemplos como a escribir tus propias queries.

En una segunda fase, enfócate en pandas: carga de datos, limpieza, filtros, groupby, merges y alguna visualización rápida con matplotlib o seaborn. No hace falta montar dashboards complejos, pero sí ser capaz de replicar en Python las mismas transformaciones que harías en SQL.

Después reserva varios días para hacer ejercicios prácticos en plataformas tipo HackerRank o repositorios de entrevistas técnicas. El objetivo es acostumbrarte al formato, a los tiempos y a la presión de escribir código en un entorno controlado.

Por último, ensaya una o dos simulaciones de entrevista completas: coge un dataset público, plantea preguntas de negocio razonables, resuélvelas con SQL o Python y explica en voz alta todo tu razonamiento, desde la exploración inicial hasta las conclusiones finales.

Con una buena combinación de repaso teórico, práctica guiada y ejercicios realistas, llegarás al día de la entrevista con una base sólida en SQL intermedio, Python para análisis de datos y métricas de modelos, que es exactamente lo que la mayoría de empresas en adtech y analítica de datos esperan ver.