# Behavioural interviews for engineers: build stories that survive follow-up questions Prepare truthful stories about a decision you made, your specific contribution and what happened next. Explain constraints and trade-offs, distinguish team results from your own work and acknowledge what you would change. Coursework and small projects can supply useful examples. ## The goal is to make your judgment understandable A behavioural question asks the interviewer to understand how you acted when the answer was not simply “write the correct code.” You may be discussing a disagreement, an unclear requirement, a mistake or a trade-off under time pressure. A useful answer gives the listener enough evidence to follow your reasoning and distinguish your contribution from the team’s. Amazon’s SDE II guidance explicitly recommends recalling specific experiences and structuring answers with STAR. It asks about the what, how and why of decisions. That is one employer’s guidance; other employers may organize their interviews differently. Check the company’s own preparation material and ask your recruiter which kinds of examples are useful. The method below is an editorial practice framework. It is designed to make truthful experience easier to explain, not to manufacture a personality or a perfect answer. A modest example with clear ownership can support a better conversation than an impressive-sounding story that falls apart under questions. Sources: [Amazon: SDE II interview preparation](https://amazon.jobs/content/en/how-we-hire/sde-ii-interview-prep) ## Build a small bank of distinct situations List situations before writing answers. Look for a disagreement, an ambiguous task, a failure, a difficult deadline, useful feedback and a time you helped someone else. One experience may support several questions, but using the same project for every answer can hide the range of your work. For each situation, record the setting, the people involved, your actual responsibility and what changed. Mark which details you can support with memory or non-confidential evidence. If you only know that a release was accepted, do not turn it into a revenue increase. If a teammate made the key decision, describe how you contributed rather than taking ownership of it. Leave some entries unused. A story bank is a set of options, not a script you must deliver in full. Choose the example that answers the question asked, even if it is less dramatic than your favourite project. ## Use STAR as a route through the story Situation establishes the context and constraint. Task identifies what you were responsible for. Action explains your choices, including an alternative you considered. Result tells the listener what happened and what you learned. Most of the substance should be in the action: what did you notice, decide, communicate or change? You can prepare a short opening version, then let the interviewer ask for depth. Do not recite the labels out loud or force every answer into an identical length. A technical interviewer may want the implementation; another may probe how you handled disagreement. Keep the underlying facts consistent while adjusting the level of detail. Include the limit of your knowledge. “We did not measure the longer-term effect” can be a stronger answer than a fabricated percentage. Explain what you would measure now. Honest uncertainty gives the interviewer a way to assess your judgment. Sources: [Amazon: SDE II interview preparation](https://amazon.jobs/content/en/how-we-hire/sde-ii-interview-prep) ## A worked answer: disagreement about release scope Consider a practice scenario, not a claim about a real Opened employee: a team is preparing a release and disagrees about whether to include a new export feature. The engineer owns the export implementation, while a teammate worries about the deadline. A weak answer says, “I convinced everyone, worked hard and shipped successfully.” It contains a result but almost no decision evidence. A more useful version is: “The release included an export endpoint, but permission checks for one document type were not finished. I owned the endpoint and initially wanted to keep the feature in scope. I wrote down the unfinished cases and asked a teammate to review the failure paths. We agreed to ship the completed changes with export disabled, then enable it after permission tests passed. I implemented the flag and documented the remaining checks. The release went ahead without exposing the unfinished endpoint.” The answer is stronger because it shows a change of mind, a concrete risk and a bounded action. It does not claim an invented business impact. The next question could be about who made the release decision, how the flag was tested or why the team had not identified the issue earlier. Prepare those details only from the experience you actually had. ### Diagram: A release-scope decision fork: disable unfinished export until permission tests pass. 1. **Constraint** — An export feature has unfinished permission checks near a release deadline. 2. **Decision** — Review the failure paths and ship completed changes with export disabled. 3. **Ownership** — Explain the flag you implemented and checks you documented; do not invent impact metrics. ## Answer the follow-ups that reveal ownership Practise with someone who will interrupt. Ask them to choose questions such as: What did you personally do? Which alternative did you reject? Who disagreed, and what was reasonable about their position? How did you know the change helped? What would you do differently with the same information today? If your first response to a follow-up is another slogan, return to the event. Replace “I communicated proactively” with what you communicated, to whom and when. Replace “I showed ownership” with the decision or repair you took responsibility for. The language becomes simpler as the evidence becomes more specific. Acknowledge the team without disappearing into “we.” You can say, “We agreed on the rollout; I wrote the migration and my teammate added the dashboard.” That distinguishes collaboration from an inflated claim of individual impact. ## Failure stories need repair and changed behavior Choose a real mistake with enough distance to discuss it thoughtfully. Explain what you believed at the time, what evidence showed that belief was wrong and how you responded. Avoid turning every failure into a disguised success or placing all responsibility on someone else. The repair matters, but so does prevention. If you missed a dependency, describe the check you added to planning. If you shipped a bug, explain how it was diagnosed and what test or release safeguard changed. Do not claim a process prevents all future mistakes; describe the specific failure it now catches. Protect confidential information. Replace customer names and internal identifiers with generic descriptions, and omit proprietary details that are not necessary to explain the decision. If you cannot discuss a situation safely, choose another one rather than hoping the interview setting makes disclosure acceptable. ## Freshers can use project evidence without apologizing A college project, internship, open-source contribution or student responsibility can provide a useful example. Scope it honestly: how many people were involved, what you owned and what constraint made the work difficult. The point is not to make the project sound like a large production service. For example, a group project with incompatible API assumptions can support a story about ambiguity. Explain how you found the mismatch, agreed on a request-and-response contract, tested the integration and coordinated the changes. A demonstration working on time is a valid outcome if that is what you observed. Do not invent user counts or uptime statistics. If you cannot find a situation for a particular question, say so briefly and offer the closest relevant experience. You can also explain how you would approach the situation, clearly separating that hypothetical answer from something you have done. ## Rehearse for clarity, then stop polishing Write each story as a few prompts rather than a paragraph to memorize. Record a practice answer, listen once, and remove context that does not help explain the decision. Then ask a peer to summarize what you owned. If they cannot tell, revise the action section before working on delivery style. Use the final rehearsal to check accuracy. Are the dates consistent with your resume? Can you support the claimed result? Have you represented the other person fairly? Does the ending explain a lesson rather than attach a generic moral? These checks make the answer credible without turning it into a performance. Before the interview, review the employer’s guidance and prepare questions of your own about expectations, feedback and how the team makes decisions. The conversation also helps you decide whether the environment suits the work you want to do. ## References - [Amazon: SDE II interview preparation](https://amazon.jobs/content/en/how-we-hire/sde-ii-interview-prep) - [Tech Interview Handbook: interview formats](https://www.techinterviewhandbook.org/software-engineering-interview-guide/) Updated 2026-11-02 by Opened editorial.