BEHAVIORAL INTERVIEWS
Behavioral interview questions
Behavioral interviews are not a memory test. They are a prediction: if you behaved this way before, how will you behave when the same pressure shows up here?
What behavioral interviews predict
A behavioral question asks for a past example because past behaviour is a better predictor than a hypothetical answer. The interviewer is listening for ownership, judgement, collaboration and self-awareness under realistic constraints. A polished hypothetical answer can sound impressive, but it does not tell them how you actually behaved when the deadline moved or the stakeholder disagreed.
STAR-L, with the emphasis on the action
| Part | What to include | Time |
|---|---|---|
| Situation | One sentence: the context and the stakes | 10% |
| Task | One sentence: what you were responsible for | 10% |
| Action | What you personally did, in sequence, including the decision and the alternative | 60% |
| Result | What changed, with a number or a concrete outcome | 15% |
| Learning | What you would repeat or change next time | 5% |
Most candidates invert this: they spend 70% on the situation and 10% on the action. The interviewer cannot evaluate you if they only hear the context. Start closer to the decision.
40 questions by competency
Ownership and delivery
- Tell me about a project you owned end to end.
- Tell me about a time you delivered under a deadline that moved.
- Describe a time you had to make a decision without all the information.
- Tell me about a time you inherited a mess.
- Give an example of a time you improved a process without being asked.
- Tell me about a time you had to say no to a stakeholder.
- Describe a time you took responsibility for a mistake.
- Tell me about a time you had to prioritise between two important requests.
Conflict and influence
- Tell me about a disagreement with a colleague and how you resolved it.
- Describe a time you had to influence someone without authority.
- Tell me about a time you disagreed with your manager.
- Give an example of a time you had to deliver bad news.
- Tell me about a time a stakeholder changed the requirements late.
- Describe a time you had to work with someone whose style clashed with yours.
- Tell me about a time you had to build consensus in a group.
- Describe a time you stood your ground on a decision.
Failure and learning
- Tell me about a time you failed.
- Tell me about a time you missed a deadline.
- Describe a time you received difficult feedback.
- Tell me about a time you had to change your approach after new evidence.
- Give an example of a risk you took that did not pay off.
- Tell me about a time you had to recover a project that was going off track.
- Describe a time you let someone down.
- Tell me about a time you had to learn something quickly.
Teamwork and leadership
- Tell me about a time you helped a teammate who was struggling.
- Describe a time you led a team through a difficult change.
- Tell me about a time you had to delegate something important.
- Give an example of a time you gave difficult feedback.
- Describe a time you resolved a conflict between two other people.
- Tell me about a time you had to motivate a team with limited resources.
- Describe a time you onboarded someone new.
- Tell me about a time you had to make a decision that was unpopular.
Customer, ethics and pressure
- Tell me about a time you had to handle an angry customer.
- Describe a time you had to choose between a customer and a policy.
- Tell me about a time you saw something that was not right at work.
- Give an example of a time you had to protect confidential information.
- Describe a time you worked under extreme pressure.
- Tell me about a time you made a mistake that affected a customer.
- Describe a time you had to escalate a problem.
- Tell me about a time you improved safety or quality.
Full example: conflict with a colleague
On a launch, the design lead and I disagreed about whether to ship a simplified onboarding flow or wait two weeks for the full version. The situation was that sales had promised the feature to three customers, and the full version had not passed accessibility review. My task was to make a recommendation without breaking the relationship. I asked the design lead to walk me through the accessibility gaps and the cost of the workaround, then proposed shipping the simple flow behind a flag for the three customers while the full version went through review. I wrote the trade-off in one page, asked the launch owner to decide, and told sales what would be available on day one. We shipped on time, the three customers were live, and the full version landed two weeks later without an accessibility exception. What I would do differently is surface the accessibility dependency earlier, before sales made the promise.
Full example: failure
I once shipped a reporting change that looked correct in testing but doubled a key metric for two days. The issue was a join I had added without checking the grain of the second table. I noticed because a stakeholder asked why the number had jumped, not because my tests caught it. I told the stakeholder immediately, reverted the change, rebuilt the query with a row-count check at each join, and added a test that compared the total before and after. The lesson was that I had tested the query’s syntax, not its assumptions. Since then I write down the grain and the expected row count before touching a join. It cost two days of a bad dashboard, and I would rather describe it than pretend it did not happen.
Full example: leadership without authority
A cross-team migration kept slipping because each team was waiting for the other to move first. I was not the project lead, but I owned one of the services. I mapped the dependencies in a one-page sequence, asked each team for the one date they could commit to, and found that two teams were blocked on the same schema decision. I set up a 30-minute decision meeting with the two tech leads, wrote down the decision and the owner, and sent a weekly one-paragraph update to the group. The migration moved from a vague “next quarter” to a dated sequence, and we completed it with one rollback instead of the three people expected. The part I learned was that leadership often looks like making the next decision obvious, not giving a speech.
The follow-up ladder
- “What did you personally do?” — separate your action from the team’s in one sentence, then go deeper.
- “Why did you choose that?” — name the alternative and the constraint.
- “What was the result?” — give a number or a concrete change, and explain how you know.
- “What would you do differently?” — pick a real decision, not a fake weakness.
- “What did you learn?” — one sentence, then stop. Do not turn it into a second story.
Build a story bank, not a script
Write six to eight stories that can cover multiple competencies: a delivery under pressure, a conflict, a failure, a leadership moment, a customer issue, a process improvement, a difficult stakeholder and a time you learned something quickly. For each, write the four lines from the top of this guide. Then map each story to three or four questions it could answer. In the interview, choose the story that fits the question, not the one you rehearsed most.
| Story | Competencies it can cover |
|---|---|
| A launch that nearly slipped | Delivery, prioritisation, stakeholder communication |
| A disagreement with a colleague | Conflict, influence, judgement |
| A mistake that reached a customer | Ownership, customer focus, learning |
| A cross-team dependency | Leadership without authority, collaboration |
| A process you improved | Initiative, analysis, impact |
| A time you had to say no | Prioritisation, boundaries, communication |
The mistakes that cost the answer
- Too much setup. The interviewer does not need the org chart; they need the decision.
- “We” for everything. If the interviewer cannot tell what you did, the story does not count.
- No result. A story that ends with “and then we moved on” is unfinished.
- A perfect story. A conflict where everyone agreed, or a failure that was actually a success, teaches the interviewer nothing.
- Reusing one story for every question. It sounds rehearsed and misses the competency being tested.
A 45-minute practice plan
- Write four stories using the STAR-L table. Keep each to six lines.
- Say one story out loud in 90 seconds and cut the setup.
- Ask a friend to interrupt with “what did you personally do?” and answer in two sentences.
- Map each story to three questions from the list above.
- Run a full mock interview and review which competency the follow-ups exposed as weakest.
These guides are written and maintained by MockInterview as original practice material. They are not leaked employer questions, and no employer has reviewed or endorsed them. Sample answers are illustrative; use your own examples and verify role requirements, licensing and local policy with the employer. Last updated 2026-11-03.