Behavioural questions for engineers
Behavioural rounds test how you work, not what you know. Choose examples from real projects and explain technical decisions so anyone on the panel can follow them.
Practise this questionWhat behavioural rounds look for
Alongside coding and system design, many engineering interviews include a behavioural round. Interviewers use it to understand how you make decisions, handle disagreement, respond to incidents and work with people outside engineering.
The panel may include a manager or someone non-technical. Your example should make sense to them while still giving an engineer enough detail to judge your reasoning.
Questions engineering panels ask
Tell me about a time you disagreed with a technical decision.
Explain both options fairly, how you made your case with evidence and what you did once a decision was made, including if it went against you.
Practise this questionDescribe a production incident you were involved in.
Cover how you found and limited the impact, how you kept people informed and what changed afterwards to stop it happening again.
Tell me about a project you are proud of.
Choose one where your contribution is clear. Explain the problem, the trade-offs you made and the result for users or the team.
Tell me about a time you had to learn a new technology quickly.
Describe how you learned, how you managed the risk of being new to it and what you delivered.
Describe a time you received difficult feedback on your code.
Show that you listened, separated the feedback from your ego and changed something specific.
Tell me about a time you worked with a non-technical stakeholder.
Explain how you translated technical constraints into terms they could use to make a decision.
Tell me about a time you failed.
A missed estimate, a bug you shipped or a design you had to replace can all work. Focus on what you changed in how you work.
Practise this questionExplain technical work clearly
- Lead with the impact: what users or the team experienced, before the implementation.
- Name technologies only when they matter to the decision. “We used a queue so checkout kept working when the email service failed” says more than a list of tools.
- Make your contribution clear. In a team, say “I designed the migration plan” rather than “we migrated”.
- Describe the trade-off. Engineering decisions usually give something up; saying what, and why it was acceptable, shows judgement.
A disagreement settled with data
Our team planned to split a large service into several smaller ones to speed up deployments. I disagreed, because most of our slow deploys came from a test suite that took forty minutes, not from the size of the service. I timed our last twenty deployments, shared the breakdown and proposed fixing the tests first, then revisiting the split. The lead wasn’t fully convinced, so we agreed to try my approach for six weeks against a clear measure. Deploy times came down enough that we postponed the split, and I learned that bringing data turned the disagreement into a discussion about evidence rather than opinion.
The speaker explains the technical point in plain language, shows how they made their case and agreed a fair test with the lead, and describes the result without overstating it.
Same question. Your story.Common questions
How technical should a behavioural answer be?
Technical enough that an engineer could judge your reasoning, plain enough that a non-engineer could follow the story. A short explanation of any specialist term usually achieves both.
Can I use personal or open-source projects?
Yes, particularly early in your career. Make sure the example shows the behaviour you were asked about, such as collaborating, handling feedback or making a trade-off.
Should I use STAR for engineering questions?
It works well. Keep the situation short and put most of the detail into your actions and decisions, including the trade-offs.
Practise for your role.
Add your CV and the job description to get five questions written for you, then answer them out loud.