SQL and Data Science Interview: Successful Tips and Tricks | Careers | Community Webinar

Key Takeaways

What's up data science dojo? My name is Nick Singh. Before all this, I was a software engineer on Facebook's growth team where I used a lot of data and AB testing and wrote a lot of SQL queries to help Facebook grow. Then I wore multiple hats across data and evangelism and marketing at Safe Graph. It's like a location analytics startup. So, we worked with geospatial data and tried to find insights about the physical world and about places from that GPS and location data. But most importantly, I'm Drake's number one fan. I'm a certified lover boy. I used to DJ and mix hiphop and Bollywood music. I've just love music. I think I have really good taste and I think I can spot trends pretty well. This is my book, A Study of Science Interview. It's a number one bestseller. It's helped a about 25,000 people so far have read the book. And then I also run data lemur, a SQL interview platform where you can practice 70 free SQL questions which is used by about 65,000 people. This is my co-author Kevin. He was a data scientist on Wall Street. Before that, he was a data scientist at Facebook. These days he does a bunch of crypto stuff um and kind of combines his passion for Wall Street and finance with his passion for engineering data. What we're going to talk about is not just the technical interview process, but also how do we get more interviews in the first place. And I hope to leave you all with some mindset shifts around the job hunt. Because sure, there's all these tactics we're going to talk about today, but I think to make the most of our next hour, I want you all to shift your thinking, but a few different things in the job hunt cuz I think there's a lot of advice out there, but a few of the things I say might be a little bit different or might be a little weird. So, I want you all to try that mindset on for this next hour. This is me DJing. That was me in high school, me after college. I love music, mixing Bollywood and hip-hop music. And the thing is, I have really good music taste, but everyone thinks that. Everyone thinks that they are really good with music or know how to spot upcoming trends. So, I wanted to build a game back in college. I want to build a game that could quantify my musical taste and prove to others that I actually have better music taste than they do. So, I built Raptock.io, a stock market for rappers using data from Spotify's API. I was able to price and value a whole bunch of different hip-hop artists. And similar to a stock market where you can, you know, invest in stocks, you can long and short them. I made a stock market of rappers where you could long an artist like Drake or shorten artists like Kanye West. So, it was pretty popular. It went viral on Reddit and you know, people liked what I had built and thought it was pretty unique. But there's one big problem in what I had built, which was that people would sign up and then turn out. They would sign up, poke around, make a few trades, but within a day, within a few hours, within a few days, people would sign up and leave. And I was really confused because to make this game work, you kind of need repeated usage. You kind of need to make a leave. You kind of need to keep coming back. So, I was curious, why did people turn out of the game? Why' they leave? And how can I get users to return back to my game? How can I stop this user turn issue? That led me to growth engineering. This weird field that combined my love of product analytics, AB testing and software engineering, which is all about kind of, you know, just using data to improve the user acquisition funnel, using data and AB testing to increase your retention rates. That was what growth engineering was all about. So, not only by learning about this field and implementing some of its best practices did I grow to 2,000 monthly active users, most importantly, I'd fallen in love. I'd found my niche within data science and engineering that kind of combined so many different of my interests about building consumer technology, data and software into one role. That led me that interest led me to work on Facebook's growth engineering team which was all about exactly that what I just told you about Raptock which is about using data to make sure Facebook can grow to its next billion users. When I joined it was at like 2.3 billion users and they were trying to hit the three billion user mark. It was about using data to make sure hey our funnels look good so that people keep signing up and people don't quit Facebook as soon as they sign up that they stay on longer. So, a lot of my growth engineering work that I had done with Raptock in my dorm room that really helped me get in front of the recruiter, the hiring managers, and all the people who interviewed me and really helped me showcase that look, I'm really passionate about the work Facebook's doing. And I'm already doing it in my dorm room. I'm not just like someone else who just says, "Oh, I love Facebook because my grandma uses it." Or, "Oh, I like Facebook because I heard um, you know, they pay well. You know, they have good perks, right?" I actually told them about my passion and I was able to relate it to the role at hand. And sure, I did ace the technical interview process. I mean, that's a must. But a big part of how I even got these interviews and got this opportunity is because of my portfolio project. So that's the magic of building one really good portfolio project. But I didn't just get lucky. It's not that I built a growth engineering project and worked on Facebook growth engineering team because at Airbnb, Snatch, and Uber, I told a very similar story because these three companies, they also have a growth engineering team where they also use data to help you book more hotel rooms, send more snaps or book more rides. They also do a lot of AB testing on their consumer user bases. So, that one portfolio project really helped me at these three companies as well. At Apple, I didn't talk about growth engineering. I told them all about my love of building consumer products and how they're the number one consumer brand in the world. They build products for consumers. I really, you know, love building for people. Where else would I work besides Apple? What do I tell Spotify? I forgot all about this growth engineering stuff. I told Spotify, look, I'm a DJ. I use Spotify data in my site. I love music. And I'm not just saying that. You can literally see I used to DJ. I made rap stock. Like I'm perfect. Who else would ever work at Spotify. Who else is a better fit than me to combine my love of music and data? What do I tell Stripe, the credit card company? They do a lot of stuff in fintech space. I told them, look, you know, I between you and me, I I didn't talk about growth. I didn't talk about music. I didn't talk about consumer. I said, look, I love fintech. I built a mini stock market in my dorm room. Who's doing that? No one's doing that. And I did that because I love data. I love engineering and I love finance. That's how I made this idea to make a stock market for rappers because I love fintech and finance. So why wouldn't I work at one of the leading fintech companies in the world, Stripe? So this one project, even though it looks really tailored and niche and it looks really random, like what stock market for rappers, one project at a whole bunch of different companies was able to show what I could do. Show, meaning the sites live. You could sign up. I had user data. I had stories. I had war stories about what I did. I didn't just tell them, "Hey, Spotify, I like music. Oh, yeah, Facebook, you know, I love people. Oh, yeah, Apple. Yeah, I think iPhone's kind of cool." That's telling people, "Oh, what you're interested in." I showed them like literally, you can see this is proof. I love fintech. I love stock markets. I love music. I love growth. I could prove that. That's the magic of one good portfolio project. Now, of course, it's not enough to build it because hiring managers, companies, recruiters, they need to know that you did this. So, for that, I love this technique called cold emails. This is where you write to somebody that you do not know. Instead of getting a warm introduction or warm referral, you hit people up cold. I mean, that's how I got interviews at Airbnb and Snapchat, even without any connections. Now, there are a lot of mechanics to sending a good cold email. So, in the follow-up after this talk, I'll send like an email to everybody about some of the actual tactical tips and talk about them in a little bit more detail on my blog. It's also a whole chapter in the book, ASA Science Interview. Chapter 3 is all about cold email tips. But today, again, I don't want to leave you with all the specific things on what you need to write a cold email. What I want to leave you with is this idea that cold emails work. And here's what it could look like for you. Case in point, the exact cold email I sent back in 2018 that got me my job at Safegraph. Look at that timestamp. 2:30 a.m. I just come back from partying with some friends. But I was kind of dissatisfied in my job and my role. And I saw this job open up in my email inbox. And I thought, okay, wait a second. This company looks cool. Whatever. Let you know what? Let me just send the guy email. I know it's late at night. I know this is probably not the right time to be applying a job, but whatever. Shoot, you know, let me just do it. Anyways, it's a long shot. I mean, chief of staff at Safegraph. I mean, they don't know me. I don't know them. Chief of staff is such a random position. It's a mix of business and data and engineering. You know, probably competing with MBA grads and Mckenzie consultants. And, you know, I was only 24 at this time. So, I was just like, yo, there's really no chance I get the job. But, you know what? I just reached out to Orin, the CEO, Orin, and I didn't know his email, so that's why you can see Orin and Orin. I didn't know his email, so I just guessed. I mean, he's a CEO, so it had to be OrinSafegraph.com. And if not, it bounces, so who cares? I tried to relate to him personally. I mean, that's a big part of writing a cold email, showing that you've done your homework. He had studied industrial engineering/operations research at Berkeley. So I said, 'You know what? Let me mention that I studied a very similar major called systems and information engineering at UVA. And then I also told him like, look, I understand your company. It's super data oriented. I have some business skills, but I also have some data skills. I've taken classes on computer vision, stocastic process, databases. Like I'm your guy. And a day later, he got back to me on Sunday and he was just like, "Hey, let's start the interview process." And fast forward about six, seven weeks and I was literally working at Safecraft. It took about six to seven weeks between me sending this cold email to start interviewing, ace all the interviews, get the offer, leave Facebook, and join here. Six or seven weeks. All started with this cold email. And if I hadn't sent this cold email, I'm not sure what would have happened because this was just like a whim. This was just something I did randomly one night cuz it just popped in. I was like, you know what? Let me just shoot the guy an email real quick. Took me about like 10 minutes to write this. So, this is what cold email can do. And I worked here for nearly 2 years. And I'm not trying to say y'all like I'll be very honest. I'm not trying to say that cold email works 100% of the time, right? That's not what I'm trying to say. Trying to say that you only need one job. You only need one internship. So if you can even send 10 20 good emails a day, you know, and get an interview in one in 10 emails you send or, you know, have a response from one in 20 emails you send. you know, every few days you're doing a networking call, you're getting an informational interview, maybe you're getting some leads, you're getting some connections, maybe you're getting some insights about the industry, especially if you reach out to alumni from your own university who are more likely to take your call or you reach out to people in the same industry as you or you reach out to people you know socially or you reach out to people in the same city as you, whatever it is, if you send enough of these messages on LinkedIn or send enough emails and you reach out enough It takes a lot of work, but the numbers work out where you start getting leads and eventually you end up getting a job, right? Of course, you still have to be really good. You have to build portfolio projects. You have to have all the hard skills. But I'm just trying to say that compared to applying on LinkedIn or Indeed, where there's hundreds, maybe even thousands of people applying for one job, very few people will ever take the effort to write a personalized message to the hiring manager. And that's the kind of difference. That's the kind of effort we need, especially in this kind of tough economy where there's all these hiring freezes and tech layoffs. That's the kind of effort we all need to do to do well in this economy. Yeah, makes sense hopefully. Cool. Um, let's go back to the slides. So, let's talk about the interview process, right? So, let's say you made your project, you sent your cold email, and you have an interview coming up. One big mindset shift I want to cover is this notion that data interviews, they cover so many things that it's not even possible to study. Compare this to software engineering interviews where usually similar types of data structure and algorithms questions. You're usually given two questions in 45 minutes. Most companies stick to the same pattern, the same script. Data interviews in that sense, they cover so many things. They cover props, stat, machine learning, SQL, coding, business and product science. They have open-ended things. They have take-home challenges. Because of the breath, people think, "Yo, I cannot study for a data interview." But I'm here to say, "No, that's not true at all. Yes, data interviews cover a lot, but there's certain topics that keep coming up. There are certain questions that keep coming up. There's certain patterns of questions that keep coming up. And that's the purpose of the talk. That's the purpose of ASA data science interview. You'll see the table of contents on the right side. It's literally me trying to catalog the must-n know concepts, the must know questions, and the must know patterns that keep coming up because it is possible to prepare. And I'll show you some of those patterns today. Here's one really common pattern. It's to explain a concept in a simple way. Explain it like the person's five. Explain it like they're nontechnical. Explain it like they only have a high school education in math. Whatever it be, it's about explaining a technical concept in a simple way. This is very common to not just check your own statistics knowledge but to also check how are your technical communication abilities because being able to talk simply and communicate with nontechnical people. This is not just a theoretical interview exercise. This is a big part of the job is this technical communication piece. So to level up on this I love the subreddit explain life on five. It's on Reddit where everyone's just explaining things simply using metaphors and analogies. I think this is a great place to not just learn technical communication but also to brush up your own concepts and your own knowledge and like just kind of critically think about what you know. I don't know if it was Einstein or someone else or Richard Fineman I think that like the proof of if you know something is if you can explain it simply. I think it was Fineman who said that. But this is exactly that kind of thing where you can practice and start trying to explain things simply to check your own knowledge and understanding. Now another really common pattern for these probabs and work experience. Now nontechnical folks they get asked about their past projects. They get asked about their past work experience, but usually they have a behavioral interview spin to them like, "Oh, tell me about teamwork." Or, "Oh, I saw you worked at so and so. Tell me about any setbacks you faced." you know, for data interviews. Sure, you might have a slight behavioral component, but it's very easy to see a past ML project on your resume and use that as a jumping off point for a technical discussion around linear logistic regression, assumptions of regression, how did you measure your model's performance, how did you stop overfitting, right? So you can get very quickly technical in the stat and ML sphere all through a simple innocuous question of oh I saw you did a cool regression project you know tell me a little bit more. So you have to be really ready for that kind of pattern that things on your resume will get grilled on and they can be really pushed into a technical way, right? So don't let that catch you flatfooted because this is a really common pattern for interviews. STAR is this really famous way to answer behavioral interview questions where you break up your answer into a situation, task, action, result. But I think that STAR isn't just for behavioral interviews. I think you can use it for technical interviews and prov questions instead of making a chart like this with common behavioral interview questions on one axis and situation task action result on the other axis. I think that you can list some of the key experiences that you've done, your key jobs, internships, portfolio projects, whatever thesis you've done, whatever it be, put three, four, five of the most accomplish, you know, your biggest accomplishments or biggest experiences on one side. And on the other axis, try to distill what you did during that summer, during that internship, during that research study down to one cris sentence. just one sentence to quickly explain what was the situation, what was the task, what was the action, what was the result. This will help you immensely in technical deep type questions. It will help you immensely in behavioral interviews. It'll just help you all around seem like a more competent communicator because when you put in the effort before the interview to catalog what are your main experiences and how can I distill them into a scint way, you will come across as so much more articulate because most people will never put in this work and most people will ha and hum and forget about details and do all kinds of weird stuff, ramble like crazy or they'll you know, blank out on key details or they'll forget to talk about the actions and results for their last internship, whatever it be. People will mess this up when it's literally like about you and your past experience. It's not even that technical. So, I really think that making this kind of spreadsheet before you interview will not just help you in your communication, but just also help show off that you know your stuff and give you a good jumping off point for those technical follow-up questions that, you know, revolve around your past work. Now here are some really common concepts that are also tested for prob stat one thing I want to call out in the machine learning area is for majority of data science roles you really don't need to know the greatest and latest in machine learning you don't need to know about transformer models and GPT11 and blah blah blah sure that's what the leading people are doing that's what the cutting edge people are doing but most companies more fortune 500s Most startups, they don't have the data, they don't have the maturity, they don't have the technical expertise to be doing the latest and greatest work. There's enough people in data science with the title of data science who aren't even building models. They're doing product analytics. They're building dashboards. They're writing SQL. They might not even be using Python day-to-day. They might not even be doing machine learning or doing regression day-to-day. There are tons of data scientists like that. So that's one thing I want to make clear that hey look if you're looking to be a machine learning engineer or a research scientist it's fine it's fine to know some of these crazy new things in ML and neural networks but for the rest of us if you're just trying to be a data scientist put food on the table work at a normal job you don't need to know crazy stuff about deep learning knowing about the more common basic concepts about overfitting underfitting knowing about boosting versus bagging knowing about regression knowing about decision trees. That's probably knowing about PCA. That's probably more of what you would need to know. And data analysts don't even worry about this, right? Data analyst, stick to your SQL, stick to your stat, stick to your dashboarding. Like, you don't even need to know that much about modeling to be a data analyst. And I think sometimes people overwhelm themselves by thinking they need to know everything and that data analysts think they need to know deep learning. That is just not the case. Here are three real interview questions asked by Uber, Facebook, and D. Shaw. Get your smartphone out because I think I'm going to have you guys solve one or two of these. Um, so definitely get your phone out. This Uber one pretty straightforward. Facebook one is kind of interesting cuz it's about 50 cards, not 52 cards. So that's kind of weird. I thought card decks have 52 cards. Also, it seems kind of weird, like a probability brain teaser type question. What does this have to do with being a data scientist at Facebook? You might think that that question is dumb. The truth is I think it's a little silly as well. I don't think that's what data scientists do all day at Facebook. But that's what they ask. And I'm not here to tell you what I think is a good or not interview question. I'm here to show y'all this is what companies ask. Like it or not, this is what they ask. Practice makes perfect. And it doesn't matter if you have a master's in CS or statistics or you have a PhD or you just graduate boot camp. If you don't remember your basic probability and statistics, you're going to get stuck on some of these questions that might not look like what you do day-to-day in data science work, but that's just what they ask. So, definitely be warned and to practice these. You can check out them on data lemur and as well as in the book because we have whole chapters of these questions. So, that's the quick call out for the Facebook one. The DSH one is pretty interesting, too. Um, I think we'll solve that one. Um, let's go to the Dshaw one. Right. So imagine you flip a coin a thousand times and you get heads 550 times. Do you think the coin's biased? Why or why not? Right? So get your phone out and scan this QR code. You don't need to sign up. You don't need to log in. It really takes like two seconds. Just give me based on this hunch, like you know, you're just given this problem statement. Hey, you flipped a coin a thousand times. Is the coin biased? What do you think, you guys? Do you think the coin's biased? Yes or no? So get your phone out. Um, definitely need some votes. Um, what are we thinking? Cool. Let me see like one or two more votes. I would love to have that. Cool. So, we have most people saying no. Um, a few people saying yes. Let's see if we can get one or two more votes. Let's see if we can hit 17. I'm waiting for you. We have 28 people here in the Zoom and I know we're live streaming. Let's see if we can get one more vote. Okay, 16. We'll 18. There we are. Beautiful. So, let's talk about this question. Remember, in a data interview, it doesn't matter whether you said no or yes. What matters is how you show your work, right? Because that's really what's on trial here. Your thought process, your approach to the problem. So, let's go into it. We can also get partial credit, by the way. I mean, if we're going to show our work, you know, it's it's okay if you mess up a step. Bigger thing is if you have a good line of reasoning. So, what I'd first start with is by saying, hey, look, this is a binomial variable. Sorry, not bali random variable. We did a thousand coin tosses and the expecta expected value is 500 heads, right? I mean, I think even a middle schooler could tell you, hey, you flip a coin a thousand times, you expect 500 heads. Maybe a high schooler, they know enough to say, hey, you know what? But it's not always going to be 500 heads. Sometimes, you know, there's random probability. It could be 5001 heads, 499 heads, but we could all kind of understand, hey, if it was 900 heads, that seems suspect. That seems too high. That seems like a biased coin. Well, instead of using random language to talk about that, why don't we talk about it in terms of, hey, it's a brutally random variable, can we compute the standard deviation? Like, what do we expect when we flip a coin a thousand times, right? And then from that, can we compute a zcore? Can we see how rare of an event is this? And use that to deduce, hey, look, this is three standard deviations away from the mean. That's a pretty rare event. I think the coin is biased based on that. Right? So, of course, in our gut, we might say no. And this is not to trick you. This is not a deep learning question. They're not trying to use any crazy new statistics here. And in a real interview, if you don't remember the formula for standard deviation of Brun random variable, that's okay. You can ask them, hey, hey, I forget what the formula is, but this is what I'd look up. Or, hey, do you mind if I use Google? I know I could just Google this formula. Or, hey, you know what? I forget what the exact formula is, but I know it looks something like this. And you know what? I'm going to guesstimate the standard deviation is 20 or 30 or something like that, right? All of these at least push you in the right direction, showing the interviewer that, hey, look, you're trying to compute a zcore, right? That's the kind of way the interviewer wants you to go and you find, oh, it's three standard deviations mean the kind is likely biased. So, coding interviews for a second. Um, they're pretty straightforward. straightforward in the sense they're hard but they're easy to practice and you don't need to know your full data structure and algorithms to solve your you know these questions like I think just knowing your basic loops and basic procedures is enough. I'm going to skip over this just because there's so much written about coding interviews. Um let me answer a question or two and then talk about SQL because I think coding there's just a thousand people who talk about data structure and algorithms interviews. Um, let me talk about SQL in a second, but let me just stop to answer a question or two. Um, because I see there's a few Q, uh, questions in the Q&A. Um, cool. What we have in the Q&A? So, uh, Pashant wants to know where you're from. Cool. Yeah. So, my parents are from India, but I'm calling in and I grew up here right outside Washington DC in Northern Virginia. So, that's where I'm at right now. And then I see Amisha is asking how should we start building portfolio projects. Yes, let me talk about this and then we'll get to SQL because Amisha you brought up a great question, right? Because I showed you so much about portfolio projects, the magic they can do, but it might sound overwhelming like where do you even start? I think the first place to start is don't try to innovate with some crazy new techniques. If all you know is Excel, go make a portfolio project in Excel. If all you know is Tableau or PowerBI, don't try to make a machine learning project. Start with visualizing some data in an interesting way in Tableau or PowerBI. Because the mistake people do is they say, "Okay, a portfolio project needs to be awesome." And in the first step, we're going to make it so awesome, so complicated, and learned a hundred things. And inevitably, no one ever gets that far, they quit, and it goes nowhere. So, where do you start is start with some stuff you already know. Start with using technologies you already know and are comfortable with. Find a data set you find interesting on Kaggle or data.world or like look it up and there's so many interesting data sets given out for free by state and local governments, NIH, UN. There's so many data sets out there and start by visualizing that data. Start by analyzing some basic stuff. Don't just jump into machine learning modeling. That's how you'd start. And then as you explore the data, visualize it, find some interesting things, then you can start doing some machine learning, you start doing some predictive stuff, you can start bringing in some new skills. But I just really encourage people like look, if you don't know any of these technologies, you don't know Python, you're weak at SQL and all you know is Excel. Well, just start there, right? And Tableau is a noode tool, right? You don't need to know coding to work with Tableau to build some really interesting dashboards and data insights. So I'd say go start there, right? That's how I'd say to start. Um, let's get back into the SQL part. Um, thanks for that question and we'll definitely have some Q&A at the end and I'll answer some more questions. SQL interviews, I think they're really important. I think they're slept on a little bit. I think people underestimate them. They think that, oh, you know what, I do R and Dippler all day. I do Python and pandas all day. Do I really need to know SQL? Well, but in industry most companies a lot of their data is in a database and you know even if you can always pull the data down and into a pandas data frame I mean sometimes you just need to chop stuff up really quickly and for that SQL is beautiful as such for a lot of data analyst jobs and a lot of data science jobs that aren't heavy on building models well they'll be doing a lot of SQL the other reason to really pay attention to SQL interviews is because often Even at more competitive companies, they'll be giving you a screening, whether it's hacker rank, codility, or code signal. They're going to give you a test that tests you on your SQL skills in a way that your stats will never really be tested that early, like through an automated assessment. SQL will be, which means if you don't want to get weeded out early, you don't want to be weeded out by a computer, let's go practice our SQL because that's a really common early screening round. And you know, they'll ask you two questions. There's a right or wrong answer. And if you pass, you pass. If you don't pass, game over. Because of how cutthroat it is, and because of how easily it is to judge these things, it's really important for you to practice on your own. So again, as I mentioned, I run data lemur, a free SQL interview platform, a way for you to practice for SQL interviews with real SQL interview questions. This is a real question from Twitter that was asked to a data scientist but a data analyst or data engineer they would basically get the same question too and it's about building a histogram of tweets. Basically given this input data how do we make the output where we say okay two people tweeted once in a year one person tweeted twice in a year three people tweeted seven times in a year something like that that's what you're expected to do. You can practice this problem yourself for free on data lemur. But what I want to call attention to is the solution real quick. We don't have time to solve it. But I want to show you all the solution because notice something. There's no join here, right? It's about one table. There's no window function here. There's no crazy functions. There's no crazy hidden knowledge right here, right? It's a group by. It's a count. It's aware. It's stuff that most people will look at in a beginning SQL tutorial. I don't think there's anything here that a beginner SQL tutorial doesn't cover. But the issue is during an interview with time pressure, with stress, with the need of translating an opaque business problem into SQL code. 80 90% of people will mess this up. I have the data. I mean, I run data lemur.com. I can see that 80 to 90% of people get this wrong on their first try. Even though there's no crazy functions, there's no crazy wees, they're not there's no trick here. 80 to 90% of people will mess this up because most people don't work with SQL day-to-day. And most people, you know, they, you know, halfass their way through a uh SQL tutorial without ever really doing the problem solving piece. You know, they know what account function does. They know what and group by does, but they're not used to putting all these things together into a 12, 13, 15 line SQL query. That's why practice is so important. And I really urge you all to, you know, check out data lemur and see all the free questions. And if your SQL is a little bit weak, because I get it, like we've all been there because I know I used more Python than SQL for a good amount of my career to practice, you know, go look at these questions and go check out the hints. Each question comes with multiple hints that kind of walk you through how you'd solve kind of hard question. So I think it would be pretty interesting for a lot of y'all, especially if you're a little weaker. And there's some really challenging questions from companies like Facebook and Google on data leaner as well. So give that a look. Um before we talk about open-ended case studies, I want to again take a second break. Are there any other questions we have about stuff because I know we ran through probability, SQL, ML, stats, um coding, C, you know, any other questions we have before. Um I keep going. There was one that came in about core languages to know, but I think that would probably be one best to wait till the end. Um, yeah, I think I think I can just tackle this real quick right now, actually. So, core languages to know. I think like start with Excel, right? Again, I'm not trying to say Excel is the best. I'm literally just trying to work our way up because I know we have so many people in the audience. Like, if you know Excel, great. That's the baseline to do data work because even sometimes you're a fancy data scientist, you'll still find yourself in Excel. Start with Excel. Then the next thing I recommend people to do is SQL. That's a core language. Doesn't matter exactly what flavor. On data leer, we use Postgress SQL because it's definitely beginner friendly and really common. If you're using MySQL or BigQuery, it's okay. I love Postgress, so I recommend that. After SQL and Excel, I recommend a visualization tool like Tableau or PowerBI. I don't think that they're crazy to get started with. So, you know, hopefully that doesn't take too long. And then after that, I would like to add Python. and if it's okay if you know R or something else but after a certain amount of these core technologies it doesn't help to add in your seventh programming language or a fifth flavor of SQL you know because at the end of the day as data scientists it's not about the technologies we use it's about finding insights in data helping the business grow through data right and for that you'll find people in SQL who can do crazy stuff and then on the flip side you'll find people who know Julia R Python C++, Java, all kinds of stuff. But never really find insights that really move the needle for a business, you know? So, let's not overly focus, of course, on core technologies. I think if you've got Excel to blow, Python, and SQL down, like you're in a great place to do the core work of data science and data analytics. Um, Frank asked a really interesting question. Um, excuse me, it's allergy season here in Northern Virginia. Um, Frank says, "Uber one day changed their titles from data analyst to data scientist." Excuse me. Um, what is a data scientist? I mean, does the title really matter? I mean, Uber literally called data analyst, data scientist one day. Frank, I've heard a similar story the same way. Um, again, uh, Chamoth, he used to head growth at Facebook. He's a big venture capitalist. He's a host on the All-In podcast, pretty famous personality, and he's a billionaire. He owns the Golden State Warriors. Big guy. Chamath said he couldn't hire analysts at Facebook because Ivy League economics folks didn't want to be called an analyst. So he just called them scientists, data scientist. And that's how he he's he claims to have coined the term data scientist. Again, he's a kind of braggy guy, so I don't even know if that's true or not, but you know, the story checks out that data scientist sounds a lot cooler than data analyst. But what really is a data scientist? Um I don't know. I I just think n going into these titles is not that helpful. Uh because honestly companies themselves haven't figured it out. People are inventing these terms, right? Like these this is not there's no some science behind it. Literally Chimant says he did it for marketing because he couldn't get Ivy League PhDs to work for him as an analyst. So he just called them scientists and that's that's how he did it. Right? So that's why I'm like saying like yes people have retrofitted some definitions like oh data scientists do X but data analysts can't do Y but I just kind of now now that I know how the sausage is made you know now that I know like oh okay you know it's similar enough and some of this is gatekeeping like I don't really feel like going down exactly what's the difference between a data scientist and data analyst because for enough places you could kind of jump between the two. Um I do like though one thing that Frank mentioned which is a quote from Josh Wis. It's a really famous quote which says a data scientist is a person who's better at stats than a software engineer and a better software engineer than any statistician. Yeah, I think that fits too. So that's what I'm saying. Like I think that answers for all these things like what's data science. It's a very cheeky answer, right? No one says, "Oh yeah, if you do X you're a data scientist." It's like a cheeky thing like oh someone who kind of knows code and kind of knows stats, right? Which honestly a data analyst is something like that too. um and maybe you mix in a little bit of business sense for a data analyst but again low-key a data scientist also know needs to know business sense so again I get confused so I will refuse to answer that question but hopefully y'all can see that titles don't really bother me it doesn't really matter um Nathan asked for non-fane companies are coding interview questions easier yes Nathan they are they are your Python questions might be much simpler you might not even have Python questions enough data science jobs don't even need Python. Yes, data science courses teach you Python, but there's so many people who get by really far as a data analyst or data scientist with just SQL and Excel and a visualization tool. That's the dirty secret. Maybe at a top company, that's not the case. But for most companies, more Fortune 500 companies, most companies that are hiring today, you know, you might not even have an explicit Python coding round or an explicit data structure and algorithms round. Cool. Now, let's talk about open-ended case studies this slide and then I'll also have you guys run through a question or two. So, again, have your phones out and really try to internalize this because I'm going to have you guys also help me out here in the next slide or two. So, open-ended case studies, again, people think you can't prepare for them, but you totally can. And there's a totally a pattern you can use, which is whatever the question is being asked, clarify what the question is about. Make sure your answer is always aligned to the product and business at hand. And whatever you do, mention trade-offs because no one answer is correct. For such an open-ended question like building Uber search pricing algorithm, you in 30 minutes, you're not going to give the perfect answer. I mean, there is no perfect answer. It's like a real team and a real project that people work on for years. So that's why whenever you say a solution, always, you know, give some of the caveats or some of the me, you know, mention some of the issues with your solution. It'll help show the interviewer that you can really think robustly about what you're talking about. But let's put it into practice. Let me give you a real open-ended question that was given to a data scientist at Facebook. Product managers, they might need to know this. Data analysts, they might need to know it. And other companies totally give these kind of questions, too. So, pretend you were working on Facebook dating. What metrics would you use to define the success of Facebook dating? Right? So, imagine you have a beta test in Brazil. The product's been out for 3 months. you know, it's a new product. It's only in Brazil and it's sort of like Hinge. It's relationship oriented. You're trying to help people find relationships. What metrics would you use to define the success of Facebook dating? Right? And remember, whatever answers you have, and I'm going to have you answer this in one second, but whatever answers you have, remember, keep in mind like Facebook's mission is all about building people, bringing people together, and forming meaningful social relationships, right? So, if you can find some metrics that can encapsulate that, that would be good. So, let me bring it over to you all. What metrics would you use to define the success of Facebook dating? I want to hear from you all. There's no one right or wrong answer. So, definitely scan the QR code. You don't need to log in. takes one second and just chat what your ideas are cuz again there's no one right answer there's no one wrong answer there's like eight nine good metrics you could use you know some bad metrics are actually good metrics are bad I want to hear from you know I want to see at least 7 8 n 10 answers here so scan that QR code and Yeah. Cool. These are some good answers. Keep them coming. Want to see a few more. Um and I will start talking about these in a second, but I want to see one or two more answers. I'm seeing some really good stuff, so keep them coming because again, there's no one or right or wrong answer. So if you have it open, like feel free to put a second answer in. I want to see Cool. Let me start talking about them and keep the answers coming in. But let me talk about a few of these. And by the way, for context, imagine, you know, like Zuck literally uses this kind of data to figure out should he lay off teams, should he reorg teams, should he expand Facebook dating to the rest of the world, should he stop Facebook dating, should we, you know, what should he do with Facebook dating? He literally will have data scientists pull these kind of numbers or I mean, Zuck doesn't know what numbers to pull. Literally the data scientist's job is to sit there and pull the numbers proactively so that when he meets when he or she meets with Mr. Zach, he has these numbers ready to go, right? So I see relationships. Okay, so money generated. I see relationship status, DMs, um time spent. Sure. Time spent's a great one. Personal satisfaction where how do I measure that? Right? Like I mean that's what we're trying to figure out. Where is there a table at Facebook called personal satisfaction where we can query it? Is there a table? Is there a column called relationship longevity? I don't think so. Feedback. What do we mean there? Survey feedback. I mean, we could always survey users, but a company like Facebook where everything's instrumented, why ask for feedback when you can just measure some of these numbers, right? Because we can already see usage, right? We can see DM sent. We can say how many people are chatting with each other 7 days or 14 days after they matched. We can count the number of matches. We have access to Messenger, Instagram, and WhatsApp, right? So, that's something Zuck would want to know. Like, yo, Facebook dating, it's an okay app, but it drives a lot of usage on Messenger, WhatsApp, and Twitter. Uh, uh, sorry, Messenger, WhatsApp, and Instagram DMs. Maybe maybe that's a good thing for him because he's trying to monetize those and grow usage across an ecosystem of apps, right? Number of users who delete or deactivate the profile for more than six months after matching. Yep, that could be interesting. But here's the thing. Remember the problem statement was we only have 3 months of data. Zuck is not a patient guy collecting the that data of who deleted their thing 6 months after matching. I mean, that takes me six months to collect. Do I really have six months or a year to figure out if my product is good or not before I scale it? No. I got weeks. I got months because Zuck is a, you know, people are not patient. This is not a slow growing company. So this is what we mean by lagging versus leading indicators where we can. We'd love to have a metric that we can measure in 14 days, 7 days, 21 days because we only have three months of data. I can't wait for seven months to figure out, hey, did people get married or not? Right? Number of couples, how do we measure that? Right? Four scheduled dates. How do I measure that? I can't I don't know if you measure, you know, scheduled a date or not. Companies like Tinder and Hinge, they do a user survey. If they think you've scheduled a date or you've gone on a date, they'll ask you later like, "Hey, did you meet up with so and so? If so, how was it? Thumbs up, thumbs down." That's their way of figuring it out. But here at Facebook, I mean, we can always survey them, but you know, maybe we can just use talking to each other as proxy for a good match, right? Or, you know, uh, I'm surprised. Okay. lens of DM. Sure. Number of users. Yeah, sure. Deleted. See, that's a very interesting thing. I don't want people delete their profile on Uber or Airbnb. But maybe on a dating app, it's okay if people stop using Facebook dating. Which makes a question of churn really tricky. See, at the beginning of the talk, I talked to you all about how I tried to lower churn on Facebook on Facebook and on rapto. How I tried to improve retention. But maybe on a dating app, maybe retention isn't what we want. Maybe we want people to find the love of their life and delete the app. I mean, literally Hing's motto, the dating app Hinge. Their slogan is designed to be deleted, right? So, that's their kind of cheeky way of saying like, "No, go for it. Like, we really think that you're going to find the love of your life. Like, you should delete the app when you're done with it. Like, we want you to do that." So, that's something interesting. That's like a twist in retention. So, this is what I mean by like, yeah, I guess we want high retention, but every answer has a trade-off, which is, hey, we'd also want to see retention because the app sucks or retention like did you quit the app because it sucks or did you quit because you found the love of your life, right? We'd want to kind of quantify that and understand that. Um, yeah. So hopefully this gives you a perspective of like how answers could be good or bad and how there's no one or right answer, but each one has its own kind of nuances, um its own kind of tricks. Um money generated. That's an interesting one, right? I mean, most companies care about revenue, but do you really think Zuck for three months of data from Brazil, do you really think he cares about how much money was made in Brazil in three months? Or is he looking for product market fit? Is he trying to figure out do we scale this app or not? Right there when you know when something is launched and doing well there he cares about monetization and how much money it's bringing. But in the early days where we don't even know how our app is doing. We don't even haven't scaled it out. We care a lot more about just like are people matching each other? Are they messaging with each other? Are people using the thing? We don't really care about money generation in the early days because hey it's a big company and this is just a beta test, right? So hopefully that gives you perspective. Usually money generated or revenue is a very good metric, very important for every business. But on a beta product at a company like Facebook where it's only in Brazil, maybe it doesn't take a maybe it's not as important. Now my secret to doing 10 times better on these open-ended problems because again people claim people always say, "Yo, Nick, you cannot practice these." Except low-key you can, which is why the whole chapters 10 and 11 are about this about product sense questions and case study questions. That's like the last two chapters of the book. But anyways, people say you can't practice. People say you can't there's no secrets. You can't even expect what to you can't even know what you're going to be asked. But I think you can because every company asks you a question about their own company. Facebook asks you a question about Facebook. Uber would ask you a question about Uber, right? So imagine you got this question at Uber and this is a real question asked to data scientists, ML engineers and data engineers at Uber and software engineers for like system design and for data people it's a little bit more not system designy but you can read to do better because you know at Uber you're going to be asked about Uber you can go and do your homework and read the quarterly reports. You can check out the Uber's rider and driver app. You can use the product. You can read the engineering blog. you can proactively see and find and learn what does the company care about, what does the CEO care about, what do consumers care about when it comes to Uber. And the stuff you learn about Uber will apply to Lyft, will apply to Door Dash, will apply to Instacart. I mean, think about it. Uber is a marketplace. Dating is a marketplace. Some of the dynamics for how people match drivers to writers during search pricing is a lot like how do you match people for on a dating app when maybe there's more men than women or more women than men, right? I mean, that's like kind of like a search pricing problem. Search pricing is all about there's way more people who want to ride than drivers. I mean, dating apps, they keep battling with there's way more guys than girls. How do we match that? How do we measure search pricing? How do we figure that out? So you start doing enough homework for enough companies and you start to really do your research about how these products work and what they care about, you start to realize you can ace not just the Uber interview, but you'll start to do do better and build your product in business sense across companies across problems. So that even if you're given an open-ended business or product sense question, it's nothing to you. You'll be able to do it. That is my secret to doing 10 times better. Now, um, next slide. That's it. That's that's the that's the talk. We'll definitely do some Q&A, but I want to thank Nathan and the Data Science Dojo team for having me. Definitely check out the book on Amazon. Hit me up on LinkedIn. I have about 140,000 followers on there. Go practice some questions on SQL. There's a whole bunch of free content there. Um, but yeah, we'll get into some Q&A. But, um, thank you all for having me. All right. And I know one person is asking uh if you can say the name of your book one more time. Ace the data science interview. Yes. If you search it, you will find it. Ace the data science interview. I also think if you just type in Nick's name, you'll also find it. Yes. Um maybe they were being cheeky. Maybe it's because I didn't mention enough times. Although I did. It might have been a cheeky one. So, feel free to scan this QR code um to ask me some questions or drop in the chat, but I think the slido Q&A part is pretty cool, too. Um so, yeah, feel free to ask me a question here. And just to start, um I will answer one question from Ali. Um Ali is asking is it normal to open Stack Overflow or Google during a technical interview? Um different companies have different rules about it. I think if you have to Google something really simple like something they ask a non-standard question. So it's okay to Google for a method or function you don't use that often. If it's really vanilla, like that Twitter question where it was just group by count where, maybe it's not good to Google. Um, but it really depends company by company. And usually if you're like, yo, I literally know what this is, but I I literally just forget the syntax. Can I Google it? Most interviewers will be okay with that cuz they know that in the job you also Google syntax and it's like if you literally know what to do, but it's just a syntax issue, then you can Google it. Now, if you're starting to Google like what's the literal solution to the problem, then that's very bad. of course. Um, cool. So, let me answer some more questions and definitely scan that QR code to ask a question because I know we have people in the group different spots. So, definitely scan it and let me know and I'll try to answer a few questions um before the time's up. What do pe what do you find people struggle with most while preparing for interviews? Um, the biggest thing I see people struggle with is they underestimate how much time it takes and they that freaks them out or they don't realize the intensity with which companies interview at. So, if you've never interviewed like a fang company or a really competitive place, you might be really surprised like, oh shoot, I need to know my probability in statistics. I mean, I did that stuff in school so long ago or I did that so long ago. So I think that's something that scares people. The other thing that people struggle with is they think they need to be an expert in everything. In the book I have divided the questions into easy, medium, and hard problems. I think people try to do one chapter and do all easy, medium, and hard. When in reality, I'm like, yo, if you can just even do easy questions from all the chapters, that's a really good place to start. So I think people sometimes overwhelm themselves and look for perfection when you know just even being you know a little spending a little bit of time to just do a smattering of problems will get you really far. Um is the book beginner friendly? Um sort of. I mean if you know some of data analytics or data science you can hang. Otherwise the book is not good for teaching you like net new data science if that makes sense. Like this is not a data science 101 book. It's a way to test your knowledge. It's not exactly a way to like teach you from scratch. Oh, here's how to do linear regression, right? Like that's not what we're doing. We're not showing you how to do that in Python or R. We're trying to test you. Is there e ebook? No, there's no ebook. It's only available in paperback on Amazon. There's no ebook. There's no PDF. You can't find one online because we've never released an e PDF or online book. But many of the questions are there for free on data lemur. So data lemur is sort of our ebook. How many projects should be in your portfolio? Great question. I think two is nice, but not like you really don't need three or four or five. If you have the time to make a third, fourth or fifth portfolio project, go make one of your portfolio projects just better. Publish it, put it on GitHub, add some more features, make it live, put it on the Play Store or App Store, whatever it is. Make that project more complete. Here's why. And the reality is in an interview it's time constraint. They're not going to ask you about all your jobs, all your internships, and all your projects. Usually, they say, "What's your favorite project you did?" or "What's your proudest accomplishment?" or "Tell me about a time that you really struggled to do a project." And that's basically teeing you up to talk about one of your projects. So, because of that, because of that, that people don't normally just randomly say, "Hey, tell me all about all three of your projects." Because you had to pick what project you talk about. It pays dividends to have one or two really meaty projects rather than try to go for quantity. How much knowledge of statistics is required for acing an interview? Um it varies. Again, look at the easy questions on data lemur or in the book to get a sense of how much stats you need to know. Um it's really hard for me to answer. I do like the book um practical statistics for data scientists. I think it's a good way to learn stats. I think data science dojo has some stuff on stats. There's so many places to learn stats and you can always do better. But I don't think you need a masters in statistics to ace a data science interview. You definitely don't need a masters. Like if you even have like a first semester or two semesters worth of statistics, you'll be okay. And you know if you just know your hypothesis testing, you know about your probability distributions, you know your base formula, base theorem, you're good. If you don't know how to answer a question technically that's really hard or it's really crazy. If it's about something you've never heard about, you can say, "Hey, I have no experience with that. Like, can you give me some hints or like I really just don't know about what that is." And if it seems somewhat familiar, but you're just kind of confused on where to start. Talk out loud. Whatever you do, don't just sit there quietly. That's the worst thing that can happen where you sit there and you act confused. That really does not work well because then the interviewer feels awkward and then just like, "What's going on? Uh, and it just turns out we are out of time. So, so it kind of works out perfectly. Perfect. So, uh, yeah, Nick, thank you so much for being here and, uh, hopefully we'll see you again soon. For sure. Thank you for having me and thanks for the great questions and the great answers, everybody. Um, see you all around.