What behavioural questions are
Behavioural questions ask you to describe something you actually did. They often start with phrases such as “Tell me about a time when…” or “Describe a situation where…”. Interviewers use them because past behaviour is often a more concrete guide to how you work than a statement about what you would do.
Typical topics for technical roles include working through a disagreement, handling a mistake, meeting a tight deadline, learning something new quickly, dealing with unclear requirements, helping a teammate, and explaining a technical idea to a non-specialist. They are separate from questions that test technical knowledge or problem-solving in real time, which belong to technical interviews. Many interviews include both kinds.
No preparation guarantees an outcome, and interviewers differ in what they value. The goal here is simply to be able to describe your real experience clearly and calmly.
Collect your material first
Before thinking about structure, build a list of experiences. Go back through your recent projects, jobs, coursework, volunteering and personal work. For each, jot down:
- What was the project or problem?
- What was your role?
- What was difficult?
- What did you do, and why?
- What happened?
- What would you do differently?
Aim for six to eight experiences with some variety, since you will not know the exact questions in advance. Include some that did not go perfectly. A story in which you made a mistake, noticed it and corrected it can show maturity if you tell it plainly.
Reading through your own portfolio and technical resume is a good way to jog memory, and it helps keep your stories consistent with what you have already told the employer.
A simple structure: STAR
A widely used format is STAR:
- Situation. The context in a sentence or two.
- Task. What you were responsible for or needed to achieve.
- Action. What you did, step by step. This is the main part.
- Result. What happened, and what you learned.
Some people add a final “Reflection” step. The format is a scaffold, not a script. Its value is that it keeps you from either rambling about context or jumping straight to the ending.
An illustration
Question: “Tell me about a time you found a problem late in a project.”
- Situation: “During final testing of a student project, a sensor board produced unstable readings.”
- Task: “I was responsible for the data acquisition side and needed to find the cause before the demonstration the following week.”
- Action: “I first checked the code for errors, then the wiring. I compared readings with the battery connected and with a bench supply, and the noise disappeared with the bench supply. I proposed adding a filter capacitor and separating the supply routing, tested it, and wrote down the change.”
- Result: “The readings became stable enough for the demonstration. I learned to test power quality earlier, and I added that to our checklist.”
This example is invented for illustration. Your own answers should describe your own experience, with details you can discuss if asked follow-up questions.
Make the action specific
Most weak answers fail at the action step. Common problems:
- Saying “we” throughout. Teamwork matters, but the interviewer wants to understand your contribution. Say “we decided” for team decisions and “I” for what you did.
- Describing what you would do in general instead of what you did.
- Skipping the reasoning. Why that approach? What alternatives did you consider?
- Vague verbs. “I handled the issue” says little; “I reproduced the fault, isolated it to the power supply and tested two fixes” says a lot.
Include numbers only if you know them to be accurate. It is better to say “it reduced the manual steps considerably” than to invent a percentage you cannot defend.
Honesty matters
Do not invent or exaggerate experiences. Interviewers often ask follow-up questions, and an embellished story tends to fall apart under them. Beyond that, it is simply the wrong thing to do. If you lack a direct example, it is fine to say so and give the closest real one, or to describe how you would approach the situation, labelled as such. If a story involves confidential work, describe it in general terms and leave out what you may not share.
Be careful about blaming others. Describing a disagreement with a colleague is fine, but your tone should show respect for them. Interviewers often listen for how you talk about people who are not in the room.
Common themes and what they probe
| Theme | What an interviewer may be listening for |
|---|---|
| Conflict or disagreement | Whether you listen, stay respectful and seek a workable outcome |
| A mistake or failure | Ownership, learning and what changed afterwards |
| Pressure or deadlines | Prioritisation and communication, linked to time management |
| Unclear requirements | How you ask questions and check assumptions |
| Teaching or helping others | Patience and clarity |
| Safety or ethics concerns | Willingness to raise problems, which connects to engineering ethics |
| Learning something new | Your approach to self-directed study |
Interviewers are not always looking for one fixed answer, and their criteria vary by company and role.
Practising
- Write short notes, not full scripts. Memorised speeches sound stiff. Keep a few bullet points per story.
- Say your answers aloud. Speaking differs from thinking. Time yourself; two minutes is often a reasonable length, though it depends on the interviewer.
- Practise with another person, ideally someone who will ask follow-up questions. A mentor or colleague is a good choice, and the soft skills involved improve with repetition.
- Prepare to adapt. One story can answer several questions with a different emphasis. Listen to the actual question and pick the story that fits best.
- Prepare questions for the interviewer. Asking about how the team works, how newcomers are supported and what a good first few months look like helps you decide if the job suits you.
During the interview
It is fine to pause for a few seconds before answering. If you do not understand a question, ask for clarification. If you start down the wrong path, say so and restart. Keep answers focused, then stop; interviewers will ask for more if they want it. After finishing, a short sentence on what you learned often rounds the story off well.
Interviews can be stressful and results depend on many factors outside your control, including the other candidates and the employer’s needs. Treat each one as practice and, where possible, ask afterwards what you could improve.