LED:  So to kick things off, why don't both of you give us a quick intro to yourselves.

​

Nick:  My name's Nick Singh. I'm the co-author of Ace the data science interview. I've previously worked at Microsoft, Google and Facebook in a variety of data science and software engineering roles. And these days, I'm all about helping people land data science roles and prepare for the technical interview.

​

Roy:  My name is Roy keys. I've been doing data science work for about a decade now and almost all with startups. So on the smaller side of things. Last year, I put out a book called Hiring Data Scientists and Machine Learning Engineers, aimed at fellow managers who are trying to hire for these data roles.

​

About half of my career has been spent as a manager leading teams doing data science machine learning stuff. And you know, I've looked at 1000s and 1000s of resumes, and of that hired a handful of people, there are a lot of applicants. That's one of the big things and, you know, hopefully, tag teaming with Nick, we can give you some interesting and good advice.

 

LED: I want to start things with talking about the initial application process. And as both of you have hinted at this already, the resume is sort of like one of the things that candidates stress out a lot about, how do I put together a good data science resume. So if you could tell us a little bit about what are the key elements that candidates should think about. And I'm using the word data science as sort of a little bit of an umbrella term, we know that in tech, there could be different types of data science roles, if you want to contextualize, please feel free to do that.

​

Roy: I'll talk real briefly about the landscape of the different roles that are in the Data Data Science World. I think right now probably the big divides are around sort of analysis on one side, and analytics. And then machine learning on the other side. Now, there's a lot of people who do both of those things, and you need analysis around machine learning.

​

And sometimes you're doing machine learning to help your analysis and all these kinds of things. But the roles that we're seeing a lot is kind of people that are working on the analytics, whether they're called data scientists, they might be called product analysts or analysts. And then on the machine learning side, they might be called data scientists, but they might be called machine learning engineers or machine learning researchers or machine learning modelers, there's a bunch of different titles.

 

Then I'd say also in there, there are some people that are closer to data engineers, those are people who are helping to get the data, move the data, put it where it needs to be, make it available. And then there's a new title that's come out that it's getting very popular called analytics engineers. And I know people will yell at me for saying this, but one of the main things they're focused on is like putting dashboards and stuff into production.

 

And so, you know, depending on what role a company is advertising, which they may be very bad at actually advertising and making it clear what the role is, you know, if it says analytics engineer, hopefully that that is a specific thing, if it just says data scientist, and it says, you know, you need to know how to do Power BI, and you also need to know how to do TensorFlow and pytorch. For deep learning, like you know, this, you probably don't know what to do. Doing but that also you need probably a pretty general approach.

​

LED: Yeah. Nick, did you want to add something to that?

​

Nick: Right? No, I agree. There are so many different data roles. But I think, point to your first question of like, well, what what does that actually look like for the resume? I think that regardless of the role, a lot of the resume tips still stay the same. Later on. When we talk about the technical interview part, I think that's where it starts to really differentiate. But yeah, the interview for the resume. I think that like, people have too long of a resume.

 

So we got to keep it from one-to-one page, if it's, you know, under 10-10 years of experience. And I think another thing that people get wrong, regardless of the role, is they put too much fluff or too many details that drown out their best content. So it's so easy to put in things like, Oh, look at me, I'm trilingual, I speak Spanish, Hindi and English. And it's like, well, aren't all these data jobs in English, you know, and I mean, that's such a small thing to nitpick.

 

But when across a one-page resume, you keep putting extra information, that doesn't really matter. And it drowns out the relevant project, their own work experience, the relevant tech stack you have, because you're just putting in synonyms and, you know, objective or summary at the top, that's very vague, and that just says, you’re a hard-working data person looking for their next challenge, you know, that's just fluff. So I think those are some of the big things that I've seen, from reviewing a lot of different resumes and things, people could do a lot better. And regardless of the role.

​

Roy: I think there are, you know, there are some kind of extreme examples of roles that meant, you know, if you're going to be a machine learning researcher, I expect to see where your PhD is from and all your publications listed, or something like that. Right? Right, that's probably a longer a longer thing, you know, versus if you're in, if you're trying to look for an internship job somewhere, and you know, you're not going to have a lot of experience. So you don't really expect that the things that we're looking for is, is this person, reasonably in the right ballpark for basic skills? Are they does it seem like they're someone who's been able to work hard, and you know, I don't know if you can say, you can see that they're smart from the resume or something, but also, often just, is there something about them that stands out? So I think, like what Nick said, you know, you can easily add too much fluff.

 

And I would say, to me, the, the most important thing is that you put your stuff that makes you look solid, as you're emphasizing that as much as possible. You know, and who knows, you know, maybe maybe Nick applies for a job that's focused on natural language processing for, you know, Hindi, and Spanish stuff. And so it's perfect that it says, He can do that. But you know, so in some sense, you also want to think about tailoring a little bit depending on on the actual role that you're looking at. 

​

LED: Yeah. 

Roy:  So I would, for example, have different resumes, for kind of the industries that I'm working in. So I've in the past, I've worked in different different places, I've worked in stuff that was, I've worked in food delivery. So you know, that one is all about more logistics-oriented stuff. I've also worked in medical worlds.

 

So it's like, if I'm applying to a role in those different areas, I'll emphasize different parts of my experience. Because I think one thing, the big the biggest problem on the hiring side that I face, and it's the same problem that or it's like, the flip side of the problem that the candidates are having. So there's just so much competition, there's just so many people going for these roles right now.

 

And so, you know, I want to be able to look for people that all kind of look the same, but oh, you know, if I'm in healthcare, and so this person has some background, that at least you know, maybe we'll help them understand and get up to speed more quickly, because they've, you know, worked in some sort of healthcare or healthcare adjacent space. There are things like that, that I think are important to emphasize if it's going to help you.

​

LED: Yeah, make sense. So just to follow up questions there. So the first is, you mentioned how you're looking for, you know, do they have the basic skills? Are they smart? Can they work hard? And then is there anything about them that really stands out? So could you perhaps share an example of what a strong resume bullet point looks like? 

​

Roy: So I think that for a lot of these roles, like I said, there are many, many candidates, and a lot of them look very similar. They've got, you know, this same types of degrees. They've done the same types of projects, especially projects for class. And so, you know, I want to see if I'm looking at the resume I, you know, not everybody goes to Harvard, or Stanford or MIT or something like that, but, you know, I'd like to see something that sticks out out. And we can talk about school stuff later. And what that means I have a, I'll take one start side route here for a second, which is that my advice to hiring people is much different than my advice to people they're trying to get hired, because most of the people that are hiring people won't follow my advice anyway.

 

So, but, you know, I want to if I see that someone has done something that's interesting, to me, like a very interesting project, but especially if there's sort of some kind of evidence around that it's good. So, you know, if you if you built something and it was featured on Reddit or something like that, you know, that's a little bit more interestingly, than if you just did it.

 

And it was for a class, if you did something, and you contributed to an open-source project. That's, that's known. And you know, those, the maintainers of that project, are they've looked at your stuff and accepted it. So there's kind of this bit of validation that's happening. And I'd like to see that stuff.

 

The main things are sort of highlighting things that are above just the basic level qualifications that probably everyone is going to have, you know, everybody, if they're, if they're doing a role. That's like machine learning, for example, everybody's going to list that they know, hi, phone, everybody's going to list that they know, psychic learn and one of the deep learning frame frameworks like TensorFlow or pytorch. The question is, you know, what are you doing? That's going to jump out to say, you know, not only do I know this, but I've actually used it in some way that I can show off, or is maybe a bit different than what everyone else has already done.

​

LED: Right. Make sense? So I guess my next question is then a little bit related, which is that, let's say a candidate does not have prior industrial experience of working in a data science role. Maybe they've only done projects in class, what can they do to make they’re their application really stand out? Can they do something on their own?

​

Nick: Sure, I can talk to that, because I've helped a lot of people kind of do that because so many people come from so many different backgrounds, and might not have the formal credentials and need that kind of extra leverage. So I'm a huge proponent of portfolio projects. So a good portfolio project is kind of making your own experience in the absence of formal work experience.

 

And just as actually, the boy had mentioned of like, hey, if something got traction on Reddit, or there's a cool demo that you know, actually worked, or your GitHub repository, you got a lot of stars, those are actually a word something. So what I tell candidates is try to make a portfolio project that's somewhat needy, not with an interesting dataset, not something that you would have used in school, not something that everyone's already used. You know, some of these standard datasets like the Titanic data set from Kaggle, like forget about those, ideally, maybe even make it use a data set that's based on your passion. You know, I love hip-hop music growing up.

​

And in college, I made a thing called rap stock IO, which was fantasy football, but for hip hop artists. So think of it like you could make your own fantasy label. And draft artists or another analogy would be a stock market where you could long or short, different hip hop artists as a way to kind of show off your case, and show off for predictive abilities that you could predict who was a good artist.

​

So I built this project out, I worked with a bunch of data sets, I put it out into production, I got a bunch of users. And when I talked to hiring managers, growth teams, I was able to show them how I could use data to build product, how I was able to use a Spotify API and analyze data and kind of price these different artists. And I think that made a very compelling story. In my own experience.

 

And for mentoring a lot of other people, I've been able to see the same thing that when somebody builds a project, on their passion, to build it to completion, so they actually have something to share a public Tableau dashboard, a real API that's out there in the world, a real GitHub repository that's getting stars, and they make it meaty, and they make it relevant to the job and they can explain that to one hiring manager of like, look, look at what I build sure I might not have every credential, but look at how it's relevant to the kind of work you guys are already hiring for. I think it goes a long, long way. In standing out.

 

LED: Yeah, yeah.

​

Roy: I'll add to that, that you know, when I'm reviewing resumes, like I'm probably not on the sort of first pass going to click on any links or anything on the resume, right. So if you do have that traction, that external validation, whatever that is, like you need to put that in there right there so that someone can see it. You know, you need to state that you have this many users or something like that or you know that this was or published or, or something work like that.

​

LED: So that's actually a great tip. This actually works for a lot of jobs, not just data science, where if you can demonstrate your instrument interest by doing the side projects, it goes a long way. Just a quick follow up on this, do you have any tips for how can, let's say, you know, I go and develop this project, I put in a lot of effort and energy into it. But you know, maybe I don't have a community as such, or a following to share this project with what's a good way to try and get that initial feedback from people and build some sort of traction for my project.

​

Nick: Absolutely. So one thing is that now I have an audience. But when I'm talking about these tips, or that rap stock story, this is all way before I had any audiences or anything. And there, I was building for the Reddit, the subreddit called our hip hop heads, which is all for music lovers. So I think that most people should be able to build something and find a community to share it with, because it's Reddit. And I guarantee you even the most niche hobbies and niche interests have a place on the internet. So I think just by the power of the internet, Reddit forums, Facebook groups, these are great places to kind of get users get feedback and get interest. And I think that it might be a limiting belief to think, oh, I don't have community when it's like, Yo, there's, you know, 50 Facebook pages for the most niche hobbies and interests. 

​

LED: Yeah. 

Nick: And that's enough to get your first users and feedback and impact.

​

LED: Yeah, yeah. So Alright, so let's say I've put together my resume, I have my project, and I have a strong application, I'm ready to now apply to companies. But maybe there's a dream company that I really want to get a job at. But I don't know anyone who can refer me? Do you have any tips for how I can still, you know, have a strong chance for actually getting shortlisted?

​

Nick: Right. And I'd be curious to hear Roy's take on it. But I always advocate people to send cold emails, which is kind of an opposition to a warm introduction. So if you really don't know anybody, you can kind of guess the hiring manager, recruiters email address, and plus you have LinkedIn. So you can always send them a LinkedIn DM too. But I'm a big fan of email because I can make a little bit longer.

​

And I could put in like a link and an image or a GIF or something to kind of stand out and actually get noticed in a way that on LinkedIn, I can't really do that. But the point is that I think by looking up the relevant hiring manager for the team, you want to join, sending them a compelling pitch that says, here's my experience, here's what I built, here's what your team is hiring for.

​

And here's why I'm a good fit. In doing that, in probably 100-150 words, you know, across six, seven sentences, you know, which six sevens short sentences, so it's kind of easy to look at, it goes a long, long way. And actually, I got my last job at a startup called Safe graph geospatial analytics startup, thanks to sending the CEO cold email. That's how I got the interview process started. And I hired that company's first intern, because they sent me a cold email. 

​

LED: Okay.

Nick:So cold emailing really has worked, in my experience, and with the people I've coached. And, of course, you know, if your dream like Google, and you don't have the credentials, you can't just call email your way to Google. But at a lot of smaller companies, especially where they're hurting for talent, and they're looking for someone who's actually passionate about the role, who has done the research on what the company does, and the position is looking for and is able to convey that briefly in six, seven sentences, it goes a long way in you might not even need that referral.

Roy: I agree with that. I think that it's, for a lot of people, for myself, it feels weird, very weird to cold email, someone like that. I have done it before. I've also done it, the Twitter a, for example, if they have someone who has opened DMS, usually if it's, you know, someone that especially if you've interacted with them otherwise, you know, say like, like on Twitter in some sort of public forum, and you know, you can kind of say, Hey, this is who I am.

 

You know, on the on the hiring side, I tell people that if you're contacted like that, any you still need to make sure you're putting people through the same process you put everyone else through, maybe it gets them to the next stage. But you know, you don't want to buy us yourself because someone just because someone's sticking out like that, or whatever. I mean, if you're hiring people for a sales role, and maybe it's different because that's what salespeople do.

But, you know, for the typical one. A lot of it, you know, you don't want to respond in a way differently than you otherwise would, as far as you know, their hiring likelihood but maybe you bumped them on to the next round when past the sort of resume screen stage if they seem reasonable.

​

I've definitely done that at different points. And I think that the other kind of version of that is, it's just asking the people, you know, hey, do any of you know anyone that company? And sometimes that helps. And, you know, sometimes you'll get useful info, maybe the info is it oh, we're actually not hiring or that actually has been filled or something like that. But oftentimes, it'll get you somewhere. But not always, sometimes the cold application is, is the way to go and, and still get you where you want to be. 

​

LED: Yeah, yeah, absolutely. And then one last question on the initial application process. I think in data sciences, this has at least been in my experience, where, where I've seen that in tech, the quality of a data science role can vary quite a bit. So there are certain teams where data scientists are highly empowered, and they're driving a lot of insights work, which can then in turn influence the product and what shape it ends up taking. And then there are other teams where, you know, perhaps it's not as empowered. So as a candidate who's not yet part of a team or not, you know, perhaps even outside the company, do you recommend any ways that a candidate can evaluate if this is a good data science opportunity?

​

Roy:That's a difficult one. Maybe I should start with by saying, if you do have any of those contacts, that can give you some insight information, you know, you get some amount of insight. Take everything with a grain of salt, obviously. But I think for a lot of the candidates, I talked to you and Nick and told me what he thinks that, you know, a lot of times you, you kind of want to look at every available opportunity, and you may not have that chance to really try to discriminate between what's like, the good role, and what's the bad role. And, you know, for a lot of people, I think, the advice that I would give them and other people I know give them as is, if there's a company that you like, and there's a team that you like, but you can't get quite there or whatever, you know, you may want to go in and then try to try to transfer or something later, because you know, that thing, your foot is really in the door, right?

​

Nick: Yeah know, it's a tough, tough ass to figure out, is this team worth joining or not? I think one thing that I've seen is, first, at some level, we're all human. So do I like the people I'm interviewing with? You know, that's a good way to read on it. The second thing that I've seen is just to get a higher level of like, how is this organization doing? Enough companies have technical blogs, or give talks at conferences? But that's one way for you to kind of realize like, Hmm, do I enjoy this work?

 

You know, because people talk about their technical work. And if you find their blog posts boring, or you're like, Yo, I don't think I could see myself working on these kinds of challenges. That's a good signal. Maybe you're not a good fit for the organization. And then vice versa. It's like, Yo, I could spend all day thinking about how do I make trips, you know, match people, writers, to drivers, and like optimize trips, and I love geospatial data. Maybe working at Uber is a great fit. And, of course, it still gets hard to get a read on the team to team but at least you have some more faith on Uber data science as a whole. If you like, the blog, geospatial as a whole and transportation.

​

Roy: I tell most candidates that are you know, people that are looking at not applying to my roles or something but kind of to evaluate it from the opposite in which is like, is this a Do you? Not like what they're doing? Does this feel there's something feels sketchy about what's going on? You know, and those are the ones that you want to reject. But maybe you should be open to almost everything else that seems reasonable. Just because a lot of competition, that's the main thing. 

​

LED: Yeah. 

Roy: It is very different if you're, you know, a very senior candidate. And then, you know, the whole thing is kind of a different ballgame.

​

LED: Of course. Yeah. And the considerations would be vastly different at that point. All right. So then, let's say now you have your interview, and you're in the phase of preparing for your interview. What are the key elements or core elements that candidates should be preparing for?

​

Nick: I think some of the major topics, besides the behavioral interview, but let's choose, let's start with technical. So the major topics for technical would include coding often in Python, with pandas, or R, depending on your shop SQL, some basic prompts that knowledge, a little bit of ml knowledge. And then sometimes for more product data science roles, which are kind of working on product analytics. You'd want to have some product sets or business sets practices as well. So those that's kind of how I see the main interview breakdown. Did I miss anything, Roy?

​

Roy: I think that covers a lot. I think one another big area though might be a, sort of round, let's say software development and, and sort of like ML ops, as they call it. So stuff around, how do you? How does the system work that we put this into production? Or how would you design one or something or just, I think for a lot of roles, they want to know, if you have experience working in an environment where other people are, depending on what you're building.

​

LED: This is where like, my complete lack of data science interviews is going to show. But I can't get it? Did I get the buckets, right? So there are behavioral interviews, then there is a big coding piece. And then within coding there, you know, all the different pieces like ML, and Python, etc. And then some sort of like just problem-solving capability and how you interface with other functions.

​

Roy: I think I would add to that, you know, just around analysis and working with data. So, you know, I definitely give candidates, just a one, one part of the technical assessment will be take this raw data, and then answer questions about it, that, you know, that I'm giving them the questions and that's, you know, that's one of the cores of pretty much all this data work is being able to, to take dirty data, especially in and then manipulate it, cleaned it up, so that you can then answer, you know, business related questions or reuse that data to make data driven solutions for things.

​

LED: Make sense. So I think, if you could just maybe give us a few things around, what are the key things that you're looking for in the coding piece of the interview?

​

Nick: Roy, I would love to hear that. 

​

Roy: Sure. So I'll say in the early days of data science, I definitely did multiple interviews that were really aimed at software developers, and they were about sort of the algorithms and data structures that computer science majors learn in school and stuff, but they really had very little overlap with data science work. So typically, the coding stuff, like assessments that I would give to people are much more in line with the kind of work that data scientists would be doing.

 

Now, some data scientists are writing code on big systems that need you know, really good software development practices, and all these things. But a lot of time, what data scientists and machine learning people are doing is more code around cleaning up data and gluing things together. And it's a little bit different. So those, you know, it's it's typically not the things that you you'd see in like leak code, or the kinds of stuff that a lot of software developer candidates are using as practice with. Now, that said, I do know a lot of people, especially on the machine learning engineering side, that when they go in for interviews, they do hit the sort of leak code and questions.

 

So if you're doing if you have the word engineer in that title, you probably do want to focus on more of those. But for the kind of stuff I do, you know, I want to know that they know how to use the use their tool, I mostly work in Python, to do the kinds of tasks which often are taking a bunch of data, whether it's text, or whatever, and munging it as one of the terms we like to use to get clean it up to make it available to use.

 

And you know, and I also see that as one of the sort of power as a data scientist over the especially old school, data analysts or business analysts is that they know how to program and they know how to deal with data formats and things like that, that are not necessarily the tools that you have can't just do it out of the box where you push a button. So instead, the data scientists can get their hands dirty with code to get what they need done.

​

Nick: Yeah, I think that Roy's right that this traditional data structure and algorithm questions might not be the most relevant to data to work. But definitely some of the easier ones around manipulating arrays or strings, I still think are pretty fair game, because it just shows that you know how to loop or you know, your conditional logic. And I think these are, you know, even if you're not doing hardcore programming, these are some basic concepts that can help test your problem-solving skills and basic competency encoding.

 

So I still favor those connect questions. But you're right that instead of these more Python, sorry, data structure questions, I do think that asking SQL questions makes a lot of sense, especially for so many roles that need SQL that sometimes get skipped in school, right? Everyone's talking about modeling this and that, and then we forget Okay, a lot of the people with the title data science are actually pulling lots of data via SQL, not Spark, not some fancy, other cool Rules. They're just writing plain old SQL queries all day.

 

And, you know, they pipe on paper, their job says data science, but you know, it's probably what we would have called data analyst or business intelligence back in the day. Yeah, that's kind of how the industry has evolved. And people want to tack onto the trends. So that's why it's now laid back.

​

Roy: I've never assessed people's SQL skills for the, for the roles I've hired for. That said, I expect them all to be able to do SQL. 

Nick:Yeah.

​

Roy: Whether whether whether because they need to learn it, but even if you're doing, you know, machine learning, or whatever, oftentimes, you'll have to pull that data in the beginning, in the explain exploratory phases from a database using SQL before, you might have, you know, nice pipelines, especially built by someone else, a different role. But I still expect that and I mean, maybe a good thing to say, which was related to an earlier point I made, which is just that just because stuff is not directly related to the actual role doesn't mean that doesn't mean you won't see it in the interview.

 

So in that sense, I think there are a lot of these skills in Nick covers these in their book that are the ones that you should review well enough in case it comes up. So no matter what the role is, if there's any data related, you should be, you should brush up on your sequel, you know, you probably do want to do some of those leet coding ones, even though I don't use that kind of stuff. I mean, maybe the sort of lowest level ones that are kind of more related to this, the kind of things you would see. But you know, it's kind of like prepare for the reality out there versus prepare for what people should be doing when they're trying to hire, we'll say.

​

LED: Would you recommend any resources that candidates can use to prepare for the coding portion?

​

Roy: I personally recommend ace the data science, co-written by Nick Singh.

​

Nick: Yeah, but I like my book for coding. But definitely a big part of coding is actually coding and my book a book, you can't code the book. But I think leak code is kind of the big winner here. And hacker rank is there, too. So I think, for coding, it's totally reasonable to be practicing on this platforms. But we also put coding questions in our book as well.

​

LED: Yeah, yeah. And I definitely read the book.

Roy: I think, especially if you're going to do any roles that are like I said, Before, they have like the word engineer on them, you know, something like the code and going in there and just practicing and make sure you're thinking about that. And then the other part I would say is, if you have especially open-source projects, or whatever it is, like go in and review your own code and make sure you understand what you did, because that's the kind of stuff you do. And there's a strong possibility that someone would ask you about that, especially public code that you put out there.

​

LED: Yeah, definitely. So you also mentioned behavioral questions. And interestingly enough, I polled a few people on what questions they have. And this came up as one of the questions that people are actually aren't sure whether they will be asked behavioral questions or not. So it sounds like they are. So what exactly is is a candidate being tested for in the behavioral section of the interview?

​

Roy: I personally, I have a strong opinion about behavioral questions, I actually think they're not very good questions. In general, I don't think it's a good technique. But you know, you it is something that, that you'll get for a lot of roles. I mean, when I've done stuff like that, I've literally have done a search for common behavioral interview questions to see what I should be preparing for. You know, and then there's the typical ones, of course, like, you know, tell me about a time when you had a conflict with a coworker, and how you resolve that.

 

And when I've done interviews for manager roles, you know, it's much harder to assess manager roles with an online quiz, you know, that doesn't really exist in the same way, as with, say, coding or something. And so for those, you know, the way I approach it is a compile as big of a list of questions. And you can find some of these in Nick's book, I believe, that are related to the behavioral interview questions, and basically, then sit down and practice your answers. I mean, it is. I think that it would, it seems a little bit weird.

 

Because, you know, they're asking you what happens in this and while that happens, you should be able to tell them, but on the other hand, you know, you want to be able to give very clear, succinct answers to these kinds of questions. And so you really want to practice them and, if possible, practice them with, with a buddy, so that someone can ask you, you know, probe your answers and try to help you craft them. A little bit better. Right? What do you think, Nick?

Nick: No, no that that that makes a ton of sense. Practice makes perfect. And it's easy to say like, man, behavioral interviews are like fluffy bullshit, or it's like, yo, it's about me, you know, I should be able to wing it. But practicing in the mirror or practicing with a friend really matters, I think. I guess some of this might be considered a behavioral interview. But the first question that usually people ask is like, tell me about yourself. And I've seen so many smart, capable data scientists mess this up. And they ramble when they ramble.

 

Or they tell a story that's not really relevant to the job. And then I have to ask them, like, Yo, you forgot these details that make you a really good fit for the job, because they tell one story for every kind of job, regardless of the company they're trying to interview for.

 

So I think practice makes perfect. And I think that being a little bit more critical, and actually techies can write this off, like, Oh, come on, it's just about you. But you know, salespeople don't you know, salespeople really go hard on these kinds of pitches the on their elevator pitch on this, that, but techies won't do that. And I think that that first question, tell me about yourself sets the tone for the rest of the interview, even if you're doing a technical assessment, how you start those first two minutes really colors the mind of the interviewer. So it's like, working.

Roy: And I guess I also add, you know, this is probably just a psychology thing on my own. And but like, if someone comes in, and they're to polish that I start to be a little skeptical or something. Right. So it's like, you know, you want to practice it gives them a natural delivery to these answers. 

LED: Yeah. 

​

Nick: I'm, I would like to claim now I would, I would, I'm really curious to hear your point on this, Roy. So I've heard of that kind of criticism, like, Oh, what if I'm like to practice and I'm like, yo, like, if I'm giving you feedback, like, unless you're an actor, or like, really that good, we all have so much room to improve on how we pitch herself and talk about ourselves or answers to these questions. Because face it or, you know, like it or not, we're not used to talking about ourselves. So I've always I've never felt someone like get too polished, I think maybe one in 100. But like, they're usually not even interviewing, you know, they're almost like selling me. But for the average candidate, I think probably reading this or hearing this problem, you will honor, err on the side of preparing more. 

​

Roy: Yeah, I think that that's, that's probably true that for the the the typical candidate, they're not going to be on the other side. I guess I'd say I can add my little quick editorial about behavioral questions. The reason I don't like them is because I feel like they are mostly useful for sort of true negative responses.

 

And by that what I mean is like, if if you say, you know, tell me about a time you had a conflict with a coworker, and the response is, well, you know, I punched that guy. And, you know, I showed him, right, and you're like, Okay, that's, that's, nobody's going to make that up. And it's a bad answer, right? You know, versus on the other hand, like, I might be able to tell you about the time that I got into a big conflict with a coworker.

 

And in the end, it was, like, I just pointed out that this is exactly what his his wife had been saying the last time, you know, in public about him. And it's like, oh, by the way, I just made that whole thing up. Right. And, you know, it's like, people can easily give you sort of false positives. But there's also a lot of false negatives, because a lot of times, especially if people are unprepared, I think, you know, they just can't think of something relevant.

 

So whatever they think they either can't remember a perfect scenario to explain that, you know, actually did happen, or what they do remember, just, you know, it doesn't sound very good, and they don't sound like they got it together very well. And so to me, you know, the only reality, it's hard to tell like, oh, is this uh, was it? Was it a false positive? Was it a true positive? Was it a false negative and the only one you can really count on is like, the true negative where, you know, if somebody says something, and they say it in a way that they think is good, and you're, you know, clearly this is a bad thing?

That, you know, maybe that's a good signal. But that said, you know, it's a very popular technique, because it's kind of based on this sense of your past behavior, behavior will predict your future behavior. But instead, I like to ask questions more around the hypothetical scenarios of what would you do in this case, but even more specifically, I like to ask, you know, What's your philosophy with dealing with this type of situation?

​

LED: And so just one quick follow-up on this, which is that so yes, candidates should definitely We try and find a list of questions and practice to the extent they can. But what exactly is the interviewer trying to figure out? And what I'm trying to ask is? So as a product manager, for example, I can talk to that one of the things we can and we can debate that, you know, is behavioral question, really the right way to test this.

 

But we know like, as a candidate, I know that they probably want to know what my problem-solving skills are, they probably want to know how well I work with other people, they probably want to know, am I a good leader? And so I have to try and bring out those qualities like, that's what my answer should be anchoring around. So from a data scientist perspective, if you're asking me, how do you resolve a conflict? What exactly are they trying to do to see?

​

Roy: It's a little bit unclear to me that you can get good information around, especially around resolving a conflict. And for the reasons I said, you know, if someone knows what the talking points are, from whatever, you know, kind of professional stuff, it's hard to know if they're just making it up or not. To me, I think you want people that will work well, on the team. And a lot of people especially coming out of school or whatnot, they don't really understand how important that is. And so I think a lot of for most of the stuff I've done, I have not explicitly tried to sass out, is this person, a good team worker? I don't, I don't like this kind of answer for me.

 

But you know, I feel like a lot of it is kind of the feeling people get. And the way I recommend, like in my book I talk about, there's like things you want to explicitly assess for. And then there are other things that you kind of want to comprehensively assess for another big one that goes in there that we haven't touched on is sort of communication skills. And for the data science side, you know, it's a lot about like, communicating technical concepts, especially to, you know, technical audiences and less technical audiences.

 

 But I think that kind of all goes together. So, you know, when I do hire, and I am involving a team of people, even if I'm running the process, and you know, so I'll ask those people for feedback, you know, did you get any sense around, you know, some of these things like this? Are there any red flags to you around behavioral stuff? Because that's, you know, from a manager's point of view, it's like, those are the worst kinds of problems to deal with is when people have interpersonal issues within the team, for example. But on the other hand, I think it's very, very hard to screen for.

​

LED: This helps. And it's kind of like the integral just kind of getting a feel for you as a person, which, you know, is obviously important in a work environment. So can either of you share examples of when a candidate really blew you away, in the interview process?

​

Nick: I like agency, were just like, oh, I just did the stuff on my own, because it's my hobby, it's my interest because then that makes me realize, like, oh, this person is going to level up and take initiatives. And I don't even have to tell them to do these things. And that's because I'm fundamentally lazy, as a hiring manager, as a coworker, I'm just like, Yo, I don't want to give you instructions, I just want you to do stuff on your own.

 

And so when folks have a track record of building their own businesses, making their own side projects, taking Coursera classes, for fun reading books in the field, just to stay up to date reading Hacker News, I find these and they have some level of baseline technical skills, I find that these people can level up very quickly. And, you know, they, they give a shit. And sometimes the smaller companies, that's what really matters. So when I find agency and a little bit of passion, about the domain or the company, it really winds me over.

​

Roy: I have to agree with that. That's, that's a thing that, that I kind of had forgotten about, which is, especially in the startup world, which is where I've, you know, been in my whole career. When I see people that, you know, they all kind of have the same background nowadays, you see a lot of people in the data science world that have an undergrad and some sort of STEM topic, and then they'll have maybe a master's degree, especially in data science, analytics, machine learning, whatever.

 

But then I see someone who on their resume, it says something where there it shows me that they are a sort of an entrepreneur in the broad sense of like, they like to go out and just build stuff and learn stuff on their own. Like I'm in some ways more excited about someone who says, Well, I did this project in totally on my own around, you know, reinforcement learning or something.

 

No, that's not what I do. I've never done that at work, but it's also not something they probably learned in their classes, you know, and it was like they did these things on their own or, you know, they put out, you know, their own little apps or whatever. And that does get me kind of excited about, you know, is this a super self-starting person? And you know, like Nick said that it is the dream of every manager is to have a team of people they don't need to manage.

​

LED: And that's the perfect candidate. Yeah. What are some common mistakes that you've seen candidates make during the interview process?

​

Roy:  Sadly, one of the common mistakes I've seen is people cheating on their assessments. 

​

LED:  Okay, yeah, that is definitely.

​

Roy: Do not cheat, it kind of blew me away. And I was not expecting this when I started giving people sort of these automated assessments. You know, it's sort of along the lines of leetcode, or whatever that, but do it for data science-related content. And, you know, I have a whole philosophy of what should be included in that and how to make it the best possible experience.

 

But when I started doing that, I started seeing people who had clearly copy pasted stuff from elsewhere or had help from some source. And, you know, I, I don't know why people would do that. And it's one of those things you think, well, logically, what if you cheated, then and then you get on the job, and you can't actually do this stuff? You know, what are you going to do then? But it I think, for some people, it's just too easy to just, you know, cheat. And I think it's just, it's not going to help you in the long run. And I feel crazy for even having to say that, because it's, it seems very obvious that for like, these technical skills, it, it won't work like that, but so don't cheat, please.

​

LED: Yeah, I mean, I think I think that goes without saying, I mean, that's probably like a straightforward way to get rejected anything else.

​

Roy: I think that sometimes, you know, people will focus on things that aren't relevant, maybe, when they talk about themselves. It could even be the projects they're on, you know, that can be an issue. Sometimes people just are flustered, but sometimes they're, they're just trying to throw everything at you, because maybe if they're there early in their career, and they don't have a lot of experience to pull from. I think another problem that happens sometimes if you do anything in person skills assessment is that sometimes people will, they won't ask for any kind of help, whether they don't know that they could ask for help, or they just feel like that will make them look bad, or whatever.

 

And, you know, I always tell people at the beginning assessment, you know, feel free to ask for as much help as you want, et cetera, et cetera, depending on exactly the assessment, but sometimes people will just sit there in silence for you know, an hour or whatever, and do some technical assessment, when, and, you know, they may have missed some fundamental things.

 

So at the end, they, you know, they don't, they don't give you a good response on the assessment when they could have easily gotten help, but just didn't. The Some of that's perLEDty also, but I think I really do think for the most part, most interviewers are not adversarial. And, you know, they will, they want you to succeed. You know, it's, it's hard to find people that have the skills you want and the experience and everything. So when they do find those people, typically the people doing the interviews want you to succeed. And not, you know, they shouldn't be helping you cheat either. That would be bad, too. But, you know, it's typically not an adversarial process.

​

Nick: Yeah, now, following up on that, I think you sort of hinted on this and asking questions, but specifically, I'd like to say clarifying questions. So this isn't even just asking for help. This is just like; I gave you a vague problem statement. And one of the good things that you should do is ask clarifying questions. And sometimes people just jump into solving the question maybe they didn't know to ask clarifying questions, or maybe they just thought, Oh, I'm so smart. I know the answer to this very broad open-ended, you know, question when really should have been asking clarifying questions.

 

So that's been the big mistake. I've seen in my talks. I tell people this and then I give them an open-ended prompt. And then we try to solve it together. And immediately, right after the next slide, people will start giving the answers and I'm like, wait a second. Don't you have questions for me? Didn't we just talk about a 10 seconds ago that we have this open-ended problem you should ask See some questions? But it's really fun to see. And hopefully, though, you know, I try to hit that emphasize that in the book a lot. So maybe over time, people will get better at knowing to ask questions and clarify it. 

​

Roy: There are a lot of bad interviewers too, or maybe bad is too strong. A word, maybe it will say, untrained and unpracticed interviewers. And so I, I think that it rests on the candidate's shoulders then for, for them helping themselves to try to get as much clarity as possible about not just the question, but also sort of the interview itself, you know, oh, is it okay, if I ask you questions, et cetera, like that, you know, try to try to put yourself forward and ask those kinds of things. So you understand the parameters better?