What I Learned From 100 Data Engineering Interviews Interview Tips

Hello and welcome to your data engineering interview at Facebook. My name is Ben and today we'll be doing three different sections focusing mostly on ProductSense, SQL, and Python. That is the intro most people hear when I'm about to give one of the 100 plus interviews I have run at Facebook over the last three years. At my peak, I was running about three interviews a week, all focused around various data engineering questions that we would ask in the ProductSense, SQL, and Python sections. During that period of time, I saw a lot of different trends and tendencies from all the different interviewees, whether they were an intern, a new grad, or an industry professional. In this video, I wanted to talk about some of the realities that you will face when you interview at a company like Facebook. The truth of the matter is, most of us interviewers are rooting for you because we have also been in your very same shoes. Along with that, I wanted to discuss some of the trends and tendencies that I see from different groups. Again, breaking this down into things like interns, new grads, as well as industry professionals, and tell you where different weaknesses lie in these different groups so hopefully you are better prepared. Starting with the realities of interviewing at a company like Facebook, it's important to realize that most companies actually want to hire you right out of the gate. It might not be well known, or maybe it is, but companies can spend upwards of $30,000 just to hire one candidate. Whether that's going to a recruiting agency, which is very common, which is why all those recruiters seem to keep pinging you on LinkedIn, or just through company time. You know, when you think about all the meetings required and interview prep and all the people that they don't accept for the role, there is a ton of money and time spent interviewing. I mean, just think about it. If I'm personally running three interviews a week, also being part of one or two reviews as part of that week, that's four to five hours a week, or 10%, all focused on hiring new people. For me, one data engineer. Imagine the other near 1,000 or so that are working at companies like Facebook, meaning these companies are easily spending millions a year just to hire a few candidates. And with Facebook recently announcing that they're going to be hiring 10,000 plus employees for their new push into the metaverse, you can see where there's going to be, again, millions if not tens of millions spent on hiring. That's just one reason that most interviewers, like myself, honestly want you to pass. In addition, we've all been there. So the first reality is, again, as a baseline, when you come in as an interviewee with me, I want you to pass. I already believe that you have the ability to pass this interview, and it is kind of my job to elicit that from you by giving you the right hints and directions. So that way, if you get stuck or find yourself down a path that really is going nowhere, hopefully I can catch it before it goes too far. Honestly, my goal is always to versus me, the interviewer, trying to just get you to do a bunch of tricks in front of me. Because as someone who's been there, it's no fun to just have someone sit in the corner quietly and watch you struggle as you sit quietly at a whiteboard to write nothing. And so that's kind of the baseline. When you come into my interview, I already believe that you have the right skills to pass, and hopefully I can somehow pull that out of you so that you can go on to the next round feeling great, or at the very least, even if it wasn't perfect, I hope you leave with some positive attitude. That way you can go forward and not feel like your whole day is ruined. So that just starts to get us on the same page. Speaking of same page, the next point I have to bring up is, honestly, especially for my round of the interview, where I'm mostly focusing on your technical skills, I probably haven't looked at your resume. It's not to say that I don't care. It's not to say I don't care where you went to for school. It's just to say that my focus is testing your skills. I don't want to feel biased towards where you've worked before, whether it was another thing, whether you went to Harvard, I don't really want to care. I want to give you a fair shake, regardless of where you've been, what your background is. To me, what is important is your skillset, especially when it's more of a technical interview. Now, for those rounds where you're doing more ownership, you're likely going to have to talk a little bit about your resume, kind of some of your projects that you've taken on, your role in them. But for more of the technical rounds, at least at tech companies, you're likely going to have to focus on these questions, and I'm not going to ask too much about your background and what you've done before. We have a limited amount of time, and I want to give you as much of it as possible to focus on answering these questions. Like I said before, I am rooting for you to pass, and my focus is not so much about what you've done in the past, but my focus is to help you get a pass for my round. That being said, if you don't, if you know that you completely bombed whatever round it was, whether it's ownership, one of the tech interview rounds, system design, it's really important that you not let that bring you down. You need to have that Naruto level of optimism where nothing really kind of takes you back. If you have one bad round, it doesn't mean everything is over. At the end of the day, you have four or five loops that you've done, each which gave you a different opportunity to succeed or fail. And honestly, if you've done well on most of them, there's a good chance that you'll have maybe one or two people fight for you in the reviews. And honestly, if someone has three good rounds that are a good mix of technical and ownership, and then maybe one off round, there might be some consideration to either send you on another loop for the interview, because maybe you just need to show that you are solid in some technical section, or maybe honestly, they might look past it and say like, hey, we might just need to help grow them in this area. This is also somewhat dependent on your experience. This is where people might start looking at your resume. You know, again, if you've been in the industry for a while, you know, it looks slightly different than if you're new. Also, depending on the company, some companies are really good at like, you know, like, okay, this was more of a consultant versus someone's an IC versus someone that's like a director and all of these different positions, right, like have different expectations and different kind of methods of operating, like a consultant might operate slightly differently than an IC, like an IC might generally have a little more tendency to have ownership because they work at this company for a long period of time, where the consultants often brought in, especially if you're earlier on in your career, to just solve a problem and then maybe not take further ownership beyond that. Usually you have a very defined scope of work. Again, depending contractor consultant, that can sometimes be somewhat the same, sometimes blurry of a line, but it really depends. And so you might not have that same level of ownership. Not that that's bad. It's just, it's different, right? Like at the end of the day, you have different ways of operating. And sometimes that's taken into consideration. The point being one bad round won't finish you off. You know, it's kind of like you have a few chances there to do well and don't let again, one bad round ruin your day. It's all about learning. It's all about trying to get a little more experience. And in fact, I recall having one not so great round at Amazon, but then I used that kind of not great round in Amazon to then do another round like five minutes later and help answer a SQL question very quickly because they happen to be asking somewhat of a similar question. And so I was able to kind of bring that in from that previous round. There's always a chance to and we have all had it. We've all done it, but don't let that kind of stop you in terms of like, you know, being like, okay, now it doesn't matter. You still honestly could have a very good chance of passing just as long as you can show your skills in the next few rounds. Now those are just a few realities. So let's talk trends and tendencies of different types of interviewees. And again, I mean like interns, new grads and industry people, a wide range of experience sets. And we're going to kind of talk about the area that I focus on more heavily and what I've seen kind of in terms of patterns and tendencies. First, I'm going to kind of group together grads and interns actually, because they do tend to have some similar tendencies. First, starting out with like product sense. In general, most interns and new grads don't have the greatest product sense. And it's not something that's bad. I think it actually makes sense. You might not have thought about products, kind of KPIs you should be using to track them and what you should actually be tracking in terms of metrics as well as like logging. So it kind of makes sense that you're not the greatest in this area. But I will also add that if what we're focusing on is like, say, Uber, and you tell me something that you could track on Uber or like Uber Eats, let's say, is the number of orders that you get in a day. That's a good metric. It's not bad. But I could probably go on the street and just ask someone, you know, what do you think is a good metric for Uber Eats? And they'd probably tell me the number of orders and the number of users that are, you know, utilizing the app. Again, solid metrics. These are very important. You want to see those go up. But when we're doing like feature focus kind of questions, you know, if I'm just looking at like how people go through the order flow, like, let's just talk about that. And maybe even just the search for maybe like a product or a restaurant. More specifically, I'm not asking for the number of users that use that. That is a baseline metric. I want to know a lot more. I want to think about like engagement. I want to think about where maybe people stop in the whole process of using this app, or maybe how many people end up leaving without actually ordering something. Those are leaning into the more meaningful metrics that you want to track and where you can actually start providing more of a why into certain things happening, or at least where you can start drilling into maybe that why. And so just answering me daily users or daily kind of orders. Again, great baseline metrics. That's what someone from a very high level is going to be interested in. But when you're focusing on a specific feature, like you would be at a large tech company, you're usually only focusing on a small section of a workflow. And that's what we're kind of interested in. If we wanted to improve this one set of steps, so maybe even five or six steps, how do we make this five or six steps better? Not afterwards, not before, just this five or six steps. Again, from a big picture, that's something that the product manager might look at. But for a data engineer, you're kind of just focusing on this little bit. And you can think about the big picture stuff later on. From there, in my experience, when it comes to SQL, most interns and new grads are pretty solid. You guys can generally do the baseline in terms of SQL, some aggregation, maybe even the self-join or two, which is great. So that's usually solid. But on the other side, one thing that I've noticed in an interesting trend, especially with grad students that are data science focused, is your Python is generally lacking or just your coding in general. Obviously, I focus on Python, but whether you like Python, Java, C sharp or something similar, it's still this overarching problem. Again, especially with people who focus more on I think modern Python or modern kind of like Spark concepts, which is a lot of people understand data frames really well. But then when you need to use something simpler, like when you need to use things like arrays or lists or dictionaries, you just have a much harder time kind of utilizing them. And I've seen people try to answer a lot of their questions using data frames, which is like trying to use a chainsaw to cut down a bonsai tree sometimes. We just need to solve this very small problem. And you're trying to use this whole massive data structure that really is unnecessary for this moment. So I would say, you know, if you are a new grad or an intern, do make sure you've got some baseline data structures and algorithms. Honestly, especially if you're using Python, you're not even having to know like half of what a lot of other people have had to know in the past where, you know, people had to know things like stacks and queues and linked lists and different types of trees and all of that. Now we're just really asking for dictionaries and arrays again, depending on what company you're going into. But that's just kind of a good point to point out that like you should have, especially if you're just using Python, a good understanding of those tools. Jumping into industry folk. Here, product sense usually tends to be on point because you have a general understanding of what metrics are important to track. Maybe you've built a dashboard in the past, or maybe you just kind of understand that it's important to be a little more granular and not just think about, again, super big picture, but also think about, okay, for this specific feature, what am I tracking? So that's usually solid. SQL is also usually pretty well done. The one interesting thing here is that by the time you've picked up more SQL skills, you'll often use things like lag and lead and other sorts of window functions, which continuously, regardless of the company that I go to, oftentimes, if I throw in a lag or lead or try to use a sum with, again, an over and a partition by, generally, they'll ask me not to do that. So in a weird way, we have more SQL skills and more kind of those tricks up our sleeve, but we often get asked not to use them. So that's just kind of a pain in the butt, but you might just find yourself having to figure out how to do a self-join versus using a lag or lead statement. Python in itself tends to be a mixed bag. I often do find industry folk know, again, the baselines and can utilize a lot of the basic data structures. And from there, it's just about making sure you fully write out the whole problem. And so in this case, there's a little less to say here. Yes, you should practice a few leak code questions. If you're coming to Facebook, I do think they try to ask more operational questions and less algorithmy questions. So that's kind of nice if you're a data engineer. And looking back to a lot of other Fang interviews, I did notice that Python wasn't always a major component. When I interviewed at Amazon, they were much more focused on like SQL and like database design and things of that nature and not heavy on the coding. So it is always kind of hit or miss. And I do recommend you spend some time ahead of your interview, figuring out exactly what your interviewers will be asking, because hopefully you've got a good recruiter. They are telling you ahead of time because these days everyone thinks that they know how to run interviews best. And it's really hard to know what is the best way. I'm sure some people below would love to comment about how they think, you know, leak code style questions are wrong and a terrible way to run interviews. And sure, there's a lot of good discussion there. I definitely see the problem. Like every time I think about ever interviewing again, I'm always like, oh man, do I want to study leak code problems again? And let's be real. The answer is no, but for now it is at least a major part of most data engineers, software engineers and well, data scientists life. So I don't want to say get used to it, but sadly, it is the case where we might have to. With that, guys, I want to say thanks so much for watching this video. I hope my experience interviewing people was helpful. Let me know in the comments if you have any questions. And other than that, I will see you next time and goodbye. Transcribed by https://otter.ai