Behavioral interview · Leadership, conflict and influence

Questions for senior and leadership roles (with or without direct reports). They’re not assessing what you know — they’re assessing how you behave when things get uncomfortable.

Important warning: in these questions the ❌ answer is almost never technically false. It’s humanly poor, which is why it slips out so easily. Read them carefully — you have probably said one of them.

Q1. How do you influence a decision when you have no authority?

What they assess: the core skill of any senior or staff role.

❌ What NOT to say

“I escalate to my manager so they impose the right decision.”

Why it’s wrong: escalating as a first resort burns relationships and marks you as someone who needs hierarchy to get things done. The manager rarely has the context you have, and an imposed decision gets executed grudgingly — the worst way to be right.

⚠️ Acceptable answer

“I prepare my arguments carefully and present them in the meeting, with data supporting my proposal, and try to convince the team.”

What it’s missing: everything that happens outside the meeting, which is where decisions actually get made.

✅ Ideal answer

“The meeting is where a decision is confirmed, not where it’s made, so I work beforehand. First I understand what each person is worried about, because disagreement is usually not about the solution but about which problem we’re solving: if two people prioritise different things, no amount of technical argument aligns them. I talk to each one separately and bring the proposal as a draft, asking them to break it; that does two things — it improves the proposal with their objections, and they arrive at the meeting feeling some ownership. Then I bring data and, where possible, a small experiment instead of an argument: two days of prototype persuade more than two weeks of debate. And I’m genuinely willing to change my mind, because if I never do, people stop listening. Escalation I keep for real risk, after trying in good faith — and when I escalate, I tell the person I disagree with first: escalating behind someone’s back is paid for over years.”

Why it works: pre-work, understanding others’ motivations, evidence over opinion, and an explicit ethical rule for escalation.

🔁 Likely follow-up: “What if the opposite gets decided anyway?” → “I back it properly, with my name on it. I record the risk that worries me and propose when we’d revisit, but I don’t execute half-heartedly so I can say ‘I warned you’.”

Q2. A colleague repeatedly delivers low-quality code. What do you do?

What they assess: how you give difficult feedback among peers.

❌ What NOT to say

“I raise it in code reviews; if it continues, I leave it on record in the comments so it’s documented.”

Why it’s wrong: turning code review into the channel for a behavioural problem is humiliating in public and ineffective: the person gets defensive and the whole team reads the conflict. And “leave it on record” is building a case file instead of solving anything.

⚠️ Acceptable answer

“I talk to them privately, give concrete feedback on what I’m seeing, and offer help or a pairing session.”

What it’s missing: understanding the cause before correcting, and what you do if nothing changes.

✅ Ideal answer

“Privately and early, not after three months of accumulated frustration. I start with concrete facts and no adjectives: ‘in these two changes we had to redo X and these bugs got through’ beats ‘your code is weak’. And I ask before concluding, because the causes are usually surprising: missing domain context, pressure to deliver, not knowing exactly what we expect, or a codebase that makes doing it well hard. Depending on the answer the fix changes: sometimes support, sometimes clarifying the standard, sometimes acknowledging we gave them work nobody equipped them for. We agree something concrete and observable and I follow up; and I reinforce what improves, not only what fails. If after a reasonable time there’s no change, I take it to their manager with facts, having told them first that I will. What I try hardest to avoid is the most common failure: saying nothing and complaining to others, which is what really destroys teams.”

Why it works: private, factual, cause-seeking, with follow-up and honest, pre-announced escalation.

🔁 Likely follow-up: “What if they’re more senior than you?” → “Same approach, but asking more and asserting less: ‘I wanted to understand the decision on X, because it was hard to maintain’. The asymmetry doesn’t change the substance, it changes the tone.”

Q3. You’re assigned a project you think is a bad idea. What do you do?

What they assess: whether you can disagree and commit, in that order.

❌ What NOT to say

“I do it because I’m told to, even though I know it won’t work. They’ll figure it out eventually.”

Why it’s wrong: that’s passivity with resentment. You withhold your judgment when it could still change something, then work expecting failure, which guarantees mediocre execution. In a senior role you’re paid precisely to say what you see.

⚠️ Acceptable answer

“I raise my concerns with arguments and, if the decision stands, I do it as well as I can.”

What it’s missing: how you raise concerns so they can be heard, and how you reduce risk while executing.

✅ Ideal answer

“I say what I think once, well and early: my concrete concern, what evidence I have, and what alternative I propose — because criticising without an alternative is noise. I also ask what I know that they don’t and vice versa, because often the decision carries business context I wasn’t told and that changes the picture entirely. If the decision stands, I commit for real — disagree and commit — because half-hearted execution out of resentment is the worst outcome for everyone, me included. That said, committing doesn’t mean switching off judgment: I propose doing it in a way that lets us check early whether it works. An early milestone with an agreed metric, or a small version with real users, turns an argument about opinions into data in three weeks. And if my concern was about serious risk, I leave it recorded in writing, without drama, so if it happens we don’t have to reconstruct the conversation.”

Why it works: disagrees with an alternative, seeks missing context, commits, and — best of all — turns the doubt into a measurable experiment.

🔁 Likely follow-up: “What if you were right and it went badly?” → “I don’t use it to collect on being right. I propose we review how we made that decision, not who got it wrong; if the focus is the person, next time nobody raises their hand.”

Q4. How do you deliver bad news to a client or to leadership?

What they assess: communication under pressure and judgment about honesty.

❌ What NOT to say

“I try to soften it or buy time until I have a solution, so as not to alarm people unnecessarily.”

Why it’s wrong: delaying bad news removes the other side’s ability to react, and when it finally comes out the damage doubles: the problem plus the sense of being kept in the dark. In incidents and delays, silence generates more noise than the bad news.

⚠️ Acceptable answer

“I communicate it as soon as possible, clearly, explaining what happened, what we’re doing and when we’ll have more information.”

What it’s missing: format and tone — the right structure makes the same news land very differently.

✅ Ideal answer

“Early, direct and with a plan. My order is: what’s happening and who it affects, what we’re doing right now, what I need from them if anything, and when I’ll report back. No hedging and no jargon: ‘checkout has been down for 20% of users since 10:15’ is understandable, ‘we have a pool saturation issue’ isn’t. I give a next update with a specific time and I keep it even if there’s no news, because silence is read as worse than it is. I don’t promise dates I can’t hold: I’d rather say ‘by 11:30 I’ll know whether this is minutes or hours’. And I separate communication from diagnosis: doing both at once means doing both badly, so if I can, I delegate one. Afterwards I close with what we’ll do so it doesn’t recur, which is what actually restores trust.”

Why it works: clear structure, the receiver’s language, realistic commitments, and closing with prevention.

🔁 Likely follow-up: “What if it was your team’s fault?” → “I own it externally, in the first person plural, with no names. Internally we analyse it blamelessly; externally the team is one.”

Q5. How do you say no?

What they assess: whether you can protect your team and your focus without damaging relationships.

❌ What NOT to say

“I don’t usually say no; I always try to help however I can.”

Why it’s wrong: it sounds collaborative and actually describes someone who doesn’t protect priorities: the result is a saturated team, late deliveries and low quality. In a senior role, saying no — well — is part of the job.

⚠️ Acceptable answer

“I explain we have other priorities right now and propose doing it later.”

What it’s missing: making the trade-off visible and offering alternatives so the other person can still solve their problem.

✅ Ideal answer

“I try to make it never a flat ‘no’ but a ‘no, unless we change something’. First I understand what they actually need, because sometimes what they’re asking for isn’t what they need and there’s a cheaper way. Then I make the trade-off visible: ‘we can do it, and then this other thing moves two weeks; shall we swap?’. That turns my no into their informed decision, and it often ends with them deciding it wasn’t that urgent. If it genuinely doesn’t fit, I say so early and clearly — leaving an expectation alive is worse than a no — and I offer alternatives: smaller, later, or who else could help. And within the team I try to absorb most of these noes myself, because if every person has to negotiate alone, they end up saying yes to everything.”

Why it works: understands the need, makes the trade-off visible, decides early, protects the team.

🔁 Likely follow-up: “What if the person asking is the CEO?” → “Same method, different tone: I ask what outcome they want and show the impact of inserting it now. A good executive would rather choose with information than get a yes that arrives late and broken.”

Q6. Tell me about a time you had to work with someone difficult

What they assess: interpersonal maturity — and above all, how you talk about other people.

❌ What NOT to say

“I worked with a toxic person who criticised everything and made progress impossible. Eventually they left and everything improved.”

Why it’s wrong: labelling someone toxic to a stranger says more about you than about them. The interviewer can’t verify the story, but they can observe how you speak about a former colleague: if you do it like that now, you’ll do it about them. And “they left and things improved” shows no learning at all.

⚠️ Acceptable answer

“I had a colleague with a very blunt communication style that clashed with mine. We talked, agreed how to work together, and it improved.”

What it’s missing: the detail of what you changed, which is what they’re looking for.

✅ Ideal answer

“I worked with someone who rejected almost every proposal of mine bluntly in reviews, and I was taking it personally. Before assuming bad intent, I tried changing my part: I started bringing ideas to him before writing them, short, asking him to break them. That’s when I found two things — he had maintained that system for years and carried scars I didn’t know about, and his tone was the same with everyone, not aimed at me. With that context his objections stopped sounding like attacks and started being useful; several of them prevented real problems. I also told him privately that the tone in public discouraged newer people, and he dialled it down. We didn’t become friends, but we ended up working very well together. My takeaway is that ‘difficult’ often means ‘I don’t understand their context’, and that assuming good intent by default has paid off far better than the alternative.”

Why it works: starts by changing their own behaviour, humanises the other person, addresses the real issue respectfully, and extracts a transferable lesson — without ever applying a label.

🔁 Likely follow-up: “What if the person genuinely has bad intent?” → “That exists, and there the line is respect: I address it directly once, and if it doesn’t change, I escalate with concrete facts. What I don’t do is normalise it for the rest of the team.”

Cross-cutting mistakes that sink a behavioral interview

Mistake	Why it costs you the job
Speaking badly about your company or colleagues	The fastest and most common rejection
Using “I” for everything or “we” for everything	Either you don’t collaborate, or your contribution is invisible
Having no failure to tell	Lack of self-criticism or of exposure to risk
Five-minute answers	In a senior role, prioritising is the job
No questions at the end	It looks like you’d accept anything
Only talking about the technical	The job isn’t only technical and they know it

How to prepare

Write your six STAR stories — without this, you’re improvising.
For each, make sure you can answer: what did you do, what number backs it, what did you learn?
Record yourself. Listen for whether you badmouth someone without noticing — it happens more than you’d think.
Practise the 30-second version: many interviews have no room for the long one.