Data Science Hangout | Asmae Toumi, PursueCare | Data Science Team Culture

Welcome, everybody, to the Data Science Hangout. I hope everyone's having a great week. And special hello to anyone that's joining for the first time, too. I'm Rachel. I'm the host of the Data Science Hangout. I'm calling in from Boston, as well as Asmae. I'm in the RStudio office today. This is an open space for the whole data science community to connect and chat about data science leadership, questions you're facing, and what's really just going on in the world of data science.

So if you ever want to go back and rewatch past sessions or share it with someone who's missed, it is recorded. And it will be shared to our brand new Data Science Hangout site. It's right on the RStudio page now. But we really want this to be a space where everybody can participate and we can hear from everyone. So there's three ways to ask questions. You can jump in live and raise your hand on Zoom, might be the easiest way with a bigger group. You can put questions in the Zoom chat. And if you're like in a coffee shop or your dogs are barking or you want me to read it, just put a little star at the end of it. But we also have a Slido link that we'll share in the chat right now where you can ask questions anonymously too.

But with that, I'm so happy to be joined by my co-host for today, Asmae Toumi, the Director of Analytics at PursueCare. And Asmae, I'd love to just kind of turn it over to you to introduce yourself and maybe some of the work you do at PursueCare too. Sure. Thanks everyone for joining this Data Science Hangout. I'm really excited to talk about the work that we do at PursueCare and how I fit in there, but also to learn from all of you. I'm Asmae. I'm the Director of Analytics and Research at PursueCare. PursueCare is a telehealth company which specializes in treating mental health disorders, specifically substance use disorder. We are a telehealth company first, but we do have also in-person clinics. We've been in operation for three years now.

Building the data team at PursueCare

Yeah. I've been working at PursueCare since last year, February last year. So I was the company's first data person. So that came with some challenges, but also some excitement because we got to kind of explore the best tech stack for us. And we weren't, I guess, beholden to some legacy code or legacy platforms. So with that, we looked at different vendors. And given that I was an R programmer, the decision there was quite easy in terms of picking sort of the publishing platform that we were going to use, RStudio Connect, to no one's surprise there.

So it's me and three data engineers. We're hopefully going to grow that a lot going into next year for sure. That's something that comes up on this call a lot, is the topic of hiring data engineers versus data scientists and which comes first.

I think I put out this tweet, I think, a while ago. But all data scientists want is a data engineer, honestly, because we're a health care company. And I think the people that work in health care would sympathize with this. It's complex to deliver the care that we do. And with that complexity comes with interfacing different vendors, so different data sources. So it's really important to invest, I think, in data engineering such that the reconciliation of that data across the many vendors is ensured. Data quality is also super, super important in any field, but especially so in health care. So I think it made a lot of sense for us to invest in data engineers early on.

All data scientists want is a data engineer, honestly, because we're a health care company. So it's really important to invest, I think, in data engineering such that the reconciliation of that data across the many vendors is ensured.

Networking and community

Yeah, I think my boss is on this Zoom, Nick Mercadante. He's the CEO of PursueCare. And the way we've met is through hockey Twitter. So we both like hockey. We made a hobby out of it, out of analyzing hockey data. And so the networking, I guess, there in terms of getting my job was pretty organic. And I think most of my sort of networking efforts are natural in a way. I invest in my public presence for sure in terms of time spent on Twitter. And I think over the years, if you're intentional about interacting in a positive way with the people in your community, whether that's your professional community or sports or any interests, then I think it makes it that much easier to build that connection, build that rapport. And when you're looking for your next step, then the awkwardness and all of that kind of dissipates.

I found you via your Big Data Bowl submission last year, one that I actually really enjoyed. I believe it was the finalist as well. I was just wondering what other competitions you recommended because of course I'm new to this and I'm trying to look at other competitions. I've entered this year to the Big Data Bowl. I just want to know what other competitions were around to try and boost my CV, so like stand out from the crowd.

Sure, yeah. The NFL Big Data Bowl is such a tremendous opportunity to get exposed to a very big and complex data set. And there's a lot of eyes on that competition. NFL staff, other sports leagues have hired from people's submissions and so on. And I think that sports is a great field to kind of, you know, practice your data science skills and post it because sports fans are very much hungry for that kind of thing. I think Kaggle always has competitions ongoing and it's great because it spans many fields that you may be exploring, finance, healthcare even. So I highly recommend using Kaggle given that submissions are online. It makes it very easy to just import that code and tinker with it yourself and learn a few things along the way while also building your portfolio.

Yeah, it's been super exciting following Slice over the summer. I think that was literally one of the highlights of my summer, quite frankly. I love just how welcoming that environment was to the participants themselves even though it was a quote-unquote competition. I learned so much from observing those participants do these timed challenges and it's been really great this kind of shift to video. Honestly, it's a little less, I think for me personally, a little less tiring to watch data science and to learn how these experts go about it live because you see them sometimes debug live or change things on the fly. It also helped a lot with, I think, my own imposter syndrome. Just seeing that they also get tripped up and they also use the pipe instead of plus whenever they're using ggplot2, that kind of thing. So yeah, definitely have noticed a bigger shift into video and it's very much a welcome one, at least for me.

Advice for the first data person at a company

A great question that's, what are some pitfalls that you would give advice on to avoid for the first data analyst in a company with no data pipeline that wants to make data-driven decisions?

Yeah, I think trying to do too much is a bad play. I think also making sure that you have a lot of face time with the stakeholders is important. I think, you know, I had sort of many ideas of what I wanted to do with this data, but when you actually sit down with the people that will be using this data, it looks differently. So I think just making sure you have that face time, that you do your due diligence in terms of, you know, what your tech stack is going to look like, make sure you right from the get-go have reproducibility and code quality in mind as you're building out those pipelines are all important considerations, I think.

Centralized vs. decentralized data science teams

I'm Jeffrey Sumner. I'm a data engineer at a gas pipeline company. My question was around, as you build out your team, do you plan to be focused more as a centralized data science team or more of a decentralized team within your organization? My definition of it, at least, is centralized would be you have more of a data science team reporting up to a data science manager, whereas decentralized would be more along the lines of you've got a team within sales, a team within marketing, or a data science member on the marketing team, the sales team, finance, whatever it may be.

Yeah, that's such an interesting question. We have, of course, typical departments, marketing, finance, ops, and I think it would make sense one day to have decentralized teams such that those data scientists can become subject matter experts as much as they could in those specific fields, such as finance or marketing. I think right now it makes more sense to have a centralized team given our size. We're about 70 employees strong, and we're really at the phase of just understanding this data and trying to better understand our business, our patients. But I think as we become a more mature company, our questions will probably become more complex in nature, and so having those decentralized teams in which they can once again have more face time with the subject matter experts would make sense, I think.

No, on this topic, I fully agree with what Asmae is saying here. I think it can be a little bit of organizational structure. There is no right answer here. Both are valid, but for a company that is starting out a data science team, I think a centralized setup is good because they can then develop and say grow this data science function as to how it will work in this company, set some good practices, et cetera. And when you're building a team, new hires have a place to come and learn, say, company processes, how does data science work, who are the best, and so forth. However, as this function grows, having data science teams within the marketing, within HR, within finance, et cetera, et cetera, shows a level of maturity now that these functions can exist and thrive within those functions. I think there is no right answer, but I think if you look at the growth of the data science function, I fully agree with what Asmae says, start centrally, but as you grow, data scientists need to understand the language of the finance team, language of the operations team, et cetera, and for them to be part of that organization accelerates that growth.

I think there is a happy middle, right? Once you, once you, you know, an organization has achieved this, a decentralized model. In my company, you know, the finance organization is set up in a centralized-decentralized, it exists in both ways. And I work in the supply chain department of my company. We have a finance lead for the supply chain organization. But that person, if you look at his reporting structure, he reports into the finance organization. So, he brings that finance expertise to the supply chain organization, but his manager, he rolls up into the CFO organization, right? So, he continues to have, like, input from both places. He knows about supply chain, but he also follows all the best practices of finance within my company.

Data analysts vs. data scientists

Is it okay to say that we are data analysts and data scientists interchangeably? Are there specific differences?

I think Jacqueline and Emily Robinson's book on data science careers has a really good definition for both and the subtle differences between the both of them. I think data scientists involves just a little bit more, you know, engineering work, ML ops, DevOps sort of work. But honestly, I use them interchangeably, but others might have differing thoughts on that.

Yes, I recently attended some lectures about AI ML. And in those lectures, it was explained in a very good way, the difference between data scientists and data engineers. Basically, data scientists are those people who understand the distribution about the data, and they figure out based on the distribution, what class of AI ML algorithms would be suitable to handle that particular problem. And once that is decided, then the data engineers or ML engineers, they then solve the optimization problem. So, within that specific class of algorithms, they figure out which specific algorithm with specific configurations, which algorithm is going to perform the best for that specific set of data.

Hey, Rachel, I think the gentleman that just spoke kind of, you know, articulated what I was intending to say as well. But I would say that's more from like a theoretical data scientist standpoint. I mean, some of the best data scientists or, you know, our programmers or Python programmers that I know have the title of, you know, financial modeler or, you know, senior actuary. Some of the best programmers and like package developers I know have the title data analyst. So, I think it really just depends on the organization. Like, we have these guidelines that, you know, are more like an ideological function of a data scientist versus a data analyst. But I really think in practice, it's all over the place.

So, for me personally, I use data analyst and data scientist interchangeably. But I think there is probably a meaningful difference there between a business analyst and a data scientist.

Live coding interviews and imposter syndrome

Someone said, I had an interview recently and they wanted me to solve write code live. I've always had issues when people watch me working. It makes me uncomfortable, even if I know how to solve the problem. Do you have any tips on how to get better at that?

First off, I'm sorry you had to do that. I really don't like that sort of live interview structure. I know that sometimes I'm on Zoom meetings where I'm displaying a dataset or a graph and sometimes have to code things on the fly because someone asked a question. I make tons of mistakes, tons of typos in front of everyone. That's just the nature of it. In terms of getting better at that, if that's going to be sort of the standard for some companies to still have those live coding interviews, maybe streaming might be a good avenue to do that. You could put up a stream and have your buddies join, sort of a low-pressure way to do that.

Yeah, I was just going to kind of add something that I've learned that was a bit interesting, is that sometimes the way to kind of... I don't like live coding interviews whatsoever, but if you were to participate in one, sometimes it's not about the right answer or being able to find the bug or whatever it is. Sometimes it's just a matter of seeing how someone reasons through doing it or how they approach the problem. It's similar to kind of like those really random consulting interview questions that you might get, like how many jelly beans can you fit into an airplane or something. There's no real right answer, but it's just a matter of how you reason it. So I think that there may be value if you can kind of change your perspective on what it is they're trying to do and maybe helps calm you in that particular moment, that there's not necessarily a right answer. Sometimes it's just a matter of how you work in that kind of uncomfortable high pressure or whatever situation.

Prabha here. We do live coding interviewing for recruiting into our team. And I agree with what Seb says, right? We are, even if they're not able to do, execute or write code that runs flawlessly, in the interview session, we evaluate them on seven or eight different categories. Writing code is one of those categories. So just like how Seb said it, it is their way of thinking. One of the evaluation criteria is when we give them a task, let's say, do some exploratory data analysis with the dataset. Do they ask, do they engage us? We are encouraging them to engage the interviewing team and ask the kind of questions that they would try to get to the answer that we are asking them. So that level of engagement, are they asking the right questions? Coding is one out of, say, seven or eight different criteria we're evaluating in that interview session.

Oh, I just remember an interview that I very much enjoyed in which I was given a take-home challenge and then was brought back for a live interview with the team to discuss my approach in depth, in which they also had the opportunity to ask questions about my approach and also give constructive feedback about that approach. And I think also it's a good way to sort of gauge, you know, emotional intelligence. How do you take that feedback and test for the soft skills? So I think that's a much happier medium that I think makes as many people comfortable given that, you know, people do struggle with live timed challenges.

Yeah. I'm Hugh Welch. I'm a management analyst with VHA. You mentioned imposter syndrome earlier, and that's something I'm always interested in hearing about, how people have dealt with that and any strategies that they've developed.

Yeah. I think imposter syndrome is kind of just a part of the, part of the deal here in our fields. But I think, you know, surrounding yourself with humble, capable friends, whether that's through Twitter or Slack communities, in which there is that honest, sort of, rapport in which, you know, you share your wins and successes, but you also share your struggles. And there's an environment in which you feel comfortable asking even the smallest of questions, or so you perceive, I think goes a long way into dampening that imposter syndrome. And communities such as this one, like we're here, you know, sharing our struggles and so on. So I think, yeah, I think investing in sort of a group of friends in a professional capacity goes a long way in terms of helping that.

Surrounding yourself with humble, capable friends, whether that's through Twitter or Slack communities, in which there is that honest, sort of, rapport in which, you know, you share your wins and successes, but you also share your struggles. And there's an environment in which you feel comfortable asking even the smallest of questions, or so you perceive, I think goes a long way into dampening that imposter syndrome.

That's the thing that always surprises me the most. When you talk to somebody who doesn't have a name for what they're feeling, you know, like the idea that somebody's going to come along and say, you don't belong here. Like, I feel that. I thought it was only me. Like, nope, that's everybody. Good luck.

Yeah, I was asked for some thoughts on streaming and live coding at one point a little bit earlier here. Personally, I think that live coding interviews get a bad rep in that I want to see how people think. And I try to stream the same way where I don't present myself as an expert, even though I consider myself a good R coder. I work through projects on stream, and I share how I think, and I share messing up. And I think being comfortable with that is useful. I think my problem with take-homes, I'll counter the massive support for take-homes, is that I feel like often it ends up being that people spend so much time doing them. Like, for me personally, I would rather respect someone's time and give them the option to do a live coding interview, because really what I'm interested in isn't, can you deliver a perfect model at the end of the interview, or solve this cleaning, or whatever. I want to see the process, and I want to see what it's like to work with you as you talk through stuff and what you think. And so when you do take-homes, if I give you a week deadline, and I say spend 24 hours on it, you're still going to spend all week, like nights on this thing, trying to get this job. I don't love that. And if you can build up fluency and confidence, even in just pair programming environments, I think that means so much.

Yeah, I mean, I suffer from impostor syndrome. I think it's inevitable, and it goes with the territory, I think, because we become specialists in a very narrow field, right? And the more specialist you become, the narrower the field it gets. And then eventually, you hear someone who you think is in a similar field talk about things that you think you don't understand, and that pulls the rug out from under you. So I think it's especially tough if you're trying to lead something, right? Because then you have people working for you in your team who are the ones who are pulling the rug from under you, right? So I think you've got to try and, you know, develop a little bit of a thick skin, but also know what you know, know what you don't know, and just be able to say, look, I'm sorry, I don't understand what you're telling me. You know, help me out here. Help me learn.

Yeah, I'm also going to add on to this hot topic of live coding. My personal preference is always take home. And one of the things that when we send out take home exercises, or when I do them myself, we try to focus on asking candidates to comment their code really well. So make sure that we are able to see their thinking process. And that's something I also try to practice, that I comment on the code, why I'm doing X, Y, Z, and, you know, what is my thought process behind that code. So I think that that part can be achieved through commenting. You can definitely pull a piece of code from Stack Overflow, but your comments will show why you're doing something.

SQL and R

But Asmae, one of the anonymous questions was, I use R to query databases, but I've noticed SQL is common in many industries. Wondering what are your views on learning SQL when I can do the same in R?

Very spoiled as R users with the ecosystem of packages that can make it quite validating for you to sidestep learning SQL. However, I found it to be a very useful skill that I personally should invest time in, and I think to generalize that other people should, too. Just drawing on my own experience, so I'm the sole data scientist with three data engineers, and they write everything in SQL. And so, you know, to better understand, you know, their code and how that translates to the data that they're feeding me, I think definitely having an understanding, just being able to read it is helpful without, you know, necessarily having to wait for them to explain it to me. So I think definitely investing in SQL is only a win for you personally, and it's good for your resume as well to have that.

Data science culture and stakeholder trust

Yeah, I think I've been super fortunate in that regard. There wasn't much convincing that I needed to do to convince the stakeholders of the value of data. Maybe that's because we are a digital first company. So, you know, yes, we do have physical clinics, but everything is data. And so, you know, because everything is data and if there is, you know, an establishment of trust there in terms of you producing quality work and reliable results, then that part is pretty seamless, I think, in trying to convince the stakeholders of the value. There just isn't, there is no question as to like the value of the data, because it's something that the stakeholders need to look at pretty much every day for, you know, assessing patients, assessing processes and identifying how those can be improved and optimized.

Maybe that has to do with the culture. So Nick was on earlier in the call, I think he dropped off, but, you know, at every monthly team-wide meeting and really every internal meeting, you know, he asks for departments to give an update and he puts into words a data-driven update. So it's something from the get-go that everyone is expected to look at and to ask for and to interface with me and my team to obtain those insights. So very grateful to have that culture and for my job to be that much easier in which I don't have to really sell people on using this stuff. Really the convincing is just in terms of, you know, how the data should be best displayed for them to then be able to use it to make decisions.

Yeah, I think, you know, maybe asking them about how they think they would utilize the data science team, how they're currently utilizing the data science team and, you know, making sure that that data science team isn't just, you know, off to the corner doing their own thing, but it's fully integrated within the company. I think, you know, in certain fields, you just drawing from what I know about sports and my colleagues in sports, you know, many teams have invested in data scientists because, you know, teams think that that gives them a competitive advantage, but in terms of actually utilizing the findings of that data science teams, you know, that that's been lacking. And I think some people have thrown around, like, you know, maybe we need decision scientists on top of having a data scientist or data science teams. And I think that's a really interesting conversation to have.

Yeah. So I'll just say that it also blends into our conversation about data scientists versus data analysts. The analysts that work on my team within Target, within supply chain, particularly in transportation, we are interested, like we are a centralized team. We sit with a lot of other data analysts, but my team, my analysts are so embedded with our stakeholders and our users. They know the business almost just as well as the business does, and they know how to manipulate data and model data and pull data just as well as any of the other centralized teams. So I use the term full stack data analyst. It is hard and it is rare. And maybe the learning process is very draining for some folks, but we get a ton of value on both sides of the table and having people who are, let's say 70 to 80% good at a lot of different things.

I have something to contribute to that. I mean, the term decision scientist, I've heard of it, but my challenge to that need for such a position, I challenge that notion primarily because if let's say you're presenting analysis and data science work to a finance person or to a supply chain functional person, they are the decision scientists here. They are the ones to make a decision. So if there is a data scientist and then there is a decision scientist, to the finance leadership person who needs to make the decision to define course of action for an organization, whether the position is called decision scientist or data scientist, they are still the outsider. So the decision makers already exist in organizations. They are the owners of business processes and P&Ls and so forth. I think of it as we need to cultivate the business owners to become better decision makers with the data that we provide them.

I'll make one last comment there. So it's a great point, right? At the end of the day, the analysts are not the decision makers, but the fact of the matter is they become partners at the table because they are able to really understand the decision, any decision frameworks that are going to be put in place in the iterations as well as say, hey, that's great, but the uncertainty in the data is this. And we know that a lot of business users want to use point estimates to make their forecasts or their decisions. Having the trust built between the data people, call them scientists, analysts, whatever you want to, and then people making decisions so that the data people have a lot of weight and input on the decision, I found to be, it pays off.

Yeah, I mean, it really does depend on not just like team culture. For example, it sounds like Frank has a really great culture that he and his team have created at Target. You know, the way that you represent your team by how you conduct interviews and things like that, that's kind of team culture. But then you have your company culture, which is really a system of systems, right? So you have a lot of different teams that are producing and consuming data. And I think that some mechanisms of that workflow are not going to work across all organizations. Another way of saying that is organizational structure plays a really big presence in how data science and data analytics get consumed and communicated across an organization or a company.

I work in experimentation. I didn't actually introduce myself. Hi, I'm Christy. I work in experimentation at Grubhub. Experimentation is a really great example of where some of these communication type challenges come to a head because experimentation sits at the intersection of finance and product and marketing and engineering and data science and analytics. And so we all have to really think hard about how to work together. And it's not easy. And I'll also say, you know, I don't think a lot of even top tier organizations have this problem fully fleshed out and solved. For a lot of the newer data scientists on the call, I think it's really important as you take on your new career as a data scientist to just kind of keep in your back pocket. Data science is still really, really new relative to software development. And developers have put into place all kinds of processes and workflows over the years to operationalize their work very efficiently. And I think that that's still kind of a source of frustration for a lot of data scientists in industry. So, you know, as you take on your new job, exercise a little bit of patience. Remember that, you know, not all of this stuff is really fleshed out yet. And you can be a source of inspiration for solving some of these problems. I know that that's something that's really driven me as I became a data scientist just five or six years ago, is I'm super passionate about how do we operationalize data science effectively? Because I would say that most companies are probably getting about 60 percent of their ROI on the data scientists they hire. We can do so much more than we're, I think, able to do today. We just need the tools and the leadership and the, I think, just the experience even. We have to fail to learn. And so, like, how do we figure out how to move these things forward? It's a big space. But I think, you know, the maturity is coming. We just we need more people like you.

Data science is still really, really new relative to software development. Because I would say that most companies are probably getting about 60 percent of their ROI on the data scientists they hire. We can do so much more than we're, I think, able to do today. We just need the tools and the leadership and the, I think, just the experience even.

Remote work

So, I work for a consulting firm and the client is all on premises. And, you know, I've been hired to work remotely. So, yeah, I just wanted to see if anybody wanted to talk about how hiring remotely has gone and whether or not you see that remaining in the field or if there's some chance that we're going to be going back to more in-person type situations, because I don't think a hybrid environment works from an advancement, a career advancement perspective.

Yeah, I think, you know, very fortunate once again that PursueCare was created with the intention of having a significant portion of its workforce be fully remote. And so I think right off the bat, the culture and the tools we've adopted and the processes we've adopted were friendly to that, to having the workforce be remote. I think there's a lot of interesting debate about sort of career advancement for people that are remote versus in-person, that people that are remote may miss out on promotions or not be considered for those. I think that's a valid conversation to have with your managers or just be mindful of that if that's your goal within the company. I think, you know, there's pros and cons to being remote for myself. You know, do I wish I had more face time with other stakeholders sort of in-person, you know, grabbing lunch or doing all that. But I mean, the pandemic is a thing. If the pandemic was over, let's say, then yeah, I wish I would have more of those organic experiences for bonding and all of that. But I think being remote has paid dividends in terms of my productivity and my overall happiness and my ability to kind of structure my day. I know that personally, I don't really like to work in mornings. My productivity kind of starts at like 11 a.m. until 3 p.m. and then I have to go make lunch and eat and then I like to kind of get back into it in the evening sometimes. So that flexibility has been really great for me personally.

So I've had my last couple of jobs now remote and all my customers that I serve were scattered all over the United States. So there was no possible way that I was going to get FaceTime with them. I sat in Boston, but my customers were in St. Louis and California and Chicago and wherever else. I could have been on the moon and it wouldn't matter. If you're requiring the FaceTime for people to advance, then that means you don't value the work. The work should speak for itself. And if it doesn't, then I think as a corporate culture, you're not valuing it enough. Because most of this stuff can be done remotely. It's not physically possible to be in the office with everybody you need to work with. It's just not possible, especially with these globalized organizations. And to Asmae's point, it gives people the flexibility. At the end of the day is I only care if you get the job done. I don't care if it takes an hour, 30 minutes, or 12 hours.

I couldn't imagine kind of sitting at an office from nine to five. It's just, it doesn't really drive with how most people work. One thing, though, that I think about, I saw this on Twitter, someone saying, you know, junior software engineers, because of this shift to remote work, will have their learning stunted or something like that because they just don't have that much face time with more senior software engineers in which they can kind of just like pop into their office and ask questions or see how it's resolved. And that's something that I think about maybe when I will hire more junior data scientists right out of school. I think, yeah, I think as long as there's structure in place to make sure that there's enough sort of one on one time and mentorship time that we can sidestep that. I know that that was really valuable for me when I was a data analyst at Massachusetts Gen. I would just like constantly pop into my more senior people and ask them to help me out. And I think it's just more awkward to do it with maybe not more awkward, but I'm slacking just like, hey, like, I'm stuck. Can you get on zoom with me or something?

Professional development and SMART goals

I asked if anyone else has scheduled time to work on non-work projects. I saw Brian responded that he designates some portion of Fridays for folks on his team to work on developing technical skills. And I know that's something, I guess, again, a statement that I've found to be helpful is that I have that same sort of time that I've gotten my manager sign on for working on non-work projects that I find interesting to help develop skills that I otherwise wouldn't necessarily encounter in day-to-day work. I know also there's sometimes people suggest here, oh, you should code all the time outside of work. But I know some people don't like to, they want to have a clean separation between the work day and then free time on afternoons and the weekends. And that's a good way to still get in personal practice without having to sacrifice free time.

They said, we're told, feel free to take time for professional development, but it's implied that is when your work is finished and it never is. That's perfect. I think I'll add that once again, culture is important. And I'm not just saying that as a throwaway. So Nick, my CEO, evaluates his staff based on what's called SMART goals. I can't recall for the life of me what that acronym is, but SMART goals is things that you've achieved over the course of one year. And one of those SMART goals has to be the demonstration of your professional development. Yes, exactly, specific, measurable, achievable, relevant, and time bound. And because of that, because it's literally part of my SMART goals, and that justifies time that I set aside for my professional development. And yeah, and it doesn't have to be coding. Professional development could be literally reading, I don't know, papers on plant science. Oftentimes, inspiration and the learning of new techniques and new frameworks could come from fields that could look very different from the field that you're working in currently. So I think having sort of leadership that understands that, and that accommodates that, and that embeds it in your performance is really great.

And so with that, I told Nick, I wanted to TA a data science class Fridays from 10 to 1pm. And you know, I didn't really need to convince him of that. He's like, okay, yeah, that makes sense, because you're going to learn from your students. And you're going to learn, you know, about how to communicate, you know, things to people that don't have experience with doing that. And that's a big skill to have, because you'll be, I think, as a data scientist, often interfacing with people that don't understand it, and that you'll need to explain it.

Managing data engineers and wrapping up

It's definitely not part of my skill set, but I'm learning, you know, slowly but surely through them, you know, good practices and so forth. So I think I'm, like, a pseudo, really pseudo data architect in that way. So, you know, I sort of interface with the vendors in terms of negotiating, you know, data access and how to obtain that data. And then I go back to my data engineers and tell them, okay, this is what the data looks like. This is, you know, the cleaning that needs to be done. This is how we should format it such that it makes it easier to, you know, slice and dice the data whenever we need to. And so that's how I've managed this team is sort of, you know, give them an understanding of the business, which then informs how the data should ideally be structured to meet those business needs. But yeah, I certainly don't really have intimate experience of data engineering. I have some ideas, but it's definitely them almost managing me in a sense. So it's a good two-way street there.

But the question was, how much of data science is data exploration versus machine learning versus deep learning?

Yeah. So I really think it depends on the company and the team and so forth. I can tell you, PursueCare machine learning right now occupies zero of our time just because we're just literally not there yet. But it's something that, you know, once our data warehouse is mature and we've understood the basics about our business, then for sure that will become a bigger part of our time.

You know, I think having exposure to machine learning is important, especially if you can fit it into your day, because there will be a time in which you're probably going to have a question that involves you, you know, modeling and maybe drawing from a machine learning model. But yeah, I think it's kind of the things like learn to, what's the expression, learn to walk before you run type of thing. I think getting really good at using group by and summarize will make your stakeholders very, very happy. So I think if I were to give advice on someone kind of starting out, I'd focus on getting really good at, you know, being able to slice and dice the data and represent it in efficient ways before, you know, moving on to more fancier and more complex questions.

Thank you all so much for joining and staying on past the hour too. I really appreciate you jumping on here, Asmae, and sharing all your insights and experience with us too. What's the best way for people to get in contact with you if they had follow up questions? God, this is so fun. I could literally do this for hours, but we all have jobs to go to. Yeah, I think the best way is Twitter. I'm usually very active on there and will definitely respond.