These Mistakes Could Easily Ruin Your Data Science Interviews
Don’t let your onsite performance undermine all of your interview preparation
Office Hours
Don’t let your onsite performance undermine all of your interview preparation
After months of interview preparation, you are confident that you know all of the fundamental ML concepts, are familiar with SQL and Python coding, and think you have a great answer for all the behavioral questions. You came out of the interview thinking everything went really well only to get a cold rejection e-mail after several days without explanation. What went wrong? You were able to answer all the theoretical questions and aced the coding section with extra time left; you are left confused and frustrated without a clear path of improvement.
If this happened to you, you are not alone; it happens to everyone at some point in their interview experiences. It sucks because most companies refuse to give you feedback or reasons for rejection, thus there’s no clarity for what you can work on to improve. Most articles out there are talking about how to prepare for interviews, but not many people talk about how your in-person performance (onsite or over zoom) can affect interview outcomes greatly. After being a DS interviewer for a while now, and sitting in rounds and rounds of group debriefs of candidates, I realized there are some common themes among the candidates that are being rejected (a lot of them showcased strong technical skills and can explain ML concepts really well). Hopefully, this list of common mistakes can help you avoid pitfalls in future interviews so your months of preparation are not wasted.
Mistake 1: Not following / paying attention to what the interviewers are saying
Being able to follow/respond to interviewers’ trains of thought during live coding or live case studies is extremely important because (good) interviewers are trained to help you get “unstuck” when necessary while trying to get as much signal as possible about whether you are a person they want on their teams. If you feel like you don’t know how to proceed with a problem, it’s likely your interviewers will give you a gentle nudge/hint; you don’t have to follow their suggestions to the letter but make sure you think about it and acknowledge it. Why? Because it’s never only about the coding or the case, it’s also about your working style and communication style, and interviewers are looking for candidates that are “coachable”.
Imagine this situation: you are stuck with a piece of code because you are nervous and forgot to increase the count in your “while” loop so it’s stuck and won’t stop running (trust me, it happens pretty often and it’s not a big deal AT ALL because everyone gets nervous). Your interviewer gives you a nudge, “you can try to test the loops individually, and see what n comes out to be”. You will be surprised how many people would simply ignore that and remain being stuck; either because they are nervous, or didn’t get exactly what the interviewer wants them to do, or don’t like to change their approach midway. What your interviewers (without knowing you) will see is a person who, if hired, won’t take anyone’s suggestion in their day-to-day work.
Listening and following the interviewers is equally important for behavioral interviews. Interviewers have the scorecard in mind that they will be filling out afterward (some interviewers even take notes directly in the scorecard template), and they will try to get sufficient “signal” on each category that they are assigned to rate the candidate on by asking follow-up/probing questions. Many candidates stick to rehearsed anecdotes and do not directly address the interviewer’s questions; unfortunately, after one or two unsuccessful attempts to tease out additional information from the candidates this will result in a comment like “didn’t get enough signal about ***” on your scorecard.
Keep in mind, being a good talker alone is just not enough sometimes (for interviews or for life); being a good listener is equally important.
Mistake 2: Giving up easily
The most awkward interview experience I have had as an interviewer was when one candidate saw the Python challenge and just decided to give up without even trying. Then I had to decide whether to sit there staring at each other for the rest of the half-hour interview or to end the call earlier since they are clearly not getting the role.
I trust most people won’t be so extreme and just sit there refusing to try, but a lot of candidates show clear signs of frustration and don’t know how to proceed when their code/approach doesn’t work the way they anticipated. The ability to break down a big problem into smaller chunks, test, and iterate is one of the most important abilities we test for in interviews. Instead of getting frustrated, view it as your opportunity to shine when your code is not working the first time around; if your for-loop is not working as imagined, there’s no shame in breaking down the steps in the loop and test on smaller numbers step by step and print out the result to debug. If you are totally stuck, it is completlely fine to take a moment to gather your thoughts and think about a new approach; showing perserverance and a positive attitude to overcome obstacles can help you “save” the interview even if you didn’t solve the problem perfectly at the first attempt.
Mistake 3: Not knowing how to handle questions you don’t have an answer for
This is more for the theoretical questions you encounter in the interviews. It doesn’t matter how much time you spend preparing for interviews, there WILL be questions you don’t have the answer for or only have a vague memory of the concept in question.
In those situations, don’t panic, take a deep breath and channel your attention to what you DO know. For example, if asked what is “boosting” in ML, and you have only heard about it in passing and know it’s an ensemble method but don’t remember the details, you should be honest about this. Don’t make things up; this reflects badly on your attitude/working style and interviewers will assume that you would similarly attempt to hide issues on the job instaed of asking for help (which can have dire consequences). Instead, talk about what you DO remember (e.g. ensemble methods in general) and let the interviewer know if you have expertise in related areas. Depending on the interviewer and how important the concept in question is for the role it might not always be possible to recover from drawing a blank on a key technical question; however, sometimes you can make up for it by showing proficiency in a related, equally important area.
This might be controversial among interviewers, but I believe you should always follow up after the interview. Ask for the interviewer’s email (or ask the recruiter to forward the message for you), do some research about the question asked, really understand the concept, and write a thoughtful follow-up email. I put stress on “really understand the concept”; if you just want to Google it and copy and paste it from Wikipedia, don’t bother. This kind of follow-up may be worth more to some interviewers than others, but a thoughtful message that shows your initiative to learn unfamiliar concepts will never hurt your case.
Mistake 4: Only focusing on problem-solving but not communication
Remember, your interviewers are likely your potential future teammates or business partners, and they are trying to determine if they would like to work with you. So show your ability to work with others by working with your interviewers. Whether it’s live coding or a live case, make sure you check with your interviewers periodically about your hypotheses and approach; by checking, I don’t mean asking them whether your approach is correct or whether you are getting to the right answer; I mean asking questions along the lines of “I’m going to focus my analysis on the XX part since that seems to be the company’s priority; but please let me know if you want me to zoom in another part”.
Remember, your interviewers cannot see what’s in your brain, they can only judge you based on what you show them. So if you made an implicit assumption, make sure you clearly state it to the interviewer. If you think there’s a caveat to your analysis, make sure you bring it up as well. All in all, don’t assume anything is “obvious” to the interviewer.
Mistake 5: Staying too high level/generic for your answers
I truly believe in the importance of top-down communication, but make sure you can delve into details when necessary; you should not proactively go into every detail (this would likely be held against you), but periodically check with the interviewer if they want to dive deeper into an area before you move on. If interviewers do ask follow-up questions after your initial answer, they want to know more details; this is the time to show that you really understand the nuances. This is not only important fot technical questions, but also the behavioral part: If you always stay at 30,000 feet high with all of your answers no matter how hard interviewers push for details, they may start wondering whether you actually had hands-on experience with the project/analysis you claimed you participated in.
Mistake 6: Not treating the interview as a two-way assessment
This one won’t necessarily ruin your interview, but it might ruin your work life later on. I learned it the hard way. I used to want a job so badly that I forgot the interview is supposed to be a two-way test and I’m supposed to be assessing my interviewers and the company through them. Even worse, I used to intentionally ignore the red flags I have observed during interviews. For my first internship in finance, one of my interviewers was yawning during my answer, which is both disrespectful and a clear sign of the bad work-life balance. But I wanted the brand name on my resume so badly that I chose to ignore my hunch, only to later realize it was accurate, that there was no work-life balance and I absolutely hated the job.
Since interviews are trying to find out whether you will be a good person to work with, you should do the same. Don’t fake to be what you are not just to get the job, you will probably regret it later. If you “didn’t click” with the hiring manager in the interview, you probably will resent working for him/her later. If you sensed people are not happy working there, you probably won’t be either.
Hopefully, these tips will help you with your next interview and make you stand out from the other candidates.