Answering behavioral interview questions with STAR stories: What makes a strong Results section?
STAR is a method for structuring answers to behavioral interview questions. The part of S-T-A-R that I see my clients struggle with most is the Results section in their story.
Anyone who’s started to create their interview answers develops a healthy fear of the Results section:
“Should I include data?” “What data?”
“What if I don’t have any data?”
“What if I don’t have enough data?”
“I’m in Sales, I don’t really collect data.”
There are some cases where the results might just be “the customer was happy” - and it’s hard to quantify happiness. But if I’m coaching you, I would try to get you to quantify it. The customer was happy, and then what? Did they sign another deal with you for $4M/year? Did they refer other clients?
Data always makes your story stronger.
Sample S-T-A-R answer
Here’s an example of a story we can use to talk about a good strategy for the Results section.
Question: How do you find out what your customers need?
Answer given by Senior Digital Product Manager.
S/T: I’m currently a Product Manager working at a training company. We have an app that provides technology learning primarily for enterprise customers. I use both quantitative and qualitative methods to find out what the customers want and need. For example, earlier this year, I wanted to find out what type of content was most popular in our app so we could do more of it.
A: I looked at data on my top customers, in terms of the customers most engaged on my platform, and I could see that content about IT certification was very popular. I wanted to dig deeper on this topic. So I started to talk to customers about the role of certification in their workplace. It turns out that getting certified is important because it’s tied to career growth, most specifically getting promoted. I also asked them what certifications they wanted the most.
Based on this research, we decided to increase our product offerings in this area. We already had courses and videos about certifications, but we added webinars to the educational product lineup because different formats appeal to a wider audience. To reach more users, we needed to diversify how the material was presented. We also increased the number and type of certifications we offered in areas where we saw the most interest – cloud-related technologies and security, for example.
R: Those trainings turned out to be popular. The average user now spends 23% more time per month on our learning platform, most of which can be attributed to our new IT certification-related materials.
Okay, so that’s our story. Overall it’s fine, but how’s the R?
Strategy for a good Results section
What does a good R include?
Did you include the Results?
First of all, you need to give results. Many people forget this section of the story entirely. You can’t have a good R if you don’t have any R at all.
Was it resolved?
What was the outcome you achieved?
You need to say what happened with the original problem. In this case, did the Product Manager find out what what content was popular? Yes. Did he provide more of it since that’s what his customers wanted? Yes. So by doing these things he’s at least hit the bare minimum of standards, for both himself and for the Results section of his story.
How did you measure success for this project? Quantify to understand volume, size, scale.
You can give both absolute numbers and relative percentage.
He did this – he talked about the 23% increase in engagement.
But I feel like he could have added more data. He has an adequate R but it’s not excellent.
Set up the Situation better
You can also imagine how he might have set up his Results better in the Situation/Task section by adding a single sentence related to the larger business goals: “For example, earlier this year, I wanted to find out what type of content was most popular in our app so we could do more of it. Since we’re a SaaS company, my ultimate goal was to increase retention.”
That single sentence does a lot because it frames for the listener the type of business the Product Manager works for, and it demonstrates that the Product Manager is seeking to drive engagement in service to an important business metric. With that sentence in the S/T section, he can now refer back to it in the Results section, making for a much stronger answer.
Where was the impact?
In addition to saying what you did resolve the issue and how, and giving the bare minimum measurement, you can also give more detail about impact. “Impact” can apply to different things depending on your job. In my example, the Product Manager talked about the customer-driven impact, but he didn’t go into much detail even about that, and didn’t hit any other areas.
YOUR IMPACT CAN BE:
Top-line driven: revenue, market share, new customer acquisition
Bottom-line driven (cost-savings): time/person hours, budget, space, equipment reuse
Customer-value driven: CSAT, customer anecdotes, adoption rate, retention rate
Engineering driven: traffic volume/velocity, week-over-week bug/severity tally, implementation time, deployment time, compute power/time metrics
Risk driven: risk reduced, crisis prevented
Team driven: morale improved, collaboration facilitated
In our example, the Product Manager could also talk about the top line: how many customers did they have in the beginning, how many did they add, what type of customers were they, what kind of revenue did that bring, etc. He could have also given more of the customer value impact: CSAT score improvement, retention rate, etc. Or he could have talked about the risk to the business he mitigated: customers were leaving the platform and he needed to stop the attrition.
Checklist:
Was it resolved? What was the outcome you achieved?
How did you measure success for this project? Quantify to understand volume, size, scale.
Where was the impact?
Top-line driven: revenue, market share, new customer acquisition
Bottom-line driven (cost-savings): time/person hours, budget, space, equipment reuse
Customer-value driven: CSAT, customer anecdotes, adoption rate, retention rate
Engineering-driven: traffic volume/velocity, week-over-week bug/severity tally, implementation time, deployment time, compute power/time metrics
Risk driven: risk reduced, crisis prevented
Team driven: morale improved, collaboration facilitated
Like I said, this data in the Results section issue is one of my clients’ biggest concerns. Even if your answers are already good, it can be hard to know whether you have enough data or you need to add more. If you’d like to focus on that in a coaching session with me, let me know.
Related reading:
How to answer behavioral questions in your Amazon job interview
