Ser um Cientista de Dados por estar estudando disciplinas de estatística, matemática ou computação e já estar atuando em alguma área correlata, ou por ter interesse e ter iniciado um processo de seleção para alguma vaga de Cientista de Dados, é importante prestar atenção para não cair em algumas armadilhas que identificam “falsos” cientistas de dados.
Outro ponto importante e uma verdadeira armadilha para quem contrata, é não fazer do seu cientista de dados um desenvolvedor ou um resolvedor de problemas. Difícil desafio.
Diante disso, seguem alguns pontos importantes para reflexão:
• Não entender se quer contratar um cientista ou um desenvolvedor – Em muitos casos, os empregadores querem contratar essencialmente um desenvolvedor ou um codificador, mas que também seja um cientista – em suma, um unicórnio. Muitas vezes até por falta de conhecimento dos contratantes isso acontece, ou porque a empresa não tem a necessidade real de um cientista de dados.
Minha dica neste caso: DEIXE CLARO O QUE VOCÊ DESEJA. Se quiser tentar convencer quem está contratando, você pode ser capaz de convencê-los que é bom em ambas as tarefas, enfatizando sua perspicácia em negócios, com base em histórias de sucesso verificáveis com fatos concretos e fáceis de quantificar com algumas métricas de performance.
• Candidatar-se ao emprego errado – Caso você se candidate a uma posição de codificador, sendo um cientista, seja muito claro antecipadamente sobre quem você é. Isso vai poupar muito tempo para todo mundo, inclusive você mesmo.
• Ignorar questões de negócios durante a entrevista – E, em vez disso, focar exclusivamente em código, tecnologia, ou teoria. Não adianta falar somente de código, fale de negócios, e como cientista qual é (são) sua (s) linha (s) de estudo de defesa.
• Oferecer respostas artificiais às perguntas, destinadas a seduzir o entrevistador, dizendo exatamente o que ele espera ouvir.
• Falta de menção a histórias de sucesso, juntamente com métricas que medem o sucesso em questão (como redução de custos em 30%, aumento da retenção de 20%).
• Não saber sobre ferramentas, técnicas, plataformas ou linguagens de programação que seus subordinados (se você for contratado), estarão usando. Pelo menos você deve ter uma ideia geral sobre eles: por exemplo, ser capaz de responder quais são as diferenças entre “Python” e “R” mesmo se você nunca usou essas linguagens. É uma boa ideia pedir ao RH informações sobre quem serão seus entrevistadores, e fazer alguma pesquisa sobre seus antecedentes, utilizando LinkedIn. Até mesmo se conectar com eles na rede.
• Não saber as tendências em sua indústria – Você não responder a perguntas como “como você acha que deep learning irá evoluir ao longo dos próximos 5 anos” ou “é a Internet das coisas ou a AI que veio para ficar?”.
• Não diferenciar-se dos outros candidatos ou não mencionar seus pontos fortes (por exemplo: um geek que entende os termos de negócio; um analista que se esforça para completar todos os projetos antes do tempo; um cara que adora automatizar suas tarefas sempre que possível para poupar tempo e para lidar com maiores cargas de trabalho; alguém que trabalha muito bem em equipe e que sabe quem delegar e até mesmo inspirar e gerar energia positiva para os colegas; ou alguém que é um autodidata e aprendeu Python e R tudo por si mesmo; um cara que desenvolve aplicativos populares durante seu tempo livre; um autor respeitado com o seu próprio blog e artigos; experiência com enormes conjuntos de dados, como terabytes; ou um analista que adora otimizar processos e pode fornecer exemplos).
• Não conseguir dizer muito sobre a velocidade (complexidade computacional) de vários algoritmos, oferecendo soluções lentas/ineficientes, quando solicitado a resolver um problema, não sabendo onde as complexidades e gargalos estão em plataformas modernas.
• Acreditar que o dado é rei – Não ser capaz de imaginar possíveis fontes de tendências e variâncias. Não ter nenhuma experiência em trabalhar com dados desorganizados. Não saber como os dados são produzidos e como as métricas são identificadas. Só poder falar sobre dados estáticos.
• Não ser capaz de dizer os prós e contras de plataformas de dois produtos populares, arquiteturas, linguagens de programação ou algoritmos. Você precisa ler a literatura para se familiarizar com isso. Por exemplo: R contra Python; as 8 piores técnicas preditivas; 10 tipos de regressões, qual escolher; ou Hadoop contra Spark.
Por fim, compartilho um estudo feito em 2015 pela Analytics Week & Business Over Broadway com mais de 490 profissionais de dados, onde foram solicitados a informar sua proficiência em 25 elementos numa escala de 0 (não conheço) a 100 (sou expert), chegou à distribuição de áreas de conhecimento abaixo:
Valeu pela leitura moçada!
Enjoy!
Fernando Parreiras 
Deixe um comentário