Floppy disks, VCRs, and the STAR format: all invented in the ‘70s, and no longer useful. There is a better way to answer interview questions, but we’ll have to hack together a solution to find it.
STAR wasn’t killed by the Death Star, it was killed by the souls of the thousands of engineers who unsatisfactorily deployed it in a job interview. It scrapes and clangs to the island of obsolete technology which is probably ruled by Sid from Toy Story who, in that universe, is around 30 years old which, in engineering years, means he’s old enough to have survived 1.5 PIPs, 2 layoffs, and an obsession with AngularJS.
In this article, you’ll learn:
- About STAR interview questions and answers
- Why using STAR to answer job interview questions is inefficient
- Learn our best alternative to STAR
What is the STAR format?
The STAR format is a technique used to answer common behavioral interview questions with a straight-ahead style by describing the Situation, Task, Action, and Result. Sometime after its release, STAR gained popularity until it became the de facto structure for interview answers across virtually all disciplines: engineering, sales, recruiting, ops, and more.
Infographic defining STAR. Kinda looks like it was made in the ‘70s 😏
Why STAR burned out and faded away
The reality is, STAR promotes windbag answers, remains unadapted to engineering interviews, and has become a predictably obvious playbook (to the chagrin of interviewers).
Somewhere along the way, duration became the goal and quality suffered; I’ve heard “2 minutes” as well as “4-5 minutes” as “goals” for a STAR answer. Even worse, some candidates get the advice of “just make a handful of 4-5 minute answers to fill up your 30-minute round.” Aiming to “fill up time” in an interview is harmful. (Candidates do this in system design interviews, too. Those failures are equally spectacular.)
Taking up so much space that the interviewer doesn’t have time to engage (ask good follow-up questions) is a massive risk. If your answer is off track, you just tanked the round because there’s no chance for the examiner to do their job, which is to find enough signal to hire you.
Interviewers of salespeople and engineers aren’t looking for the same criteria; salespeople ad coders need not use the same framework to communicate to an interviewer. There are certain things almost all engineering interviewers will appreciate hearing, and they have a higher hit rate than the “situation”, “task”, etc.
Sticking to the script too much (being “too scripted”) gets heavy penalties from senior (and above) interviewers. When candidates use a playbook so egregiously that it’s obvious to the interviewer (or hiring manager) that they’re using a playbook; it might not be cheating, but it’s no further than a distant relative. This lumps you in (from the interviewer’s perspective) with the other candidates who rely too heavily on playbooks, and most of them aren’t good enough to pass. By the way, this over-and-obvious reliance on playbooks seems as common (and as unfortunate) in system design rounds, too.
The only time to use the STAR interview response
The STAR interview method is a helpful beginner framework for learning how to answer behavioral questions because it’s formulaic. If you’re a junior engineer, or brand new to interviewing, the STAR format provides solid training wheels for providing a straightforward interview response but you need to take them off to go anywhere worth mentioning (like Hogwarts, Dairy Queen, or successful senior-and-above-level interviews).
Use cases STAR can’t handle well
A knock on effect is that candidates who train in STAR will employ the approach even when it’s clearly unnecessary: you see what you train yourself to see. Every question is seen as a nail, and STAR is the only known hammer. When interviewers ask more conversational questions (designed to have a back-and-forth discussion)–these questions are usually shorter or more reflective–a STAR-style answer can arrive loudly and abrasively.
A brazen belief in STAR is an illusion that follow-up questions don’t exist. Follow-up questions are the more challenging part of an interview. Give your 5-minute monologue, think you crossed the finish line, and then be rudely awakened by a smart follow-up question. Companies, like Amazon, lie in wait during your initial answer, only to ask pre-planned targeted follow-up questions asking you to radically change course (such as asking about a time when the answer you just gave wasn’t true).
Mike Tyson famously quipped: “Everybody has a plan until they get punched in the face.” In interviews, the follow-up questions are that punch in the face.
At a company like Google, though interviewers tend to not take behavioral rounds very seriously, their behavioral interview questions tend to be more conversational. Even if a company doesn’t explicitly seek more conversational rounds, they will appreciate brevity and you’ll stand out against the hordes of others who spoke for too long and got rejected.
10 don’ts and do’s: From STAR to an alternative
The 5 (“do”) factors here provide a roadmap to clear communication, and more importantly, a blueprint for a desired alternative framework to answer interview questions:
- The more conversational it feels, the better
- Less is more
- Shield your interviewer from unnecessary details
- Fit the model to the engineering interview
- Break the rules
Best alternative to STAR Method
There are several known alternatives to the STAR method. The best known interview technique, for the five (“do”) factors we’ve described, is called BLUF. “Bottom Line Up Front” is basically the staff-and-above-level special: it’s extraordinary at shielding your counterpart from unnecessary details; you tell them the most important thing first, don’t make them wait til the end to hear why they should be listening at the beginning! This is the opposite approach of STAR, which often buries the lede.
From its Wiki page, “BLUF aims to enable the receiver of a message to make faster decisions, especially for people who are busy, time-constrained, or overloaded with lots of information.” I don’t know if I’ve ever heard a better description of engineering interviewers. However, BLUF is only a helpful starting point, because technically, it’s a writing framework made by the military so when applied to tech interviews it doesn’t get us across the finish line. To get there, we’ve got to hack together a solution specific to this problem.
Engineer Interview Method
Apply these 3 interview tips to prepare for your next interview:
Step 1: Deconstruct your projects
Step 2: Use 1PBL to answer interview questions
Step 3: Break the rules
Deconstruct your projects
Remember, in tough interview rounds, follow-up questions are where the game is won or lost. So, if you jump straight into “writing answers to interview questions” you have skipped the prep for the notoriously more difficult follow-up questions. Instead, get all of the details out in the open by deconstructing your projects; this preps you for follow-ups and it warms you up for the initial answers to questions.
Decouple your past projects from belonging to a certain category (such as “this one is about hard tech challenges” and “that one is about interpersonal conflict”). Instead, map out what each one entailed with just the facts. The hard way to do this is to diagram all your relevant projects, name them, and write out details for each one. I have seen an L7 Amazon engineer who color-coded and mapped out all of the projects from his last 4 years of work; he said he couldn’t have gotten that L7 offer without that diagramming process.
The easy way to help you prepare for follow-up questions is to simply grill yourself. Ask yourself questions in the handful of categories they’re sure to ask. A solid list of questions can be found here (under “Self Reflection”). Whether with the easy or hard way, you now have a solid beginning repository of language for follow-up answers and answers. Time to tighten it up.
Use 1PBL to answer behavioral interview questions
We developed a new format for you to implement into your interviews and mock interviews. The “1PBL” method is a technique that’s BLUF-inspired, engineering-specific, and checks all 5 boxes we want in an alternative solution to using the STAR technique, which, again, are:
- The more conversational it feels, the better
- Less is more
- Shield your interviewer from unnecessary details
- Fit the model to the engineering interview
- Break the rules
Definition of 1PBL:
The name ain’t sexy, but passing interview rounds sure is. The 1PBL method can be used to answer behavioral interview questions more optimally, especially in senior-and-above interview rounds. This method will help send more signal to your interviewer, giving you a better chance to pass your interviews and get you closer to locking in your next job.
Why this method helps you pass interviews
Give the “Bottom Line Up Front” response by summing up the project and result in 1 line (including a metric/impact). This demonstrates to your interviewer: why they should listen, and your ability to shield them from unnecessary details which is a communication skill that above-senior engineers are expected to have. If you’re unsure of how to find metrics/impact check out this post.
“Problems”, “solutions”, “challenges”, and “lessons learned” are pre-oriented into the engineering brain: speak a language you already know and more importantly, that you know that the interviewer already knows and is partial to.
When digging into “solutions”, talk about tradeoffs to flex your decision-making muscles. The more senior you are, the more this focus on tradeoffs is expected. Here are some ways you can dig in:
- How that solution was picked
- Why you picked that solution
- The drawbacks of that solution
- Other approaches you considered and their tradeoffs
- If it was hard to get buy-in, how you got it
When you talk about a past project, we know that Apple engineering managers want to hear about the greatest challenge you faced at your previous job. Ostensibly, other decision makers at bigtime high-tech companies want to hear that, too. Ideally, pick a challenge you didn’t plan for because that’s where interesting stuff (learning under pressure) happens. Describe these high ROI details to score points.
Lessons provide an opportunity for humility and ending on a more measured tone. It’s not realistic to end on a sensationalist note, which can sound a bit like: “And then we achieved World Peace!!!1” Instead, the idea is: “I tackled this one thing, but if I was going to do it again tomorrow, I’d do X to tackle more things (or to tackle that one thing more effectively).” Do it right to look positively obsessive about self-improvement.
Little things
Eighty percent of your answer is about what you did, that’s called “individual contribution.” Do not miss that. It’s one of the most common reasons for rejection in a behavioral round. That leaves 20% for “everything else”: what the team did, and other helpful context.
Metrics/impact can be used in other parts of your answer, too. Not just the one liner. Another of the most common complaints from engineering interviewers is not hearing enough metrics/impact in candidates’ answers. This is one of the rare interview tactics that can’t be overdone, the more examples of your impact the better your chances.
In terms of duration, this isn’t a hard and fast rule, but I recommend (at least as a starting point) limiting yourself to 3-4 lines per section. (For example, “Problem + Solution” is a section.) That way you can measure the effectiveness of a lean answer before adding any complexity.
Example answer using 1PBL
1 liner:
“I found a bug in the AWS architecture which saved 300k in annual customer support costs.”
Problem (+ solution):
“The problem we were trying to solve was discovering how hackers were getting into our infrastructure. It had been investigated by many teams before us, and they couldn’t figure it out.
The solution was implementing 1 new technique to catch the hackers every few days, which was, in a way, up to 30x more effective than those teams before us (they implemented 1 technique every 3-6 months). Eventually we figured out they were getting in through a backdoor of our cloud infrastructure.”
Biggest challenge:
“The trickiest part was how fast the hackers changed directions. They are constantly switching up tactics to not get caught, and that’s why other teams never found them. I eventually came around to the cloud, as to how they were getting in, so I read a bunch of AWS white papers and implemented a way to trace and identify them which was technically challenging because how our infrastructure is set up.”
Lesson:
“If I was going to do it over again, I would’ve sought more connection opportunities. The end result–me and one data scientist finding the bug and saving the company a bunch of money– ended up on the VPs desk, and we got some attention but, career wise and social capital wise, I wish I would’ve used that moment to meet more senior folks in other orgs.”
Break the rules
As much as 1PBL may help, never over-and-obviously rely on any framework. Not because your interviewer might notice, but because it blocks your mind from possibilities. Getting things done and effectively breaking the rules is basically a job description for engineers above the senior level. Ambiguity, and the ability to thrive in it, is what interviewers and employers are looking for. You can start practicing now, by not getting too attached to any playbook. Even this one.
So… try the framework. Change it. Make your own. Throw all of it away and just talk to your interviewer. Up until a certain point, you need structure to stand. And after that point, that same structure will stagger you. It’s like a crutch, or any other tool: helpful, until it’s not needed to succeed.
Key Takeaways
The time to use the STAR method is behind us. Do not lose your interviewer’s attention. Give the most important piece of information first. Structure your answers with the language you already know: problems, solutions, tradeoffs, biggest challenges, and lessons learned. Use the structure when it suits you, and break away when it doesn’t.
If you want to check out more content like this, stop by hey.applypass.com.
Or if you’re a senior (or above) engineer, we want to come up with more ways to make your interviewing processes more useful and enjoyable.\
