Why The S.T.A.R Method Does Not Work in Data Science Interviews and What to Do Instead

At some point in the data science interview process, you’re going to be asked to describe a previous data science project.

Although this question is not technical, failing to prepare for it is a big mistake! To give a good answer to this type of question you need structure so that you cover what you need to and keep the interviewer engaged.

In this post, we are not only going to discuss a useful structure, but we are also going to go over why one of the most common structures (the S.T.A.R method) is actually not the best for describing projects.

The S.T.A.R. Method

This method is one of the most popular for answering behavioral questions and interviews. It goes 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.

The S.T.A.R. method makes sense to people because it is natural. It basically relies on telling a story in chronological order. However, there are some issues with using it to describe a past project.

Time Limit Problems

The gist of this problem is that the S.T.A.R. method puts the results at the end.

While this makes sense chronologically, the results are the most important part of your answer, and you do not want to save them to the end. Results show what you can deliver as an employee which is what the interviewer cares about.

That makes the S.T.A.R. method risky. There’s a very real possibility that you will run out of time before you get to the important stuff.

Lack of Flexibility

In some ways, the S.T.A.R. method is actually too structured. It does not leave room for engagement with the interviewer.

The S.T.A.R. method requires you to tell your story from beginning to end without interruption to hit everything. If the interviewer asks questions about the situation at the beginning, your structure will be off, and you will not have enough time. That makes it difficult to have a conversation with the interviewer which is what an interview should be.

An Alternate Method

This alternate framework gives you structure while also giving you flexibility. This framework also has 4 steps:

• Goal
• Impact
• Challenges
• Finding

Let’s look into these 4 steps and how it helps the problems that come with the S.T.A.R. method.

Goal

The first thing you need to do is summarize the goal of the project. Why were you doing it, and what business problems was it addressing?

The main difference between this and the situation step of the S.T.A.R. method is the length. Keep it to just one sentence.

You can add another sentence if you need to provide more context, but it should never be more than 2 sentences.

Impact

After that brief introduction, you want to move straight into the most important part: the impact.

This gives you plenty of time to discuss what you were able to achieve, demonstrating your capability as a candidate.

One thing to keep in mind during this section is to use numbers. Quantifying things makes it clear how you impacted the business.

It is at this point that pausing to interact with the interviewer is a good idea. You can ask if they want more context or if they want to know more details. Let the interviewer guide where the discussion goes so that it feels like a conversation.

If they do ask for more background information, still try to keep it short as this information is not going to explain why you’re a good job candidate.

Challenges

It’s possible that your description might stop after the impact stage, but if the interviewer wants to hear more about the project, you can move into this step.

Discuss 2 to 3 challenges (a mixture of technical and non-technical).

Technical challenges are practical problems related to data science, and non-technical challenges are problems that are not related to data science. A technical challenge would be a problem defining success metrics and a non-technical challenge could be tight deadlines.

Describing the project through challenges is great because it lets you talk about yourself. You talk about the difficulties you faced and how you resolved them. This gives you more opportunities to show the interviewer that you are qualified and have impact.

Just remember not to get carried away. Continue checking with the interviewer to see what they want to hear about after describing each challenge.

Finding

If you are not going to end with the results, how do you wrap up your answer?

Sharing a finding is a great way to end the discussion. It’s interesting, but it’s not absolutely crucial in case you run out of time and don’t get to this step.

What qualifies as an interesting finding? Here are some examples:

• An unexpected aspect of the data
• An insight you gained from the work
• An interesting observation

This part isn’t about just sharing fun facts. Sharing an interesting finding shows that you actually find your work interesting and engaging which means you’re motivated. That’s an excellent quality to show the interviewer.

Just like the goal section this should be brief. Stick to just one interesting finding.

Final Thoughts

Discussing a past project is something that you will almost certainly have to do, so it pays to be prepared.

The important thing to remember (and why I ultimately do not recommend the S.T.A.R. method) is that the goal is not to tell a story but to convince the interviewer to hire you. Focus on impact and challenges because they show off your capabilities. Interact with the interviewer so that you give them the information that they want to hear.

Best of luck with your interviews, and if you found this article helpful, you may want to consider reading the longer version of it here.