Every once in a while, I have the opportunity to speak to a group of folks interested in launching a career in data. Normally, I run through the essentials: learn Python instead of R, use leading commas in your SQL, start with Bayes and jump to neural nets if needed, leverage pie charts extensively — you know, universally accepted truths.
This week, I have just such an opportunity. This school has a budding analytics major, but most students are drawn from a variety of disciplines — business, humanities, communications, the arts, and the sciences.
It’s intimidating to try and break into a career even with the best of preparation, but the data field can seem particularly incoherent to aspirants. So this week, in lieu of a post, I’d love to collect some stories connecting what you studied in college to careers in data. (For the children!)
So, in the thread, shout out:
What did you study in college, and what is one way it has helped you in your data career?
I’ll kick off the discussion with my own thoughts in a comment below.
I was a philosophy major, quite a hard-core one, I’ll admit. I would read Nietzsche on Spring Break while others were playing beer pong. I had an existential crisis where I fled to Florida and read Kierkegaard to work out my religious convictions. I wrote my senior thesis on whether it was ethically possible to make the marital vow — “till death do us part” — and then I got engaged.
So philosophy and I have a thing. But as a data professional, I have found its toolbox to be indispensable. Broadly, philosophy teaches you how to think clearly, and exposes you to some of the clearest thinkers in the past 3 millennia of written history.
Of the rhetorical devices I deploy regularly, my favorite is the “thought experiment”. The thought experiment starts with three magical words: Let us suppose. This phrase can turn an emotionally charged, multidimensional problem into a flat, pliable hypothetical. The best part is that you don’t need any data.
It can be deployed anywhere, and notice how it launches us into dialogue:
- Ok, so let us suppose feature X increases daily active users by 20%. How will it affect metric monthly recurring revenue?
- Alright, let us suppose we hire two new data team members. Does this fix the root cause of the team being stressed and overworked?
- Let us suppose humans have souls. If we found silicon-based lifeforms outside our solar system that are otherwise identical to humans, would we say that they too have a soul?
The thought experiment is a bit like coming to a fork in the road, then jogging further down one side to see if it’s the right track to go down. In the context of data problems, it can save a lot of effort spent solving the wrong problem.
Since I am of the “build first, ask questions later,” disposition, having some rhetorical tricks to slow me down is hugely useful. It’s safe to say I never expected to find myself as a data engineer, but even here, I rely on skills I learned in philosophy (and chemistry, as well) fairly regularly — not to speak of the adjacent skills (like writing, reading, argument) that it helped me hone.
I was a math major. I believe one of the most valuable lessons instilled in me was the importance and value of having rigorous definitions. Any proofs-based math course is about learning and digesting definitions. It sounds a bit dull, but I really grew to love the process of understanding a definition, stretching it until it broke, prodding it until it swelled, considering its corollaries, and trying to apply it to novel situations. Like many of the sentiments already shared, this trained my ability to think hard and express my ideas clearly.
I was surprised to learn that the job market didn't uniformly recognize these as marketable talents. I remember failing a data analyst internship interview after being asked "3 ways to aggregate data in Tableau" - I tried to explain something about being careful not to aggregate away the useful variation in the data, only to learn my interviewer wanted me to recount some sequence of drag-and-drop clicks instead.
That said, having now worked for a few years, I've been surprised how quickly technical decisions turn into philosophical discussions, and I often find myself falling back onto my mathematical roots. This happens frequently when trying to define a metric - the questions immediately begin surfacing: What are we actually trying to measure? Why should certain entities be included in the cohort? What amount of deviation in the metric would be meaningful? If this metric improved x%, what would we expect to happen to our business?
I was a Chemistry major then Materials Science in graduate school. I didn't really have a career plan related to those choices (still don't), but I have no regrets. I think any STEM degree will give you the background you need in statistics/ math although sometimes I do have to dig deep in the caves of my memory for these topics. But, as others have said below (love it @Ian Whitestone), what has really helped me in data is:
1. Being comfortable tackling a problem you don't know much (if anything) about. Ian says it well below, but I think a STEM degree prepares you to say: 'Well I don't know anything at all about that, but I do know this and it could be related. This is how we might be able to implement it in this case.'
2. Being comfortable being wrong - I can't tell you how many times I was wrong during my degrees; I stopped counting. But becoming comfortable with the wrong-ness, talking about it, learning from it and making a project better until its awesome is what science, engineering and the data versions of those things are all about and it's a skill that I have found invaluable.
3. Communicating technical things and selling your subject - During my degree I was often challenged to explain my thought process or my understanding of a concept on the spot. Being able to distill my thoughts into a logical and hopefully succinct sentence has been really powerful when sitting in meetings with both other data professionals and stakeholders without a data background.
Love the collection - so great to hear people's stories
I studied chemical engineering. The only relevant materials taught were some basic statistics courses (super boring, didn't remember a thing or enjoy them) and some introductory programming courses in matlab (ugh. WHY?!?!) and C++. Most of these were in first year, and I quickly forgot pretty much everything taught. Lots more math/calculus courses, but I think these are way less applicable unless you're going DEEP into understanding how certain ML algos work (or building new ones). So very useless in terms of directly applicable coursework, compared to what you'd get in a CS or more stats-heavy degree.
Now with all that said, I have zero regrets. I've worked in data for the past 6 years and still wouldn't go back and change a thing if I had the chance. Two ways (i know you only asked for one :) ) it helped:
1. I learned how to learn. You have to grok a ton of new, hard material in most engineering programs. You also get really comfortable walking into a situation where you have zero idea about any of the stuff and just have to go figure out. Super valuable in any career. Especially valuable in data & tech where things are constantly changing.
2. I learned how to think and reason from first principles. You can't remember how to solve specific problems. You have to learn fundamentals, and then be able to apply them to new areas you've never seen before. You won't do well in your courses if you can't do this, unless you have an easy prof who re-uses exam questions from previous years. Again, super relevant for any career.
I still remember one of my final exams in my fourth year. It was a transport phenomena course and the 1 question on the exam was something like: "you have an ice cream cone and the cream is slowly melting into cone. derive an equation to describe the rate at which the ice cream diffuses into the cone, using a cylindrical coordinate system". Walking out of that exam I was thinking to myself, that was the most irrelevant course (and stupidly hard question), I'm literally never going to have to do anything like that ever. But wiser me looks back at that and smiles.
> You can't remember how to solve specific problems.
Very direct and very true. Education can't be about a specific problem, has to be about the principles. Definitely going to use this -- I think it really strikes at how an undergraduate should be framing what they're learning now vs. what they want to do in ten years.
I studied maths and IT in a French engineering school; I think the most important stuff I learnt is math methodology. I don't use all the technical concepts in my daily job but the methodo and the "way of thinking" is definitely something I kept from my studies.
Data is an engineering field and require engineering thinking (and analytical mindset for sure). Maths teach people to solve problems - not only math problems.
Math and physics teacher should definitely put more emphasis on the system behind math rather than pure technical concepts and pure math/physics problem solving.
So now, whenever I encounter a problem in my daily job as a data practicioner, I start by looking at the engineering parts of it. At the system beyond the problem. It helps me a lot
Yeah, I think educators distilling the "way of thinking" is really powerful. It's that methodical approach that we carry along with us long afterwards.
Do you have a few "engineering parts" of the problem that you usually start with? Inputs, outputs, scale, load -- those sorts of things?
Yes, I usually start by inputs/outputs - without thinking too much of the middle process. Also the scale; definitely. I'm generally not happy with solutions that scale poorly. If I don't have the choice (constraint by time or people) I use to always put some backdoor in case someone (or me) have to come back to the project afterward...
However, it's usually something not really conscious - so not a perfect process but with experience growing more and more it will naturally come an habit. Hope so ;)
In grad school I studied Chemical and Biomolecular Engineering. One of the biggest life and data skills I learned is how to troubleshoot.
One of my many responsibilities was the maintenance of our GC/MS which was a fun and complicated piece of equipment. It had regular ongoing maintenance that was required and it also had lots of things go wrong randomly when others used it. Over the four years I worked on that equipment I learned how to break problems down further and further to figure out where the issue was occurring. I learned how to create protocols for users to self serve and how to iterate on them when problems inevitably came up. I learned how to teach others how to debug their own problems and when to ask for help and when to continue working it themselves.
These are all skills that come in handy when solving data problems (or any problem really). When I then moved on to my first real data job (Concert Genetics) I was working with a whole new complex system (web scraping and nosql databases and redshift) and those troubleshooting skills all came to bear in multiple dimensions. It's useful for learning new tools, systems, and processes as well as figuring out how to solve problems when they arise.
To solve a problem you must first find where it exists! And to answer a data question, you must first find the data - and then continue troubleshooting it until you get an answer.
So maybe it's a bit of a stretch but I come back to this skill regularly. :) Good question Stephen!
I was a double major in Computer Science & Math at a small liberal arts school. It's kind of hard to pick out any one way in which those helped me in my career because I feel like everything is useful -- the amalgamation of everything I learned, every experience I had, is a large part of what makes me, me. I can definitively say though, that Graph Theory was my absolute favorite class and I'm so happy to see how the practical implementations of it are part of our everyday lives now. If I had to pick a most useful class - I think I'd go with Statistics because of the way it teaches you not just how to work with data, but how to question it too.
Being at a liberal arts school, you have to satisfy a lot of requirements in taking classes across a wide array of fields, from the arts, to literature, to language, to science & engineering, etc. In hindsight, those classes outside of my majors were just as valuable as the CS & math degrees to my career, and even more valuable to me as a human being. They exposed me to different ways of thinking, different types of people and viewpoints, different forms of communication, and above all, empathy. I think a lot of us are guilty of (myself included) focusing too narrowly on how we can become the best, most technically sound individual out there -- but we often lose sight of the (non-technical) human in the loop -- which I think many would argue is one of the biggest gaps we have in the MDS space right now.
Others have touched on this in their replies but I'll echo the same sentiments that what's been most valuable is learning how to think, how to communicate, how to ask questions. Learning the HOW, not the WHAT.
I have the same feeling about the non-core classes in liberal arts education -- I still use literary references, geographical knowledge, etc., in conversation and when reading popular culture. Very much "shaped" me.
Also -- shout out to graph theory. Still surprises me how few graph metrics float around the data space, given all our gnarly dags.
I’m not going to write anything constructive here, but I would like to add that it is a long time since I’ve seen such copious amounts of bait in an article’s first paragraph. :)
I studied Political Science, and got a Master's in Public Service Administration. I did learn some hard skills from those programs: Statistics using STATA and R, understanding types of analyses (Cost Benefit, Risk Assessment), a high level understanding of Economics, and a high level understanding of how people studied management academically.
But really what I end up valuing most from my schooling is being primed to understand systems thinking, and how the skill shift between evaluating building a bridge and building a feature isn't huge, what's really hard is understanding the different contexts in which the things being built are going to affect the people who could be using them.
Were you explicitly taught "systems thinking", or was it something you picked up organically by studying different systems -- organizations, economies, political systems, etc.?
I was a finance major & was originally set on pursuing a career in investment management. Not long after graduating I decided to pursue a career in data instead. Leveraging my background in finance helped me get my first data role as an Investments Data Analyst. My technical skills at the time were not the best but because I had the domain knowledge it helped me land the job.
Domain knowledge is very important in any data career. It makes it a lot easier to communicate with data adjacent roles and stakeholders within the company & better understand the problems they are facing. There seems to be a trend with data roles that are embedded within specific business units (Marketing, Finance, HR etc). All these areas have their own unique data and problems.
Having the technical savviness and domain expertise can make for a very successful data career. It also makes your work a lot more interesting if you are dealing with data in a domain that interests you!
Good call on the domain expertise! It's easy to forget, especially with all the hype around tooling, how impactful deep subject matter expertise can be.
I was a philosophy major, quite a hard-core one, I’ll admit. I would read Nietzsche on Spring Break while others were playing beer pong. I had an existential crisis where I fled to Florida and read Kierkegaard to work out my religious convictions. I wrote my senior thesis on whether it was ethically possible to make the marital vow — “till death do us part” — and then I got engaged.
So philosophy and I have a thing. But as a data professional, I have found its toolbox to be indispensable. Broadly, philosophy teaches you how to think clearly, and exposes you to some of the clearest thinkers in the past 3 millennia of written history.
Of the rhetorical devices I deploy regularly, my favorite is the “thought experiment”. The thought experiment starts with three magical words: Let us suppose. This phrase can turn an emotionally charged, multidimensional problem into a flat, pliable hypothetical. The best part is that you don’t need any data.
It can be deployed anywhere, and notice how it launches us into dialogue:
- Ok, so let us suppose feature X increases daily active users by 20%. How will it affect metric monthly recurring revenue?
- Alright, let us suppose we hire two new data team members. Does this fix the root cause of the team being stressed and overworked?
- Let us suppose humans have souls. If we found silicon-based lifeforms outside our solar system that are otherwise identical to humans, would we say that they too have a soul?
The thought experiment is a bit like coming to a fork in the road, then jogging further down one side to see if it’s the right track to go down. In the context of data problems, it can save a lot of effort spent solving the wrong problem.
Since I am of the “build first, ask questions later,” disposition, having some rhetorical tricks to slow me down is hugely useful. It’s safe to say I never expected to find myself as a data engineer, but even here, I rely on skills I learned in philosophy (and chemistry, as well) fairly regularly — not to speak of the adjacent skills (like writing, reading, argument) that it helped me hone.
I was a math major. I believe one of the most valuable lessons instilled in me was the importance and value of having rigorous definitions. Any proofs-based math course is about learning and digesting definitions. It sounds a bit dull, but I really grew to love the process of understanding a definition, stretching it until it broke, prodding it until it swelled, considering its corollaries, and trying to apply it to novel situations. Like many of the sentiments already shared, this trained my ability to think hard and express my ideas clearly.
I was surprised to learn that the job market didn't uniformly recognize these as marketable talents. I remember failing a data analyst internship interview after being asked "3 ways to aggregate data in Tableau" - I tried to explain something about being careful not to aggregate away the useful variation in the data, only to learn my interviewer wanted me to recount some sequence of drag-and-drop clicks instead.
That said, having now worked for a few years, I've been surprised how quickly technical decisions turn into philosophical discussions, and I often find myself falling back onto my mathematical roots. This happens frequently when trying to define a metric - the questions immediately begin surfacing: What are we actually trying to measure? Why should certain entities be included in the cohort? What amount of deviation in the metric would be meaningful? If this metric improved x%, what would we expect to happen to our business?
I was a Chemistry major then Materials Science in graduate school. I didn't really have a career plan related to those choices (still don't), but I have no regrets. I think any STEM degree will give you the background you need in statistics/ math although sometimes I do have to dig deep in the caves of my memory for these topics. But, as others have said below (love it @Ian Whitestone), what has really helped me in data is:
1. Being comfortable tackling a problem you don't know much (if anything) about. Ian says it well below, but I think a STEM degree prepares you to say: 'Well I don't know anything at all about that, but I do know this and it could be related. This is how we might be able to implement it in this case.'
2. Being comfortable being wrong - I can't tell you how many times I was wrong during my degrees; I stopped counting. But becoming comfortable with the wrong-ness, talking about it, learning from it and making a project better until its awesome is what science, engineering and the data versions of those things are all about and it's a skill that I have found invaluable.
3. Communicating technical things and selling your subject - During my degree I was often challenged to explain my thought process or my understanding of a concept on the spot. Being able to distill my thoughts into a logical and hopefully succinct sentence has been really powerful when sitting in meetings with both other data professionals and stakeholders without a data background.
Love the collection - so great to hear people's stories
I studied chemical engineering. The only relevant materials taught were some basic statistics courses (super boring, didn't remember a thing or enjoy them) and some introductory programming courses in matlab (ugh. WHY?!?!) and C++. Most of these were in first year, and I quickly forgot pretty much everything taught. Lots more math/calculus courses, but I think these are way less applicable unless you're going DEEP into understanding how certain ML algos work (or building new ones). So very useless in terms of directly applicable coursework, compared to what you'd get in a CS or more stats-heavy degree.
Now with all that said, I have zero regrets. I've worked in data for the past 6 years and still wouldn't go back and change a thing if I had the chance. Two ways (i know you only asked for one :) ) it helped:
1. I learned how to learn. You have to grok a ton of new, hard material in most engineering programs. You also get really comfortable walking into a situation where you have zero idea about any of the stuff and just have to go figure out. Super valuable in any career. Especially valuable in data & tech where things are constantly changing.
2. I learned how to think and reason from first principles. You can't remember how to solve specific problems. You have to learn fundamentals, and then be able to apply them to new areas you've never seen before. You won't do well in your courses if you can't do this, unless you have an easy prof who re-uses exam questions from previous years. Again, super relevant for any career.
I still remember one of my final exams in my fourth year. It was a transport phenomena course and the 1 question on the exam was something like: "you have an ice cream cone and the cream is slowly melting into cone. derive an equation to describe the rate at which the ice cream diffuses into the cone, using a cylindrical coordinate system". Walking out of that exam I was thinking to myself, that was the most irrelevant course (and stupidly hard question), I'm literally never going to have to do anything like that ever. But wiser me looks back at that and smiles.
> You can't remember how to solve specific problems.
Very direct and very true. Education can't be about a specific problem, has to be about the principles. Definitely going to use this -- I think it really strikes at how an undergraduate should be framing what they're learning now vs. what they want to do in ten years.
Fellow reformed chemical engineer checking in! Agree with everything you've written here.
I studied maths and IT in a French engineering school; I think the most important stuff I learnt is math methodology. I don't use all the technical concepts in my daily job but the methodo and the "way of thinking" is definitely something I kept from my studies.
Data is an engineering field and require engineering thinking (and analytical mindset for sure). Maths teach people to solve problems - not only math problems.
Math and physics teacher should definitely put more emphasis on the system behind math rather than pure technical concepts and pure math/physics problem solving.
So now, whenever I encounter a problem in my daily job as a data practicioner, I start by looking at the engineering parts of it. At the system beyond the problem. It helps me a lot
Yeah, I think educators distilling the "way of thinking" is really powerful. It's that methodical approach that we carry along with us long afterwards.
Do you have a few "engineering parts" of the problem that you usually start with? Inputs, outputs, scale, load -- those sorts of things?
Yes, I usually start by inputs/outputs - without thinking too much of the middle process. Also the scale; definitely. I'm generally not happy with solutions that scale poorly. If I don't have the choice (constraint by time or people) I use to always put some backdoor in case someone (or me) have to come back to the project afterward...
However, it's usually something not really conscious - so not a perfect process but with experience growing more and more it will naturally come an habit. Hope so ;)
In grad school I studied Chemical and Biomolecular Engineering. One of the biggest life and data skills I learned is how to troubleshoot.
One of my many responsibilities was the maintenance of our GC/MS which was a fun and complicated piece of equipment. It had regular ongoing maintenance that was required and it also had lots of things go wrong randomly when others used it. Over the four years I worked on that equipment I learned how to break problems down further and further to figure out where the issue was occurring. I learned how to create protocols for users to self serve and how to iterate on them when problems inevitably came up. I learned how to teach others how to debug their own problems and when to ask for help and when to continue working it themselves.
These are all skills that come in handy when solving data problems (or any problem really). When I then moved on to my first real data job (Concert Genetics) I was working with a whole new complex system (web scraping and nosql databases and redshift) and those troubleshooting skills all came to bear in multiple dimensions. It's useful for learning new tools, systems, and processes as well as figuring out how to solve problems when they arise.
To solve a problem you must first find where it exists! And to answer a data question, you must first find the data - and then continue troubleshooting it until you get an answer.
So maybe it's a bit of a stretch but I come back to this skill regularly. :) Good question Stephen!
I was a double major in Computer Science & Math at a small liberal arts school. It's kind of hard to pick out any one way in which those helped me in my career because I feel like everything is useful -- the amalgamation of everything I learned, every experience I had, is a large part of what makes me, me. I can definitively say though, that Graph Theory was my absolute favorite class and I'm so happy to see how the practical implementations of it are part of our everyday lives now. If I had to pick a most useful class - I think I'd go with Statistics because of the way it teaches you not just how to work with data, but how to question it too.
Being at a liberal arts school, you have to satisfy a lot of requirements in taking classes across a wide array of fields, from the arts, to literature, to language, to science & engineering, etc. In hindsight, those classes outside of my majors were just as valuable as the CS & math degrees to my career, and even more valuable to me as a human being. They exposed me to different ways of thinking, different types of people and viewpoints, different forms of communication, and above all, empathy. I think a lot of us are guilty of (myself included) focusing too narrowly on how we can become the best, most technically sound individual out there -- but we often lose sight of the (non-technical) human in the loop -- which I think many would argue is one of the biggest gaps we have in the MDS space right now.
Others have touched on this in their replies but I'll echo the same sentiments that what's been most valuable is learning how to think, how to communicate, how to ask questions. Learning the HOW, not the WHAT.
I have the same feeling about the non-core classes in liberal arts education -- I still use literary references, geographical knowledge, etc., in conversation and when reading popular culture. Very much "shaped" me.
Also -- shout out to graph theory. Still surprises me how few graph metrics float around the data space, given all our gnarly dags.
I’m not going to write anything constructive here, but I would like to add that it is a long time since I’ve seen such copious amounts of bait in an article’s first paragraph. :)
I'm not above clickbait! Haven't put it in the title yet, but I can only fight for so long :joy:
I studied Political Science, and got a Master's in Public Service Administration. I did learn some hard skills from those programs: Statistics using STATA and R, understanding types of analyses (Cost Benefit, Risk Assessment), a high level understanding of Economics, and a high level understanding of how people studied management academically.
But really what I end up valuing most from my schooling is being primed to understand systems thinking, and how the skill shift between evaluating building a bridge and building a feature isn't huge, what's really hard is understanding the different contexts in which the things being built are going to affect the people who could be using them.
Were you explicitly taught "systems thinking", or was it something you picked up organically by studying different systems -- organizations, economies, political systems, etc.?
it would be the latter!
I was a finance major & was originally set on pursuing a career in investment management. Not long after graduating I decided to pursue a career in data instead. Leveraging my background in finance helped me get my first data role as an Investments Data Analyst. My technical skills at the time were not the best but because I had the domain knowledge it helped me land the job.
Domain knowledge is very important in any data career. It makes it a lot easier to communicate with data adjacent roles and stakeholders within the company & better understand the problems they are facing. There seems to be a trend with data roles that are embedded within specific business units (Marketing, Finance, HR etc). All these areas have their own unique data and problems.
Having the technical savviness and domain expertise can make for a very successful data career. It also makes your work a lot more interesting if you are dealing with data in a domain that interests you!
Good call on the domain expertise! It's easy to forget, especially with all the hype around tooling, how impactful deep subject matter expertise can be.