Picture this: you’ve just finished a six-hour-long data science virtual onsite interview. You nailed every single technical question: especially that random question about writing a K Nearest Neighbors algorithm from scratch. You can still feel your heart beating through your chest, but you slowly realize all that Interview Query and Leetcode study grind paid off.
A few days later, the recruiter gets back to you with a rejection.
What? How could they turn you down, especially after all of your hard work? You did the things you were supposed to do and said the things you were supposed to say.
Many times, these rejections are due to a lack of preparation for the behavioral portion of the interview. Behavioral interview questions can be suspiciously benign (and, in fact, are designed to be this way). But they can cost us the entirety of our interview without us even knowing.
Stated bluntly, if you’re struggling with the behavioral portion of the interview, it can be extremely hard to figure out exactly why without talking to an expert coach. But let’s go over some common behavioral questions for data scientists and try to understand:
- What behavioral questions are actually asking, and
- Exactly how we should answer these questions.
In technical interviews and specifically in interviews for data scientists and machine learning engineers, we can group the common behavioral questions into:
- Can you communicate technical concepts?
- Does your resume and experience hold up against questioning?
- Are you a good team player and culture fit?
- And lastly, do you really know what you’re talking about?
When do behavioral questions show up in data science interviews?
When most people think of “behavioral questions,” they’re thinking of the kinds of questions asked by recruiters. It’s not a surprise when a recruiter asks if you are okay with a certain location or commute and it’s not a particularly tough question to “pass.” (Just don’t say no.)
But most behavioral questions that actually matter occur in the hiring manager screen and the onsite interview. In this stage of the interview process, candidates have to defend their resumes, demonstrate technical communication skills, and prove they can be a good culture fit.
Demonstrating technical competency
Demonstrating technical competency generally requires two things: strong technical skills and strong communication skills. You could have all the technical knowledge in the world and it won’t mean anything if you can’t communicate it to anybody. Unfortunately, it seems (ironically) that there’s often some miscommunication on what it means to have “strong communication skills.”
Let’s look at an example:
Once, when I was interviewing a candidate for a data science internship role, I asked them to describe a project they were proud of.
The candidate enthusiastically responded with:
Candidate: Yeah, so, for our CS 100 class, we were divided into teams and to build these robots that would battle out in an arena. And basically our robot won the competition and my TA said my group’s robot was really good.
Me: Okay… How did you end up building it?
Candidate: We used Java.
Me: What made your robot good?
Candidate: Well, it won the competition.
You would be surprised how many people say something similar to this when asked about their projects. The problem with the candidate’s response isn’t that the example they chose wasn’t a good example, it’s that they described their accomplishments without actually diving into any of the details that make the experience worth describing.
As an interviewer, almost ALL we care about are the details.
I don’t care if the intern programmed a robot that won their class competition. I care about the strategies they used to do it. An interview is really about allowing an employer to understand exactly how you think so they can judge whether the way you think and exercise judgement can be applied on the job.
That’s not to say that diving into the details is all you have to do. If you’re interviewing for an analytics role and find yourself only talking about the intricacies of SQL queries that you’ve churned out, getting bogged down in those details isn’t going to help you in the interview. Nor does diving into the nitty-gritty make much sense if you’re an engineer talking about building a new deep learning model either.
Rather, the best project descriptions are like stories that are framed from beginning to end that dive into the necessarily interesting parts and leave the listener satisfied and maybe even wanting to learn more. This means balancing the different parts of the project: neither diving straight into something extremely technical nor glossing over the details that make the project interesting.
Example answer to a technical project question
Here’s an example data science behavioral interview question and answer talking about a project
Q: Tell me about a time when you used data science to inform a business decision.
A: My previous company, Jobr, was like Tinder for jobs: a swiping app. Basically, how it worked was that a user would sign up and they would fill out their information and resumé and start getting job recommendations. So, our goal was to try to increase the amount that users would apply to jobs because we got paid on a per job basis. So what I did was build a recommendation system that allowed users to see more relevant jobs than they would have seen before.
A: Our baseline recommendation system was a naive Bayes model. It worked pretty well, but we had to manually tag it. The one that I designed actually used an elastic search model. Basically, it would take the titles from different job positions a person had held and weight them to different degrees. For instance, we weighted their current position more than their previous one. We added their education to the elastic model as well. The model basically performed a flexible query, which was then weighted, and we would apply that query to all of the jobs that were in our system within a fifty mile radius of the person’s listed location.
A: So that way we got way more effective job postings, but we realized we still had to A/B test this, so we could actually know that the elastic search model outperformed the naive Bayes model. So we gave a small sample of the users the elastic search algorithm and then a small control group the Bayes model, then ran a test for two weeks to see how many jobs each user applied to on average.
A: After those two weeks, we saw a ten percent lift in job applications using the elastic search model.
See what a difference a little structure can make? Instead of giving the flat answer (“I designed a job recommendation system and we saw a ten percent increase in job applications”), I elaborated where necessary to give my interviewer a deeper glimpse into the project. Instead of getting bogged down in the details of how the recommendation system worked, I provided a few salient data points (“It weighted their current position more than their previous one,” “We applied the query to all of the jobs that were in our system within a fifty mile radius”) to give the interviewer a practical working knowledge of the system.
Most importantly, my answer took the form of a story with a beginning (“I was working at Jobr”), middle (“I designed a recommendation system”), and end (“We saw a ten percent lift in applications”).
Making sure you can back-up your resume
It’s incredibly easy to boast about yourself when writing a resumé nowadays. It’s almost a feature of the genre. I frequently find myself amazed at how many resumés seem to be packed with buzzwords and projects that have greatly influenced their companies revenue goals.
I once read a resume that claimed that the person had worked on a project that increased monthly revenue by 30% for their business. I was skeptical, but I kept asking questions. It turned out the business was an e-commerce SaaS company and the increase in monthly revenue happened between November and December of the year the person had worked there.
I asked them what happened in the month of January the next year and suddenly they didn’t have as much to say.
Don’t get caught in the resumé inflation trap! When you put things on your resume, it’s important that you can back them up with what you actually worked on and the details that matter to an employer. If you work in an analytics capacity, you need to be able to explain the business decisions and detail behind the projects that influenced certain metrics you achieved. If you work in an engineering capacity, you have to be able to explain exactly how you or your team built a project that delivered business value.
For example, if I were to ask you about that deep learning propensity model that you built, you can bet I’d ask you more about how it was trained, the decisions between using different models, and exactly how well it performed when deployed into production. As a candidate, you have to be able to back up your claim and explain exactly how it happened. If you start fluffing on some of the details, then that’s a red flag for an interviewer.
Establishing culture fit
Culture fit means a lot of different things for a lot of different companies, but for technical hires it generally means few things:
- Don’t be an asshole.
- You can work well with others.
- If you’re senior, you’re adaptable to teaching and mentoring.
- If you’re junior, you’re eager to learn and hold some humility.
But this is a really tough question to answer. Mainly because each company is so different. If you're interested in finding a company whose values align with your own, Key Values is a company that helps match software engineers to different startups based on the top values each company holds.
Lastly, do you know what you’re talking about?
This is just the B.S. flag that pops up in everyone’s head. As a candidate, you are a fraud until proven otherwise. This is just by nature of how many people apply to jobs and the scarcity of data scientist positions. Everyone is worried about hiring the wrong person for the job, so they overcompensate. This can be seen at many companies that reject a candidate if they have even one slightly bad or neutral onsite interview experience.
So just realize that you can’t fake it until you make it. At least not in your first few interviews.
Example Data Science Behavioral Interview Questions
Here are some example behavioral practice questions for data scientists. We’d recommend you try this out with a practice partner.
- Tell me about a time you had to communicate something technical to a nontechnical person?
- How would you communicate data driven insights to a business stakeholder?
- Tell me about a data project you have worked on where you encountered a challenging problem. How did you respond?
- Have you gone above and beyond the call of duty? If so, how?
- Tell me about a time when you had to clean and organize a big data set.
- Tell me about a time you failed and what you have learned from it.
- How have you used data to elevate the experience of a customer or stakeholder?
- Provide an example of a goal you reached and tell me how you achieved it.
- Provide an example of a goal you did not meet and how you handled it.
- How did you handle meeting a tight deadline?
- Tell me about a time when you resolved a conflict.
- What did you do in your last job?
- Tell me about a data science project you worked on?
- Tell me about a time you used data to influence a decision or solve a problem.
Thanks for Reading
We hope that you found the article helpful. If you did, subscribe to the Interview Query blog to receive weekly updates and new articles to keep you up-to-date on the state of the data science profession and loaded with tips and tricks to keep you one step ahead of the competition.
If you're currently in the process of interviewing for a job in the data science field, or just looking to brush up on your DS skills, consider signing up for a free account on Interview Query for access to our question bank filled with real interview questions from companies like Google, Facebook, Amazon, and more. Our questions are sorted by question type, position, and difficulty to make sure that you're practicing exactly what you need to practice to level up your skills and ace your next interview.
Finally, if you're looking for an all-inclusive starter course for data science, look no further than the Data Science Course on Interview Query. Covering subjects ranging from Product Intuition to Machine Learning to SQL, our course will bring you up to date on the things you need to know to become a data scientist.
Take the next step in your data science career. Try Interview Query today.