Office Hours; DATA SCIENCE INTERVIEW

One of the most common questions in Data Science interviews is being asked to talk about a previous data science project. The interviewer asks you to describe an impactful or interesting project from your past experience.
This question can appear in any part of the data science interview process. You could be asked this during the technical phone screening or the onsite interview, but the bottom line is if you want a job in data science you should expect this question. Every company asks it.
Yet, despite how common it is, many people do not prepare for this question. They view it as non-technical, and therefore not requiring advanced preparation.
However, failing to prepare for this question about past data science projects is a mistake! Many people do not provide good answers to these types of questions, and they may even be failing interviews because of it.
When you answer a question about a previous project, it is crucial to be prepared. Your answer needs to have structure so that you can easily make the necessary points and engage the interviewer.
The structure many people turn to answer such questions is the S.T.A.R method. While the S.T.A.R method certainly provides structure, it is not the best method for describing previous projects in a data science interview.
In this article, we will outline why the S.T.A.R method does not work in interviews and go over an alternative framework that will help you deliver a clear and engaging answer the next time an interviewer asks you to describe a past data science project.
Let’s dive in.
Table of Contents
What Is the S.T.A.R Method?
To understand why the S.T.A.R method does not work, let’s first make sure we understand what the S.T.A.R method is.
The S.T.A.R method is a framework that people use to answer behavioral questions in interviews. It is broken down like this:
- Situation: Begin by setting the scene and providing any necessary context or details for your story.
- Task: Continue by describing what your task or responsibility was in that situation.
- Action: Explain what actions you took to address that task.
- Result: Share what the outcomes of your actions were.
As a way to tell a story, the S.T.A.R method makes perfect sense. You start by setting the scene, then introducing yourself into that scene, describing what you did, and finishing with the impact of your actions. It relies on one of the most natural ways to order a story: chronologically. You start at the beginning with what you had to do and then end with what you did.
Why Does the S.T.A.R Method Not Work in Interviews?
While the S.T.A.R method is very natural and does provide structure, it is not an ideal framework for answering a question about a previous data science project for two main reasons: time limits and flexibility.
The Order Does Not Work with Time Limits

Let’s start with the problem of time limits. The S.T.A.R method puts the results at the end. Although this is logical in terms of the order things actually happened, it means that you will not be discussing the impact of your work and the project until the end, but the results are the most important part of your answer!
Remember what the overall goal of this question is from the point of view of the interviewer. They want to know if you are a good candidate for the position. They are trying to see if you can deliver as a potential employee, which means that the interviewer cares more about the results of a project than the context.
Putting this vital section at the end, as you do with the S.T.A.R method, is risky. If you run out of time, you will have missed the opportunity to discuss the most essential part of your answer.
And running out of time is a real possibility in interviews. When an interviewer asks you about a previous data science project, they could be looking for a 2 minute or 20-minute answer. There is no guarantee you will have enough time to get to everything you want to say, so saving the results for last is not a good idea.
Lack of Flexibility
The other problem with the S.T.A.R method is flexibility, or rather a lack thereof. The S.T.A.R method is in some ways too structured. It is a step-by-step plan that does not leave room for engagement with the interviewer.
What if the interviewer is not interested in the situation but wants to know more about your actions? What if the interviewer spends a lot of time asking for more details on the situation, and you do not have time to get the action and results?
A better structure will have set places that allow you to interact with the interviewer and alter your answer to best meet their interests and the flow of the interview. The S.T.A.R method is great for telling a story, but an interview should not be a story. It should be a conversation and that is where the S.T.A.R method falls short.
What Is a Better Alternative to the S.T.A.R Method?

Knowing what doesn’t work in interviews will only get you so far. Now that we know what’s wrong with the S.T.A.R method, let’s examine an alternative framework that allows you to structure your answer while giving you the necessary flexibility.
The framework I recommend also has four steps:
- Goal
- Impact
- Challenges
- Finding
Let’s examine these four steps and how this framework solves the problems that arise with the S.T.A.R method.
Goal
The first step of my framework is to summarize the goal of the project. Why did your company choose to do the project in the first place? What business problem was the project supposed to solve?
While this step is similar to the situation section in the S.T.A.R method, a vital difference is the length. You should only use one sentence to explain the goal of your project. You are not setting a scene, but simply explaining what the purpose of the project was.
If you need to provide more context beyond the goal of the project so that the interviewer understands, you can add another sentence here. This is where you might provide information like when you did the project, what company you did it with, how long it lasted, etc.
In total, the goal section of your answer should never be more than two sentences. Although some initial context is important, you want to keep this short so that you can quickly get into the parts of your answer that will show the interviewer why you are a good candidate
Impact
After explaining the goal of the project, now you can move into the most important part of the project: the impact. The S.T.A.R method leaves this part to the end (results), but by making this the second part of your framework instead, you ensure that you have time to discuss what you were able to achieve, which shows your capability as a candidate.
When explaining the impact of your project, it’s crucial to tell the numbers. For example, here is the first part of an answer to an interview question asking about past data science projects.
The most interesting data science project I’ve done last year was a project that aimed at improving customer retention by delivering a new feature on our app. The new feature was to provide predictions of the estimated time of arrival for shipments. It was a six-month project and we were able to improve customer retention by 20%.
In this example, you can see both how quickly I explained the goal of the project and how the metric I provided clearly displays the impact. By stating the result so soon you trigger the interviewer’s interest, which is vital during an interview. If you have them listening to you, all of your answers will have a much better chance of standing out and getting you noticed.
After you have finished the goal and impact, which all together should only be a few sentences, you have given a basic overview of the project. It is at this point that you should take the chance to interact with the interviewer.
Ask the interviewer if they want you to provide more context or dive into the details of the project? Let the interviewer choose which direction you will take next. This again keeps the interviewer engaged and makes your answer feel like a conversation rather than a report.
If the interviewer asks for more context, give more background information, but do your best to keep it short. The context can seem crucial, but it does little to help you in terms of the interview. The context of a project does not explain why you are a good job candidate, so avoid spending too much time dwelling on background information.
Challenges
It could be that the interviewer will be satisfied with your basic overview of the project, but most of the time they will want further details. When the interviewer asks you to continue describing the project, you can move into the third part of the answer framework: challenges.
I recommend discussing 2 to 3 challenges of the project. In choosing the challenges to discuss, aim for a mix of technical and non-technical examples.
Technical challenges are the practical problems related to data science you may have encountered during a project. Here are some questions you can use to think about technical challenges:
- Were there problems defining success metrics?
- Was it difficult to obtain the data?
- Was the dataset large? How did you deal with it?
- Was the data high quality?
- How did you process the data?
- Was there any challenge in model training and deployment?
Non-technical challenges include a wide range of problems that are not directly related to data science. This could be in areas such as project management and coordination with other teams and leadership. Here are some questions that can lead to non-technical challenges for you to discuss:
- Did you face any objections or obstacles from other teams?
- How did you get other people to buy into your idea?
- Were there any difficulties with deadlines?
- What did you do to unblock yourself or your team?
Why do you want to use challenges as a way to describe the project? Why not just describe the project?
Always remember the goal of this interview, and even of this specific question is for the interviewer to determine if you are a good candidate for the job. By describing a project with some of the challenges you faced, you demonstrate that you can deliver results.
Framing things in terms of challenges allows you to talk about yourself. If you just describe the project as a whole, the interviewer will be unclear about what specifically you did to drive the project.
It is not really about discussing the challenges. Instead, you should focus on demonstrating how you stepped in and resolved the challenges. This is a great way to show that you are qualified and able to have a real impact where you work.
While you may have a lot of great points to make here, remember to continue interacting with the interviewer. After you finish discussing each challenge, ask the interviewer if they want to hear more details or if they want you to continue describing the project. You want the interviewer to remain engaged.
Finding

After you have finished talking about the challenges, if you still have time left, you need a way to wrap up your answer.
Unlike the S.T.A.R method, we do not want to save the most important information for last, but we also want to end on a high note with the interviewer. To do this, I suggest sharing an interesting finding from the project.
There are lots of different things that can qualify as an interesting finding. You could share:
- An unexpected aspect of the data
- An insight you gained from the work
- An interesting observation
This might seem like you are just sharing fun facts, so how does it help you in an interview? In the challenges part of the answer, you demonstrated to the interviewer that you can deliver on the project. By sharing an interesting finding, you show the interviewer that you also enjoyed the project.
Showing that you take a natural interest in your work is a great way to assure an interviewer of your attention to detail and capacity for growth. You care and therefore are far more likely to devote your attention and effort to your work. It also ends your answer softly and engagingly after the intensity of discussing challenges.
Remember this is how you are ending your answer. You want to keep this section brief so that your answer does not drag on and bore the interviewer. Limit yourself to one thing from the project.
Conclusion
While the S.T.A.R method is an effective way to organize a story, it is not the most impactful way to explain a past data science project to an interviewer.
Instead, I recommend the Goal, Impact, Challenges, Finding model. This model puts the essential information first and uses a structure that keeps you focused on your own contribution to the project.
When using this model, always remember to leave room for interviewer interaction as I have discussed throughout the article. You do not want your answer to feel like a report. Let the interviewer guide you in terms of how much detail they want as you work through the various steps of the framework.
Describing a prior data science project is bound to come up in almost all data science interviews. Failing to prepare for it is thus a very preventable mistake. Using my framework, you can plan and structure your answer to give a clear, informative, and effective answer that will impress interviewers and make the most of your time.
Thanks for Reading!
If you like this post and want to support me…
- Subscribe to my YouTube Channel!
- Follow me on Medium!
- Connect on Linkedin!
- Head over to emmading.com/resources for more free resources on data science interview tips and strategies!
Product Case Interviews Dos and Don’ts for Data Scientists
How To Deal With the 5 Types of Interviewers on Data Science Interviews