Como migrei para a área de dados

Photo by Helloquence on Unsplash

Olá data hackers! Estou aqui para compartilhar um pouco da minha jornada para migrar para a área de dados. Essa é uma iniciativa que visa devolver a comunidade de dados todas as contribuições que recebi nessa jornada. Ficam aqui os agradecimentos especiais (aproveita pra seguir essa galera F*DA):

1. A comunidade do Data Hackers (link), sempre disposta a responder as dúvidas de todos! Especial aí ao mestre Adamastor que me passou um bom panorama relacionado a minha track de treinamentos e me livrou de semanas de cursos inúteis!
2. Pessoal das Startups aqui de CWB — Renato Tironi, Vinicius de Paula, Almeida, Cabeça!
3. Pessoal do Kraggle — Leonardo Ferreira

Aviso/Disclaimer: Apresento aqui o meu método, nem sempre o melhor para todos, nem sempre correto, porém sempre em constante evolução. Lembre-se:

Nós profissionais da área de dados somos extremamento susceptíveis a uma variável chamada: CONTEXTO.

Créditos: Photo by Markus Spiske on Unsplash

Sendo assim sugiro a utilização dos post como um guia lógico e não como uma referência do que deve ser feita em 100% dos casos.

Quem sou eu?

“All in all, you’re just another brick in the wall” — Pink Floyd

Créditos: Photo by Glen Carrie on Unsplash

Eu sou Jonas Scherer, trabalho 12+anos com TI, formado em Sistemas da Informação. Gostaria de me apresentar para passar uma visão daquilo que me motivou e que fundamentou minha passagem para essa área. Trabalhei em empresas grandes (Grupo Boticário/HSBC) e tive 2 empresas de Design/Desenvolvimento onde trabalhei com clientes de variados portes (PUBG, Boticário, Boleto Bancário, Mondelez, Visa, Pipefy). De maneira simplificada (pois o foco não sou eu e sim na base que me ajuda a lidar com dados hoje em dia) segue meu histórico e os pontos que me ajudaram a fundamentar conhecimentos que hoje são utilizados na área de dados:

• Trabalhei por 4 anos na área de Redes e infraestrutura: Isso me deu uma base bem sólida e prática para lidar com: TCP/IP, conectividade, latência, criticidade de serviços, protocolos diversos de conexões entre servidores e equipamentos de rede, gestão de mudanças em produção, gestão de crises. Aqui participava da migração e monitoramento de equipamentos de um Banco junto a serviços extremamente críticos como operadoras de cartão de crédito, call centers e bolsa de valores em suporte 24/7 que me fizeram perder algumas festas da faculdade. Por incrível que pareça, a área de infra tem programador sim! Aqui eu comecei a programar, mas nesse caso o foco era automatização de tarefas em scripts bash/pearl. Daqui vem o conhecimento sobre Unix, essencial para resolver problemas de instalação de pacotes rs.
• Trabalhei por mais 4 anos na área de Segurança da informação: Aqui entrei mais a fundo na área de aplicações e arquitetura. Bancos de dados, linguagens de programação, arquiteturas de software e de infraestrutura, análises forenses, gestão de crises, gestão de vulnerabilidades e principalmente a área de Firewalls. Isso me deu base sólida para saber o que acontece quando não consigo conectar meus serviços na AWS ou no Google Cloud 😜. Aqui também aprendi a ir quase ao nível dos bits para debuggar problemas em ambientes complexos que “pararam de funcionar do nada”, isso foi importante pois eu conseguia descrever um problema ao invés de perder tempo em hipóteses mirabolantes ou cruzando os braços xingando a tecnologia.
• Por 2 anos tive uma empresa de Design e Desenvolvimento: Me dividia entre a gestão estratégica e operacional da empresa e além disso programava em PHP e Javascript para sites e aplicativos híbridos (não façam isso em casa). Isso formou uma base boa em termos de relacionamento com pessoas/vendas e entendimento de arquitetura de software e conectividade (APIs). Quem somos nós sem as APIs!

• Por 4 anos tive outra empresa, dessa vez focada no processo de Design de Serviços, passando por UX e com a implementação tecnológica. Aqui fazíamos pesquisas de mercado, entrevistas com os usuários e implementávamos aplicativos e sistemas com foco no usuário. Me colocava muito mais na parte de gestão da empresa (financeiro, contratos, projetos, relacionamento com o cliente, vendas). Aqui criei uma boa base para lidar com TRETAS: Gestão de conflitos (sócios, clientes, funcionários). Também aprendi tudo aquilo que é crítico para o negócio. Além disso o maior ensinamento que tirei foi: Como criar coisas que as pessoas vão usar? Colocando o usuário final em primeiro lugar.
• Hoje trabalho a 3 meses numa empresa de Tecnologia onde lido com mais de 30 milhões de acessos por mês (mais detalhes do que faço aqui nos próximos posts)

Nada acontece do dia para noite. Estou relativamente a pouco tempo na área de dados e ainda menos tempo dentro da empresa, entretanto meus 12+ anos de bagagem me dão velocidade para implementar aquilo que preciso. Maturidade muitas vezes supera a experiência.

Como migrei para área de dados

Comecei em 2018 pegando a tendência do termo “Data Scientist” como uma das profissões mais desejadas da próxima década. Sim, eu cai no golpe. Porém no fim do dia você descobre que os temos são apenas termos, muitos deles existem a muito tempo e muitos mudam a cada dia. Sendo assim e o que fica é aquilo que você construiu e deu de retorno. Vamos aos passos que segui:

1. Especialização

Depois de ler muito sobre o assunto dei o primeiro passo fazendo uma especialização de Big Data no Coursera (link). Gostei bastante do curso, mas como tudo na vida isso tem seus prós e contras:

Pros:

• Apesar de ser um curso com o título de Big Data, ele é muito focado em Data Science, Machine Learning e o processo de dados como um todo;
• Os conteúdos são bem relevantes, estabelecem fundamentos sólidos para lidar com dados e principalmente ALTO volume de dados;
• Gostei do balanço entre teoria e prática;
• Ainda que seja online, me dá o título de especialista. Existem algumas controvérsias filosóficas com relação a isso, mas no fim do dia para os profissionais que vão te contratar isso faz diferença. Fora isso, o curso é da renomada UC-San Diego, acho que dá um peso bom no meu CV;
• Você lida com dados reais e já consegue ter casos de uso para seu portfólio. Por exemplo: Dados de estações climáticas do deserto da Califórnia para análise de riscos de queimadas.

Contras:

• O curso foca em Spark e também passa por alguns assuntos de maneira superficial. Você vai aplicar o básico do Machine Learning na prática e usando as bibliotecas do Spark.
• Algumas aulas são bem chatas e lentas(rs).
• Nem todo mundo precisa de uma especialização, talvez esse tenha sido um tiro de canhão pra matar uma mosca. O custo fala bastante de processamento em larga escala, que deve ser o foco de um engenheiro/arquiteto de dados, trata também de Graph Analitycs que eu ainda não tive a oportunidade de usar. Aprendi muito tempo depois a parar de seguir o que está na moda e aprender aquilo que é necessário para fazer meu trabalho. Se há a necessidade de fazer uma análise de Churn, segmentação de clientes, forecasting, etc… Vou lá e faço um curso específico para cada necessidade. Nesse caso cabe bem a regra 70/20/10 .

2. Casos de Uso

Depois da minha especialização comecei a montar casos de uso (na época eu não conhecia o Kraggle) para vender para alguns clientes. Usei Hacker Statistics para criar meus datasets e fazer as análises (Não faça isso em casa). Tudo isso é muito inválido do ponto de vista de análise, pois quando criamos datasets, criamos eles enviesados, ou seja, jamais vamos conseguir simular a realidade e seus elementos (como a aleatoriedade) criando nossos dados. Se eu crio um dataset para fazer uma análise de conversão, eu vou precisar pesar alguns dos atributos do meus dados para chegar a uma conclusão e demonstrar isso. Explico: Em meus datasets eu queria demonstrar que a variável de gênero tinha uma importância significativa na decisão do modelo e portanto da conversão, sendo assim eu precisava criar o dataset de uma forma que isso se demonstra-se posteriormente, ou seja, eu ditava o que o modelo ia predizer já na criação do modelo (Repito: Não faça isso em casa). Entretanto tudo isso me ajudou a abrir algumas portas, pois eu conseguia demonstrar as possibilidades do que poderia ser feito, na expectativa de convencer alguém a me dar acesso a datasets de produção rs. O fato é que ninguém botou fé em mim, primeiro porque esse é um serviço que custa caro e segundo porque não conseguia demonstrar o valor gerado por um processo de Data Science.

O que funcionou então? Isso tudo serviu pra solidificar a prática (análise de dados, limpeza, extração, criação de modelos, predição, clusterização, programação em Python). Além disso exercitou a criatividade, algo que ainda é subjugado no meio de exatas.

3. A busca por empregos

Aqui foi uma das partes mais frustrantes para mim, pois apesar de toda minha senioridade em termos comportamentais, ainda pecava na parte técnica na hora das entrevistas. Cheguei a me inscrever em 25–30 vagas por semana e a fazer ao menos 8 testes técnicos e os feedbacks foram esses:

Acertos:

1. A lógica de modelagem, teste e predição foi bem adequada;
2. Elogios aos relatórios que levavam em conta o conhecimento sobre a pergunta do negócio e detalhes sobre o domain knowledge;
3. Uso de variadas ferramentas para predição dos modelos;
4. Cheguei a receber um “você tem futuro se continuar assim”, mas não me contrataram 😐.

Erros:

1. Não tratar os outliers;
2. Não limpar os dados corretamente;
3. Usar os dados errados na criação de um modelo;
4. Partir direto para a modelagem sem o EDA ou com pouco EDA;
5. Não validar o modelo (AUC-ROC) — Saber validar o modelo é muito mais importante do que sua precisão;
6. Não fazer cross-validation;
7. Não fazer um baseline;
8. Não fazer scalling dos dados;
9. Dar um tiro de canhão usando Python e modelos avançados para algumas análises que um Excel resolve (ex: Forecasting e segmentação RFM)
10. Não dizer “Eu não sei” nas entrevistas. Recebi o feedback de que eu dava muitas voltas para explicar algo que claramente eu não sabia.
11. Fazer a predição tentando responder uma pergunta errada! Exemplo: Em um dos casos eu tinha que prever o grau de deterioração de algo e montei um modelo binário que dizia se aquilo ia parar de funcionar. Preste atenção, a diferença é sútil, porém não deixa de ser um erro terrível. Fazendo uma analogia: O que eu deveria predizer é QUANDO as peças do carro vão deteriorar, conhecimento útil para uma manutenção preventiva que facilitaria todo um cronograma de manutenções de uma oficina. O que eu estava predizendo era SE o carro ia parar de funcionar. Podemos dizer que a segunda predição também é importante? Sim. Ela é mais importante que a primeira predição? Não necessariamente e aqui está o “pulo do gato” jovens. A primeira informação é mais útil para uma oficina mecânica, enquanto a segunda é mais importante para, sei lá, o serviço do guincho. Por isso é necessário SEMPRE pensar no negócio. A parte mais importante de um processo de dados é o “Domain Knowledge”(traduzido livremente como conhecimento de domínio rs), ou seja, saber daquilo que está se falando sobre. A título de exemplo: Estamos vendo aí uma série da análises sendo feitas em relação ao Covid-19 onde as pessoas não conversam com médicos. É tipo eu querer analisar os componentes de um carro por conta própria, sem falar com um mecânico ou um engenheiro.

Lições aprendidas:

• Humildade: Não é porque sou muito bom em uma coisa, que serei bom em outra. Um título não me garante uma vaga.
• Temos que estar sempre atentos aos detalhes. Eu vim de uma criação mais generalista e funcional. Na área de dados nem sempre o que funciona é o certo. Nem sempre o feito é melhor que perfeito.

Paciência

Nesse processo de transição tive que ter muita paciência. Estava com algumas propostas na mão para abrir outras empresas, virar sócio em outras, criar um projeto relacionado a dados (como programador) até mesmo vagas de liderança em tecnologia. Pensei em abrir minha própria empresa também, cheguei a conversar com algumas pessoas sobre isso e a prospectar alguns clientes. Pensei em largar a área. Pensei que estava fadado ao fracasso por ser tão generalista.

3 meses depois chegaram 2 propostas no mesmo dia. Aceitei uma delas. Depois disso propostas continuaram chegando.

Aqui não tem milagre, é atirar pra todo lado até acertar algo que você queira.

Autoconhecimento

Nos processos seletivos que fiz e nas mentorias, aprendi muita coisa sobre o meu aspecto comportamental que desconhecia. Eu de fato sou um cara analítico, porém meu perfil generalista me coloca em alguns dilemas de decisão de carreira (vide todos os cargos que já passei na vida). Para ajudar nisso temos várias ferramentas (pesquisa aí: DISC, 16personalities, Mindsight).

Considerações finais:

Muita gente me ajudou nesse processo e ainda me ajuda (inclusive em processos de mentoria) pois aqui dentro eu ainda sou a famosa “Euquipe”. Fui contratado como cientista de dados, mas aceitei o desafio de montar todo processo da área de dados por alguns motivos. Primeiramente meu background de negócios e de TI e segundo porque a realidade é a seguinte: Nem sempre será possível trabalhar focado e sendo especialista em algo (isso é um privilégio). O que eu vivi na maioria das empresas que trabalhei é que você sempre será especialista em uma coisa, porém há sempre a necessidade de saber muita coisa fora da sua área de domínio e ter um perfil “T-shaped”. O que suporta esse argumento é que alguns cientistas de dados estão deixando seus empregos e que a maior parte do tempo de um cientista de dados é utilizada limpando ou movendo dados. Portanto se você é um cientista de dados que consegue sentar na sua cadeira e pedir os dados pro engenheiro, você ganhou na loteria rs.

Por mim eu cunharia o termo a abaixo:

Data Whateverist: Faz tudo relacionado a dados.

Muitas pessoas enxergam isso como algo pejorativo, pois isso é ser o pato! Não voa, não anda e não nada direito. Eu particularmente prefiro ser generalista, pois desde que eu entregue algo que impacte a vida das pessoas de maneira positiva, fiz valer meu dia. Em momentos de crise como estamos passando agora com a pandemia do COVID-19, onde o monstro da crise econômica também nos aterroriza, quando uma empresa pensa em demitir, os salários altos são os primeiros a serem levados em consideração. Se um salário alto não retorna resultado, não importa o título dele ou o quão especialista as atividades do cargo são. (minha opinião)

Além disso, um Machine Learning Engineer, especialista, afinando parâmetros de Machine Learning ou criando um modelo estatístico não é melhor nem pior do que um analista de dados que está criando um Dashboard para o time de Customer Service ou do que um DPO cuidando da LGPD. Portanto, a lição que eu aprendi é:

Menos títulos, mais ações

Se preocupe menos com títulos dos cargos, pise um pouco fora das suas atividades usuais que isso vai ser muito bom pra sua evolução como pessoa. O conhecimento técnico é consequência disso.

Em resumo:

1. Crie seus casos de uso para aquilo que você quer trabalhar;
2. Converse com pessoas de negócio e entenda como você pode aplicar seus conhecimentos nisso;
3. Converse com pessoas técnicas para saber o que está acontecendo no meio e use as informações com discernimento (não faça qualquer curso);
4. Se aplique para o máximo de vagas possível (as quais você deseja) e use os testes como maneira de aprender algo (peça sempre o feedback);
5. Se possível, tenha mentores;
6. Busque um curso que você goste e que se alinhe com seu propósito e método de aprendizado;
7. Nas análises que você fizer, pense sempre se está usando a ferramenta correta para o trabalho correto e se você está respondendo a pergunta de negócio correta;
8. Saiba descrever seus problemas e bugs com ferramentas de debbug. Isso vai fazer com que você dependa menos dos outros e perca menos tempo com problemas (além de saber descrever o problema com maestria).
9. Se preocupe mais com as atividades do cargo do que com o título do cargo. Garanta que as atividades façam sentido com aquilo que você busca e entenda que nem sempre você vai passar 100% do tempo fazendo só o que você quer. Cargos especialistas, com apenas uma função são raros e temos que cuidar para que nosso job description não vire um cabresto;
10. Antes de aceitar uma vaga, pense naquilo que você vai sacrificar antes de pensar no que você vai ganhar. Créditos ao Mário Filho e ao podcast do data Hackers “As Mentiras que te contam sobre Data Science”

Por enquanto é isso!

Fique a vontade para vir falar comigo. Críticas e dúvidas são bem vindas!

Twitter / LinkedIn / DataHackers / Email: jonaslsl@gmail.com

Você ainda não é um DataHacker? Faça parte da maior comunidade de dados do Brasil! Chega no link, entra no nosso Slack e escute nosso podcast: https://datahackers.com.br/