You know, it would be a real shame if you were to get a rejection from that dream company of yours for not passing the behavioral component.

Imagine that you are prepping for an interview with Google, Amazon, Facebook, and Microsoft. You are grinding hours on Leetcode, mocking people on Pramp, and shaving through extra coding algorithm and systems design questions. It’s a LOT of work.

Now imagine if all that work goes to waste because you didn’t prepare a good enough answer to “so tell me about this project” or “what was your bigget technical challenge?”

You see, times are changing. Google and Amazon have both confirmed to have a dedicated interview slot entirely for behavior components.

Many others are starting to care a lot more about a person’s personality and character as well.

Why? Well, we are all human. We aren’t robots. Those companies out there are run by humans, who are trying to work with other humans and do human stuff.

Technical skills are great, but they can be taught. A person’s personality and character is, however, very hard to change.

If companies wanted to find candidates that can spit out Leetcode medium solutions in 15 minutes, they would be hiring armies of coders from China and India. The thing is, technical skills are just one piece of the puzzle. Being great a technical questions doesn’t make you a great employee. The correlation of technical interview performance and being a good employee is only 26 percent.

Ever hear about that Google interviewer who says he gives a “Strong hire” to people who fail to get the correct solution? Ever hear about my Google on-site interview, where I thought I completely bombed the first interview but the interviewer actually gave me a “Hire” recommendation? Either my behavioral component carried me through, or that interviewer was trolling Google.

It’s just natural selection. The environment changes, and we adapt.

That said, I want to talk about the popular STAR method that is officially recommended at Amazon as a way of answering behavioral questions.

STAR

STAR stands for

• Situation
• Task
• Action
• Result

How to use STAR

You basically use each abbreviation to formulate the answers.

Let me give some examples.

I will show you how I answered questions without using STAR vs using STAR.

Here’s a snippet of my projects from an old resume of mine.

Question: Tell me about Green Detect

Rough answer

Me and 3 other programmers were participating in the Implement AI hackathon. We made an app that could detect the type of plant disease through a single picture of the leaf. I was working on the Android app development side of things. I wrote the app pretty well, and in under 8 hours too. We ended up winning 2nd place.

It’s not that bad, is it?

• Situation - hackathon.
• Task - an app.
• Action - worked on Android app.
• Result - winning 2nd place.

Okay but hold on a second.

I don’t think the point of STAR is to have you literally spit out the answer to each of `the S.T.A.R. topics.

It’s more of a guideline on how you should be approaching these questions.

Here’s an approach - how would you get the other person to feel the way you feel about a project?

Better answer

Me and 3 other programmers were participating in a hackathon. We wanted to tackle the problem of diagnosing plant diseases. Our idea was to deliver an app that could diagnose the disease of a plant with just a single picture of a leaf.

The thing is, nobody in our team had much knowledge in mobile app design and development. I took the ownernship of this and led the process.

I designed the app with a huge focus on the user, which I could tell you more about if you are interested. (I designed everything on Figma. I made it super simple to use by removing all and keeping only the necessary UI. I made it satisfying to use by giving it a great look and adding cute little Lottie animations. The judges loved it).

One of my peers also wanted to learn some Android development. I ended up teaching him through peer programming and we had a lot of fun. I could elaborate if you are interested. (I selected certain modules that were perfect for a beginner to code out, and gave the responsibility of those modules to my peer. When I was the one coding, I would still explain the code that I was writing as well as my thought process. We had a really great time peer-programming the entire app.)

I made sure to have a rough outline from start to finish before writing too much code. This allowed us to avoid rewriting our code in the middle of the hackathon, which happens quite frequently. I was able to push out a clean working app within 8 hours, which is a nice accomplishment for a hackathon.

The judges loved the simplicity, responsiveness, and friendly user interface of the application. At the end, we won 2nd place.

See what happened?

Is it about writing a longer answer? In this example, yes, but no that’s not the point.

And it’s not about answering each topic (Situation, Task, Action, Result) either.

It’s about the story you have prepared to give to the interviewer. The impression you want to have on their minds. STAR is just a guideline to make sure you don’t digress in your story.

Without thinking of STAR, I could either keep my answer short and fail to deliver the impact of the story:

At this hackathon, I made an Android app for this idea we had, which was a about detecting plant diseases. And I made the app super fast in under 8 hours. And we got 2nd place!

Or I could ramble on too long and digress, which will take my point away:

I was at this machine learning related hackathon held in Montreal. Me and 3 others were discussing an idea to tackle challenges for plant-growers. We wanted to create an app that could easily diagnose plant diseases. We found a good dataset on Kaggle, but didn’t know the best medium to interact with our users. I was the only one with app development experience. So I proposed to develop an Android app…

---

In brief, here’s what you can do:

1. Consider the listener’s persective - how technical should you be, how interested are they in this topic
2. Consider the impression you want to have on the listener - What do you want them to be impressed with? Your efforts? Your decision making skills? Your technical abilities?
3. Tell them just enough of the background information so that they can understand the problem (hackathon)
4. Formulate your problem statement (we needed an app, which no one knew much about)
5. Talk about how you tackled the problem and resolved it (develop the app lol)

---

Well, I hope that helps.

What do you think? Is there a better way to approach behavioral questions? I'm all ears, so let me know.

Until next time, happy interviewing :)