Perguntas de entrevista para engenheiro de dados, por etapa

Você pode estar se preparando do mesmo jeito que para um processo de engenharia de software, e se perguntando o que é diferente. Esta seção mapeia as etapas que essas entrevistas reutilizam, para que você gaste seu tempo nas duas que de fato separam os candidatos. O filtro técnico raramente é onde as ofertas se perdem.

• SQL. Funções de janela, deduplicação e performance de queries, quase sempre ao vivo.
• Modelagem de dados. Projetar tabelas para um negócio descrito e defender a granularidade escolhida.
• Design de pipeline e ETL. Uma etapa de design de sistemas aberta, restrita à movimentação de dados.
• Processamento distribuído. Como um framework realmente executa seu job, e por que ele é lento.
• Codificação. Python ou Scala, muitas vezes mais leve que uma etapa de engenharia de software.
• Comportamental. Incidentes de plantão, dashboards quebrados e stakeholders que queriam o número ontem.

Os títulos se sobrepõem bastante com analytics engineering e funções de plataforma, então a mistura varia. Bancos de perguntas de funções relacionadas ficam no hub de perguntas de entrevista por função.

SQL

• Deduplique uma tabela mantendo apenas a linha mais recente por chave.
• Escreva uma query que retorne a contagem de sessões de cada usuário usando um intervalo de inatividade de 30 minutos.
• Calcule um total acumulado e uma variação mês a mês em uma única query.
• Encontre linhas presentes no snapshot de ontem, mas ausentes no de hoje.
• O que QUALIFY faz, e o que você escreveria sem ele?
• Essa query varre um bilhão de linhas e leva vinte minutos. Como você diagnostica isso?
• Explique a diferença entre particionamento e clustering, e quando cada um ajuda.

Modelagem de dados

• Projete as tabelas para o histórico de pedidos de um marketplace online. Qual é a granularidade da sua tabela de fatos?
• Explique um esquema em estrela, e quando você desnormalizaria ainda mais deliberadamente.
• O que é uma dimensão de mudança lenta, e como você implementa o tipo dois?
• Um stakeholder quer que relatórios históricos reflitam a região atual de um cliente. O que quebra?
• Como você modelaria um stream de eventos que chega fora de ordem?
• Quando você escolheria uma tabela larga em vez de um modelo normalizado?

A etapa de modelagem recompensa se comprometer com uma granularidade e defendê-la. Candidatos que descrevem três designs possíveis sem escolher um pontuam pior que candidatos que escolhem um design razoável e nomeiam sua fraqueza.

Design de pipeline e ETL

• Projete um pipeline que carregue transações diárias em um warehouse para relatórios.
• A fonte upstream envia os dados de ontem de novo. O que acontece com seu job?
• Como você torna um pipeline idempotente, e por que isso importa para reruns?
• Como você faria o backfill de dois anos de histórico sem interromper a carga diária?
• Dados atrasados aparecem três dias depois de a partição fechar. O que você faz?
• Como você detectaria que um pipeline teve sucesso mas produziu dados errados?
• O que você monitora, e o que aciona alguém às três da manhã?

Processamento distribuído e streaming

• O que causa um shuffle, e por que ele é caro?
• Seu job está lento e uma tarefa demora bem mais que o resto. O que está acontecendo?
• Explique data skew e duas formas de lidar com ele.
• Quando você escolheria streaming em vez de um job batch agendado?
• O que o processamento exactly once realmente garante, e onde isso não vale?
• Como watermarks tratam eventos fora de ordem em uma agregação com janelas?

Note quão poucas dessas pedem para você nomear uma ferramenta. Nomear uma é o início da resposta, não a resposta. A repergunta é sempre por quê, e o que quebra.

Ler essas listas gera reconhecimento. As etapas de design testam outra coisa: manter um sistema na cabeça enquanto alguém te interrompe com um caso de falha. Isso só vem de falar os designs em voz alta.

• Desenhe e narre um pipeline em quinze minutos. Fonte, landing, transformação, serving, mais como cada etapa falha.
• Ataque seu próprio design. Depois de cada prática, pergunte o que acontece em um rerun, com dados atrasados e com uma mudança de esquema.
• Tenha um número pronto para a escala. Linhas por dia, tamanho, orçamento de latência. Declarar sua escala assumida primeiro é pontuado.
• Escreva SQL à mão. Etapas ao vivo costumam usar um editor simples, sem autocompletar e sem execução.
• Ensaie bem uma história de incidente. O que quebrou, como você descobriu, o que você mudou para que não pudesse se repetir.

Uma engenheira de dados com seis anos em pipelines batch se preparou revisando os internos do framework, e depois travou em "a fonte upstream reenviou o arquivo de ontem" porque ela só tinha lidado com isso manualmente, nunca explicado. O conhecimento estava lá; a resposta falada não. Praticar a etapa de design com repreguntas é exatamente para o que o modo entrevista simulada foi feito.