Behavioral interview questions, grouped by what they test

Most people prep behavioral rounds by collecting questions and writing an answer to each. Then the interviewer asks "Describe a decision you pushed back on" instead of "Tell me about a time you disagreed with your manager," and the prepared answer feels like it belongs to a different question. That mismatch is where blanking starts.

Prepare as if the interviewer is scoring a competency, not the question, because often they are. Amazon says so openly: it asks behavioral questions "to evaluate candidates against the Amazon Leadership Principles." Most companies don't publish a list. Learn the topics anyway, and any phrasing becomes a pointer to a story you already have.

The answer format is the familiar one: situation, task, action, result. If STAR still feels mechanical, the STAR interview answers guide walks through full answers line by line. This page is about choosing which stories to build in the first place.

Every topic below lists the phrasings you're likely to hear, what the interviewer is listening for, and the specific way answers on that topic tend to fall apart.

A prepared story gets you through the first two minutes. The interviewer then probes, and that's where rehearsed answers come apart. Expect at least one of these after every story:

• What was your part, specifically, versus the team's?
• What did the other person think was going on?
• How did you know it worked?
• What would you do differently now?
• What happened next, a few months later?

If you can't answer these for a story, you don't know it well enough yet. Write the follow-up answers down when you write the story. They are usually one sentence each, and having them ready is most of the difference between sounding rehearsed and sounding like you were there.

You don't need a story per question. You need enough stories that every topic has a strong one and most have a backup. Six to eight stories, each covering two topics, is usually enough.

1. List every project or situation from the last few years that had a real stake: something that could have gone wrong, or did.
2. For each, mark the two topics it answers best. A missed launch you recovered might be failure and pressure. A migration you pushed through might be influence and judgment.
3. Look for empty columns. If nothing covers conflict, go looking for one before you polish the others.
4. Write each story once in STAR, with the result as a number or a concrete change, and add one-line answers to the follow-ups above.
5. Say each story out loud with a timer. Aim for about two minutes. Writing it is not the same as being able to say it.

Before a specific interview, reread the job description and the company's published values, if it has any, and decide which two or three topics the role leans on hardest. Lead with those stories when you get a choice. For an Amazon loop, that means mapping stories to the Leadership Principles; Amazon's interview prep page asks candidates to "map them to specific Leadership Principles." The Amazon software engineer guide has the rest of that loop.

This page deliberately stops short of full answers, because a memorized answer is the thing that breaks when the wording changes. When you want to see a story built line by line, with what each sentence is doing, use the STAR answers guide.

Engineering manager loops add topics this page doesn't cover: managing an underperformer, hiring, team conflict you had to resolve rather than take part in. Those have their own failure modes, mainly telling a story where you're the individual contributor who happened to have reports. The engineering manager behavioral interview guide covers them.

Read the grid, not the scripts. You want the topics and the first line of each story fresh, so that when a question lands you can name the story to yourself in a second and start talking. If a question doesn't fit any topic you prepared, say so plainly and offer the closest story you have. "The closest thing I've done is" lands better than a story bent out of shape to fit.