Preguntas de entrevista de PySpark

Puedes escribir PySpark que funcione y aun así tropezar aquí, porque estas preguntas indagan qué hace el motor, no qué dice tu código. Los entrevistadores suelen empezar con ellas precisamente porque separan a quienes han ajustado un job de quienes solo lo han ejecutado una vez. Esta sección cubre las preguntas sobre el modelo de ejecución y lo que debería incluir una respuesta completa.

• ¿Cuál es la diferencia entre una transformación y una acción? Las transformaciones construyen un plan y devuelven un nuevo DataFrame de forma perezosa; acciones como count, collect o una escritura disparan la ejecución. Nada se calcula hasta que una acción pide un resultado.
• ¿Por qué es útil la evaluación perezosa? El optimizador ve toda la cadena antes de ejecutarla, así que puede reordenar filtros, eliminar columnas innecesarias y combinar pasos.
• ¿Transformación estrecha o amplia? Las operaciones estrechas como filter y select hacen que cada partición de salida dependa de una sola partición de entrada. Las operaciones amplias como groupBy, join y distinct redistribuyen los datos entre particiones, lo cual es un shuffle.
• ¿Qué es un shuffle y por qué importa? Los datos se mueven por la red y llegan a disco, formando un límite de stage. Suele ser lo más costoso que hace un job.
• Explica qué son job, stage y task. Una acción inicia un job, los límites de shuffle lo dividen en stages, y cada stage ejecuta un task por partición.
• ¿RDD, DataFrame o Dataset? Prefiere DataFrame, porque se benefician del optimizador Catalyst y de la ejecución columnar. Los RDD se mantienen para control de bajo nivel. Los Dataset tipados son un concepto de la JVM, así que en Python la respuesta honesta es que no aplican.

Usa las palabras shuffle y stage cuando corresponda en la respuesta. Los entrevistadores las usan como un atajo para saber si realmente has revisado un Spark UI.

La mayoría de las entrevistas senior de PySpark son, en realidad, entrevistas de rendimiento. Las preguntas llegan como escenarios, no como definiciones.

• Un join va lento. ¿Qué revisas? Primero el tamaño de cada lado. Si uno cabe en la memoria del executor, lo difundes con broadcast y evitas el shuffle por completo. Si no, revisa el particionamiento y el sesgo antes de tocar el tamaño del clúster.
• ¿Qué es el sesgo de datos y cómo se corrige? Unas pocas claves concentran la mayoría de las filas, así que un task sigue corriendo mucho después de que los demás terminan. Los remedios incluyen aplicar salting a la clave caliente, difundir con broadcast el lado más pequeño o filtrar los nulos que se hashean juntos. La señal de diagnóstico es la dispersión en la duración de los tasks en el Spark UI.
• ¿Cuándo usar cache o persist? Cuando un DataFrame se reutiliza en varias acciones y recalcularlo sería costoso. Cachear algo que se usa una sola vez desperdicia memoria, y hacer unpersist a tiempo importa en jobs largos.
• ¿repartition o coalesce? repartition provoca un shuffle y puede aumentar o reducir particiones de forma uniforme; coalesce fusiona sin un shuffle completo, lo que es la forma más barata de reducir el número de archivos de salida.
• ¿Por qué evitar un UDF de Python? Las filas se serializan entre la JVM y un proceso de Python, y el optimizador no puede ver dentro de la función. Prefiere las funciones nativas, y recurre a un UDF vectorizado solo cuando no exista una función nativa equivalente.
• ¿Por qué es peligroso collect? Trae el resultado completo al driver y puede agotar su memoria.
• Un job falla por falta de memoria. ¿En qué orden lo investigas? Primero si es el driver o el executor, luego el sesgo, luego el tamaño de las particiones y por último la configuración de memoria. Subir la memoria como primer paso es la respuesta que delata falta de experiencia.

A un data engineer que entrevistaba para un equipo de plataforma le preguntaron por qué un job nocturno que llevaba un año funcionando de pronto tardaba cuatro horas. La respuesta que funcionó no fue un cambio de configuración, sino que un socio upstream había empezado a enviar valores nulos en la clave de join, de modo que todas las filas nulas se hasheaban hacia la misma partición. Los entrevistadores premian ese orden: mirar los datos antes que el clúster.

Los bancos de preguntas relacionados por rol están en preguntas de entrevista por rol.

Las preguntas restantes comprueban si has puesto en producción un pipeline, y no solo terminado un tutorial.

• ¿Cómo leer datos de forma eficiente? Formatos columnares como Parquet, partition pruning en la columna de filtro y predicate pushdown. Explica por qué leer menos bytes vale más que optimizar lo que ocurre después.
• ¿Por qué definir un schema en vez de inferirlo? Inferirlo cuesta una pasada extra sobre los datos y puede adivinar tipos de forma inconsistente entre ejecuciones.
• ¿Cómo se manejan los nulos y los duplicados? Las funciones relevantes, además del hecho de que las claves de join con muchos nulos generan sesgo.
• ¿Para qué se usan las funciones de ventana? Para rankings, totales acumulados y deduplicar al registro más reciente por clave, una tarea muy común en un pipeline.
• ¿Cómo escribir la salida sin generar miles de archivos pequeños? Hacer coalesce o repartition antes de escribir, y particionar la salida por una columna con una cardinalidad razonable.
• ¿Cómo se prueba código de PySpark? Con sesiones locales pequeñas y DataFrames de prueba, y con la lógica de negocio separada en funciones que reciben y devuelven DataFrames.
• ¿Cómo se envía y configura un job? El número de executors, los núcleos y la memoria, junto con el razonamiento de que tanto demasiados executors pequeños como muy pocos grandes desperdician capacidad.

Las respuestas de PySpark fallan en voz alta de una manera reconocible. El candidato sabe que un shuffle es costoso, pero no sabe decir qué operaciones lo provocan, así que la respuesta termina siendo una lista de adjetivos. Leer un banco de preguntas genera reconocimiento, y el reconocimiento no es lo mismo que dar una explicación mientras alguien espera.

Toma un pipeline que hayas construido y nárralo de principio a fin: la lectura, cada transformación, dónde caen los límites de stage y qué revisarías primero si se volviera lento. Hazlo en voz alta hasta que dejes de reiniciar la explicación. Practicar estas preguntas frente a un entrevistador de IA que hace repreguntas se parece más a una ronda real que releer notas, y para eso está pensado el modo de entrevista simulada.

Aaron Cao, fundador de SubcueAI, construyó la práctica alrededor de esa brecha al hablar, en lugar de simplemente ofrecer más preguntas. En una entrevista en vivo, la app de escritorio y el panel lateral de la extensión de navegador pueden mostrar estructura mientras el entrevistador habla, lo que ayuda sobre todo en contenido que ya has ensayado. La configuración toma unos minutos y está explicada en la página de tutorial.