Como se tornar Engenheiro de Dados em uma Top Tech: Processos Seletivos — Parte 1

Um Quick Guide para arrebentar nos processos seletivos de Data Engineer!

Allan Sene
Tableless
8 min readApr 27, 2018

--

“A production line in a factory with large hooks carrying materials” by Ant Rozetsky on Unsplash

Você teve uma chance: te deram aquele call no LinkedIn e você está todo empolgado! Seu currículo é bom, mas você está nervoso porque nenhum amigo seu desenvolvedor passou por um processo específico de Engenheiro de Dados… são Frontend ou Backend, acostumados com outros esquemas. Ou pior: ninguém do seu círculo de amizades já fez um processo de seleção tão exigente pra uma empresa fos sonhos que nem essa.

Amigo, eu vou te ajudar!!!

Pelo bem de toda a comunidade e ecossistema de profissionais de dados, alguém precisa explicar como processos de seleção maduros para Engenheiros de Dados funcionam!

Neste guia, dividido em 2 partes, vou compartilhar uma visão dos processos de seleção que participei em algumas empresas tidas como referência quando o assunto é excelência técnica em Dados. Obviamente, por mais imparcial que eu tente ser, minha opinião pode ser um pouco enviesada. Mas, as always, críticas são mais que bem vindas. As vagas que utilizarei como exemplo são:

Nubank: Engenheiro de Dados — Time de Democratização e Acesso a Dados
Microsoft: Engenheiro de Software — Time de Buscas do Bing Brasil
Globo.com: Desenvolvedor Big Data — Time do GlobosatPlay
MaxMilhas: Engenheiro de Dados — Time de Data Science & Analytics
Spotify: Engenheiro de Software — Capítulo de Sistemas Distribuídos

Cada um desses processos tiveram particularidades e coisas em comum, e vou passar nos trechos “Caso Real” situações reais minhas, fazendo paralelo com o que eu deduzi posteriormente que estava certo ou errado.

Irei separar o guia em 4 etapas:

  • Primeiro Contato (parte 1)
  • Code Challenge (parte 1)
  • Primeira entrevista técnica (parte 2)
  • Segunda entrevista técnica (parte 2)
Discriminação das etapas. Em vermelho, etapas que não participei.

P.S.:Em todos estes processos (exceto da MaxMilhas) , eu fui abordado por um recrutador ou pela pessoa-chave responsável pela contratação. Talvez, futuramente, farei outra etapa deste guia falando só sobre currículo e sobre applications. Me cobrem! xD

Primeiro contato

Ah, aquele nervoso! A primeira call a gente sempre tá com a mão suando!

Dia da entrevista

Mas cara, relaxe… O principal objetivo do primeiro contato é: convencê-lo de que essa empresa dos sonhos é mesmo uma empresa dos sonhos. Na maioria das vezes, a primeira conversa pode ser com:

  • Recrutador: normalmente alguém acostumado com recrutamento de TI, principalmente pelo fato do cargo ser muito técnico e específico.
  • Líder(s) responsável(eis): quando assim, podem vir algumas perguntas um pouco técnicas, relacionadas a conceitos de arquitetura de dados, mas nada muito elaborado.

Você pode tirar grande vantagem nessa etapa, coisa que vários candidatos se esquecem, ou porquê não se preparam ou porque se deixam levar pelo encantamento — que é o principal objetivo para a empresa!

Detalhe bem o seu background

Nessa empresa aqui eu pegava os carrinhos e VRUMMMM

Aproveite-se deste momento menos tenso para falar das suas conquistas na carreira. Seja específico sobre quais resultados mais importantes você deu em cada bullet de seu currículo. Use a tática do STAR — Situation, Task, Action, Result. Também aproveite para demonstrar seus softskills em casos reais.

Caso Real: Usei o STAR na entrevista para a Microsoft. Percebi que isso direcionou totalmente o restante da entrevista, dando foco ao meu conhecimento e experiência com de sistemas distribuídos e DBs de fulltext search:

“Durante um Hackathon, após toda a construção do MVP, percebemos que o último caso de testes sugerido não rodava em tempo factível para o mundo real (situation), como desenvolvedor mais experiente do time, eu deveria propor alguma mudança simples e rápida, de tal forma que não fôssemos penalizados por perda de tempo (task). Então subi todos os nossos documentos de testes no ElasticSearch, datastore que usa Índice Invertido e recuperava as informações usando TF/IDF (action). Assim, conseguimos bater o todos os casos de testes e, com usa solução simples de arquitetura, chegamos na premiação da Hackathon. (result)”

Pergunte detalhes sobre a empresa, vaga e o time

Entenda realmente o que é a empresa, quais seus principais objetivos de curto prazo e de longo prazo. Tente se encaixar nessa visão. Inclusive, se ver que a expectativa para a vaga é de alguém que entre esteja desalinhado com o seu objetivo atual, aproveite para ser claro neste momento! Nem sempre estão recrutando-o para um posto específico e maioria das vezes se interessam muito mais pelo seu perfil e vivência do que estritamente pelo seu know-how ferramental. Quanto antes você alinhar as expectativas sobre seus pontos fortes e fracos, menor vai ser a surpresa e o impacto caso algo não saia tão bem quanto o esperado para a etapa.

Caso Real: No first contact com o Spotify, depois de ouvir que o time que estava recrutando era o de sistemas distribuídos, perguntei ao recrutador técnico se eles preferiam um cara bom em algoritmos de concorrência/paralelismo ou se preferiam alguém com boas noções de design de sistemas distribuídos. Após a entrevista, o recrutador, lembrando dessa pergunta, me mandou vários posts do blog do Spotify sobre a arquitetura de realtime deles e frisou que o necessário de algoritmos (justamente meu ponto fraco) que eu precisava saber, seria suficientemente mostrado nos testes do Code Challenge e na primeira entrevista técnica.

Pergunte detalhes sobre o processo e próximas etapas

Essa é a hora de você obter todos os detalhes possíveis sobre o processo! Quais as próximas etapas? Como e por quem serão conduzidas? O que é esperado em cada uma delas? O que devo deixar preparado?

Caso Real: Na última etapa do processo do Nubank, eu deveria fazer um pair-programming utilizando algum projeto de dados que eu julgasse que fosse relevante. Pensando no processo como um todo, levei um projeto que era a ponta de desenvolvimento de toda uma arquitetura realtime de grande valor que eu havia montado. Porém, tal projeto estava quase zerado de cobertura de testes.

Daí, o entrevistador me pediu algumas alterações, mas deixou ressalvas de que queria ver outro projeto meu que estivesse minimamente testado unitário. Assim, tivemos que fazer outra etapa, não prevista, com um pair-programming remoto.

Se eu tivesse alinhado bem o que era esperado do pair, iria levar outro projeto, diminuindo o desgaste de fazer uma etapa extra no processo e, óbvio, dando uma melhor impressão para o avaliador.

Code Challenge

Talk is cheap…

Hacking time! Uuiirrrlll _o_

Há 2 tipos de Code Challenge: o tipo Teste, a.k.a Hacker Rank, plataforma mais usada pra esse tipo de teste, e o tipo Projeto. Poucas empresas aplicam ambos os tipos num mesmo processo. Já vi gente reclamar sobre esta etapa, mas na boa: como você vai garantir que o cara consegue resolver bem um problema relacionado a dados, em tempo hábil, sem aplicar um teste? Não faz sentido algum… Tem que teste de código sim!

Teste

É muito comum no Hacker Rank testes de algoritmos, daqueles com tempo e vários test cases pra bater a pontuação máxima, contudo nem todos os testes são só o típico Trabalho Prático de AEDs. Há testes que mesclam código com perguntas, ou de arquitetura, ou de lógica. Então é bom ficar ligado!

Dicas preciosas:

  • Se planeje para fazer o teste: marque uma data na sua agenda e se prepare. Não saia fazendo qualquer horariozinho que sobra.
  • Treine antes! Dá pra saber o que cada empresa costuma cobrar… as perguntas não mudam muito. Se não achar na net, procure alguém que está lá dentro pra trocar ideia, sempre ajudam.
  • Não tente colar… não vai dar tempo de achar resposta e você vai perder tempo que poderia usar pra resolver outra pergunta/teste. Se prepare antes!

Caso Real: No caso do Nubank, como vocês devem imaginar, o deve ser em Linguagem Funcional. O ideal é em Clojure, mas dependendo do time, você consegue fazer em Scala, como foi o meu caso. Scala é linguagem franca no meio de DE, já fica ligado…

Nos casos da Microsoft e do Spotify, os testes foram abertos em C, C++, Java ou Python. Mas fiquem espertos! Adianto que nas entrevistas técnicas, podem te pedir para mudar a abordagem de uma linguagem para outra e fazer uma análise de como cada linguagem se comportaria debaixo dos panos! Ambos focaram em problemas que envolvem Hash, Strings e Busca textual.

Projetim no Mac de Hipster by Luca Bravo on Unsplash

Projeto

Ainda é raro, para vagas de Engenheiro de Dados, que o teste seja restrito a alguma ferramenta ou linguagem. Obviamente, uma boa decisão é você se manter dentro dos requisitos técnicos da vaga. Os projetos sempre envolvem requisitos de volume e velocidade, além dos requisitos normais de software — modularização, padrões, testes, etc.

Dicas preciosas:

  • Testes unitários sempre! Cobertura de testes é essencial para qualquer pipeline de dados. Deixar de testar um ETL é digno de eliminação! Imagina um cenário no qual você, sempre que quiser testar seu código, tem que subir um cluster de Spark? Não dá…
  • Facilidade para subir o ambiente! Lembre-se de que, quem corrige seu teste, está atolado de trampo e tem que fazer isso no meio de uma Sprint. Se seu ambiente for difícil de subir e mal documentado, não vão nem corrigir direito seu projeto.
  • Código bom não precisa de documentação! Economize o seu tempo e do corretor.
  • Maioria dos projetos dão pontos extra por “soluções diferenciadas”. Não fique só no Node + Mongo. Mesmo que cumpra os requisitos, essas soluções não costumam escalar em ambientes de grande volume.

Caso Real: Ambos projetos da Globo.com e da MaxMilhas têm requisitos parecidos: alto volume de dados e tempo mínimo de resposta da API. Mas diferenciam no contexto.

No caso da MaxMilhas, o projeto consistia em fazer ETL de uma quantidade gigante de registros de voôs e fazer uma API que exponha certas estatísticas sobre esses dados.

No caso da Globo.com, o projeto consistia em fazer um sistema de recomendação simples, mas que aguentasse um teste de carga muito grande e com tempo de resposta bem pequeno.

É isso aí, galera! Não vou me estender mais, porém estou totalmente aberto a dúvidas pra quem quiser uma mãozinha — deixa um comentário! No próximo post, foco nas partes mais tensas e difíceis: as entrevistas! Fiquem ligados!

Curtiu esse guia? Que tal trocar mais ideias sobre seleção na maior comunidade de profissionais e entusiastas de dados do Brasil: o Data Hackers? Lá, além de posts e outros relatos, você pode conversar com engenheiros, cientistas e profissionais das mais importantes empresas e centros de pesquisa do país sobre carreira!

Se inscreva na nossa news, blog e no nosso chat no Slack! Até o próximo post!

--

--

Allan Sene
Tableless

CTO | Lead Data Engineer | Co-Founder of Data Hackers and Dadosfera. Loves science, code and cats ^*^