Behavioural interview practice for engineers

A useful behavioural answer makes your contribution understandable. Choose a real situation, explain the decision you faced, describe what you personally did and give an outcome you can support. Situation, task, action and result can help organise an answer; they are a structure, not facts to fill with an invented story.

Start from an experience, not a polished script

Choose one project involving a disagreement, a mistake, uncertain requirements or a decision you reconsidered. Write short notes:

• What happened, and why did it matter?
• What were you responsible for, and what was outside your authority?
• Which options did you consider?
• What did you do, including how you worked with other people?
• What changed? What evidence do you have, and what remains unknown?
• What would you repeat or change next time?

Remove confidential names, customer information and internal details that are unnecessary to understand the example. If a number cannot be verified or shared, use an honest qualitative outcome.

A fictional example: changing a caching decision

Practice question: Tell me about a technical decision you changed your mind about.

The following scenario and answers are invented for teaching. They are not a customer testimonial, an actual MockReps result or an experience to present as your own.

The available facts: An engineer proposed caching an internal dashboard response because users reported slow loading. Their team could inspect request traces and test changes in staging. The traces instead showed repeated database queries. The engineer changed the proposal to batch those queries, worked with a teammate on correctness checks and compared equivalent staging requests. Staging requests became faster, but the team had not yet measured a production effect.

An unclear answer: “We had performance problems, so we optimised the dashboard. I was flexible and we made it much faster.”

The answer does not show the original decision, the evidence or the engineer's contribution. “Much faster” leaves the listener unable to judge what was measured.

A clearer answer using the same facts: “I initially proposed caching a slow internal dashboard response. Before implementing it, I inspected request traces and found repeated database queries. That changed my view: batching the queries addressed the observed cause without adding cache-invalidation work. I revised the proposal, worked with a teammate on correctness checks and compared equivalent requests in staging. Those requests were faster, but we had not yet measured a production improvement. I would keep the habit of testing the suspected cause before committing to a fix.”

The second answer supports the change of mind and distinguishes a staging observation from a production result. It does not add a percentage improvement, ownership of the whole project or an outcome that was never observed.

Practise the follow-up

Answer one of these without changing the original facts:

1. What evidence would have made caching the better choice?
2. How did you explain the revised proposal to someone who preferred the original approach?
3. What would you measure after release, and how would you check that correctness had not regressed?

If the scenario does not contain the answer, say what information you would need. For your own experience, return to your notes rather than generating a convincing missing detail.

A self-review checklist

Ask whether the listener can identify the decision, your responsibility, the evidence, your action and the outcome. Check that the answer addresses the question instead of forcing a favourite story into every conversation. Keep enough context to make the decision understandable, then spend most of the answer on what you did and learned.

A Story Bank can help you find relevant experiences. It should preserve the facts as you revise the wording. See MockReps Story Bank, how feedback works and the software-engineering practice plan. Free sample questions are available without signing in.