10 Common Interview Mistakes to Avoid: Business Intelligence and Data Science Edition
Don't sabotage your chances: key mistakes to avoid in data interviews!
Waiting for perfection
The best way to get better at interviews is to actually interview! Of course take some time to follow the pointers below, but no one is ever fully “ready”. It is better to kick off the process earlier, as the experiences gained interviewing will help you in exponential ways to prepare for the next one rather than continuing to delay and study on your own.
Lack of day of interview preparation
Some things are unavoidable, but there are preparation elements that can be controlled. When you are in an interview, nerves are already higher than usual so it is important to set yourself up for success. Even dry mouth from dehydration, stomach rumbling from forgetting to eat, loud noises from lack of noise canceling headphones, and having an early interview as a night owl can throw off your game. This gets harder when you are already in the workforce, as balancing interview(s) during a workday often leaves little time for pre-interview preparation. Make sure you have everything you need on your desk, have had a proper meal and water, are in a quiet space or have noise canceling headphones, and schedule according to when your level of focus performs best. If possible, test out the video software well before the interview to ensure there are no software installment or login delays.
Not researching the company or interview structure beforehand
There is nothing worse than a candidate not knowing anything about the company, and being completely unprepared for the interview structure. You will most likely be asked “Why XX company?” or “Why this role?”. If you are stumbling on answering even these questions, it will raise a red flag with the recruiter or interviewer and potentially cause the interview to start off on the wrong foot. It only takes a few minutes to search for the company’s website, review its culture and values, and read through the entire job description. Always have questions prepared for the end!
Miscallibrating yourself
I am a big advocate for applying to roles where you do not cover 100% of the qualifications (women more often shy away from applying to stretch roles), but it is also fundamental to understand your individual skills and resume project impact callibration not just on your team, organization, and company-wide but tech-industry wide. Most companies have an (unspoken) specific reputation and if you have blind spots, they will often painfully surface when externally interviewing. People often get pigeonholed or “stuck” at their company for several years because their seniority level, technical complexity of projects, and/or impact of responsibilities do not match up equally to a similar external role. I urge everyone to connect with peers and mentors across the industry, keep up with company reviews and professional communities such as Blind or Glassdoor, and have a good mechanism for receiving feedback. Levels.fyi is a good comparison site, but unfiltered personal antecdotes are often more insightful. This not only helps you level up at a faster pace, but it also strengthens self awareness in interviews by allowing oneself to proactively address gaps and highlight strengths.
Forgetting what is on your resume
After introductions and asking about interest in the company and/or role, the next question often revolves around either walking through your resume or picking specific projects from your resume to drill into. If it has been a while since working on certain projects (which is often the case), make sure to review each bullet to prevent blanking on details. Focus on the “why” of decisions being made, conflict resolution, impact, and what you would have done differently. For data science roles, they will often ask why a certain machine learning or statistical model and performance metric were used versus others. This requires reflection and critical thinking of previous project workflows and outcomes.
Trivializing technical interview preparation
Data interview roles will always be two-part with a behavioral/situational part and technical/coding part. Though it is extremely important to do some preparation for the first part, the technical portion is often where candidates fall short. The most difficult aspect of technical interviews is the ambiguity of each company’s role definition. There is also such a wide variety of methods used to test candidates’ skillsets. The most common incude: 1) live coding with the interviewer, 2) a take home test similar to Leetcode or a multiple choice test with code output options, 3) a case study and presentation, 4) setting up an experiment, or 5) back and forth Q&A of short questions related to statistics, probability, machine learning, SQL, and/or system design. Candidates often prepare anticipating the most advanced tests (which can happen), but I often recommend starting with truly understanding the basics and foundations of coding, modeling, and statistics. It is easy to get thrown off during interviews with these simple, straightforward questions as candidates often overthink and overcomplicate their answers.
Not asking follow-up questions
Before beginning to work on the interview questions, it is always important to ask follow-up questions (even for non-technical questions!). This is 100% necessary on the job, so interviewers will want to see how you respond to ambiguity. In the corporate world, developing a solution too quickly without understanding critical assumptions can lead to major tech debt. It can also lead to misalignment amongst cross-functional teams and executives, if the business question and assumptions at hand were not fully understood and validated. It is always better to validate and clarify with the interviewer, rather than letting ego get in the way and pretending to know exactly what needs to be done. There are no “stupid questions” at all levels of seniority. Some basic examples include: 1) who is the customer, 2) how large is this dataset, 3) what metric would you like optimized, 4) what key decisions will be made from this, or 5) how important is scalability and long-term sustainability in this example?
Lack of thinking out loud
This is true for most things in life, but it is often forgotten that other people cannot read your mind. It is totally okay to take a few minutes to read through questions or pause to brainstorm, but make sure to think out loud. This often benefits candidates rather than hurting them, as interviewers may give some more clues to help you in the right direction. When live coding, it is good practice to say out loud why you are using a certain function, syntax, package, table name, column name, etc. while you are typing. This helps the interviewer understand your way of thinking and knowledge of technical skills, even if you ultimately get to the wrong answer.
Choosing the wrong tools and models to use
Choosing the wrong tool or model can be a red flag for an interviewer. This often happens when a candidate has prepared very specific examples and tries to fit the framework where it is not applicable. If you encounter a question on developing a tool and model with no idea where to start, begin with the basics. Take a deep breath, and ask questions that you genuinely would be curious about if you were on the job. Budget, timeline, infrastructure resources, metrics, and audience are often overlooked. Sometimes a simple Excel tool is the most optimal solution for certain business cases (though not my favorite, lol), so it is important not to overcomplicate things. There are plenty of brilliant candidates that can provide a highly sophisticated solution, but it will unfortunately work against them if they did not take the time to land on the most fitting tool or model. This will require some prep work to understand the use cases for various models, tools, and statistical questions. For more deeply complex machine learning and engineering roles the expectation will most likely be a model, but do not overlook the simple tools for business intelligence and even some data science roles.
Verbose answers
One of the biggest pet peeves I have noticed over the years of managers and executives is giving verbose answers and explanations. It takes some time to develop this skill (even I continually need to work on it), but it is important to keep things crisp and snappy. Technical roles tend to struggle with this more than non-technical roles, as there is less of an expectation to interface with business leaders. However, it is critical in interviews to show that you can not only develop technical solutions but also explain them to an audience who has little context. A lot of leaders are short on time for meetings, so it is important that things are well documented, easy to understand (imagine explaining to a child), and built to enable decision-making. It is better to explain things to your interviewer in a simple and easy to understand manner, rather than assuming they know all and trying to show off highly complex concepts.
