Perguntas de entrevista de PySpark

Você pode escrever PySpark que funciona e ainda assim tropeçar aqui, porque essas perguntas questionam o que o engine faz, não o que o seu código diz. Os entrevistadores costumam começar por elas justamente porque separam quem já ajustou um job de quem só o executou uma vez. Esta seção cobre as perguntas sobre o modelo de execução e o que uma resposta completa deve incluir.

• Qual é a diferença entre transformation e action? Transformations constroem um plano e retornam um novo DataFrame de forma preguiçosa; actions como count, collect ou uma escrita disparam a execução. Nada é calculado até que uma action peça um resultado.
• Por que a avaliação preguiçosa é útil? O otimizador vê toda a cadeia antes de executá-la, então pode reordenar filtros, remover colunas desnecessárias e combinar etapas.
• Transformation estreita ou ampla? Operações estreitas como filter e select fazem cada partição de saída depender de apenas uma partição de entrada. Operações amplas como groupBy, join e distinct redistribuem dados entre partições, o que é um shuffle.
• O que é um shuffle e por que ele importa? Os dados trafegam pela rede e chegam ao disco, formando um limite de stage. Geralmente é a operação mais cara que um job realiza.
• Explique job, stage e task. Uma action inicia um job, os limites de shuffle o dividem em stages, e cada stage executa uma task por partição.
• RDD, DataFrame ou Dataset? Prefira DataFrame, porque o otimizador Catalyst e a execução colunar se aplicam. RDDs continuam úteis para controle de baixo nível. Dataset tipado é um conceito da JVM, então em Python a resposta honesta é que não se aplica.

Use as palavras shuffle e stage quando fizerem parte da resposta. Os entrevistadores as usam como um atalho para saber se você já leu um Spark UI de verdade.

A maioria das entrevistas seniores de PySpark são, na prática, entrevistas de desempenho. As perguntas chegam como cenários, não como definições.

• Um join está lento. O que você verifica? Primeiro, o tamanho de cada lado. Se um deles cabe na memória do executor, faça broadcast e evite o shuffle por completo. Caso contrário, olhe o particionamento e o skew antes de mexer no tamanho do cluster.
• O que é data skew e como corrigir? Algumas poucas keys concentram a maior parte das linhas, então uma task continua rodando bem depois que as outras terminam. As soluções incluem salting da key quente, broadcast do lado menor, ou filtrar nulos que caem todos no mesmo hash. O sinal de diagnóstico é a dispersão na duração das tasks no Spark UI.
• Quando usar cache ou persist? Quando um DataFrame é reutilizado em várias actions e recalculá-lo seria caro. Colocar em cache algo usado só uma vez desperdiça memória, e fazer unpersist no momento certo importa em jobs longos.
• repartition ou coalesce? repartition causa shuffle e pode aumentar ou diminuir partições de forma equilibrada; coalesce faz a fusão sem um shuffle completo, sendo a forma mais barata de reduzir o número de arquivos de saída.
• Por que evitar um UDF em Python? As linhas são serializadas entre a JVM e um processo Python, e o otimizador não consegue ver dentro da função. Prefira funções nativas, e recorra a um UDF vetorizado apenas quando não houver uma função nativa equivalente.
• Por que collect é perigoso? Ele traz o resultado completo para o driver e pode esgotar sua memória.
• Um job falha por falta de memória. Qual é a sua ordem de investigação? Primeiro se é driver ou executor, depois skew, depois o dimensionamento das partições, e só então a configuração de memória. Aumentar a memória como primeiro passo é a resposta que denuncia falta de experiência.

Um data engineer entrevistando para um time de plataforma foi questionado sobre por que um job noturno que rodava havia um ano de repente passou a levar quatro horas. A resposta que funcionou não foi uma mudança de configuração, mas o fato de que um parceiro upstream começou a enviar nulos na join key, fazendo com que toda linha nula caísse na mesma partição. Os entrevistadores valorizam essa ordem: olhar os dados antes do cluster.

Os bancos de perguntas relacionados por função estão em perguntas de entrevista por função.

As perguntas restantes verificam se você já colocou um pipeline em produção, e não apenas terminou um tutorial.

• Como ler dados de forma eficiente? Formatos colunares como Parquet, partition pruning na coluna de filtro e predicate pushdown. Explique por que ler menos bytes vale mais do que otimizar o que acontece depois.
• Por que definir um schema em vez de inferir um? A inferência custa uma passada extra pelos dados e pode adivinhar tipos de forma inconsistente entre execuções.
• Como lidar com nulos e duplicados? As funções relevantes, além do ponto de que join keys com muitos nulos criam skew.
• Para que servem as window functions? Para ranking, totais acumulados e deduplicar até o registro mais recente por key, uma tarefa muito comum em pipelines.
• Como escrever a saída sem gerar milhares de arquivos pequenos? Fazer coalesce ou repartition antes de escrever, e particionar a saída por uma coluna com cardinalidade razoável.
• Como testar código PySpark? Com sessões locais pequenas usando DataFrames de fixture, e lógica de negócio isolada em funções que recebem e retornam DataFrames.
• Como submeter e configurar um job? O número de executors, cores e memória, além do raciocínio de que tanto executors pequenos demais quanto poucos executors grandes desperdiçam capacidade.

As respostas de PySpark falham em voz alta de um jeito reconhecível. O candidato sabe que um shuffle é caro, mas não consegue dizer quais operações o causam, então a resposta vira uma lista de adjetivos. Ler um banco de perguntas gera familiaridade, e familiaridade não é a mesma coisa que entregar uma explicação enquanto alguém espera.

Pegue um pipeline que você construiu e narre-o do início ao fim: a leitura, cada transformation, onde ficam os limites de stage, e o que você verificaria primeiro se ele ficasse lento. Faça isso em voz alta até parar de recomeçar. Praticar essas perguntas com um entrevistador de IA que faz perguntas de acompanhamento é mais próximo de uma rodada real do que reler anotações, e é exatamente para isso que o modo entrevista simulada foi criado.

Aaron Cao, fundador da SubcueAI, construiu a prática em torno dessa lacuna ao falar, em vez de simplesmente oferecer mais perguntas. Em uma entrevista ao vivo, o aplicativo de desktop e o painel lateral da extensão de navegador podem mostrar estrutura enquanto o entrevistador fala, o que ajuda mais em conteúdo que você já ensaiou. A configuração leva poucos minutos e está descrita na página de tutorial.