I love the answers that have been voted up so far, but felt like they didn't really cover the boxes the interviewer may be trying to tick off with these questions.
CAVEAT - different companies do use the same question differently. So there's not a universal right candidate or right answer or even a right answer format.
So - #1 rule would be - know the company and assist yourself by trying to get information on what this company holds as important about it's own culture. This is helpful, also, since if they are particularly misaligned with what you think is important - it's probably not a great fit.
But, having asked these types of questions across multiple companies, here's some of the things I want to learn from questions like these:
What's the degree of complexity/difficulty of the types of problems you've had to solve? And what level of experience/skill did you use in solving them? It tells me both what the company trusted you with, and also what you consider hard/interesting - factors into what level of seniority I might recommend and/or if you have tackled anything similar to the types of problems this team has.
How does this person interact with others? Does it line up with what this company is going to expect? Does this person have enough social awareness to modify their behavior? Would they be happy doing so? This lines up with some of the cultural attributions like "Earns Trust" and "Dives Deep" - but how, say, AWS assesses this can be quite different from how a different company would assess the ability to meet the same pithy phrase.
One box I always look for on this - "is this person a jerk?" - if the reflection has a lot of "this was the other person's fault" in it, it will almost always throw red flags. Even if it was the other person's fault - most great candidates will have an idea for isolating or mitigating the problem that originated from someone else.
What happens when I ask for details? In most behavioral interviews, the interviewer is expected to dive in and ask for more. The idea here is partly that a candidate shouldn't have a memorized statement, they should be able to speak authentically about personal experience without a script. This is both a way to check off boxes the candidate may not have covered, and a way to check for authenticity. A person feeding me a story that isn't actually their own will usually lack the ability to make up credible details that hang together in a sensible way.
Can this person summarize but hit key points of the story in a way that a person who shares the skill set but not the context can understand - which is a pretty common skill to need in every team I've managed - engineers will always have more context on the thing they spent days working on that I (the manager) will. To be able to help and support them, I need them to sum stuff up, hitting the core of the problem and eliminating irrelevant details. If I can't understand the problem quickly in the interview phase, I don't feel confident that it will go better when the candidate is on the team.
STAR is a pretty good way to frame this stuff (situation, task, action, result) - since it helps focus on the candidate's work, and to keep the details as limited as possible to those 4 things.
It's worth noting that there's a LOT of variation here. Some companies have very formal methods for these types of interviews, and the interviewer (and even the recruiter prepping the candidate) may be VERY explicit about what aspects they are trying to assess. When I worked for (and interviewed with) AWS, for example, the interviewer was advised to say what AWS core competency they were interviewing for with a given question.
In other companies, a manager may be completely on their own to figure out what behaviors they are looking to see demonstrated, as well as what types of interviews to conduct to figure that out. They may or may not even have training on how to do a behavioral interview. And they may just not think it's a useful tool.
