SuccessfulRounds

Spend ten minutes in any forum where engineers talk about interviews and the same worry surfaces, almost word for word:

“I’ve never interviewed anywhere like this before. I just want to feel confident walking in.”

People will happily pay a fee for a single mock interview just to take the edge off. And when they go looking for help, plenty of them hit the same wall:

“Every prep tool I find caters only for tech.”

But the most expensive line in the whole conversation comes from someone who’d clearly sat on the assessor’s side of the table:

“Most people try to shine and take credit and show technical excellence in the behavioural round. Those are the wrong answers. Many don’t even realise it’s a behavioural question.”

Read that last sentence twice: it’s the whole problem in miniature.

You know your work. You can walk anyone through your projects, defend your design decisions, and answer the technical questions cold. So you prepare the way you always have: fundamentals, projects, standing behind the numbers. Then the interview turns, and someone asks:

“Tell me about a time you had to convince a colleague to change their approach.”

And you give a perfectly good engineering answer, the problem you spotted, the calculation you redid, the fix you implemented, and walk out thinking it went fine. Weeks later, the rejection lands, for a role you were clearly qualified for, and no one tells you why.

Here’s why: you were answering the wrong round.

The competency interview is a different game with different rules

Most engineering selection processes have two distinct parts, and they test completely different things.

The technical round (and your CV, and your degree) already established that you can do the engineering. That box is ticked. The competency-based interview, you might see it called the behavioural interview, the values-based interview, or competency questions, is not asking “is this person a good engineer?” It’s asking “can this person evidence specific behaviours we need, like influencing others, managing risk, communicating with non-technical stakeholders, or owning a problem under pressure?”

The assessors usually have a scoring sheet. Each question maps to a named competency, and they are listening for evidence they can tick against it. If you’ve ever sat a chartership professional review, this is the same machinery your answers are scored against a competence framework, not against how clever the engineering was.

And here’s the part almost nobody tells you: a lot of strong engineers don’t even realise this is a separate round with separate rules. They treat every question as another chance to demonstrate technical excellence. So when they’re asked a behavioural question, they answer a technical one, and hand the assessor nothing to score.

Why “showing your technical excellence” actively costs you marks

Take that question again: “Tell me about a time you had to convince a colleague to change their approach.”

The answer that feels right to an engineer:

“On a heat transfer system we had, the exchanger was undersized for the duty. I reran the calculations, found the original sizing was wrong, specified a larger unit, and the system performed within spec after that.”

That’s a fine piece of engineering. But read it as the assessor: where’s the convincing? Who was the colleague? What did you specifically do to change their mind? It evidences your technical skill, which they weren’t asking about, and almost nothing about the competency they’re actually scoring. It’s a near-zero answer to the question that was asked.

The same story, restructured to evidence the competency:

“(Situation) On a process upgrade, I believed a heat exchanger had been undersized, but the lead engineer who’d signed off the original design disagreed and we were close to ordering. (Task) I needed to make the case for re-checking it without undermining a senior colleague or stalling the project. (Action) I reran the duty calculation, laid the two sets of assumptions side by side so the difference was obvious rather than personal, and walked him through it privately first before raising it with the team. I framed it as de-risking the order, not as catching an error. (Result) He agreed to revise the spec, we ordered the correct unit, and avoided a costly retrofit. I learned that with a senior colleague, how you stage the conversation matters as much as the evidence.”*

Same project. Same engineering. But now it’s scored against influencing, judgement, and communication.

How to actually prepare for it

1. Find out what’s being scored. Look up the competencies for the role or scheme. If it’s a chartership review, that’s your institution’s competence framework (UK-SPEC). If it’s a graduate or experienced-hire interview, the job ad and company values are your clues. You’re reverse-engineering the scoring sheet.
2. Build a story bank. For each competency, find one real example from your work, ideally one that does double duty across two or three. Six to eight solid stories usually cover a whole interview.
3. Structure every story the same way. Situation, Task, Action, Result, and weight it heavily toward Action and Result. Assessors are scoring what you did, so police your language: every time you catch yourself saying “we,” ask whether you can honestly say “I.”
4. Say them out loud. The most common failure isn’t not having the material — it’s being able to write it but not deliver it under pressure. Rehearse each story aloud until it’s a story, not a recital. This is the single highest-return thing you can do, and it’s the step everyone skips.

One last thing

If you’ve gone looking for help with this and found that every interview-prep tool, course, and mock service seems built for software engineers, you’re not imagining it, most of it is. The behavioural frameworks are real and they transfer, but the examples, the language, and the assessors in your world are different. You deserve prep that’s built around how chemical, civil, mechanical, and safety engineers, etc., are actually assessed.

That’s what I write about here.