In my last post, I talked about a misconception that many applicants to our data area have: that it’s necessary to be a data science unicorn to have a career. In it, I explained how unrealistic this standard is and how a “unicorn” profile doesn’t really contribute to the acceleration of data initiatives.

We don’t need everyone to be a Data Scientist

The distinguishing feature of a Data Scientist is their specialization in mathematics and statistics. When we take a step back from this focus on math, the mix that’s left is popularly known as Data Engineering. This term encapsulates all our demands and contexts in one way or another; however, the diversity of our demands and contexts leads us to the same dilemma I described in my previous post: we want racehorses, not unicorns.

It’s a question of focus. If we want to move faster, we need people who are focused on specific problems and who become really good (and fast!) at solving them. At Creditas, we wanted to speed up our deliveries, so we split the role of a Data Engineer into three others.

The needs of a large data department

When we talk about the initiatives related to the data of an organization, especially from the point of view of management, the needs are many: from the storage, distribution, and availability to the discovery, governance, and understanding of data. It’s in the flow that different professionals, with a variety of focuses and abilities, are meant to participate.

The following image depicts a diagram of how we can arrange theses different demands according to the four major areas of knowledge needed to extract value from data: business, database, programming, and mathematics (statistics).

The way we used to organize Data Engineering here at Creditas (and perhaps how you have organized yourself as well), our Data Engineering team was responsible for most of these demands. In my first post, I included a list of responsibilities (among others) which the team had:

• construction of workflows for data processing;
• crawlers for data capture;
• data ingestion via streaming;
• construction and organization of the data lake;
• data warehouse modeling and construction;
• deploy of data-science models;

…in addition to those we might add, among others:

• database access governance;
• database documentation;
• user data capture systems;
• provision of analytical data in the operational environment

The problem with this mix

If we were to look at the way we now structure these responsibilities among teams, the diagram would look something like this:

• Data Science: a team of data scientists focused on constructing models that aggregate value to the business, especially regarding innovation and the automation of repetitive tasks.
• Product Development: teams made up of developers and product managers focused on delivering technologies that add value to business. From a data point of view, they are the producers of operational data and are the technology teams closest to business.
• Analytics: teams of data analysts focused on tracking operational KPIs and answering business questions. From a data point of view, they are the analytical environment’s main consumers and the team that demands the most from the Data Engineering team.
• Data Engineering, the mix: our team of superheroes/heroines (not to say the others aren’t) who do their best to meet the data needs of all the other teams in the analytical environment.

Although this wide range of demands brings a lot of fun and learning to our daily lives, many problems arise from this scenario; often generating friction, rework, and inefficiency. To name a few problems:

1. The lack of focus reduces the in-depth mastery that people can achieve in an area or technology;
2. A change of context is a toll that is always being paid;
3. It’s not rare that work needs to be redone due to an incomplete understanding of the domain being addressed;
4. Interpersonal relationships are diluted since each task requires interaction with a different person;
5. It’s hard to find people with all the necessary qualifications, so it’s hard for the team to grow;
6. Wages become inflated for professionals who have little depth or experience.

Moreover, our company is in a stage of speeding things up. Simply put, the old system needed to go — the unicorn had to be dismembered. (poor thing 😭)

The right amount of multidisciplinarity

If we go back to the beginning of everything (relax, not that far back), to the conceptualization of data science, we see that an ability to overcome obstacles was crucial. What was once done by different people according to their capabilities and limitations came to be done in a new and more creative way, which had fewer restrictions, by someone with multidisciplinary knowledge (a unicorn).

How to solve this dilemma, then? It’s simple: with people who are able to hurdle one barrier very well, not all of them. The following diagram shows how we dissected the mix that was the role of a Data Engineer into three distinct new roles.

• Analytics Data Engineering: a team focused on enabling and accelerating the acquisition of answers to business questions that demand data analysis. They demand infrastructure from the Data Platform Engineering team and collaborate closely with Analytics.
• Data Platform Engineering: a team focused on the automation of data capture and redistribution, both in the operational and analytical environment. They collaborate with the Product Development team for operational data capture and with Machine Learning Engineering to organize the data lake.
• Machine Learning Engineering: team focused on helping data scientists, working with a model throughout its entire life cycle, from data capture for training to the production of the same data.

Included in the diagram below is the flow of value creation, showing how each team collaborates with those beside it to overcome the obstacles presented in everything, from the production and storage of data to its use in decision making and business innovation.

In the posts to come, I’ll go into detail about the function of each one of these “new” roles and what skills are expected for each one. Stay tuned, we have vacancies opening up! See you next time!

Interested in working with us? We’re always looking for people passionate about technology to join our crew! You can check out our openings here.

Data engineering needs to be specialized — here’s how we did it was originally published in Creditas Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Everyone wants to be a Data Scientist!!!

Well, needless to say that I’m not the only one thinking it, do I? See this question on Quora about whether we are heading toward a talent bubble in Data Science.

The truth is that in order to be a true data science talent you need to be that fantastic being everyone keeps talking about: someone who has hacking skills, math and statistics knowledge, and mastery of business. A true unicorn!

Unicorns are not born unicorns

Yes, unicorns do exist. True data science talents do exist. Those people who master everything needed to impact the business by using data, from the conception of the business issue up to the delivery of the production model, they do exist. But they did not start their careers like that. It is simply not possible to gather enough experience to perform such a complex role after only a few career years.

Studying hard, dedication, taking online courses on all kinds of algorithms and techniques seems to be the standard strategy to becoming a unicorn. But the truth is that you need much more than that to become relevant in solving real issues. You need experience, and you can only get experience with time and work.

In her “Data Science is different now” post, Vicki Boykis, a data scientist since 2012, says that the current job market is full of candidates for junior job positions in data science, the competition can be up to 100 candidates for 1 job position. She advises those who wish to become data scientists to use the following career plan:

1. Don’t shoot for a data science job
2. Be prepared for most of your data scientist work to not be data science. Adjust your skillset for that.

then, regarding this PWC report, she says:

… the number of data science positions is estimated at 50k. The number of data engineering postings is 500k. The number of data analysts is 125k.

It’s much easier to come into a data science and tech career through the “back door”…

And that is exactly the reality we see in applications to Creditas Data Scientist and Data Engineering positions. DS positions receive much more applications, while we have many more open DE positions.

We do not need unicorns anymore, we want racehorses

Even though unicorns are extremely valuable to our teams, we understand that this is not the best way to work. Times have changed. Creditas now wishes to specialize its Data Science and Data Engineering teams. This way, we can improve the efficiency of both teams.

Vicki Boykis on Twitter

Have been extremely curious about this for a while now, so I decided to create a poll. "As someone titled 'data scientist' in 2019, I spend most of (60%+) my time:" ("Other") also welcome, add it in the replies.

It is a well-known fact that 70% to 80% or more of the time spent by data scientists is actually just in preparing the data. This is a task that is clearly the responsibility of a Data Engineer.

Another examples are data organization in the data lake, crawlers for data capture or the deployment and packaging of the generated models (a position nowadays most known as machine learning engineer).

We do not need unicorns who are capable of solving issues on their own because that model is neither sustainable nor scalable. What we need most today are data engineers who can create infrastructure that maximize the amount of time that data scientists can focus on data analysis and model training.

The relation between Data Engineering and Data Science

Data Engineering is the part of Data Science focused mainly on technological and analytical infrastructure, in order to collect, organize and enable the analyses needed. To better explain this, I have created a new version of the Venn diagram for the skills needed for a data scientist, by splitting “hacking skills” into “programming” and “database”, that are specific to and present in the Data Engineering routine.

When we look at the diagram, we see that the only skill not used in Data Engineering is Math and statistics. What we do every day is coding pipelines to move, prepare and transform data; seeking to democratize access to data within the organization simply and instinctively.

As I said before, the need to accelerate delivery requires our teams to be
specialized, and the usage of Math and statistical models has become a well-
defined boundary between DE and DS responsibilities; and it is probable that this is a trend for the market as a whole.

Moreover, to be fair, it must be noted that a Data Engineer is not a Data Scientist who does not know Math; this is not a matter of qualification, but rather of specialization. The data engineer focuses on infrastructure so that the data scientist can focus on research and modelling. A good data engineering team unlocks the entire company’s productivity in data use, including, obviously, the data science team. (This paragraph was suggested by Jéssika Darambaris, thank you!)

Nice! Now, can you explain a little more about what you done in Data Engineering?

In short, everything related to programs that manipulate databases (create, migrate, transform, convert, etc.), such as, but not limited to:

• building data pipelines (python, airflow, spark, pandas);
• crawlers for data capture (scrapy);
• data ingestion via streaming (kafka);
• data lake construction and organization (S3, Athena);
• data warehouse modeling and construction (Kymball model, Redshift);
• Deployment of data-science models;

In the list above, the technologies in brackets are those we use here at Creditas.

Profiles we want for our Data Engineering team

Professionals from different backgrounds can be valuable to our team in many ways, and the most common are:

• Software developers interested in data and distributed processing;
• Data and BI analysts with knowledge of and interest in programming;
• DBAs with knowledge of and interest in programming;
• Experienced data engineers;
• Professionals who wish to become data scientists one day and want to start their careers working with Data Engineering. :)

If you found this article interesting and would like to apply for a job position on our Data Engineering team, click here.

We don’t need everyone to be a Data Scientist was originally published in Creditas Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

We don’t need everyone to be a Data Scientist

A principal especialização que diferencia os Data Sicentists é o conhecimento que possuem em matemática e estatística. Agora, quando tiramos o foco da matemática, o bolovo que resta é popularmente conhecido como Data Engineering. O termo não é ruim pois de fato tudo se trata, de um modo ou de outro, de engenharia de dados; mas a diversidade de contextos e de demandas nos leva ao mesmo dilema do post anterior: queremos cavalos de corrida e não unicórnios.

É uma questão de foco. Se queremos andar mais rápido, precisamos de pessoas focadas em problemas específicos e que se tornem realmente boas (e rápidas!) em resolvê-los. Hoje na Creditas buscamos acelerar nossas entregas, então por isso vamos decompor o papel de um Data Engineer em três outros.

As necessidades da grande área de dados

Quando falamos das iniciativas relacionadas aos dados de uma organização, principalmente do ponto de vista gerencial, as necessidades são muitas: desde o armazenamento, a distribuição e a disponibilização até mesmo à descoberta, governança e entendimento dos dados. E nesse fluxo participam diferentes profissionais com diferentes focos e diferentes habilidades.

A imagem a seguir mostra um diagrama de como podemos dispor as diferentes demandas em relação às quatro grandes áreas de conhecimento necessárias para se extrair valor dos dados: negócio, banco de dados, programação e matemática (estatística).

Historicamente, pela maneira como organizamos Data Engineering aqui na Creditas (e talvez como você se organizou também), grande parte dessas demandas é responsabilidade do nosso time. Dentre elas a lista de responsabilidades que já coloquei no primeiro post:

• construção de workflows para processamento de dados;
• crawlers para captura de dados;
• ingestão de dados via streaming;
• construção e organização do data-lake;
• modelagem e construção do data warehouse;
• deploy de modelos de data-science;

além dessas podemos acrescentar:

• governança de acesso às bases de dados;
• documentação das bases de dados;
• sistemas de captura de dados de usuários;
• disponibilização de dados analíticos no ambiente operacional,
• entre outras.

O problema do BOLOVO

Olhando para nossa estrutura de times atual sobre essas responsabilidades, a figura seria mais ou menos a seguinte:

• Data Science: time de cientistas de dados focados na construção de modelos que agreguem valor ao negócio, principalmente em termos de inovação e automação de tarefas repetitivas.
• Product Development: times formados por desenvolvedores e product managers focados em fazer entregas de tecnologia que agreguem valor ao negócio. Do ponto de vista de dados são os produtores dos dados operacionais e são os time de tecnologia mais próximos do negócio.
• Analytics: times de analistas de dados focados em acompanhar KPIs da operação e responder perguntas de negócio. Do ponto de vista de dados são os principais consumidores do ambiente analítico e os principais demandantes do time de Data Engineering.
• BOLOVO Data Engineering: nosso time de super-heróis/heroínas (não que os outros não sejam =) que fazem de tudo um pouco para atender todos os times acima em suas necessidades de dados no ambiente analítico.

Embora toda essa gama de demandas traga muita diversão e aprendizado ao nosso dia a dia, muitos problemas surgem deste cenário, gerando atrito, retrabalho e ineficiência. Para citar alguns desses problemas:

1. a falta de foco diminui a profundidade das pessoas tanto em termos de domínio quanto tecnológico;
2. a troca de contexto é sempre um pedágio que precisa ser pago;
3. não raramente há retrabalho por conta de entendimento parcial do domínio a ser atendido;
4. os relacionamentos interpessoais não se fortalecem como deveriam, uma vez que a cada tarefa é preciso interagir com uma pessoa diferente;
5. é difcíl crescer o time pois é difícil encontrar pessoas com tantas qualificações;
6. os salários tornam-se inflados por profissionais com pouca profundidade ou tempo de experiência.

Para completar essa lista, no momento atual estamos em uma etapa da empresa que precisamos ganhar velocidade. Ou seja, não dá mais, precisamos desmembrar esse unicórnio. (tadinhooo… 😭)

A medida certa de multidisciplinaridade

Se voltarmos ao princípio de tudo (calma, não tão longe assim), do surgimento do conceito de data science, veremos que o grande diferencial foi a capacidade de transpor barreiras. O que antes era feito por pessoas diferentes, cada uma a partir de suas próprias capacidades e limitações, passou a ser feito de um novo jeito, mais criativo, e com menos restrições por alguém com conhecimento multidisciplinar (o unicórnio).

Como resolver este dilema, então? Simples, com pessoas que sejam capazes de transpor uma barreira, e não todas. A figura a seguir mostra como decompomos o papel do "BOLOVO Data Engineering" em três novos papéis distintos.

• Analytics Data Engineering: time focado em habilitar e acelerar a obtenção de respostas para as perguntas de negócio que precisam de análise de dados. Demanda infraestrutura do time de Data Platform Engineering e colabora estreitamente com Analytics.
• Data Platform Engineering: time focado na automação da captura e redistribuição dos dados, tanto no ambiente operacional, quanto no analítico. Colabora com os times de Product Development para a captura dos dados operacionais, e com Analytics Data Engineering e Machine Learning Engineering na organização do data lake.
• Machine Learning Engineering: time focado em apoiar os cientistas de dados, atuando em todo o ciclo de vida dos modelos, desde a captura de dados para treino até a produtização dos mesmos.

Incluindo no diagrama o fluxo de geração de valor, cada time colabora com os que estão ao lado para romper as inúmeras barreiras existentes entre a produção e armazenamento dos dados até seu uso em tomadas de decisão e inovação de negócio.

Nos próximos posts irei explicar melhor o que cada um desses "novos" papéis faz e quais as habilidades esperadas para cada um. Fiquem ligados(as) pois temos vagas por abrir! Até a próxima!

Tem interesse em trabalhar conosco? Nós estamos sempre procurando por pessoas apaixonadas por tecnologia para fazer parte da nossa tripulação! Você pode conferir nossas vagas aqui.

Precisamos especializar a engenharia de dados was originally published in Creditas Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recentemente em conversas com a Bárbara Barbosa, líder do time de Data Science da Creditas, comentei com ela a dificuldade que estava tendo para encontrar bons candidatos para o time de Data Engineering. A área de dados é bastante concorrida, candidatos com não muita experiência e salários muito altos formam o cenário; e pra completar, aqueles que de fato eram boas opções para integrar nosso time estão buscando mesmo é se tornar um data scientist. Desde então toda vez que falo sobre o assunto eu repito:

Everyone wants to be a Data Scientist!!!

Bom, e não preciso dizer que não sou o único achando isso né? Veja essa pergunta no Quora questionando se estamos em direção a uma bolha de talentos em Data Science.

Pois é, mas a verdade é que para ser um verdadeiro talento em ciência de dados você precisa ser aquele ser fantástico que todo mundo já ouviu falar: uma pessoa que tem “hacking skills”, conhecimento de matemática e estatística e domínio do negócio. Um verdadeiro unicórnio!

Unicórnios não nascem unicórnios

Sim, unicórnios existem. Verdadeiros talentos em ciência de dados existem. Pessoas que dominam tudo o que é necessário para gerar impacto no negócio utilizando dados, desde a concepção do problema de negócio até a entrega do modelo em produção, existem. Mas elas não começaram a carreira assim. Simplesmente não é possível alguém ter a experiência necessária para desempenhar esse papel tão complexo com poucos anos de carreira.

Estudar bastante, se dedicar, fazer toda sorte de cursos online sobre os mais diferentes tipos de algoritmos e técnicas parece a estratégia padrão para virar um unicórnio. Mas a verdade é que para ser relevante na resolução de problemas reais é preciso bem mais que isso. É preciso experiência, é preciso vivência; e isso só vem com o trabalho e com o tempo.

Em seu post “Data science is different now”, Vicki Boykis, uma cientista de dados no mercado desde 2012, relata que o mercado hoje está saturado de candidatos a uma vaga júnior de ciência de dados, onde a concorrência chega a ser de 100 candidatos para 1 vaga. Ela aconselha os aspirantes à cientistas de dados a utilizar o seguinte plano para para iniciar na carreira:

1. Don’t shoot for a data science job
2. Be prepared for most of your data scientist work to not be data science. Adjust your skillset for that.

em seguida, referente a este relatório da PWC, ela afirma:

… the number of data science positions is estimated at 50k. The number of data engineering postings is 500k. The number of data analysts is 125k.

It’s much easier to come into a data science and tech career through the “back door” …

O que é exatamente a realidade que temos visto nas candidaturas para as vagas de Data Scientist e Data Engineering da Creditas.Temos muito mais concorrência nas vagas de DS e muito mais vagas abertas para DE.

Não precisamos mais de unicórnios, queremos cavalos de corrida

Embora seja extremamente valioso termos em nosso time os tão disputados unicórnios, entendemos que essa não é a melhor maneira de trabalhar. Os tempos mudaram, hoje na Creditas buscamos especialização dos times de Data Science e Data Engineering. Desse modo podemos potencializar a eficiência de cada um dos times.

Vicki Boykis on Twitter

Have been extremely curious about this for a while now, so I decided to create a poll. "As someone titled 'data scientist' in 2019, I spend most of (60%+) my time:" ("Other") also welcome, add it in the replies.

Um fato já amplamente conhecido é que de 70% a 80% ou mais do tempo gasto por cientistas de dados é na verdade apenas a preparação dos dados. Um trabalho cuja responsabilidade é claramente de Data Engineer.

Um outro exemplo desse tipo de situação é a organização dos dados no data lake, a captura de dados através de crawlers, ou ainda o empacotamento e deploy dos modelos gerados (função hoje sendo definida como machine learning engineer).

Não precisamos de unicórnios capazes de resolver os problemas sozinhos, pois este não é um modelo sustentável nem escalável. O que mais temos necessidade hoje é de engenheiros(as) de dados para criar infraestrutura que maximize o tempo dos cientistas focados em análise de dados e treino de modelos.

A relação entre Data Engineering e Data Science

Data Engineering é a parte de Data Science focada principalmente em infraestrutura tecnológica e analítica, com intuito de coletar, organizar e viabilizar as análises necessárias. Para facilitar esse entendimento, criei uma nova versão do diagrama de venn das skills necessárias a um cientista de dados quebrando a dimensão de “hacking skills” em “programação” e em “banco de dados”, específicas e presentes no dia a dia de Data Engineering.

Olhando para o diagrama, vemos que a única habilidade não exercitada no trabalho de Data Engineering é o uso de matemática e estatística. O que fazemos em nosso dia a dia é codificação de fluxos de movimentação, preparação e transformação de dados; tendo como objetivo democratizar o acesso aos dados dentro da organização de maneira simples e intuitiva.

Como disse anteriormente, a necessidade de acelerar as entregas tem exigido especialização dos nossos times e o uso de matemática e modelos estatístico tem servido como uma fronteira bem definida entre as responsabilidades de DE e DS; e é provável que esse seja um movimento do mercado como um todo.

Além disso, é preciso dizer que um Data Engineer não é um Data Scientist que não sabe matemática; não é uma questão de qualificação e sim de especialização. O DE foca em infraestrutura para que o DS foque em pesquisa e modelagem. Um bom time de DE destrava a produtividade de toda a empresa no uso de dados, inclusive do time de DS. (este parágrafo foi sugestão da Jéssika Darambaris, obrigado!)

Gostei, explica melhor o que vocês fazem em DE?

Em suma, tudo que diz respeito a programas que manipulam bases de dados (criar, migrar, transformar, converter, etc.), alguns exemplo seriam:

• Construção de workflows para processamento de dados (python, airflow, spark, pandas);
• Crawlers para captura de dados (scrapy);
• Ingestão de dados via streaming (kafka);
• Construção e organização do data-lake (S3, Athena);
• Modelagem e construção do data warehouse (modelo de Kymball, Redshift);
• Deploy de modelos de data-science;

Na lista acima, as tecnologias entre parênteses são as que utilizamos aqui na Creditas.

Perfis que procuramos para nosso time de Data Engineering

Profissionais de backgrounds diversos podem agregar em nosso time de diversas maneiras, sendo os mais comuns:

• Desenvolvedores de softwares com interesse em dados e processamento distribuído;
• Analistas de dados e de BI com conhecimento e interesse em programação;
• DBAs com conhecimento e interesse em programação;
• Engenheiros de dados com experiência;
• Profissionais que desejam ser cientistas de dados um dia e que desejam começar a carreira colaborando com Data Engineering. :)

Como é trabalhar em Tecnologia na Creditas?

O que mais me motiva em trabalhar na Creditas é a cultura, é o primeiro lugar que sinto que os valores e propósito não são apenas frases bonitas num mural. Aqui sinto que temos muita liberdade para aprender, testar e criar. Em suma, temos muita autonomia para gerar impacto. A missão da empresa é sensacional: “viabilizar suas novas conquistas”; costumo dizer pra todo mundo que “se a gente fizer essa empresa dar certo, a situação de muitos brasileiros muda”.

Se você se interessou pelo que leu aqui e gostaria de aplicar para uma vaga em nosso time de Data Engineering. Nós estamos sempre procurando por pessoas apaixonadas por tecnologia para fazer parte da nossa tripulação! Você pode conferir nossas vagas aqui.

We don’t need everyone to be a Data Scientist was originally published in Creditas Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.