Preparación para Entrevistas de Científico de Datos: Guía Completa 2026

Por qué la entrevista de DS se ve así en 2026

El título de científico de datos en 2026 no es el mismo trabajo que hace cinco años. Dos cambios estructurales comprimieron el rol desde ambos lados. Desde el lado del modelado, los ingenieros de ML absorbieron el trabajo de productización — cualquier cosa que se envíe a un stack de servicio ahora es un trabajo de MLE, no de DS. Desde el lado de análisis, los «analistas de ingeniería» con fuertes habilidades de dbt y almacén absorbieron el trabajo de dashboarding y definición de métricas. Lo que queda en el medio, donde viven la mayoría de las ofertas de trabajo de «DS» ahora, es ciencia de datos de producto — el rol que posee la experimentación, el diseño de métricas y el rigor estadístico detrás de las decisiones de producto.

Esto importa para la preparación de entrevistas porque el bucle ha seguido el rol. Hace cinco años un bucle de DS era 60% modelado y 40% SQL. En 2026 es más cercano a 60% SQL y experimentación, 25% sentido de producto y métrica, y 15% modelado — y la ronda de modelado, cuando aparece, es cada vez más un «caso de estudio» en lugar de un problema de codificación. Obtén la ponderación incorrecta en tu preparación y te sobre-enfatizarás en competiciones de estilo Kaggle mientras la entrevista real te está pidiendo que diagnostiques por qué una métrica cayó.

Hay una segunda pista — los roles de DS aplicado a ML en empresas que aún distinguen entre investigadores científicos, ingenieros de ML y científicos de datos aplicados (Netflix, Stripe, Anthropic, DeepMind en los casos limitados donde contratan bajo el título de DS). Estos bucles invierten la ponderación a ~50% profundidad de modelado, con la ronda de caso de estudio esperada para ir tres niveles profundos — diseño de características, metodología de evaluación, evaluación en línea — en lugar de abordar esto de manera superficial. Si estás buscando estos roles, prepárate en consecuencia; si estás buscando Meta o Airbnb, no.

El bucle de entrevista de DS en 2026, etapa por etapa

Un bucle típico de científico de datos en 2026 consta de cuatro a seis etapas durante tres a cinco semanas. La composición exacta varía según la empresa y la pista, pero la forma es consistente.

Llamada de reclutador (30 minutos). Principalmente logística y expectativas de compensación, más algunos sondeos de «háblame sobre ti». La señal aquí es si puedes articular claramente los tipos de problemas en los que has trabajado — sin jerga, sin falsa modestia. Dos o tres descripciones de proyectos claras, cada una vinculada a un resultado empresarial mensurable, es lo que te lleva a la siguiente ronda.

Pantalla SQL / codificación (45–60 minutos). Este es el filtro técnico. Codificación en vivo en StrataScratch, DataLemur, Coderpad, o HackerRank — dependiendo de la empresa. Dos o tres problemas SQL de mediana dificultad más, ocasionalmente, un problema de manipulación de datos en Python. El estándar es corrección en la primera ejecución, nombres de variables decentes, y una explicación de casos extremos que el entrevistador no preguntó. La presión de tiempo es real; la mayoría de los candidatos fallan por sobre-complicar el join.

On-site o on-site virtual (4–5 rondas, típicamente 45 minutos cada una). Aquí es donde los bucles divergen según la empresa:

• Meta ejecuta un análisis profundo de SQL, una ronda de sentido de producto/métrica, una ronda de pruebas A/B, y una conductual («¿cuál es un proyecto del que estés orgulloso?»). La ronda de producto tiene el mayor peso.
• Google es más amplio: SQL, estadística, un caso de estudio de ML, una ronda de producto, y una conductual de «Googleyness». El caso de ML está más presente que en Meta.
• Amazon está impulsado por los Principios de Liderazgo; espera que cada ronda se enhebre con sondeo de LP, más contenido técnico. SQL es corto; estadística es corta; la ronda específica de DS es usualmente un problema de diseño de métricas enmarcado en lenguaje LP.
• Netflix destaca por su énfasis en el pensamiento estratégico — menos rondas, mayor señal esperada por ronda, y un énfasis fuerte en la capacidad de escritura. Se te puede pedir que escribas un memorándum de una página explicando tu análisis.
• Airbnb pondera fuertemente las métricas del lado anfitrión («¿cómo medirías la rotación de anfitriones?») y ejecuta una ronda de producto larga.
• Empresas enfocadas en investigación de ML (DeepMind, Anthropic, OpenAI en los casos donde contratan DS en absoluto) ejecutan una ronda de discusión de papers y una ronda de modelado profundo además de las rondas estándar.

Ronda con el gerente de contratación (45 minutos). Típicamente programada al final, a veces entre rondas técnicas. Menos técnica, más sobre compatibilidad y cómo estructurarías tus primeros 90 días. Los candidatos senior deben esperar preguntas estratégicas — «¿cuál es la métrica más importante que este equipo debería rastrear que actualmente no?»

El tiempo total invertido desde la primera llamada del reclutador hasta la oferta raramente es inferior a tres semanas, y frecuentemente cinco a seis. Construye tu horario de preparación alrededor de eso, no alrededor de un único día de alto riesgo.

Rondas SQL: qué se evalúa realmente en 2026

La ronda SQL es donde la mayoría de candidatos pierden la oferta, y la brecha entre «sé SQL» y «puedo pasar una ronda SQL de 60 minutos» es más amplia de lo que los candidatos se dan cuenta. Tres categorías de problemas dominan.

Funciones de ventana — casi universalmente evaluadas. Las funciones específicas que aparecen una y otra vez: ROW_NUMBER(), RANK(), DENSE_RANK() para top-N-por-grupo; LAG() y LEAD() para cambio período-a-período; SUM() OVER (PARTITION BY ... ORDER BY ...) para totales acumulativos. Si no puedes escribir una consulta top-N-por-grupo sin pensarlo, fracasarás. La trampa clásica es recurrir a auto-uniones o subconsultas correlacionadas cuando una función de ventana lo haría en cinco líneas.

CTEs y transformaciones multietapa — el estilo moderno. Se espera que cualquier cosa más compleja que una unión única se exprese como una cadena de CTEs, nombradas claramente, con cada paso haciendo una cosa. El entrevistador busca legibilidad además de corrección; una cadena CTE de 40 líneas con nombres descriptivos siempre supera una solución de subconsulta anidada de 12 líneas.

Los cuatro patrones canónicos:

1. Top-N por grupo (encontrar los 3 principales clientes por gasto en cada región) — función de ventana con RANK() o ROW_NUMBER(), filtrar por rango.
2. Análisis de retención y cohortes (qué fracción de registros de enero regresaron en febrero) — auto-unión en user_id con aritmética de fechas, o funciones de ventana para banderas de días activos.
3. Conversión de embudo (registro → activación → primera compra) — CTEs escalonadas con comprobaciones LEFT JOIN o EXISTS, calculando tasas de conversión entre etapas.
4. Sesionización (agrupar filas en sesiones donde eventos consecutivos están dentro de 30 minutos) — LAG() para calcular diferencias de tiempo, luego una suma acumulativa de banderas de «nueva sesión».

El error más común con diferencia es la granularidad incorrecta. Si tu salida debe tener una fila por usuario-día y accidentalmente produces una fila por evento, cada recuento posterior es incorrecto por órdenes de magnitud. Siempre indica en voz alta cuál debe ser la granularidad de la salida antes de escribir la consulta, y verifica con un pequeño SELECT COUNT(*) después.

Rondas de estadística y probabilidad

La ronda de estadística es la más variable entre empresas. Algunos son teóricos (derivaciones de Bayes, propiedades de distribuciones); algunos son aplicados («¿qué prueba ejecutarías para este escenario?»). Tres subcategorías cubren la mayoría de lo que se pregunta.

Probabilidad bayesiana / condicional. El problema de Monty Hall sigue siendo preguntado, sorprendentemente a menudo, y sus variantes — «dos monedas, una justa una sesgada, lanzas y ves caras, ¿cuál es P(sesgada)?» — aparecen en la mayoría de empresas. El procedimiento mecánico es escribir el Teorema de Bayes, identificar la probabilidad previa, la verosimilitud y la evidencia, y calcular. Hacer esto en una pizarra mientras hablas es la habilidad real que se prueba; obtener la respuesta es necesario pero no suficiente.

Distribuciones y cuándo asumirlas. Las aproximaciones normales son útiles pero los candidatos las sobreutilizan. El entrevistador quiere escuchar: «Asumiría normal aquí porque n es lo suficientemente grande para que CLT aplique, pero verificaría comprobando los residuos; si los datos subyacentes tienen colas pesadas, recurriría a una distribución t o una alternativa no paramétrica». Nombrar la suposición y la verificación es la señal de nivel senior.

Pruebas de hipótesis. El marco estándar «¿qué prueba ejecutarías?»: identifica el tipo de métrica (proporción, media, recuento, razón), verifica los supuestos (independencia, normalidad, tamaño de muestra), elige la prueba (z-test para proporciones, t-test para medias, chi-square para categóricas, Mann-Whitney para no normales), establece la hipótesis nula y alternativa, define el nivel de significancia y discute la corrección de comparaciones múltiples si aplica. Deberías poder recorrer esto en 90 segundos para cualquier escenario.

Intervalos de confianza. La trampa está en la interpretación. «Hay un 95% de probabilidad de que la media verdadera esté en este intervalo» es incorrecto — los intervalos de confianza frecuentistas no hacen afirmaciones de probabilidad sobre parámetros. La afirmación correcta es: «si repetiera este experimento muchas veces, el 95% de los intervalos construidos contendrían la media verdadera». Si lo entiendes mal, los entrevistadores con fluidez en estadística lo notarán.

Pruebas A/B y experimentación: el pan de cada día

Este es el round más valorado en empresas product-DS (Meta, Airbnb, Uber). La rúbrica esperada, como mínimo:

1. Hipótesis — ¿qué crees que sucederá y por qué? Vinculada a un mecanismo conductual, no solo «creemos que será bueno».
2. Métrica — métrica de éxito principal, métricas secundarias, guardrails. Los candidatos senior siempre especifican guardrails antes de ser preguntados.
3. Power calculation — ¿cuántas muestras se necesitan para detectar un aumento del X% con una potencia del 80% y un nivel de significancia del 5%? Deberías poder estimar esto sin calculadora usando la regla práctica n ≈ 16 × σ² / δ² por brazo.
4. Unidad de aleatorización — ¿usuario, sesión, dispositivo? El entrevistador lo investigará; elige deliberadamente.
5. Guardrails y SRM check — desajuste de relación de muestra (la división real se desvía del 50/50 previsto) es la señal más común de un experimento fallido, y los candidatos senior lo comprueban antes de informar resultados.
6. Análisis — estimación puntual, intervalo de confianza, p-valor (con corrección de comparaciones múltiples si aplica), y la distinción entre significancia práctica y estadística.
7. Decisión — lanzar, no lanzar, o iterar, con el trade-off explícito.

Las trampas que el entrevistador investigará:

• Efectos de novedad. El tratamiento se ve excelente en la primera semana y retrocede en la tercera porque los usuarios solo estaban explorando la nueva característica.
• Efectos de red. La trampa clásica de Facebook News Feed — si el tratamiento cambia quién ve qué, no puedes aleatorizar por usuario porque el grupo de control está contaminado por el comportamiento de usuarios tratados. El entrevistador a veces fraseará esto como «¿y si estuviéramos probando un cambio en la clasificación del mercado?» y quiere escuchar el marco de interferencia de red.
• Dilución. Si solo el 10% de los usuarios ven la característica, el aumento en la población completa es el aumento en el 10% multiplicado por el 10%. Olvidar esto convierte un «aumento del 5%» en una afirmación de marketing que no resiste un segundo examen.
• Trade-offs entre métricas primarias y guardrails. «¿Y si los ingresos suben pero DAU baja?» La respuesta senior implica la elasticidad del guardrail y una pregunta de horizonte — un aumento de ingresos a corto plazo que cuesta compromiso a largo plazo raramente vale la pena.

Un recorrido de ejemplo práctico — diseñar el experimento para un nuevo feed de la página de inicio — debería tomar unos 8–10 minutos. Practica esto hasta que sea automático.

Estudios de caso de ML (el ángulo product DS)

Cuando ML aparece en un loop product DS, aparece como un estudio de caso, no como un round de codificación. El marco siempre es alguna variante de «diseña un ranker para X» — clasificación de feed, resultados de búsqueda, recomendaciones, selección de anuncios. La estructura esperada:

1. Objetivo empresarial — ¿para qué estamos realmente optimizando? ¿Compromiso, ingresos, retención a largo plazo? La señal senior es nombrar el objetivo a largo plazo incluso cuando la métrica de proxy es a corto plazo.
2. Etiquetas — ¿cuáles son las clases positivas y negativas? ¿Cómo se generan las etiquetas y qué sesgos introduce? (Sesgo de posición, sesgo de selección, el problema de arranque en frío).
3. Características — tres a cinco categorías: características de usuario, características de elemento, características de contexto, características de interacción, y (para modelos conscientes de secuencia) características de historial reciente.
4. Clase de modelo — árboles potenciados por gradiente como valor predeterminado confiable, aprendizaje profundo donde los datos y la señal lo justifican. El candidato senior nombra el trade-off — interpretabilidad, costo de entrenamiento, latencia de servicio en línea — en lugar de alcanzar lo que sea de moda.
5. Evaluación sin conexión — AUC-ROC para clasificación, NDCG para clasificación, RMSE para regresión. La trampa es parar aquí; las métricas sin conexión correlacionan débilmente con métricas empresariales en línea, y el candidato senior lo señala.
6. Evaluación en línea — diseño de prueba A/B, métricas primarias y guardrails, el bucle de vuelta al round de experimentación.

La profundidad honesta esperada por nivel: en L4 (junior) puedes describir cada paso. En L5 (mid) puedes argumentar trade-offs en cada paso. En L6 (senior) puedes identificar los dos o tres pasos donde este estudio de caso es inusual — qué lo hace más difícil que el marco de libro de texto — y proponer cómo lo manejarías.

Rounds de producto/métrica: la caída de DAU

El round de producto característico, preguntado en casi todas las empresas que hacen entrevistas de product DS, es alguna variante de: «DAU bajó un 5% semana a semana. Cuéntame paso a paso cómo lo investigarías».

El marco esperado, ejecutado en vivo:

1. Valida los datos primero. ¿La métrica realmente bajó, o es un problema de instrumentación? Verifica el pipeline de logging, verifica cambios upstream, busca datos de día parcial.
2. Segmenta. Por geografía, plataforma, SO, país, cohorte de usuario, canal de adquisición. La caída rara vez es uniforme; encontrar el segmento localiza la causa.
3. Descompone por comportamiento. DAU = nuevos usuarios + usuarios que regresan. ¿Bajó el registro de nuevos usuarios? ¿Bajó la retención de usuarios que regresan? Estas tienen causas completamente diferentes.
4. Descompone por embudo. Dentro de cada grupo de comportamiento: ¿bajaron las aperturas de la aplicación? ¿Bajó la tasa de apertura a compromiso? Cada paso tiene diferentes causas upstream.
5. Referencia cruzada con eventos externos. Lanzamientos de productos (propios y de los competidores), ciclos de noticias, vacaciones, cambios de marketing pagado, incidentes de infraestructura.
6. Forma una hipótesis, diseña una verificación. Una vez que tengas una explicación candidata, ¿qué datos la falsificarían?

En Meta y Google, el resultado esperado es un «árbol de métricas» — una descomposición visual de la métrica que muestra cada entrada y la magnitud relativa de su cambio. El candidato senior dibuja el árbol antes de hablar, luego lo recorre; el candidato junior habla primero y nunca llega al árbol.

Dónde un asistente de IA en tiempo real ayuda en rondas de DS — y dónde no

Sé honesto al respecto. El ciclo de DS tiene rondas donde la ayuda de IA te puede llevar gran parte del camino, y rondas donde te hace sonar como un fraude. La tabla de abajo es lo que les decimos a nuestros propios usuarios.

Feature	SQL	Estadísticas	Pruebas A/B	Caso de ML	Producto / métrica	Conductual
Calidad de ayuda de IA	Excelente	Buena	Fuerte	Fuerte	Moderada	Fuerte
Requisito de latencia	Menos de 200 ms (codificación en vivo)	Conversacional	Conversacional	Conversacional	Conversacional	Conversacional
Requisito de sigilo	Alto (compartición de pantalla)	Medio	Medio	Medio	Medio	Medio
Comodidad ética	Controvertido	Cómodo	Cómodo	Cómodo	Cómodo	Decisión personal
Modo de uso recomendado	Script casi verbatim	Ayuda para pensar	Prompt de marco	Esquema + tú completas	Lluvia de ideas; defiéndete	Solo esquema — dilo con tu voz

El resumen honesto: las pantallas de SQL son donde la asistencia de IA está más cerca de asumir el trabajo — la sintaxis es rígida, la distancia de edición desde prompt a consulta funcional es pequeña, y buenos asistentes como Acedly leen el editor directamente. En rondas de estadísticas y pruebas A/B la IA es extremadamente útil para hacer aflorar el marco correcto y la prueba correcta, pero aún tienes que defender la respuesta cuando el entrevistador indaga. En rondas de producto/métrica la IA es un socio de lluvia de ideas pero no puede defender la respuesta por ti — el entrevistador preguntará "¿por qué ese segmento, no este?" y necesitas tener una opinión. En rondas conductuales la IA puede producir una estructura (situación-tarea-acción-resultado) pero el contenido tiene que ser tuyo, con tu voz, o sonará ensayado.

Acedly durante una ronda de DS en vivo

Acedly está construida para entrevistas humanas en vivo donde tú controlas la divulgación. Específicamente, para rondas de científico de datos, tres cosas importan:

Latencia. La latencia mediana de extremo a extremo es aproximadamente 98 ms — medida desde el final de la enunciación al primer token renderizado. Ese presupuesto importa más en la pantalla de codificación SQL, donde la brecha entre "la IA ayuda" y "la IA es demasiado lenta para ayudar" es la diferencia entre escribir tu propia respuesta y copiar la suya.

Lectura del editor de plataforma de codificación. La mayoría de pantallas SQL de DS se ejecutan en Coderpad o HackerRank — ambas superficies verificadas donde Acedly lee el enunciado del problema, el esquema y la consulta parcial que el candidato ha escrito, y usa los tres como contexto de fundamentación. Un copiloto que solo escucha audio deja el esquema sobre la mesa, lo que significa peores sugerencias SQL.

Enrutamiento multi-modelo. Las preguntas de SQL se enrutan a DeepSeek para generación de código; estadísticas y probabilidad se enrutan a Claude para calidad de razonamiento; rondas de producto/métrica se enrutan a GPT para contexto empresarial más amplio. El enrutador selecciona por pregunta, no por sesión.

Ocho plataformas verificadas. Zoom, Microsoft Teams, Google Meet, Webex, Lark/Feishu, Amazon Chime, Coderpad, HackerRank. Juntas cubren aproximadamente el 95% de las superficies de entrevista de DS profesional en 2026.

12+ lenguajes de programación, incluido SQL. Python, R, SQL (dialectos PostgreSQL, MySQL, BigQuery, Snowflake), Scala, Java, JavaScript/TypeScript, Go, Rust, C++, Julia, MATLAB, Bash. La detección del dialecto SQL importa porque la sintaxis de función de ventana difiere sutilmente entre Postgres y MySQL.

Un plan de preparación de 4 semanas para entrevistas de DS

Si tienes cuatro semanas, el cronograma a continuación es un plan viable. Ajusta la ponderación si te estás dirigiendo a un tipo no estándar.

Semana 1 — Práctica de SQL. Dos horas al día. Cincuenta problemas en StrataScratch o DataLemur, enfocados en funciones de ventana, patrones de retención/cohorte y consultas de embudo. Cada problema requiere un análisis de una sola frase: qué patrón, qué función de ventana, cuál era la granularidad. Al final de la semana deberías poder reconocer top-N-per-group desde la primera frase.

Semana 2 — Estadística, probabilidad y pruebas A/B. Una hora de teoría (revisión de distribuciones, pruebas de hipótesis, Bayes), una hora de aplicación — resuelve diez preguntas clásicas de pruebas A/B (tamaño de muestra, efectos de novedad, efectos de red, dilución). Practica la rúbrica de siete pasos en voz alta hasta que sea automática. Lectura: Trustworthy Online Controlled Experiments de Kohavi, Tang y Xu cubre casi todo lo que se pregunta.

Semana 3 — Casos simulados de producto y métricas. Tres casos simulados por día, 30 minutos cada uno, sobre una variedad de métricas. La caída de DAU, el declive del engagement, la caída de la tasa de conversión, el pico de churn. Usa el marco de árbol de métricas cada vez. Grábate a ti mismo; reprodúcelos; los primeros tres son malos, el décimo es automático.

Semana 4 — Específico de la empresa. Si te estás dirigiendo a Meta, practica casos de producto de la pista Decode and Conquer. Si te estás dirigiendo a Google, amplía entre casos de SQL, estadística y ML. Si te estás dirigiendo a Amazon, prepara un portafolio mapeado por LP de dos historias por principio. Las últimas 48 horas: descanso. Problemas más ligeros, dormir, el refresco mental de reconocer que has hecho el trabajo.

El hábito más apalancado, a lo largo de todas las semanas: escribe un análisis retrospectivo de una sola frase para cada problema que resuelvas. Después de 50 problemas, tendrás una tabla continua de tu propio historial de reconocimiento de patrones. Después de 100, estarás diagnosticando caídas de DAU mientras duermes.

Preguntas frecuentes

¿Cuánto tiempo debo prepararme para una entrevista de científico de datos?

¿Necesito saber deep learning para obtener una oferta de DS en 2026?

SQL vs Python: ¿cuál se prueba más en entrevistas de DS?

¿Cuál es la diferencia entre entrevistas de product DS y ML-applied DS?

¿Puedo usar un asistente de IA durante una pantalla SQL en vivo?

¿Qué empresas todavía están contratando DS en 2026?