There are people mostly with an IT background who think that for data science you don’t need to know math and just monkey see monkey do sutoml based on atutorial, inspirational MOOCs and libraries that appeared magically out of thin air.
There are people with a math background who think data science is just an extension of statistics, so business, knowledge of scalable information storages, and productization is irrelevant.
There are both kind of posts here on HN. My take has been to hire math people with some cs msc, cs people with datascience msc, and business people that also know sales.
For me that has worked painlessly but your milage may vary.
I haven’t seen that black swan CV capable in all three disciplines, but I have seen CVs that seem to think that they can tackle every problem because they have read all towardsds and kaggle tutorials. Marginalization? Kubeflow? POV?, 2 out of 3 are usually foreign concepts.
I've met quite a lot of Black Swans, and been employed alongside precisely zero.
I know one hard science PhD who runs their own K8s cluster at home and plays with Linux distros.
They describe themselves as "a statistician who can program."
Generally speaking it's more common for them to come from the math side of the fence. From the IT side I'll say the math is a bit harder than the computer stuff.
I know one hard science PhD who runs their own K8s cluster at home and plays with Linux distros.
That's super awesome for that data scientist, but the question for a business is can/should you structure yourself in such a way that you NEED employees with that cornercase level of joint expertise.
The answer is you really can't. Individuals have awesome strengths that they developed for reasons particular to them. Use those strengths when you can. But the business has to rely on a common denominator of a role or else it'll never fill it when their unicorn leaves to go backpacking in Europe.
Agree. You need to structure your talent pipeline, and organization, based on the average level of talent you can likely receive at your compensation bracket. You cannot create a single point of dependency on an employee who you'll never be able to replace for the same amount of money.
However, the issue is that productivity is logarithmic.
The unfortunate truth the school of hard knocks has shown me is that someone without the "roll your sleeves up" attitude to learn Docker is generally speaking just not going to be that effective when push comes to shove.
Now if you're using tools to abstract the time of data scientists who are CAPABLE of learning Docker, that is a different story.
But someone who starts grumbling about having to learn the command line to containerize their pipeline is generally speaking on the west side of the Pareto principle.
I can only guess at which particular area they will trip up, but it'll be somewhere.
Agree thar work ethic is the most important thing since complicated qualitative things cannot be measured, trust precedes everything. But work ethic does not complete the puzzle because people dont know always what they dont know.
For the example you mentioned, I will use a simplification I make to explain levels of expertise of challenging knowledge:
1.ABOUT: Know about something (heard it, know some examples) 2. KNOW: Know that something well (I now understand it and can leverage it towards an end to end a useful thing, also know its weaknesses) 3. HUMBLE: Realize I did not know many things about it but now know many ways of using it, can correct and extend other people's work, most of the time. 4. EXPERT: Know why it was structured that way. Contribute to the knowledge/tool itself.
So for that PhD an initial estimate would be a 3 or 4 scale on the math level, 1 or 2 on the kubernetes level (don't know him ofcourse I can be wrong without first discussing). If he works independently level 2 kubernetes is pretty great. If he needs to be part of a larger support team, a level 3 knowledge based on my (admittedly back of the napkin and ambiguous) categorization might prove to be less risky.
Smart and creative peope can grasp a lot of things but not everything is pure thought. Experience and experimentation time is required and there are only 24 hours in a day. Also the ds field has a lot of young people that did not have that much time or opportunity yet.
My N is a few hundred, not all my personal hires. I have visibility because now I do project management office duties (build sub teams per project), lead most of the interviews on the ds side, internal technical consulting duties. Ten you mentioned is my target number for hires previous and next week approx.
My claim is based on experience from the academic and the consulting space for global corp (which included consulting for other corps to build their ds teams, rarely though). I hope my claim appears logical and is useful.
Comments
There are people mostly with an IT background who think that for data science you don’t need to know math and just monkey see monkey do sutoml based on atutorial, inspirational MOOCs and libraries that appeared magically out of thin air.
There are people with a math background who think data science is just an extension of statistics, so business, knowledge of scalable information storages, and productization is irrelevant.
There are both kind of posts here on HN. My take has been to hire math people with some cs msc, cs people with datascience msc, and business people that also know sales.
For me that has worked painlessly but your milage may vary. I haven’t seen that black swan CV capable in all three disciplines, but I have seen CVs that seem to think that they can tackle every problem because they have read all towardsds and kaggle tutorials. Marginalization? Kubeflow? POV?, 2 out of 3 are usually foreign concepts.
It's mostly work ethic I find.
I've met quite a lot of Black Swans, and been employed alongside precisely zero.
I know one hard science PhD who runs their own K8s cluster at home and plays with Linux distros.
They describe themselves as "a statistician who can program."
Generally speaking it's more common for them to come from the math side of the fence. From the IT side I'll say the math is a bit harder than the computer stuff.
It's genuinely, 100% work ethic.
That's super awesome for that data scientist, but the question for a business is can/should you structure yourself in such a way that you NEED employees with that cornercase level of joint expertise.
The answer is you really can't. Individuals have awesome strengths that they developed for reasons particular to them. Use those strengths when you can. But the business has to rely on a common denominator of a role or else it'll never fill it when their unicorn leaves to go backpacking in Europe.
Agree. You need to structure your talent pipeline, and organization, based on the average level of talent you can likely receive at your compensation bracket. You cannot create a single point of dependency on an employee who you'll never be able to replace for the same amount of money.
However, the issue is that productivity is logarithmic.
The unfortunate truth the school of hard knocks has shown me is that someone without the "roll your sleeves up" attitude to learn Docker is generally speaking just not going to be that effective when push comes to shove.
Now if you're using tools to abstract the time of data scientists who are CAPABLE of learning Docker, that is a different story.
But someone who starts grumbling about having to learn the command line to containerize their pipeline is generally speaking on the west side of the Pareto principle.
I can only guess at which particular area they will trip up, but it'll be somewhere.
Agree thar work ethic is the most important thing since complicated qualitative things cannot be measured, trust precedes everything. But work ethic does not complete the puzzle because people dont know always what they dont know.
For the example you mentioned, I will use a simplification I make to explain levels of expertise of challenging knowledge: 1.ABOUT: Know about something (heard it, know some examples) 2. KNOW: Know that something well (I now understand it and can leverage it towards an end to end a useful thing, also know its weaknesses) 3. HUMBLE: Realize I did not know many things about it but now know many ways of using it, can correct and extend other people's work, most of the time. 4. EXPERT: Know why it was structured that way. Contribute to the knowledge/tool itself.
So for that PhD an initial estimate would be a 3 or 4 scale on the math level, 1 or 2 on the kubernetes level (don't know him ofcourse I can be wrong without first discussing). If he works independently level 2 kubernetes is pretty great. If he needs to be part of a larger support team, a level 3 knowledge based on my (admittedly back of the napkin and ambiguous) categorization might prove to be less risky.
And what makes you think that when presented with a problem those people who can grasp 2 concepts cannot get the 3rd one.
Was it shooting questions from the hip on the spot while interviewing them?
Or you hired 10 people and worked with them for at least 6 months to really know what they are capable of?
I think the former because no one has enough budget to hire people stick with them for 6 months just to see how they fare.
So what is your N to back up your claim?
Because it sounds like you really have something to say.
Smart and creative peope can grasp a lot of things but not everything is pure thought. Experience and experimentation time is required and there are only 24 hours in a day. Also the ds field has a lot of young people that did not have that much time or opportunity yet.
My N is a few hundred, not all my personal hires. I have visibility because now I do project management office duties (build sub teams per project), lead most of the interviews on the ds side, internal technical consulting duties. Ten you mentioned is my target number for hires previous and next week approx.
My claim is based on experience from the academic and the consulting space for global corp (which included consulting for other corps to build their ds teams, rarely though). I hope my claim appears logical and is useful.
Few hundreds seems quite fair to have a good opinion.