As a data scientist, I agree with this. On my team, the data scientists with the largest impact seem to be the ones who are sort of hybrid software engineers / data scientists. I’ve noticed these people tend to swap between the two titles occasionally (re-interviewing within the company for one role or the other).

I think if I had my own company I’d create a position like “scientific software engineer”, which would basically be a SWE with a scientific or statistical background. It would de-emphasize pure analysis in favor of directly applied research in the form of production code. There are some similar titles out there (research scientist, ML engineer), but they don’t quite capture exactly what I have in mind. “Applied scientist” would probably be the closest.

I've done this at a couple of places, creating "scientific developer" positions. It works reasonably well but has some gotchas. The biggest one is identifying people who are truly interested in developing some depth in both areas.

I agree. Last time I hired a data scientist, we got someone who could code but who'd write very much suboptimal code that worked for his exploration and as a proof of concept, but not much more.

That worked out fine: we paired him with a relatively junior developer that worked with him on translating his proof of concept code into something more suitable for production. I think both of them learned quite a lot of coding and data science respectively from each other, and output was good.

But if our data scientist hadn't been able to produce something that we could run as a starting point, the gap would have been too big.

What's a concrete example of production DS code? Does it mean that the code handles edge cases, uses logs, is well documented, etc or what exactly? I'm a DS student and don't know what everyone means by "production" code.

It's pretty much the same as production software code.

I'm not talking about code to visualize data and present in some form of media. They are part of DS for sure but more for BI and analysts.

For instance, in my previous experience with data science we've built production pipeline to ingest, digest, create model, serve model on some API. The model updates itself every so often, all without human intervention. Code powering something living in production like that would be production DS code imo.

The other replies here, and your own suggestion all makes sense. Often it's also performance and memory use. The prototype code didn't tend to take into account which shortcuts etc. we needed to take to run things fast enough on hardware of more than a decade ago with the sheer amount of data needed in production.

Which was fine - clarify of the methods was helpful in order for the rest of us to understand what he was trying to do.

imo as someone who does ds & analytics and has deployed prod models: meets business-defined specs, is maintainable, requires little to no support. everything else falls underneath

tbh i dont think this is something you learn in school, or is expected of new grads

the fact is all the knowledge that a data scientist has should already be discoverable by any decent programmer. Basically college level statistics is required to be a data scientist. If your engineer cant handle that I hope they are more frontend than backend.

Data science does have particular algorithms and analysis graphs that are unique to the field but the underlying math is set theory and statistics.

"Data scientist" is a fancy title for "smart math guy". But math without application gets you no where. You need someone to put it into the machine.

Depends. If it’s a spam classifier, yeah I agree. If it’s estimating causal models for some type of economic analysis it will be harder for a self taught SDE to compete with someone with academic research experience dealing with messier social sciencey economic data.

Actually spam classifiers are not easy at all.

First, the data is very unbalanced.

Second, you would need to retrain the model often. So you would need to understand statistical methods for comparing text level/word level distributions. This is not a college-level stat.

Third, you would need deep knowledge in NLP, feature engineering and algorithm selection.

I didn't say it's easy, I said it's something more amenable to an SDE self-learning.

I think the point is that the person with academic research experience dealing with messier social sciencey economic data would/should have basic junior SDE level programming skill.

If not, say that his research is conducted in excel, I'd still rather have the former.

Yeah. I agree with you, as I have both the academic research skills and the SDE level programming skills as a DS (by only doing a masters I was able to get out of academia earlier and develop some SDE skills instead of writing a dissertation). But every once in a while we hire someone who is in their early 30s and just finished academia, and despite sucking at engineering, can blow everyone away scientifically. I think a well crafted 2-pizza team can support 1 or 2 of those people.

> 2-pizza team

Unrelated, but since you spoke of this, I just want to tell you whoever came up with this term severely underestimated our teams appetite.