STAR is old-hat. RATS could be the new cool.

The "STAR Method" for responding to some common, widely used classes of interview questions has likely been touted for a few decades now. In practically every kind of career foundations training I've been through, the coach/mentor would invariable propose to learn and execute this ancient formula for telling a story. However, I think it's actually quite an awful format. It's one that is more suited to written form than oral form. In fact, I think it's time to put STAR into the graveyard and replace with its reverse - the "RATS Method".

What is this "RATS Method"? Simply, it is delivering all the same information as intended by STAR, in reverse order.

But why?

Let's first take an archetypical STAR story.

Situation: In my previous role as a sales representative for XYZ Company, we identified a potential client in the manufacturing industry who was looking to streamline their supply chain processes.

Task: My task was to secure a meeting with the client's decision-makers and understand their specific challenges, with the ultimate goal of proposing a customized solution that would improve their efficiency and reduce costs.

Action: I initiated contact with the client and successfully scheduled a meeting. During the meeting, I actively listened to their concerns and requirements. Drawing on my knowledge of our product offerings, I presented a tailored solution that addressed their pain points. I also demonstrated how our solution had successfully improved processes for similar clients in the past.

To further build trust, I collaborated closely with our internal teams to ensure we could meet any specific requirements the client had. I provided regular updates and engaged in transparent communication throughout the process. Additionally, I offered a trial period for our solution so they could experience the benefits firsthand.

Result: As a result of our efforts, the client not only adopted our solution after the trial but also expanded their engagement with our company. The streamlined processes led to a 20% improvement in their supply chain efficiency and a 15% reduction in operational costs. This success not only strengthened our relationship with the client but also served as a case study for attracting new business in the manufacturing sector.

Looks great in text. We're used to reading chronological tales in that form: start - middle / development - conclusion. Some people may even be masters of oral storytelling in that form and do an amazing pitch in that style. Above, I used a "sales" story - most people can latch on and fill in blanks in contextual understanding by leveraging cultural norms and social patterns.

Now consider the cognitive load during a 2-3 minute delivery of such a story.

The storyteller must have formulated extremely brief "situation" and "task" contextualization in advance. That is because the listener typically wants to filled with meaty "action" and "results" drama and feel-good happy endings. That's fairly easy to setup when describing "social challenges". It is not easy when describing "technical challenges", because of the extreme amount of expertise required to completely and accurately describe and even understand what will typically be highly unorthodox, gnarly, and novel situations.

Social challenges probably often resolve very nicely through simple-to-understand "smiles and rainbows" – think, see, do... done – with a heaping of sparkles.

Technical challenges, in my opinion, are best appreciated by diving into the minute of the details. Additionally, a ton of them will likely be the style of "problem, fault or puzzle" -> "motivations" -> "scientific method" -> "innovation".

I'll illustrate a STAR style rendition of one case I've personally handled, and add a set of hypothetical "reflections" that an interview might have on the spot.

Situation: Working on the e-commerce team of a brick-and-mortar retailer, it was really painful that a weekly deployment of the "new, latest and greatest" version update to the online store demanded "all hands on deck" for a whole day.

Interviewer > Okay. Retail and e-commerce work. Clearly, he'll tell me he solved the challenges of the weekly deployment. That's the obvious conclusion that the STAR method will have anyway.

Task: One day, it was my turn to take the reigns as the "leader" of the deployment. Rotation of the "leader" role makes for good skill-sharing, after all.

Interviewer > As predicted, it falls on this person to tackle the problem.

Action: I completed the deployment in merely 1 hour of effort, solo. In fact, that day, I spent about 6 hours on hold before things finally got deployed, because the system administrator was a bottleneck due to them being highly busy and unavailable – they were the gatekeeper to the production servers.

Interviewer > Naturally, he took actions handling deployment.

Result: The team was impressed with how I accomplished what was effectively a 64-fold boost in productivity – the normal routine took 64 hours by having 8 staff members working an 8-hour day for an average successful deployment. Eventually, my deployment method was adopted by the team. The dependency on the system administrator was also eliminated. Extrapolating that over just 1 year (let's say 48 working weeks) would net 3,024 newly freed-up hours that could be put towards other useful work. That's roughly the equivalent of having an extra 1.5 staff members available – people typically work around 2000 hours per year.

Interviewer > Ah, right. If I think about it that way, he really did create savings of an amazing amount of time yearly, but I already predicted some kind of innovation since this is a STAR story.

Personally, I find that story to be extremely lackluster when framed in that way because it does not demonstrate the key details of HOW the candidate accomplished the technical feat of a 64-fold increase in productivity in the team.

How about telling the story in reverse, though? This is the "RATS Method".

Result: Once upon a time, I introduced roughly 3000 hours' worth of yearly productivity gains at a brick-and-mortar retailer with an 8-member e-commerce team.

Interviewer > Oh, a "wow" kind of result. I wonder what got him that. Better listen closely.

Action: This was accomplished by teaching the team how to use "git", and having the e-commerce project completely migrated over to "git" as the primary version control system.

Interviewer > I listened and learned what the principal solution was. But why that? Better keep paying attention.

Task: Each week, the team needed to deploy the latest new features of the e-commerce platform to the "production" servers.

Interviewer > Ah, it's starting to become clear. There's a weekly problem.

Situation: Before "git" was adopted, the team was using "svn" for managing their codebase. Due to how poorly branching and merging are handled using "svn", it actually took the entire team a full day of effort, weekly, to slog through preparing a package that could be deployed to the production servers. Checkouts took a long time. A single merge operation was often conflicted and took enormous efforts to resolve. Having multiple challenging merges to do would be typical. The baseline effort for these deployments was 64 hours of effort with all hands on deck – 8 staff members working an 8-hour day. To reiterate the results that I've produced, it becomes roughly 3000 hours per year in effort savings because I reduced the required effort down to merely 1 hour on average. A single developer would be able to easily do the deployment using "git" instead of "svn".

Interviewer > Aha!

I have a hunch that telling the story in reverse order puts emphasis on the crafty, smart innovations that were put in place. It should also help to enable a strategy to more easily "hold back" on nitty-gritty details until later into the conversation rathern than "detail dump" earlier in the process and be penalized for not "keeping things ultra concise and brief".