#55 Getting Your First Data Science Job

Hi, I'm Maggie, VP of Curriculum at datacamp, and I know firsthand how overwhelming it can be to keep up with the rapid changes in data and AI. But staying ahead doesn't have to be hard. That's why our curriculum team has curated the best learning content to help you and your team stay ahead, covering everything from data and AI literacy for busy executives to cutting edge generative AI for developers, and everything in between. Whether you're upskilling yourself or your team, we make learning practical, engaging and flexible. It just works. Power your data and AI transformation journey on datacamp.com.

This week I'll be speaking with Chris Albon about getting your first data science job. Chris is a data scientist at Devoted Health, where he uses data science and machine learning to help fix America's healthcare system. Chris is also doing a lot of hiring at Devoted, and that's why he's so excited today to talk about how to get your first data science job. You may know Chris as co host of the podcast, partially derivative from his educational resources, such as his blog and machine learning flashcards, or as one of the funniest data scientists on Twitter. Welcome to Data Framed, the weekly data camp podcast exploring what data science looks like on the ground for working data scientists and what problems it can solve. I'm your host, Hugo Bown Anderson. You can follow Datacamp on Twitter @Datacamp and Megobown. You can find all our episodes and show notes@datacamp.com Community Podcast this is Data Framed.

Hi there, Chris, and welcome to Data Framed.

Hey, how's it going?

It's great, man. How are you?

I'm good. This is like one of the first podcasts I've done in a while. This is like I stopped my podcast and now I've gone on a few ones, but then I had a kid and I did a move and that kind of stuff, and now I'm back, back on the podcasting circuit. This is it.

Fantastic. How long's it been?

It's been like, you know, so my, my kid is 2 months old, so I think I did my last podcast like two months before that. So it's been four months without.

Right on. Well, congratulations on the new member of your family.

Thank you. Thank you. She is doing great. All is well.

Awesome. And congrats on the new job and the move. There's been a lot of change, right?

It's been a lot of change. There's definitely been a lot of change. I feel like it's one of those things where I have a very hard time saying no to dj. So when he does think that you should come do something, you have to think really hard about whether or not you, you want to say no to him. Which I've said no to him in the past and I could not say no to him this time. Thus, I'm with DJ on a crazy adventure.

And so this is DJ Patil.

This is DJ DJ Patil, former chief data scientist of the US former head of data at LinkedIn. I don't know his whole resume, but a well known, well known person in the, in the data science world.

Very well known, very well respected, doing a lot of interesting work at Devoted and Otherwise as well. I mean, his recent series of articles with Michael Kidis and Hillary Mason around, kind of forming a conversation around data science ethics is really interesting as well.

Yeah, I think he's doing a lot of really important thinking in a space that we're still figuring out. I mean, this was something that I think a lot of us have been talking about sort of off and on for a long time of like, hey, we don't actually, you know, we have lots of goals for what this field can do, but what does that actually mean in practice? And the more we get to do that and the more that people sort of carve out space in their workday to say, hey, I'm going to think about this topic, I'm going to produce something that other people can read and agree with and disagree with and use as a point of discussion or build something off of is great. And I hope you he does it more and I hope Hillary does it more. And I think more people should spend a little bit more time thinking about that. And it's part of it. That was nice to go work for him because it is sort of nice to go work for someone who's thinking about that kind of stuff and really is big on ethics and is big on trying to use technology for social good. Because for people on this podcast, my background is not in business. I have started a, a startup, but my main background is nonprofits, humanitarian nonprofits. I work on data on humanitarian nonprofits, did that for most of my career. And so to work for a team that's led by someone who spends a lot of time thinking about how to build companies with a soul was very refreshing.

Awesome. So maybe you can start off by telling us just about Devoted in general and the work you're doing.

Sure. So Devoted, a health insurance company that was started by Todd and Ed park, who Todd park was the former CTO of the United States and Ed park was the CEO of another health insurance company or another healthcare company before this. And what Devoted tries to do is, tries to frankly, like, create a health insurance company that you would want your own family members to be at. It is, it is a company, it is a startup, operates exactly like the startup, is funded exactly like the startup. I think there's, there's areas that would set it apart from the startup, but I think overall you would look at it and be like, yes, this is a startup. However, Devoted is on a mission. We are trying to make healthcare that works, that works for people, particularly right now, senior citizens. So we work on Medicare. If you don't know Medicare is the health insurance, the government health insurance program for senior citizens. That is what Devoted is focused on. That's sort of what we consider ourselves as a, as a Medicare company. But on the daily basis, if you work inside Devoted, you can see that we are trying to build something that would be a company with a soul. A company that's trying to do something real and trying to do something that matters in people's lives and do right by people and is hyper compliant with the law and do more than just simply profit.

Awesome.

That was what drew me to do it. I think that's what draws a lot of people to Devoted.

That's great.

And as we'll discuss, you're working a lot on hiring at the moment. And what we're going to talk about today, among other things, is people getting their first data science jobs and advice for such people, how it works, what it looks like from your, your side of the conversation as well. And I think particularly at this point where junior data science parts aren't necessarily fleshed out, we're starting to see a bunch of specialization in the industry. These types of things will be incredibly important going forward. But before we dive into that, I just want to get a bit more background about you. And if you could tell me, like you said, your, your background isn't necessarily in data science. I'm wondering how you got involved in data science in the first place.

My background's in quantitative political sc, Political science, studying of politics. I studied civil wars. But it's political science from completely from the perspective of statistics, of quantitative research, of experimentation rather than qualitative work, interviewing people looking at historic documents, that kind of thing. And when I was getting my PhD, I kept on having drinks with these people in San Francisco where I was sort of living at the time, and they were working at places like LinkedIn. So there was DJ and this number of other People and they were doing such cool applied stuff. So many, you know, amazing projects, amazing uses of data in a very, very applied way. And it was about then that I kind of decided that if I really wanted to have a real impact and really wanted to do something that would matter, that I needed to not be in academia. I needed to go out and actually apply the skills in a way that was beyond research. And don't get me wrong, I love research. I every single person who applies for devoted, who has any kind of PhD, I just want to talk to them about their PhD all day. I think, you know, you know, that's a, as a bias of mine, but there's so many ways that you could apply it. And then at the time there was some chances for me to go work for some joint Kenyan US nonprofits, Kenyan nonprofits, that kind of stuff. And I spent a number of years working, being sort of the first data hire over there at say, Ushahidi, which is a Kenyan nonprofit that works on election monitoring and disaster relief. Went to go work for bric, which is a Kenyan startup that works on providing free WI fi to lower income people in Kenya. Frontline SMS did a lot of work around election monitoring. But you know, taking data, real data, about say, say an election in a country with an authoritarian leadership and actually seeing like, is this data true? Are people filing in fake, you know, are people filing in fake elections? Are people filing in fake reports? Like what is actually happening on the ground with real data with people who are in places where they can get arrested if things go wrong? You know, that was a big eye opener to me around issues of safety, around issues of ethics, around issues of like, for example, if I go to a place that has election monitoring and we're running an election monitoring campaign with a local ngo, if the cops bust down the door for some reason because something happened, I would be arrested and then flown back to the us they would be arrested and God knows what would happen. And that means that our threat models are very different. And sort of understanding that your threat model isn't their threat model, I think has a lot of applications for data science in the US and everywhere that I think it was an important lesson for me.

Absolutely.

And I have a question around. Just it seems like on this type of work you'll learn a lot on the job, both in terms of domain expertise, but also in terms of data scientific techniques. I'm just wondering, before you got your first data science job, did you know how to program in Python or did you have an idea of what the landscape look like from your time in research.

Where I was when I was finishing up my PhD was I had done some web work. So I'm not going to say web development because it wasn't a lot of JavaScript and that kind of stuff, but I'd done like HTML and CSS which aren't really programming, but just, you know, that kind of stuff, like making some web pages with a little bit of JavaScript in there and that kind of stuff. And I done all of my research in Stata and R, but I wasn't very good at it. I think my code was very poor at that moment. But I did see through my conversations with other people that there was this world of coding wasn't just a little script that you run and leave your laptop, if it needs to run for more than six hours, you just leave your laptop open for six hours. I realized that there was much more into the world of software engineering and I started to move in that direction because when you want to build stuff with other engineers, it's nice to use the tools that they use and to think about things that they use and to take code that they can insert into their, into their projects. And so I really started to push more along the lines of developing more software engineering skills, more languages that are pretty common in software engineering, such as Python. But I definitely, when I left my PhD, I was not the wizard programmer that I'm not today, but I could be today.

I love that. So I usually ask a question around what your colleagues think you do as opposed to what you actually do that might be slightly different in what you do. Devoted people may have more of an idea. I think historically though, in terms of the startups you've worked in doing analytics and data science, is there a mismatch between what people think you do and what you actually do?

I think people. So we'll take Brick. Brick is a Kenyan startup that does free WI fi for low income people. The whole team is Kenyan, they are based out of Kenya. And I was the first data hire at Brick. I think a lot of them thought that I was doing wizard mathematics. Like, you know, there was a whiteboard in my office and I'm writing equations and solving riddles of mathematics to get them some kind of thing where in fact what I was doing was a lot of of software engineering stuff, a lot of building functions, running things, cron jobs, like using a lot of Python or a lot of Pandas, some scikit, learn that kind of stuff. But I was mostly using established tools. But it would provide them with actually something that was useful in their work. But I think from their perspective I was like wizardry, right? Because I would do something like imputation where you take missing values in your data and you impute the value, fake what the value would probably be. And it was like wizardry, right? Like whoa, I can't believe that happened. Like you were predicting this stuff. And so I think it feels very normal to the data scientists and to me. But I think it felt very, it was very exciting for a team that didn't have that to start to have that kind of option for stuff. And I think it worked well.

Fantastic. So as we've said, we're here to talk about getting your first data science job and you're working on hiring data scientists. Devoted and thinking a lot about people getting their first data science job today. And I want to kind of figure out what companies are generally looking for when hiring first time data scientists. But before that I suppose, yeah, a preliminary question is, are a lot of companies trying to hire first time data scientists? Because a lot of the job listings like want 10 years experience of distributed computing and all of that jazz, right? So like where is, I hesitate to use the term entry level but for a first time job, are there, are there a lot of jobs out there?

Yeah, I think there are. Although from. So the perspective I think we could take this interview is that I'm sitting on the other side of the table where I'm doing a lot of the working with a team at devoted to a lot of hiring for our data science team and I talk to a lot of my friends who are doing similar roles at other companies. You know, so in the interview they're on the, they're on the hiring side. So there definitely are a lot of junior roles and I wouldn't put into someone's head that they're like junior roles are dying or everyone needs experience and that kind of stuff. There is something I definitely see that as a team you can absorb infinite number of senior hires. So say you have a team of six people, you can hire six new other senior people and be pretty okay that everything's just going to work because they're senior. Right. Like it'll do fine. It is much more of a risk from the organization's perspective if you have six people on your team and then you hire six junior because there's those junior people need a lot more support and if you're unable to give that support, it is not good for the junior people or for you. And definitely take this from the perspective of that junior person. Like, you do not want to be in a place where there is one senior data scientist and there's six junior people who are all hired at the same time because you are not going to learn what you need to learn. You want to be the one junior person on a team of six senior people. That would be the ideal situation. And you can just sit down and take all the time of them as you want and you can work with them very closely and your learning would be massive.

That would be incredible.

There's definitely junior jobs out there, but there is something from an organization's perspective where you might have a small startup and you only have three data scientists or two data scientists at this company because data science is a specialty job. And you just can't, you can't have a posting that says you want to hire five junior people. Like, I wouldn't. Don't apply to that job. I think that would be very horrible.

Yeah.

Instead you want somewhere. I think if I was looking, if I was junior. So one thing we should point out that when I was junior in data science, it was a very different field. So you should not take my how I got into the field as an example of how you should get into the field. Because when I started there wasn't really the concept of data science and you was sort of a bunch of people who are interested in the same topic and just sort of like got together.

Yeah.

And doing it, doing it. Now it's a little, it's different obviously, but I think I can see some things around if you are, you know, if you're looking for that first job. I would definitely look for places in mid to larger companies and not in smaller, smaller scrappier startups. I think one of the things that I've found a few times during the hiring process is that people who got their first job at say Facebook and they're a junior data scientist at Facebook, there's so much more support that they got in that time for learning, for experimentation, for using things at scale, like learning how to work at Facebook scale, but doing so as a very junior person, they have such great experience that then they move on to say, you know, say apply for a job at Devoted or something like that. And they have all that experience and we can use that experience. Like, that's great. You're awesome. Like, cool. You have this great experience. This is hard experience to get because, you know, it's hard for a boot camp to say replicate 50 million messages a day that you have to Process or something like that. That's a weird boot camp project, but that is what a lot of companies end up doing. So going to somewhere like Facebook or going to. I'm just like picking up Facebook and this isn't an app for Facebook is interplaying. But any kind of larger company that can absorb, can absorb you as a junior hire and like allow you to learn and allow you to learn from really senior engineers and then moving on to something else is I think a great perspective for sure.

And those companies I think have the infrastructure all set up as well. So you're not like battling with your data lakes and airflow and all of that, right?

Yeah, there's absolutely a trap that I think junior data scientists fall into, even mid level data scientists fall into where they join a scientific small scrappy startup. Not as a founder, right. But just, you know, the startup is six people or something like that and they're the first data hire. And there's no data infrastructure in place at all and there's no safety nets. There's no, you know, ability to get data from the database in a way that's useful and you have to sit down and build all that, which in certain times can be okay. But I think in a really scrappy startup where they're like struggling to make payroll or, you know, they're like grinding away or something, something, it can be a very, very hard experience and probably not the best experience as opposed to something where you had, you know, you go work at some really hard problems at a larger company, but you do so in a way that you can leave work at the end of the day and you know, knowing that everything's fine and then you come back the next day and all that infrastructure is in place and I'll have talks and lectures and you can go over to some person who's done data engineering for 10 years and say, hey, why does it work like this? And they'll be like, oh, it's because of X, Y and Z and that kind of stuff. And so I think there's just, there's so much learning that can happen at larger companies. I've never worked at a larger company, so this is me talking from the outside. But I do think that as someone who's worked at a few smaller companies or smaller organizations, that if you, those organizations do better, if you're senior, just because you can sort of be left alone and figure everything out by yourself because you've done this before as opposed to actually, I don't know what I'm doing. I really need someone to tell me how to do it right. And so you learn things the right way. I think there's a lot of things where, like, particularly where a data scientist is doing more software engineering stuff, where it's really nice to sit down for someone to be like, hey, explain to me object oriented programming because I don't understand what in the world's happening. Or explain to me like how testing works, like unit tests, integration tests, or you know, patterns like software engineering patterns like factory of factories and that kind of stuff. Just tell me about that. Like all those are totally simple concepts that anyone listening to this podcast can know. Just need to like have someone tell you about them or know that you should read about them. Like understand that. Oh, actually this comes up a lot. I should read about this. That kind of stuff, which is great in companies with more support and is terrible in really, really small, scrappy places.

So in general, what are companies looking for when hiring first time data scientists, do you think? And if you don't want to answer that, you can tell me like what you in particular are looking for when hiring first time data scientists.

Sure, I'll try to stab at the one, but then we'll definitely hit on the other one. So it depends on the company. I should say organization because I worked for a lot of nonprofits, but we'll just use company as like a filling gap for that. Places that are very small and scrappy tend to look for senior people that they can run the whole like I think you would call them like a full stack data scientist. I'm not entirely enamored with that phrase, but whatever.

Like a generalist.

A generalist so that you could, you could just have them join the software engineering team or the product team or something like that, and you give them pseudo access on your, you know, on your server and they will just build everything they need to build. They'll build all the pipelining, they'll build all the, you know, saving backups all the data. They'll build the tables that they need to build. Then they'll run the analysis and they'll run it in a way that runs every single, you know, every single day, but only on, you know, certain times. And they'll install airflow by themselves and they'll do all this kind of stuff that just, they can, they can do. That's awesome for that person. That's not really a junior role no more. I think if you go to the other end of the spectrum and you go for large companies, they do a mix. Well, they will hire people from more senior positions to do things like say, someone very specialized, say someone who just got their PhD in AI or something like that. Like, they might have them join the team that's working on an algorithm, and that junior person can work on a part of the algorithm or work on some testing part and grind through that kind of stuff. Or I think what's very common is more generalist data scientists who are junior join larger companies and they do probably what I would would call like advanced analyses or advanced analytics. Right. So you have like a new product, and you want to understand how that product is actually doing at scale. Right. Because it's, you know, deployed globally on all Android devices or something like that. And you want to see how that product is working and how people are using it. There is some very, very complicated analyses that need to be done for that to be true. And that is a great sort of thing for a junior person to kind of tear off and start working on. And it doesn't affect the production code, but it does affect the business.

And in that respect, I suppose we're talking about the data analyst breed of data scientists, right?

Yeah. And so again, I don't know why I keep on talking about Facebook, but I know at Facebook a lot of people who have the title of data scientists do more analysis, which is totally reasonable and is super hard and given massive credit. And it is. That kind of stuff is a real role. It's a real job. And I think people who come from academia, you know, like people who I know come from sort of political science, social scientists, they go into those kind of roles and have a great time because they are working on hard analyses, like hard analytical problems. It's not. You're not making dashboards to show that someone's clicking on something. You're making really complicated analyses to figure out, you know, the churn model that applies Bayesian to one. You know, we all. That kind of stuff, which is cool, I think, in the middle, right? So you have the teeny companies and you have the large companies. You have companies like Devoted that sort of sit in the middle where there is a mix between trying to hire senior people who can craft the foundational data science infrastructure. Right. So Devoted is building a health insurance company's tech stack from scratch. You know, like it was at one point an empty GitHub repo. Now there's. Now there's a lot of code in there. But yeah, at some point we're like, okay, we are a health insurance company. This is our code base. Like, let's write the first line of code. That's where we are. And in those kind of environments you want a mix of people who are senior who can build the architecture for how things work and how data is moved around and how say tasks are run every day or how there's, you know, things around testing and if companies do testing and all that kind of stuff. And in addition, you want people who have more junior experience that you can come in, you can provide some, lift them like teaching wise, like you can do more teaching with them and you can have them support the role where you might tear off a piece of a project and say, hey, can you make this for me? Like so I don't need, so I don't need to make it because it was definitely so. One of the people who's on our team currently is Kate Rodolpha, who is the former chief data scientist of the Hillary campaign. And he's done some amazing complicated work and he's also done some amazing work that was well below his level of expertise because there was just no one else there to do it. And so there's, I think typically mid level companies like ours tend to have both. Some are longer range.

And so for you, for your size of company, what would a, for a junior data scientist, what skills would they.

Or what would be good qualities? What would they need to do or.

Demonstrate for you to be like, hey, this person would be a good fit here?

Yeah. I think for us at Devoted, we are a health insurance company, but if you looked at the internal workings of how the tech team works, we operate far more like a Silicon Valley tech company. And concepts of move fast and break things or ask for forgiveness rather than permission are real things that we are doing. I think a lot of the people at Devoted are building things that is the largest and hardest thing that they've built ever in their career. And that's what we want you to be. That we want you to be the person who is building the, doing the best work of career, doing the hardest thing, that is pushing yourself right to the limit of what you think you can do. And we have a very strong culture that says, hey, we want you to run right up until the point that you break the, break the thing and then come and be able to say, hey, I totally broke this. Can someone fix this? Dear God. And then we'll go back and we'll work with them to fix it. And I say this as them, but like I have in fact broken many things at Devoted. And to have a culture that says, hey, you can break these things. It's okay, don't worry about it. You should definitely admit that it broken because we should know that. But run right up until you break it, then we'll talk about why it was broken and we'll then run again. Like don't stop running, keep on running. But that fast paced, the fast paced doesn't translate into a huge amount of work hours because, you know, devoted, like I have a family and no one's, no one at devoted, I think is grinding the midnight oil left, right and center. There's definitely, people are working, you know, 9 to 5ish, but just, you know what you're doing. I think there's a lot of pushing the boundaries of what we can do skill wise right to the end and a lot of learning and trying to build the things that are the limit of our capability is pretty common. And I think that would be a skill regardless of your expert, you know, level of experience, whether you have one year of experience or no years of experience or 10 years of experience. We really do look for people who are very happy to take on a task that they've never done before. But they're pretty, you know, they kind of understand how they might go about it and go for it, like go and run it. And we have safety guards in place that nothing's, nothing's bad going to happen, that they can push themselves. And then once they have that, once they've built that thing, they go, okay, cool, I understand it now. It's great, I've got it. Like, let's do something else. Like, let's go harder, let's do this, build the next thing. I think that's really, it's hard to instill because it is not experience per se. It's more, you know, aptitude and attitude is probably a closer one where I don't necessarily, we don't necessarily say we're only looking for people with X ears. We tend to have a willingness to say, hey, you're actually, you know, like we were kind of looking for someone more senior, but you are more junior. But you really are kicking butt. And we can see that when we talk to you that you have a lot of aptitude for your level, like for your levels of experience. And we love your attitude for running with it. Like, let's go like, come on board. Yeah, we've definitely, you know, we've had a few hires like that and I think it has worked out. But it is, it is something, it's not uniquely devoted, but it is something that is probably pretty uncommon for our industry.

Yeah. And that speaks to certain skills that you've mentioned in there are being like an active problem solver, communication, having a passion and drive.

We'll jump right back into our interview with Chris Albon after a short segment. Now it's time for a segment called Guidelines for Online Experiments. So I'm here with Emily Robinson, a data scientist on the growth team here at Datacamp.

Hey, Emily.

Hi, Hugo.

So, Emily, you've written what I consider a fantastic post on guidelines for a B testing, and you've also given a related talk several times.

And I'm really interested to hear your.

Thoughts on what kind of rules of thumb and guidelines for a B testing actually are. But maybe first you can start by just reminding us or what an online experiment or an AB test actually is.

Sure, Hugo. So the idea of an online experiment is that you want to measure the impact of a change that you make on your website. And how you do this is that you randomly assign people to either the control, so the old experience, or the treatment group, the new experience. And by randomly assigning people, you can then make sure that there's no differences between the two groups. So, for example, that people, the countries are randomized, that new and returning users, et cetera. And this is really helpful because another approach might just be to launch the change and watch the graph move and say, oh, okay, we launched this change on Tuesday. Did registration rate go up? Well, the problem is registration rate or your other metrics are not a fixed value each day they have their own variants. And you also have other stuff going on in the world at the same time, like say maybe there is a holiday or another project was launched. And that means that it's very hard to tell if one, if there was any movement at all and two, if that movement really was because of your change. And online experiments allow you to make that inference by giving you a control group telling you what would have happened without that change.

Okay, so that's a great explanation of.

What an online experiment or an a.

B test actually is. Before we get into the guidelines, though, there are a couple of, I suppose, technical terms that would be good to demystify. And I'm thinking really about test statistic and the scary P value.

Right.

So maybe you could just tell us.

How you use these in online experiments and then we can jump into your guidelines.

Sure. So let's say you have your control in your treatment group and you're interested in registration rate on your website, and it's 5% in the control and 5.05% in the treatment. Does that mean that your treatment was a success and you increased registration rate? Well, the problem is there is some randomness again in that there's variability. And it could have just been chance that this happened. You know, for example, if you flip a coin two times and it turns up heads, you wouldn't say that's necessarily an unfair coin. That could just happen by chance. So what I do is we run what's called a proportion test for, specifically where we're looking for the percent of people who did a certain action, a proportion test. Then we compare the proportion in the control versus the treatment, and not just 5 versus 5.05, but specifically, you know, is that 5,000 of 100,000 or 500 out of 1,000, because that matters. And that test gives us back a P value. And the definition of a P value is, if your null hypothesis was true, which in this case is that there's no difference between the control and the treatment group, how likely is it that you would have seen a difference this extreme or more.

Right. So the idea then is it's really, it has to do with how surprised you should be about seeing your result, Right?

Exactly. So statistics can never tell us, oh, we're absolutely sure that there was a quote unquote, real difference. But it can tell you a p value of 0.0. One would say, for example, okay, if there was no difference, only 1% of a time would you see the results that you got or results that were more extreme? So, you know, maybe you're that 1%, maybe there was no difference. But generally there's a rule of thumb that if your P value is less than 0.05, so there's a less than 5% chance of getting a false positive. If there was no difference, then we'll go ahead and say, okay, we are going to reject the null hypothesis and assume that there was a real difference.

Great. Okay. So that's a great introduction to online experimentation. You quote a great saying in your blog post, in your talk that generating numbers. So getting data for this type of stuff, generating numbers is easy. Generating numbers you should trust is hard. And you've written that there are many ways AB testing can go wrong, but most of them won't be obvious. So that's a brief introduction to or motivation for your guidelines. And we're here to start talking about best practices for AB testing. So what's your first guideline?

The first one is to have one key metric per experiment. So what that means is define what your Success metric is that doesn't mean that you can't monitor multiple metrics to make sure you don't accidentally tank them. For example, here at datacamp, we're a subscription business, and so while we might be targeting registration rate for a certain experiment, if suddenly subscription rate went to zero in the treatment, that would be pretty bad. But the reason we only want one metric is that if we're looking at many metrics, you'll end up with an increased false positive rate unless you apply corrections. What that means is if you say are looking at 10 metrics, the probability that one of them has a P value of below 0.05 is even if there's no difference, if your treatment made no change, no impact to your metrics is way above 5%. In fact, I think it's above 30%.

Fantastic. So that kind of leads into my next question. How long should you run an experiment in order to see an effect?

This is a tricky question because here you're looking to avoid false negatives. So thinking that there is no difference when there actually is one. And when you say see an effect, it really matters what the magnitude of effect is. So essentially the longer you run it, the smaller a difference you can detect. And how you can measure this or estimate this is doing a power calculation. So you take your key metrics. So say your registration rate, you figure out, all right, over a week, we have 10,000 people and their registration rate is 10%. You assume that's going to be roughly the same the week you're running the experiment for the control group. And then a power calculation can say, all right, with that much data, with that registration rate, how big an effect can you detect where there's an 80% chance of, if there's an effect of this size, you'll detect it. So for example, your power calculation might say, oh, in a week you could detect a 5% increase. And that means if your increase is only 2%, you're probably not going to detect it. And even if it is really 5%, there's still a 20% chance you'll miss it. But you have to make these trade offs because again, statistics can never tell you something definitively. And you may decide, hey, I'm okay, missing a 2% change because we need to move fast. And a 2% change actually wouldn't even be that impactful.

Right?

And I suppose one of the, the.

Point is you want to do this power analysis during the experimental design phase, right? You don't want to do a post hoc power analysis, for example, Right. In the best case scenario.

Exactly. And there's a couple reasons for this. One is you want to do it beforehand because sometimes it may tell you that you shouldn't bother running the experiment. So, for example, let's say you're making a change. You're like, all right, I believe this change could have a 10% increase in registration rate. And you run a power calculation and it says in three weeks you could only detect a 30% increase because maybe you just, just don't have that many visitors on this part of the site. And given that you may decide that you don't want to run this test after all.

Perfect. So, Emily, that's all we've got time for now, but I really look forward to coming back and hearing more about your guidelines for online experimentation.

Thanks, Hugo. Looking forward to chatting more about it.

Time to get straight back into our chat with Chris.

How about in terms of hard skills, whether it be domain expertise or background in programming, whether it's Python or R, or knowledge of how the math behind machine learning models actually works to data analytics skills.

Yeah, I've noticed something with hiring where typically when we have someone in the hiring process, I will say to them up front that there are places like if you just got your master's degree in machine learning and you believe that how you are going to advance your career is to do machine learning, become an expert in machine learning, that's what you're going to do. That is a completely valid job, like career track. You should absolutely do that. Also, that isn't a place like devoted. Devoted tends to be more generalist builders who are trying to, you know, we will, we'll use machine learning here because it's useful and then we'll use, you know, fuzzy matching here because it's useful. And then we'll, you know, like use some simple things somewhere else because it gets the job done. We tend to focus on the ability of people to build and solve the needs of our internal users more than say, someone's really nuanced view of machine learning algorithms. Just because we are a small team in a new company, if you wanted to just do machine learning, there are definitely companies that are big enough that have the infrastructure to have you just do that. Someone else will worry about, you know, some of the analytics or some of the data processing. You can just sit down all day and read machine learning journal articles and then implement them. That's totally okay. And you know, if you. I think I never worked at Google Brain, but I imagine Google Brain has a strong feeling around that, which is cool.

Would that be your advice to first time job seekers? Learn a bunch of general things in order to build stuff as opposed to go deep into machine learning models and all of that.

If I was sitting in somewhat in front of someone who is taking or looking at a junior job or something like that, I would say that you probably want to take one of two tracks. One, if you have the educational experience on paper and the credentials to go for say deep AI that just go deep on AI like you have, you have the master's degree in it or you have a PhD in it or something like that, go for that track. Like that's an amazing. It's incredibly high paying, it's super in demand and there are places where you won't have to learn anything else. But ML. That can be a career and I think there's probably going to be a full career in that and there's absolutely no problem with that because those are very, very hard. And by AI, I would almost exclusively say neural networks at this point. There's a lot of companies that are doing things that are self driving cars or things like that where you just, you need a lot of people with that kind of knowledge to work on those problems because those are incredibly hard problems. But it is definitely along the lines of neural networks, I. E. Deep learning to do those.

And for this track there is a certain mathematical overhead which perhaps the other track we haven't got to that yet may not have, but for example, knowing enough about multivariate calculus to understand backprop and the vanishing gradient problem and all of this stuff, right?

Oh no, absolutely. And I would expect that the interviews for those would be very math heavy and very theory heavy, such that it would almost feel like, I don't know, like a dissertation defense in that area for that track.

As you said, you'd expect some sort of. Of graduate work to have been done in math or something related.

Yeah, I would expect like 95% of people to have some kind of like very obvious that they're going down that track. I know I'm sure there's some people who have like gone around that and those people are awesome and amazing. But I think typically you would expect someone to be from that perspective. The other one, if you don't have that like very obvious sort of machine learning, deep learning focus, which I don't. So this is more my perspective. There's another field that is way more sort of doing data science more generally at a company. Right. So instead of just being like all I do is machine learning all day. There's so many other problems that need to be solved using data science. Whether you do like Bayesian analyses or you do some kind of random force, or even if you use some deep learning stuff, but you're not doing cutting edge deep learning stuff all day. There's so far more jobs. Although the hype and the focus is on the sort of AI jobs, there is far more jobs, like 50 times as many jobs of people who are semi generalist data scientists at companies. Solving those companies needs to understand what's happening in their data. Whether that's predicting when their drone should fly over and water the crops, or predicting when a customer might return. Or you know, for us like predicting when someone might have a particular illness so we could do an intervention and prevent that illness from happening. Those kind of analyses fit better for people who sort of have a more general experience because there isn't a very type for that. Right? There's no Bayesian analysis PhD. And if you have that, you get to do Bayesian analyses and if you don't, you don't get to do that. It's much more general. So that the people who apply for us in those kind of roles can come from any perspective and can be everything from a music major, or can be Someone with a PhD in data science and one of the new programs, or can come from a boot camp, from a PhD in some other crazy field, or could not have a PhD. It's more about just if that kind of person fits what we want and what we need. But it is, I mean that I think that's where most people do it. I say this only because I think there's a lot of people who think if I know enough machine learning and I go deep enough on machine learning, I'm like, that's the guaranteed job. Which isn't true because you could self teach a lot of machine learning and then you apply Google Brain and they could be like, hey, you're just not even close to. Because you didn't get a PhD in this and haven't spent a huge amount of time doing that. But then you could go to another company, take that same person and go to another company, say hey, I know a lot of machine learning. They go awesome. This is like you're not going to just be doing machine learning. But we have need for people who know machine learning because our products use natural language processing and that kind of stuff. Come on, join the team, you'll be great. And so I think that second job has a lot more generalist things where you end up working, you end up sort of having to be, you know, a lot more software engineering skills, a lot more, you know, skills working with sort of the software side of skills of working with like internal customers. So say someone on the sales team wants some kind of particular analysis. That analysis is very difficult to do. You go back and you do it, but then you have to go and present it to away and then work with them to tweak the analysis in the way that they want. You need to be able to work with them such that they're happy with what you're delivering with them. That kind of stuff I think is more common. I think that's what most people do. It's also, it's different than just saying, hey, I'm just going to know everything about machine learning and then I won't need to care about any other topic.

And so for this second job, which I think is kind of the lion's share of what we're discussing today, there's a chicken and egg problem in the sense that for a first time data scientist applying for their first job, how can they demonstrate that they have kind of this general array of skills? Would it be project based, like writing a blog themselves to demonstrate it? Because it seems like you need the experience in order to get the first job. Essentially, yeah.

For us when someone applies, some of the best things that they can apply with are projects that they've done or you know, something at like say a boot camp or maybe their, maybe their dissertation research or something like that where we can take a look and say, oh cool, like you've done some interesting stuff, you've worked with some data, some interesting ways. And then for us we have designed a take home that is very, without giving out any kind of secret to the take home is very open. So there's many, many ways, I mean, there's an infinite amount of ways essentially that someone could solve it. And how they solve it really says a lot about them. But those kind of skills of being able to demonstrate, hey, I can write software, I can write unit tests, I can sit down and do Bayesian and I'm totally comfortable with it. Here's my blog post around how this certain type of Bayesian analysis works in this setting. Or here's this really sweet data visualization that I did, that kind of stuff is like a nice demonstration. I don't think it's required, but I think if you come from say a field that isn't known for making a bunch of quantitative people, and I come from political science. I think people don't think about political science and think we're all math nerds. The more things that you can do around that, where you can sort of demonstrate that you have that kind of experience is better because otherwise you don't hit people's biases around what a social scientist is, right? Because someone can say, oh, you do political science, you must really love Kant and Rousseau. And that's all you talk about all day. And if that's not true, like, you need to demonstrate that, it's probably not fair that you need to demonstrate that, but that is just what it is that you need to demonstrate that. And so things like boot camps, things like projects that you can run, your own blog posts are great because it's really easy to access them. Like you can just click, you know, like someone has a link in their resume and then you click the link and you say, oh, cool. This is like a really nice, you know, I love the way that they're thinking about this particular problem of feature importance in random forest or something like that is a really nice way and I think it is helpful. We don't require someone has side projects, but we are trying to do filtering of thousands of candidates. And so it's nice to find people who have, who can show you right up front that they have those kind of skills and can do so in a way that is more than just a resume line. Because as someone who's looked at a lot of resumes, everyone says that they do every skill under the sun. Like everyone lists every skill. So everyone says Python and SQL and R and machine learning and random forests, and everyone says every skill, which is like, so it's not a very strong signal. But if you also have, say, a blog post about some nuanced point about random forest or some nuanced point of Bayesian analyses, that is a real thing. That's a costly signal to me that you actually do know that rather than just typing in the word in your resume. And it helps, I think it helps for me to get a handle on who that person is. It helps to guide interview process in the future that like other people do, and I don't do that, I can sort of say, hey, like, here's this article from this person's blog that probably will be a subject of an interview, which is totally fine and probably helps the candidate a little bit because they can sort of stay in the area that they know, but it is demonstrations of that are very helpful. Do I think everyone needs to do side projects left and right. Otherwise they're a crappy data scientist. No, of course not. Like this isn't, you don't need to live and breathe data science to get a job in data science, but it is helpful to someone who's hiring to sort of see the things that you've worked on and see the things that you've done more than just adding that keyword to your resume.

And I think the other thing that writing blogs demonstrates is, is the ability to take a project through to the end and actually do a write up. And on top of that demonstrates communication skills which are of course incredibly important in this line of work.

We had one candidate who I really, I really liked. They ended up taking another job somewhere else, but I really liked. And they sat down and they actually had a GitHub project that they were working on. I don't think it was like a full Python package yet, but they had basically built an open source library very close to one. I don't think they had released it but they had like a little open source library for some project and they had testing in there and they had documentation and they had, they had object oriented Python in there and they were importing like relative imports of modules so they could do the tests and all that kind of stuff and it was cool. Like you could look at that and be like, okay, I kind of like this person has this level, right? This person has this, this amount of knowledge because they've clearly written it in their own GitHub account and I can see it, it's a nice signal for me. You could do that anyways, there's no particular way that I like, absolutely want but I think the resumes that are send the least signal to me or other people who are hiring on devoted are the ones that have just here's the five skills that I have. And then kind of don't do any kind of explaining because there's a lot of like cheap signals. Like you could, I mean I could say that I do deep learning and then you're like oh really? Let's talk about that. And it turns out that I do not know enough about deep learning.

Right. And the other thing you mentioned in there, there are a couple of other points which GitHub repository I'm sure is incredibly helpful. And on top of that you mentioned testing and a through line through this has been the importance of at least basic software engineering skills in terms of data science. And I find that that's something that's missing with a lot of kind of early career data analysts. And data scientists, whether it be using debuggers or unit testing or versioning, these types of things, people need to work on a bit more.

I think that's key. If there's anything that goes through our data science team at devoted when we are looking to hire someone or when we are working on our own projects, is that the stuff that we work on, on our products? We are building full products for people, whether they are only a few lines of code or you know, say they're something simpler like moving some kind of data from a Google spreadsheet to redshift, just something really simple like that or something more complicated. We are building full products, products for people and thus they need to have as much of that as we can have. We want testing in there, we want things to be say, linted. We want things to follow some kind of, of object oriented notion or say functional Python with the doc strings in there that describe all the documents are doing say static typing. If we could do that. We're seemingly on the verge of doing that, but not doing that yet. But that kind of stuff, like we think of that as a software product. We make software products for people. Whether that's, you know, whether it's actually like a reusable tool or analyses, that's just what we do. And I wish I thought about that more from the start. And I think as data science matures, I think there's definitely going to be this movement in the direction of data scientists sitting on software engineering teams and being a member of a software engineering team just with a certain specialty set of skills. And part of that means that you need to be able to work with them and write code that they can use and write code that they are fine to incorporate in their stuff. And that just means more software engineering skills for sure.

And so something that we've thrown around a bit is this idea of graduate school and dissertations. And a question I get a lot of is from people who are thinking of going to grad school and they're actually wondering whether to go to grads if they want to work in data science, whether to go to grad school or whether to get like a data analyst job that they can get at that point and then try to progress into data science demonstrating that they have developed a bunch of analytical tools. Do you have any thoughts on that from your side of the hiring table?

Sure. I would never recommend someone get a PhD. I mean masters might be different, but we'll start with I would never recommend someone get a PhD because they wanted to Get a better job. Like, a PhD is a long and difficult process and you got to really.

Want to do a PhD in order to do a PhD.

My PhD, like, a huge amount of people quit. Maybe like half or more than half of people quit along the way and got nothing right. Because if you. A PhD can be six years long. If you quit after year three, you don't get anything. I think maybe they might give you a master's as like a sort of a consolation prize or something like that. But, like, it is a very, very tough activity and it's very, very hard. And most people don't complete it. And people have a lot of stress around it and is difficult.

And the final year in particular, I just remember my PhD. The final year was absolutely brutal. I don't want to say I hated the work I was doing, but there was certainly at the end a bunch of negative sentiments that involved, you know, the stress and the suffering and also the sleeping under my desk for the final six months, actually.

Oh, yeah, no, complete. I hated my dissertation by the end. I mean, I. Yeah, the phrase that I kept on saying over my mind is that the only good dissertation is a done dissertation just grinding through and like. But it is worth it because I got to spend five years studying a topic that I really, really cared about. And I got to go as. I mean, imagine being able to go. I mean, you don't need to imagine, but like, if you're interested in PhD, imagine being given five years to go as deep into a topic as you could possibly go. Like, there is no level of deepness that is. Okay, keep on going deeper over and over and over again. And that is interesting and super cool. And it's a. It totally changes your thinking and it totally changes you as a person. And it's not a good way to get it, like, as a stepping stone to getting another job. It really just isn't. You could have much better spent that time doing other things that are directly related to getting an interview than going off on some crazy quest to study some amphibian in the whatever in the South Polynesian Islands or something like that? Like, there's definitely better ways of just getting a pay raise and, you know, more advanced stuff.

So is it a viable option to enter as a data analyst and try to progress to data science or.

So I think there's probably two tracks. One, if you can find the right place, you can absolutely go from data analyst into data science. And I think it more. It's about trying to find the place where there isn't a firm division between the two. Right. So like if I joined a larger company as a data analyst, as a junior data analytics, I would try to find chances where I could do more software engineering stuff. Stuff I would start to work on more complicated projects. I would try to see like, okay, cool, like yeah, sure, I can make this, this quick analysis, but can I do it better using Bayesian or something like that? Like you. But you sort of have to be self motivated to gain more of those skills. Another option is like a master's degree which could be one or two years and can expose you to a lot of that kind of stuff in a relatively quick amount of time. And then you get out and then you can, you know, I think you can do like a step up. Like we don't care around about education, like your education. We don't care about degrees at devoted. There's no requirement for some kind of degree. But there is lots of skills that people would learn, say in a data science master's program or any kind of quantitative master's program. Yeah, master's in mathematics or something like that that they could really take advantage of. And it can be a big step up for people to do that. And I think it's probably relatively cheap. I don't really know exactly, but I would either, you know, so you could either do the self learning path, which is you have to be scrappy, you have to kind of find opportunities where they are and move up through that and probably have to switch jobs a few times because the people hired you as a basic data analyst. And all of a sudden you're doing Bayesian left, right and center. And then you want to be paid like you're doing Bayesian work all the time. And then you go find another job that focuses on Bayesian and then you move up from there and then the other one is getting that master's degree and then going back and trying to find another job after that, saying that you've got this experience of that you know more about the formal training around some of this kind of stuff. And it doesn't help you with a lot of business cases, but it does help you that you can say you understand the problems around Bayesian analyses or the problems around some kind of machine learning model that then you can apply in a real way.

And if someone comes to you and knows these types of things, but doesn't necessarily know how it works in the health space, I presume a good strategy there is to say, hey, I know all these techniques. I don't know A lot about health, but I would love to learn about this stuff to demonstrate like a passion for the domain expertise. Essentially.

This is the first health insurance company I've ever worked for. We do a lot of learning around that, around that area where. So I remember, I think my second day at Devoted, they were like, hey, you should come to this meeting. And I came to the meeting and it's just four data scientists sitting in a room with a doctor explaining how medical coding works. So what is the code for someone who breaks their hip and how does that relate to the other code and how people are built on that thing? It's just a doctor who's sitting around telling us how all these things work. And it was so educational and it was so new that it's a big part of it.

Absolutely.

And I really like the way that this conversation has gone in terms of providing a variety of different paths from the machine learning to the first time data scientists demonstrating what they've done through projects or through quantitative research, through to the self learning approach. And for anyone out there who wants to take the self learning approach, I've heard that datacamp.com is an incredible place to learn data science. Yeah. It was actually Chris who told me that before we started recording, he was like, data camp.

That's it. I was just like, data camp. You got to use Data camp. No, no, no one's paying for you for this. I'm ambivalent. This is unsponsored.

Yeah.

And this is not sponsored by Facebook either.

Or Bayesian analyses.

Exactly. Yeah. Gelman. Gelman isn't paying us. Hey, that's a good, that's a good idea actually. So I'm wondering if there are any like, any advice things that you love people doing when they come into interviews or that you think are the worst things that people could do. Just any general tidbits of advice for first time interviewees from your side of the table?

That's a good question. I think for us. I'm trying to say us because I don't want to say it's just me because that's biased. Like that would be biased if I was just like, well, maybe actually. Well, this. We hire as a team. So it's not just me obviously hiring, but I'm the person that's interviewing. I will say what I, what I tend to like think rather than like us as a team because I don't know what they are biased towards. For me, I'm a big fan of people who are excited about learning new things and excited about data Because I genuinely enjoy what I do. I, I enjoy learning a new technique. I enjoy sitting around, around with a new book around some kind of analysis or an old book around some analysis that I don't know very well. And I really, really enjoy that. And I think when you're coming in as a junior person and you can sort of say, hey, I don't know how a lot of this stuff works, but I am really, really interested in what it is. And I know where I want to be in five years. And that involves a huge amount of learning. That is exactly what we want. Like, we are not hiring you because we're junior. We're hiring you because we think that you could be senior with some, some training, with some mentorship, with some projects and that kind of stuff. Like, we do not want you to be junior forever. We want you to be senior. And like, we acknowledge that the more we train you, the more you might leave. And that's totally okay with us. Like, come join devoted. Be a junior person for a while. Enjoy yourself. Like, learn a huge amount of stuff. Be really excited. What you do and then, and then go find a better job somewhere else is a completely reasonable, like, thing. That we don't have expectations that you, that you don't do that. But it is, I want someone to be excited about it. That excitement can come out in various ways. So people who have lots of side projects, obviously that's a signal that people use to be like, I love it in my spare time, but other people don't have a lot of spare time. So that can be one signal. But it's not the only signal we care about. If you just come in and are really, really excited about it, and I can tell that you have spent a lot of time thinking about it and you have a lot of knowledge around it and a lot of knowledge around it for what I would expect someone at your level to have. That's a nice sign that you really care about this one thing. You might not have knowledge around everything thing, but you might have this one thing that's like, I just, I think random forests are super cool. I spent a lot of time reading about them. Like, I don't know, deep learning. I don't know software engineering. I don't know anything except for, like, I'm just like, super interested in this one thing. Like, that's kind of cool. I, I think that that excitement bleeds off onto me, possibly onto other people who are interviewing, but definitely, definitely for me. Because if you can't get the job based on Your experience, which when you are more experienced, you could just get the job because you're experienced. You kind of need another strategy. And one of the strategies is just saying that you have the right attitude and you're excited to do it and you know, you can learn a lot and you could be a good member of the team that people want to work with. And that's a great way of doing it. If you, if you don't have the 10 years under your belt or something.

For sure you need something that differentiates you, right? A differentiating factor.

I understand that one of the hard parts for junior data scientists is that their resumes often look a lot alike because they go, one person went to a boot camp, someone else went to a different boot camp, someone else else, you know, like, was a math major, someone else, like did this mathematic project, someone else wrote one research paper. Like, you know, there's a lot of like, signals that are pretty much the same. And so the way that people can distinguish themselves, I think, at least in my mind, is having some enjoyment for what you do. Because we want you to enjoy it and therefore learn more at it, you know, learn more about doing it. You don't need to grind them, you know, you don't need to burn the midnight oil to do it. You could totally work 9 to 5 with the rest of us. But we want you to be interested in it. And if we every hire, now that I'm sitting on this side of the table, every hire is a bet. And for the junior person, the best bet that we could make is that we are hiring you and you don't know everything we wish you knew, but that in two years you could know like a big portion of what we wish you knew as a senior person. Right. Like, I mean, you wouldn't be senior two years, but you get my point, right? Like you can be so much more capable and so much more of a resource for the team. So we come in and hire you when you're junior and then all of a sudden you're mid level and you're kicking butt and then we try to retain you because we want you to stay there because you're so awesome. That part is like a big thing.

Yeah. And I suppose one thing I'd like to gauge your opinion on is the difference between what you learn, self learning or even in research, in terms of using Bayesian inference or machine learning, whatever it may be the difference between the types of tools and techniques you use there, which may be importing CSVs and then doing Machine learning in production, in a company. And you may have all these things that you haven't actually been exposed to before by doing kaggle competitions, for example.

I'll give you another example. Like one of the things that is very hard to learn is data engineering. So data scientists are different than data engineers, of course, but there's a reason that there isn't a bunch of data engineering boot camps. Because to do data engineering you basically need a production system to learn that skill. Like you need to have millions of data points flowing around and all this kind of stuff for you to, to actually do stuff with that. And so if you don't learn it on the job, like there's relatively few areas that you, you could learn that on your own. And I think there's some parallels to data science where there's just some, some things that are hard to do as, you know, a self directed project. I would recommend that people do side projects or do learning projects that take advantage of those. So like instead of say instead of importing a CSV with the data, like load it into a database and then pull it down, and then pull it down once an hour or something like that just to like get more experience with that. And there's no, I mean these tools are either free or cheap. So if you have like a small amount of data. So for example, like there's Amazon Athena, which is like a way of kind of search. Like it's basically like a way to do queries on big data. You could totally upload just a little bit of data to that. And then you pay by query. So you could pay like 30 cents to do a query and so you do like 30 queries and you kind of understand what's happening and then you kind of use it for a project and then you drop that project and you never pay for it again. But you have that experience under your belt. And then so when someone comes to you and says, hey, I saw you have this AWS experience, you can be like, yeah, because I did this kind of project, we use Athena. I had to work out the IAM security roles of me and then how I put it onto a server and how I, et cetera, et cetera, et cetera, and all that kind of stuff you could do. Because with things like aws you just pay for usage, just have a small amount of data when you do it. But you do have that experience that is really useful, that's a good signal that like, hey, you are really interested in the kind of stuff if I release you onto our system that costs tens of thousands of dollars a month. You could sit down and do some really interesting stuff and you would be interested in that. I think that's great. I would recommend that if you really wanted to stand out, you should try to identify the skills that are harder for people to get right. Because it's very easy to download a CSV and then do some group by statements in Pandas or something like that. And that's why there's 50,000 tutorials that do that. And that's why my homepage has a bunch of tutorials on doing that. And that is useful stuff. But to stand out, if you had some kind of experience in something that was harder to set up and something that was harder to do, I think that's a nice way of sort of saying like, no, no, no, I'm super serious about this. Like I tried to do this thing that was more difficult and it's more in line with like what a real businesses would do, just at a much, much smaller scale. But I'm still using the same technologies. I mean, that's awesome. That's great.

So, Chris, I want to ask you what one of your favorite data science techniques or methodologies is. But before that you've said random forest enough. But my first question is random forests or support vector machines?

Always random forests. Who uses support vector machines? I don't think there's ever, I cannot think of a single case of someone who has used a support vector machine in production. Support vector machines are mathematically cool. They're just super cool when you explain how they work. It's just super interesting. It's a very clever technique. But random forests are like if you need to get something done. A random forest just seemingly works out of the box in so many ways and so many cases very, very, very easily that it is definitely the one of the best starting points. I think a random forest is definitely one of the best starting points for a lot of modeling. And then I would kind of go from there and decide if you wanted to, you know, make the random forest more complex or add more feature engineering or change your model up or something like that. But I would definitely, I'm a big random forest fan for sure.

And I actually, I was riffing off, it was a couple of weeks ago, someone tweeted out, out, does anybody use support vector machines for anything? And you, and you, you just replied, no.

Yeah, I can think of like, I don't know who uses that. I, I cannot think of a single time that someone would choose a support vector machine. Over, over anything. I don't know, I don't, I don't see that, that one moment where it's like the killer, killer model to use. Someone's going to listen to this and send me some kind of article that, you know, like they cured some kind of cancer using some kind of support vector procedure. But I cannot think of an example off the top of my head. I always considered a support vector machine more as sort of a teaching function for like, hey, here's one of the techniques that people tried. It's mathematically genius. I think it explains a lot of the concepts of, you know, like a decision line between groups and that kind of stuff really well for sure. And what happens when people are on the wrong side of the, like when a data point is on the wrong side of the decision line, all that kind of stuff. I think that's totally, totally useful also. I, I've never seen someone use it in production.

So do you have a final call to action for our listeners out there?

Sure. I mean, one, you should completely apply for the jobs that devoted. This is not actually an attempt for me to get. This is not an attempt for me to get people to apply for jobs devoted. But hey, we are a awesome company. Come work with DJ Patil and myself and a number of great people. That is. It'll be fun, it'll be great and I hope you apply.

Incredible. And we'll include a link in the show notes as well too.

Awesome. See, look at this final like, God, can I expense? I mean, I'm not really paying any money for this, but I feel like I should expense like a, I don't know, like a lunch because of this or something.

Absolutely, let's do that.

This would be my other more general call to action. I think for, for someone who's interested in data science, think very carefully around the skills that you're trying to develop and the skills that other people who are applying are trying to develop and sit down and, and think about ways that you can apply those skills in a way that both demonstrates that you have those skills because and, or that you're learning those skills or something like that, but has some kind of real impact in society around us. Right? There is, there is so much free data out there. There is so many really, really, really interesting projects that you can do by yourself on your own with basically no money that you can sit down and say, hey, like I have, you know, I've used Random forest in this really strong way, but I've also used it in a way that that I whatever detected some crazy cool thing, detected parking tickets in New York or detected like some kind of, I don't know, like some kind of thing around like police. Police shootings or some kind of thing around crime or some kind of thing. Anything like that. Like I think there's so many really interesting things that you can do with data science. This is a applied field and so learn things in data science, that's a big part of it, but then also apply it in in your home life and in the projects that interest you. That is the ultimate thing that I want to talk about in every single interview. It's just the cool things that they've done and used data for. And I want to see that spark of excitement in the things that they've done because then I want to work with them. Because if they're excited about it, I'm excited about it and it makes me want to go to work every day.

So and this has been a great conversation, Chris. So thank you so much for coming on the show.

Yeah, thank you. Thank you for having me.

Such a pleasure.

Thanks for joining the conversation with Chris Albon about getting your first data science job. Chris made it clear that one thing you need to do is provide a differentiating factor in your resume and interviews. When most resumes state the same skill sets such as R or Python SQL machine learning, how will you stand apart from the pack? One way, although not the only way, is to have a small portfolio of projects you've worked on, whether in a GitHub repository or in a blog. Another way to stand apart is to have a bit of experience with projects and techniques that aren't so commonplace. For example, instead of importing your data as a CSV, load it into a database and then pull it down. And then pull it down at regular intervals. Or get up to speed with using Amazon Web Services, for example. Yet another way is just to be super duper excited about the organizations you're applying to and the techniques you like to use to answer questions. Chris also gave the great advice of looking for positions in mid to larger organizations and not in smaller scrappier startups. In mid to larger orgs. You'll be able to learn a lot, develop your career, and won't need to be too concerned with all the data infrastructure challenges at that point. More generally, look for orgs that will foster your career aspirations and will invest in you. I'd suggest making that a first order principle of your job search. Next week I have the great pleasure of speaking with Noemi Dershi, a Senior inventive scientist at AT&T labs within the Data Science and AI Research Organization, doing lots of science with lots of data. We'll be talking about her work at AT&T Labs research, the mission of which is to look beyond today's technology solutions to invent disruptive technologies that meet future needs. AT&T Labs works on a multitude of projects from product development at AT&T to how to combat bias and fairness issues in targeted advertising and creating drones for cell tower inspection research that leverages AI, ML and video analytics. We'll be talking about some of the work Noemi does, from characterizing human mobility from cellular network data to characterizing their mobile network to analyze how its topology compares to other real social networks reported and understanding TV viewership and how engaged people are in different shows. All this and as always, more next week. I'm your host Hugo Bau Anderson. You can follow Data Camp on Twitter @Datacamp and me Hugo Bown. You can find all our episodes and show notes@datacamp.com community podcast.