The five behavioral questions we see most in software engineer loops: your greatest weakness, adapting to a major change, giving hard feedback, deciding without full information, and juggling competing priorities. Answer each with a real, specific STAR story that shows judgment, not just competence.
Everyone preps for the coding round and forgets that the behavioral round is where a lot of software engineer loops are actually won or lost. These are the five behavioral questions we see come up again and again for engineers: your greatest weakness, a time you adapted to a major change, a time you gave difficult feedback, a decision you made without full information, and how you balance competing priorities. The first two show up in almost every interview for any role, engineering included; the last three are the ones that dig specifically at how you operate on a team of engineers. The move for all five is the same: one real, specific story that shows judgment, told tightly with STAR, not a list of things you are generally good at.
This is the classic that trips up strong engineers because the instinct is to dodge it. The interviewer is not fishing for a reason to reject you. They are checking whether you can look at your own work honestly and do something about what you find, which is exactly the muscle that separates a senior engineer from a fast junior one.
Structure it in three beats. Name one real weakness that is not a core requirement of the job. Acknowledge, in a single line, the actual cost it has had. Then spend most of your answer on the specific steps you are taking and the evidence they are working. “I used to over-polish code before opening a PR, which slowed my team’s feedback loop, so I now push a draft PR early and let review catch the rest” is honest, specific, and shows a fix in motion. Skip “I’m a perfectionist” and any weakness that is secretly a brag; interviewers hear those as ducking the question.
Expect the follow-up “can you share an example of progress you’ve made in this area?” Have a concrete before-and-after ready so the improvement is not just a claim.
For the full breakdown, see our guide on how to answer “what is your greatest weakness”.
Software moves fast, and this question checks whether you are an asset or a drag when it does. A framework gets deprecated, a re-org scrambles your team, the roadmap flips mid-sprint. They want to know if you stay productive when the ground shifts and whether you help the people around you adjust too.
Use STAR around a change you did not choose. Set up the disruption, state what you still had to deliver, then put the weight on your actions: the concrete steps you took to get ahead of the change instead of mourning the old way. A single honest clause of initial resistance makes the story believable, but do not camp there. “At first I was sure the migration would torch our velocity, so I spent a day actually learning the new tool and found its tracing was better than what we had” is the shape you want. Land on a result that shows you came through effective, not merely unbroken.
A common follow-up is “how did you ensure your team was also adapting effectively?” If you helped others climb the same curve, that is a strong signal - do not skip it if it is true.
Our full walkthrough lives in how to answer “tell me about a time you had to adapt to a major change”.
This one goes straight at your interpersonal judgment, and it comes up more the more senior the role. Engineers work in tight loops of code review, design debate, and on-call handoff, so the ability to say a hard thing without blowing up the relationship is load-bearing. They are watching how you balance honesty with empathy, and whether you can influence a peer you have no authority over.
Frame it with STAR around a real moment where staying quiet would have cost the work or the person. Show that you were specific rather than vague, private rather than public, and focused on the behavior and its impact rather than the person’s character. “Your PRs keep landing without tests, and it is creating rework downstream” beats “you need to be more careful.” Walk through how you opened the conversation, what concrete change you asked for, and how you followed up to see if it stuck. The best answers end with both the problem improved and the relationship intact.
Be ready for “how did the team member react to your feedback?” Do not pretend it went perfectly; a little friction that you then worked through is more credible than a tidy fairy tale.
This is most of engineering, so interviewers lean on it hard. The spec is ambiguous, the metrics are noisy, the deadline is real, and you still have to pick a direction. They want to see structured reasoning under uncertainty, not a lucky guess dressed up after the fact.
Structure your answer around the reasoning, not just the outcome. State what you actually knew, what you had to assume, and how you bounded the downside. The strongest move is to separate reversible from irreversible: a decision you can undo cheaply deserves a fast call and a fast learning loop, while a one-way door earns more caution. Describe the smallest safe step you took to buy information - a feature flag, a canary, a spike, a quick prototype - and the signal you watched to know whether to press on or roll back. “I shipped it behind a flag to five percent, set an alert on error rate, and had a rollback ready” shows exactly the judgment they are scoring. Close with the result and one honest line on what you would keep or change.
Expect “how did you mitigate potential risks associated with your decision?” Your answer to that is really the whole point of the question, so make the risk-bounding explicit rather than implied.
You can go deeper with how to answer “describe a challenging situation and how you handled it”.
Every working engineer is over-subscribed, so this question checks whether you can carry real load without dropping the thing that mattered or quietly burning out. Feature work, a production incident, a stack of reviews, and creeping tech debt all want the same hours. They are looking for a visible decision process, not “I just worked harder.”
Use STAR around a stretch where the demands genuinely collided. The core of a strong answer is the criteria you used to rank them: impact, blast radius, who is blocked on you, what is truly time-sensitive versus merely loud. Make the trade-off explicit and name what you consciously chose not to do, because owning the cut is what shows real prioritization. “I paused the refactor, shipped the fix that unblocked three teammates, and flagged the deferred work to my lead with a date” reads as judgment; “I did everything” reads as someone who has not had to choose yet. Mention how you communicated the trade-offs, since silent re-prioritizing is how deadlines get missed.
A likely follow-up is “how did you decide which priority was the most important?” Have the ranking rule ready, not a vibe - that single sentence is what they are actually after.
A real engineering loop is more than these five questions. It usually runs a Coding round, a System Design round, a Behavioral & Leadership round, and a Domain Deep-Dive, and each one rewards saying the answer out loud, cleanly, under a little pressure. Reading these structures is the easy part; the hard part is delivering a tight STAR story when a stranger is watching and the clock is running. That is the gap Koaches is built to close: practice these questions live with an AI coach that asks the real follow-ups, scores your structure and substance, and shows you exactly where a story wandered - so by interview day the pivot from “I know the framework” to “I just nailed that answer” is muscle memory.
The Koaches team builds Koaches, an AI interview-prep coach. We have reviewed thousands of practice answers and resume bullets, and we write about the small structural fixes that turn a decent answer into an offer.
The Koaches Team•7 min readThe Koaches Team•6 min readThe Koaches Team•7 min readRun a free mock interview with an AI coach that asks follow-ups, scores your answers, and shows you exactly what to fix.
Start practicing →