From talents to assets

After the first part of this mini-series, I received some very interesting insights from fellow data professionals. Interestingly, one of the recurring topics was talent management. This topic is also very close to me. I know from first-hand experience that without good mentors and talent management I would never have been able to get to this point and still enjoy so much my everyday work. In this article, I would like to discuss the two specific aspects of talent management. The first is nurturing talent during internships and the second is whether a computer science dropout or a fresh PhD is better material for a data scientist.

One could argue that hiring is more about acquiring talents and not about talent management. In my opinion, though the term talent management is better suited to emphasize the interactive nature of the hiring and onboarding process. Here, one must keep in mind that highly intelligent people require room and guidance to develop and probably will never be able to work longer for a fat paycheck. To realize the importance of this claim just consider how much money it takes to get a good data scientist. Early employee turnover means essentially wasting financial assets. Therefore, the below lines are not only about an effective data science team from the R&D point of view but also making it in a business aware and cost-effective way.

Interning in a data science team

Today, if you study some STEM subject at the university, chances are you have already met the myriad of opportunities to enter the data science world. Banks, marketing companies, IT giants, and {food, health, etc.}-tech startups are looking for entry level data scientists to bolster their data team.

For many people, the prime requirement for an internship is that it should be at some well-known company. This is a valid consideration but here I would rather talk about some other points to take into account. Because in my opinion, doing an internship is not only about making your resume look better, rather about jumpstarting your career by learning about the practice of the field. I mean, there is nothing more disappointing when after looking at some impressive CV, on the interview the person shows mediocre performance… So let’s take one by one, the 3 points to consider when you choose your internship.

(1) The most important thing I feel often lacking from internships is focus: you get to the company and are going to work on basically everything that other people don’t want to or don’t have time to. This may even sound great first because you have the chance to try several methods, packages, data types etc. But be aware that this is something that you can also try on Kaggle, Drivendata or KDDCup. On the other hand, focused, ML-based product development is something that you can only learn by doing it at a company. This means you are going to learn about why and how to use machine learning methods to design something useful (on the price of trying fewer methods/packages/libraries).

(2) This brings us to the next point: accountability. I remember once catching a conversation at a conference banquet where a senior colleague was talking about how he usually gives interns some tasks but then forgets even what they are doing, not mentioning where they are at with what they are doing. This happens more often than you think.

If you are a senior just think about how excited you were when you first entered the work-life. Leverage this and get real work done by your interns. Even if they seem to be not senior enough for any of the tasks your team is facing, mind that they are eager to learn and challenge is the best motivation. If you are an intern, consider that one of the most valuable lessons you can experience during an internship is responsibility. Openness to taking responsibilities is a characteristic I am also looking for during interviews.

John is learning the hard way that interns today are not only looking for cool projects at a job fair but are often collecting fantastic swags as well. They have to bring next time some … as bait.

(3) The third point: find the intersection of hot and cold. Hot topics are easy to find in data science, just look at what was the most discussed topics last year at NeurIPS or ICML and chances are you find companies trying those ideas already today. Cold, on the other hand, is harder to find. Let me explain: it does not take 10+ years to see that there is a lot of hype on the field and often it turns out that this effective “new” method is actually a refurbished control theory application running on a big computer. Seeing this is extremely valuable since it enables to see also the connections, limitations and consequences based on several decades of research. This helps also to learn about the context where the new models born. So try to find a place where hot and cold meet. Hot in itself means just using trial-and-error model building and trust that the data behaves well (it never does..). Cold in itself means ignorance to any new addition to the field, and although the basis is often some classical theory but there are important additions in every major breakthrough that should not be ignored. So as Katy Perry sung: hot ’n’ cold.

Although, these points are recommendations for the position seeking intern but I’m also looking for the same qualities in the candidates during an interview. This leads us to the next point because besides these characteristics there are important experience factors that make certain data scientists more attractive to a company.

PhD or converted software engineer?

Everyone knows that the ideal data scientist has a PhD, knows Hadoop, Spark, and Docker, has 5+ year of business experience, 7 publications at top ML conferences and is under 25 years. Also, everyone knows that these data science unicorns rarely found in the real world. So the question is where to make compromises. One of such is whether a company should choose someone with deep statistical/ML background and experience in the ups and downs of working with real data (aka. PhD) or someone who has practical experience in how to efficiently write production level code and store data in a concise, safe and easy-to-access manner (aka. Converted software engineer hereafter referred as CSE).

Mind that an interview is challenging. Even for a data science unicorn.

I wish there was an answer to this. The problem is that these groups show variance as well. You can easily find a PhD who writes better code than a CSE and a CSE who knows clustering methods better than a PhD. On average PhD people from academia are inferior in coding and CSE people have more lacking mathematical foundations. But this difference should only bother you if you randomly (!) choose from the pool of CVs and hire the person who that CV belongs to. Then — of course — because of the nature of random variables you have a higher probability of ending up with someone writing better code if that person is incidentally a CSE.

But I am sure that I can safely say that no company is making costly hiring decisions by random selection. Instead, they want to know more about the candidate to reduce the uncertainty about his/her future performance. So let’s stop acting like it is a random selection because this whole thing brings lots of frustration to the people working in data science. Many of my friends coming from the software engineering track are frustrated because they don’t have the Dr. prefix while others with the PhD are doing totally unnecessary code polishing because they want to show their coding skills. And as the manager, the last thing you want in your team is frustration when you expect them to be creative.

I think avoiding this evil loop it is essential to have a mentor who helps mitigate the frustration and drives the person in the intricate path of becoming a real data scientist. Years ago, when I joined Synetiq that mentor was Adam Divak, the CTO of the company. Before founding the company, he was running brain simulations on supercomputers and had an outstanding interest in complex systems. Everyone knew him as the goto person with whatever technical problem and he is one of the few people I know who strives for perfectionism and can stop because of pragmatism. I was the guy from academia, coding in Matlab, not knowing git, unaware of all software engineering jargon (i.e. CRUD). But I really wanted to take this chance, so when I got one week to complete the interview task, I learned Python to the level to be able to submit the code. When I told on the interview that I learned it just for this task, I saw a genuine surprise in his eyes. From that time he looked closely my progress. During my trial period, every day after work I spent extra hours to study the tools I was supposed to work with and understand the methods that I was supposed to use. I quickly understood many new methods and utilized my existing knowledge in various tasks. Still, I was frustrated and did not feel that I’m improving enough. Now I know that this is a warning sign of an incoming burnout.

That is the point when a good mentor has to be there. I was lucky when Adam saw it. He asked me to update him on my progress at the end of each workday. This update often meant an extra hour of work for both of us but he took the effort and made sure that I can focus on the things that matter. He explained to me that knowing the meaning of all git commands does not make a good data scientist; understanding the data, the methods, and being able to make the right inferences do. So I should not feel less because I don’t speak all the CS talk, that will come with time. And he was right.

All of us — no matter PhD or CSE — have frustrations and lacks in knowledge but also strong sides and potentials. This is true for any team, anywhere in the world. A good mentor sees beyond the stereotypes and can help you with reaching full potential. Ideally, this starts as early as the interview process so try to find a manager that you feel could help to take your next step in the career path. Of course, reaching full potential is not necessarily an easy way but one worth taking definitely.