Using the STAR Framework

While Exponent doesn't recommend heavy use of frameworks, we often find the STAR framework to be a helpful starting place for structuring behavioral interview answers where rambling is a real danger.

STAR stands for:

• Situation: What relevant context does the interviewer need to understand the challenge?
• Task: What was your specific role in this situation?
• Action: What steps did you take to solve the problem?
• Result: What was the outcome? (use numbers if you can!)

The purpose of STAR is to keep you focused. If implemented correctly, you'll communicate all the relevant context needed to answer the question, while highlighting your specific actions and achievements, in a concise way.

For this lesson, we'll use a very common behavioral question as an example: Tell me about a time when you disagreed with a colleague.

Situation

First, think back to your story bank. Of your chosen stories, one should stand out to you as the most challenging and nuanced. It should also map to one or more company values. Remind yourself what you wrote down, and which company values you'll be showcasing.

Remember - it's absolutely fine to pause before launching into your answer. In fact, interviewers often like this. It shows poise and thoughtfulness.

Once you're ready, begin with the S - Situation. Describe the context of your story. This is a great way to set the stage and set up why this problem is worth talking about. Don't just say the basics, but also accentuate the ways in which this setup led to a challenging circumstance that you had to face. If you can tie the context back to company goals or business priorities, that's a bonus! Business acumen is a definite plus for engineering candidates.

Tip: Don't forget to also fill in the gaps with information or knowledge that the interviewer may not have - it's easy to slip back into acronyms or describe projects as if the interviewer was on the team!

Question: "Tell me about a time when you disagreed with a coworker."

Answer: Situation

In my last role, I had just switched to a new team where I worked as lead engineer. My first project was orchestrating a major feature release. Product management wanted to launch three new features for testing in order to validate the product roadmap prior to raising a Series B round from investors. Upper management understandably wanted everything in tip-top shape before investor talks. However, we'd just dealt with a massive setback in our coding progress because of previous work that had been done sloppily, requiring our team to redesign much of our system architecture from the ground up. This cost us significant engineering time and put everyone under a lot of stress. I wanted to hold off on the feature release until we could implement a few infrastructure changes that would allow us to more easily test in the future.

Task

You can feel free to skip this step if you feel like your situation step already described it (technical folks often use a variant of STAR called SAR). That said, it usually helps to clarify what the specific task is at hand here, and your role in it.

It's also worth calling out any specific benchmarks/goals you were meant to accomplish (reduce latency by X%).

Answer: Task

The company goal was to solidify the product roadmap and be investor-ready within just one month. Launching the feature set for testing was a major part of meeting this goal, but as lead engineer, I was specifically tasked with implementing long-term solutions, not hacky fixes. My manager was insistent that we not repeat sloppy practices that had led to the significant refactor we'd just finished. I was at a crossroads - between upper management and product management, which were both pushing to release the full feature set (which blocked important investor-related presentations broadly) versus my manager, my team, and my commitment to quality engineering.

Action

Now, for arguably the most important piece - describe how you tackled this problem. Be sure to highlight the skills that are relevant for the job and the company values you've identified.

Because behavioral questions assist all manner of soft skills including collaboration and communication, we recommend not just talking about yourself, but also about your team and any other stakeholders you worked with to overcome the challenge. It's easy to think that you're supposed to highlight your role in the entire process, but it's also important to have humility and not overstate your role. Be confident while also crediting the larger team appropriately.

Answer: Action

At first, I asked whether the one-month deadline was set in stone. I was immediately assured that it was. I sat down to think through my options, made a list, and shared them with my manager. I saw roughly three choices. 1) delay the feature release to implement the needed changes, 2) launch a reduced feature set while also investing in engineering infrastructure, or 3) launch the full feature set and delay engineering updates. I realized that launching an altered feature set might be possible, as I knew that testing was blocking product management decision-making, but I wasn't sure if all three feature requests were critical blocks. My intuition was that I could find a way to unblock the PM team while still going ahead with the needed infrastructure updates. But I needed more information.

The above answer does a great job of demonstrating thoughtfulness and out-of-the box thinking.

I set up a meeting with the product manager and a UX researcher. I gathered that what the PM and UX researcher really wanted was to validate a hypothesis about user behavior that would have a significant impact on the product roadmap. The launch supported that goal, but I wondered if it may be possible to validate the hypothesis with a reduced launch if we also implemented some clever data collection. I prepared details on the cost/time spent on the recent refactor, and shared my plan for the infrastructure update that would allow us to A/B test more easily. I did my best to minimize the timeline, and remove barriers to the roadmap validation. The product manager understood my concerns and was excited at the prospect of easier testing, and went back to his manager to get a sense of what the CEO most cared about given the investor meetings. He told me that the CEO wanted a solid roadmap insofar as it affected his ability to chat with investors and showcase our amazing product - he didn't care much about what specific features were tested.

This latter half of the "action" stage really showcases empathy, collaborative skills, and "bias for action" - an extremely common value that's highly sought-after by tech companies.

Result

This is the final part of the interview answer, and the most satisfying! Tell your interviewer how the situation was resolved, thanks to the action you took. Be sure to also voice any learnings or lessons from the experience.

Answer: Result

I now knew that we'd be able to come up with a solution that worked for everyone. We all restated our goals clearly, and with a common understanding of what needed to be done, the PM accepted my plan for a reduced launch while completing a larger system design change that would allow us to avoid headaches in the future. We all moved ahead without escalating to the CEO. The reduced launch went off without a hitch, the product team validated its hypothesis with confidence, and with a few late nights, we completed backend work seamlessly. In the end, I learned a valuable lesson about checking assumptions before jumping to conclusions and changing direction such that everyone's goals are met.

Tips for using the STAR framework

Now that you've practiced the STAR framework, you may be tempted to rehearse your answers. We do NOT recommend this, as authenticity is key to performing well in behavioral interviews. If you rehearse too much, you'll be thrown when you're inevitably asked a follow-up you haven't practiced. Instead, we recommend coming into the interviews with a few high-level examples and situations and tailoring them to your interviewer in a natural, conversational tone.