Cracking the Behavioral Interview: Putting it together with PEARL
Problem, Epiphany, Action, Result, Learning
Cracking the Behavioral Interview is now complete! The first article is optional, but reading the rest in order will set you up for success:
So, you’ve done the hard part. You’ve chosen a high-stakes project where you personally drove success. You’ve remembered the impressive details.
Now we just have to put it together into an engaging and easy-to-follow story. A little bit of structure will help you out.
There’s nothing wrong with using STAR (Situation, Task, Action, Result) if it’s working for you. But when you’re applying to senior roles in tech, STAR might lead you astray:
The story sounds like it is happening to you, not something you’re driving. The situation existed and you fell into it.
The task appears out of nowhere and you need to deal with it. Did the manager tell you to take on the task? Maybe?
The comprehensive step-by-step list of actions goes on forever and feels like a waste of time.
You end negatively framed questions like “tell me about a failure” on a low point
A lot of tech people have found that PEARL works a little better to tell impressive stories.
PEARL
PEARL stands for Problem, Epiphany, Action, Result, and Learning. Here’s how it works.
Problem
Start the story by framing up the problem. you’re going to teach the interviewer what they need to know about the product, customer, industry, etc, so that they care about the problem you went on to solve.
Our job is to solve problems. Customer Problems, Business Problems, Design Problems, Technical Problems. These pain points matter, and I bet they’re something you feel strongly about. Your goal is to get the interviewer to care too.
Some things to include
Quick Intro and Starting Context details - you can reuse your company’s existing mission, strategy, etc. to get started
The problem, and how it ended up on your plate. What were you handed, and what did you notice yourself? Make it clear if you identified the problem.
An example that highlights the pain point
It’s okay for this part to get long. Your interviewer will enjoy learning about your industry and the bits of expertise that you’ve picked up along the way. They should feel emotionally invested in the problem and believe that it’s important to solve.
Epiphany
Next, you need to show your unique contribution. If you’ve picked an impressive story, then you weren’t just doing what anyone in your shoes would have done.
There’s some reason that you decided not to go with the flow, and that reason is the insight you had. What insight did you discover? How did you see it when others didn’t? That’s your epiphany.
For senior-level roles, the epiphany is key to the hiring decision. Once you’ve come up with your insight, the rest of your actions naturally follow.
This is a great place to bring in your principles, values, and other signs of your experience. Maybe your key insight came from your value of digging deep into the data. Or you’ve learned from experience to pay attention to surprising customer questions and follow up on them. Perhaps you’re always strategically looking for opportunities to integrate your product lines.
There’s more examples of insights and epiphanies here.
Action
For the story to make sense, you do need to touch on the work you did, but keep it brief.
This is were you talk about how you made it happen and what obstacles you overcame.
You don’t want to list out a bunch of obvious steps where you did what anyone would do. On the other hand, the interviewer might be looking for specific experience like A/B testing or AI prototyping that you should mention.
Knowing what to include and what to skip takes a bit of awareness. Did the job description or company website list specific requirements? If so, include. Are you going from one well known company to another? If so don’t bore them with steps that they already assumed you followed.
Result
You need to show that you’re results-oriented, so be sure to include the results. Strategically, how did it go? Tie this back to the original problem and goals.
It’s great to include numerical results when you have them, and even better to put those results in context. Was this the biggest adoption win your company had ever seen? Did it double your expansion revenue? Maybe these results were strong enough that leadership decided to double the investment in your team. Help the interviewer understand how good the results are.
Learning (for growth stories):
Your interview story should end on a positive note, and including what you learned lets you do that.
Growth questions are the ones that ask you about a time you messed up. If you took them at face value, you’d just talk about the negative results. But they’re really meant to surface how you’ve learned and grown.
What was your assessment of what went wrong? What did you learn?
And then, talk about a time you applied that learn. How did you do better next time?
However, you don’t need to include learning on every story. If you’re applying for senior and director level roles, it can backfire if it looks like you’ve just learned new things in your recent projects. You want to show that you’re past the learning stage, and into the “knows how” or “excels” stage.
Examples
Here’s how it all comes together.
Moneyball
Here’s “project I’m proud of,” inspired by the book Moneyball.
I’d love to talk about how I turned around the Oakland As baseball team, sound good?
When I first took over as General Manager of the Oakland A’s, we were one of the poorest teams in Major League Baseball.
When you run a baseball team, one of your biggest levers for winning is the players you sign. Big teams like the Yankees and Red Sox could spend two to three times more than we could on salaries. They could sign superstar players and poach the talented players we developed. That cycle made it nearly impossible to sustain success, and we were expected to sink to the bottom of the standings. (Problem)
But, I realized that the way we were traditionally scouting players didn’t seem very predictive: the fastest runners and players with the best batting averages didn’t perform the best once they were on the team. There had to be a better way. So, I worked with my assistant GM who ran models and found out that on-base percentage was one of the most predictive stats for scoring runs, and it was deeply undervalued. I realized we could buy wins more cheaply than anyone else if we changed how we valued talent. (Epiphany)
So, I restructured our recruiting strategy, focusing on on-base percentage. We hired older guys with bad knees and hitters with awkward swings. As you might imagine, there was a lot of resistance from scouts, coaches, and ownership, if you want I can go into how I brought them over. (Action)
With this new approach, instead of collapsing in the standings as predicted, we won 103 games, tying the Yankees, and finishing first in our division. And we did it spending less than a third of the Yankees’ payroll. I’m really proud, not only of the division title win, but also because this approach was eventually adopted by the entire league and led to better baseball. (Result)
Notice how most of the answer is spent explaining the Problem and Epiphany. We’ve let the interviewer know we can dig into the Action more if they want, but we’re not going there pre-emptively.
Combining Projects
Sometimes you don’t have a perfect project to talk about. In those cases you can combine multiple projects into a larger theme.
I’d love to talk about how I turned around some struggling teams at my company over the past year.
So, at my company we have about 20 product teams across 3 focus areas. Strategically it seemed like we were going after the right problems, but the teams were struggling to ship. Sometimes a team would spend months circling around dependencies and requirements, and it was taking a long time to get new products launched, which was affecting our revenue. This was considered the top company risk by the leadership team.
The head of product saw that my teams had shipped well, and so he asked me to join the dashboards team to run their next launch which was at-risk. When I joined I realized that things were being run in a very ad-hoc manner, and so engineers just weren’t clear on what they should be building and not driving towards small milestones. (Problem)
So for this first team, I just came in, listened to all the people on the team to understand their concerns, and put in place some basic best practices - 2 week sprints, prioritized backlogs, daily standups. We got the launch out on time, and the team’s morale improved a lot.
I thought I’d go back to my original team, but the Head of Product then asked me to keep working on the next high-impact at-risk team. I found basically the same problems on that team, and I realized that the root problem was that teams lacked a repeatable playbook for execution. A lot of our PMs had been promoted internally and were learning on the job, so they sometimes missed things that were more obvious to me. (Epiphany)
So, I decided that in addition to helping these teams get back on track, I’d document the best practices and run a series of learning lunches to help other teams. (Action)
So, I’m really proud that over the year, I helped six projects get out the door and increased our revenue growth rate, but I’m also proud that I was able to improve our overall shipping culture. Today most of our teams use my playbook and we’ve stopped seeing our launch execution problems as a top company risk. (Result)
Since none of our individual projects were that impressive, we’ve instead focused the answer on the repeatable process and organizational excellence.
To make this story work, the documentation and learning lunches were an important, but small step. If you’re in this situation today, see if there are similar ways that you can share your learnings with the rest of the company to uplevel your experience.
Growth Questions
When we get asked about a failure, we’ll need to add on the Learning so that we can end on a positive note. Remember to pick a story that was foundational for one of your current strengths.
Here’s one of my real examples from early in my career, although for an actual interview this was too long ago. I’ve got a more recent example in this post.
When I joined SharePoint full-time, one of the features I was assigned to own was RSS feeds, which had just been built over the summer by some interns. This was my first time taking over an in-progress feature, and my instinct was to respect the work & planning the previous people had done, and just finish up the remaining polish.
So you might not have heard of RSS feeds, but they’re basically the way the podcasts work today - any website can make a podcast, and any podcast app can subscribe to get new episodes. But, news reader apps didn’t have the “open in app” functionality yet, so websites would just put a link to the feed that you’d have to copy/paste. If you clicked on the link instead of copy/pasting it, by default you’d get a scary page of xml. We didn’t want to scare SharePoint users that way.
Luckily, a few sites were already using stylesheets to make that scary page look like a normal web page. I knew some other teams at Microsoft used RSS, so I reached out on their mailing list to see if they had stylesheets we could use. I asked for one for RSS, and one for another format called Atom, since we were letting the user choose which format they wanted.
I was totally shocked and embarrassed when I got a reply-all email berating me for having an Atom option when we should only have RSS. (Problem)
After I got over the shock, I realized the other PM was right. I learned that the RSS vs. Atom debate was an internal standards debate between Microsoft and Google, and it had no end-user impact because all the news readers supported both. (Epiphany)
I felt bad about undoing someone else’s work, but I removed the Atom option and added a stylesheet for RSS, which turned out fine for our customers. (Action+Result)
What I really learned from this experience was that it’s my responsibility to become the expert in the features I own, even if I’m inheriting them from someone else or coming in near the end of a project. Now when I join a team I really dig into the past decisions and make sure I understand and agree with them. I’m still mindful of the balance of changing things and delaying a launch, but I’m willing to make changes if I believe they’re important for our customers or business and the timing matters. (Learning)
This one took a while to explain the problem, because the story wouldn’t make sense without it. I could probably get it a little shorter if I could get rid of my instinct to explain how things were different in the old days. But, I kept the action and result really short, because they’re not important to the story.
I like this story because I think it illustrates my strengths and weaknesses fairly well: I get a little caught up in my emotions, but I also recognize it and have found ways to push through to get the right results. The interviewer really learns something about what it’s like to work with me.
How not to sound over-rehearsed
When it comes to the interview, you don’t want to get disconnected from your story and end up in that awkward spot where your mouth is reciting words and your brain zones out. Trust me, I’ve been there.
There’s two approaches you can take:
Jot down just the keywords in bullet points, and then come up with the words you’ll say in the moment
Practice, practice, practice, until you’ve rehearsed through the awkward stage and you really know your stuff so well it’s natural
Many people love approach number one. I’ll be honest, it doesn’t work for me. I freeze if I just see keywords and I’ll still ramble. So, I get my interview stories to the same point of familiarity as my “How my husband and I met” story.
You probably have a similar story that you’ve told a million times, how you chose your college, what made you decide to go into technology, etc. Think about how you don’t use the exact same words every time you tell the story, but you probable hit the same beats in the same order. Once you get two of your interview stories to this point, the rest come a lot easier.
Conclusion
The hardest part of behavioral interviews is picking the experience you want to talk about and finding the impressive details. Once you have those, you just need a little structure to get your story across.
If the STAR format hasn’t been working for you, try out PEARL to keep your answer sounding high-impact and focused on your specific contributions.
To practice and to generate more examples, try out my custom GPT : PEARL Interview Coach.
Good luck!
In case you missed them,
Cracking the Behavioral Interview, the complete series: