Senior & staff behavioral signal

Tell me about the most technically complex thing you have worked on.

The trap is answering the question as asked and describing complexity. Interviewers hear a hundred complex projects; what differentiates candidates is whether the complexity was essential or accidental, and what your relationship to it was.

Structure a strong answer in four parts, roughly 20/40/20/20 of the time:

1. Why it existed. The business problem, with a number. "Our onboarding took eleven days and 40% of signups abandoned during it" — not "we built a workflow engine".
2. The hard part, specifically. Not the whole system: the one or two decisions that were genuinely difficult, why the obvious approach failed, and what you traded. This is where you demonstrate depth, and it should be technical enough that the interviewer asks a follow-up.
3. Your role, precisely. "I owned the design and wrote the ingestion path; two others built the UI; I reviewed their work" is far stronger than an ambiguous "we". Ambiguity here reads as inflation, and experienced interviewers probe it hard.
4. What you would do differently. Always include this. Every real project has a decision you regret, and a candidate with no regrets either did not own it or has not reflected on it.

Tell me about a time you influenced a decision without having authority over it.

The shape of a strong story is almost always the same, and it is worth knowing so you can select the right example from your history:

1. You noticed something others had not, or had normalised — a rising failure rate, a process everyone worked around, a decision made on stale assumptions.
2. You made it legible. A measurement, a prototype, a document. Not an opinion in a meeting. "I instrumented it and found we were losing 4% of orders at that step" is influence; "I thought it was a bad idea" is not.
3. You found the person who could act, and framed it in what they cared about — cost for a director, roadmap risk for a PM, on-call burden for the team.
4. You let them own it. The best influence stories end with someone else advocating for the change as theirs. Candidates often resist telling it that way because it feels like giving away credit; interviewers read it as exactly the seniority they are looking for.
5. The outcome, quantified, and what you learned about persuading that particular audience.

Tell me about a time you were wrong and someone else was right.

This question is deceptively hard because most prepared answers are fake humility: "I was wrong about the timeline" or a story where being wrong turned out fine. Interviewers have heard those and score them as evasion.

What works is a story with three properties: you were genuinely, technically wrong; it cost something real; and you changed how you work as a result. Junior engineers being right and you being wrong is an especially strong version, because it tests whether you evaluate arguments on their merits rather than their source.

"I pushed hard for event sourcing on a service where an engineer six months out of a bootcamp kept asking why we could not just use a table with an audit log. I had good abstract reasons and I out-argued her, mostly because I was more senior and more fluent. Six months later we had 40 event types, a projection nobody fully understood, and a two-day debugging session every time a projection drifted. She had been right: the domain did not have the temporal complexity that justifies it. I rewrote it as a table with an audit trail in three weeks and deleted 4,000 lines. What changed for me is that I now make a point of asking the person with the simplest proposal to state their case last rather than first, because seniority ends conversations too early — and I say out loud what would make me change my mind, so the disagreement has somewhere to go."

Notice what makes it work: a specific technical error, a measurable cost, credit given plainly, and a concrete behavioural change that is still in use.

Tell me about a conflict with a colleague.

The rules:

• Steelman the other person. If your story does not include a sentence explaining why their position was reasonable from where they stood, you have failed the question regardless of the outcome. "He was being obstructive" is a red flag; "he had been paged four times that month by a similar change, so his caution was earned" is the answer.
• Choose a substantive conflict, not a personality clash — a technical direction, a priority, a standard. Personality-conflict stories rarely have a good ending and make the interviewer wonder what your colleagues would say.
• Show the mechanism: what you did to move it forward. A one-to-one before escalating. Finding the shared goal. Proposing an experiment that would settle it. Bringing in a third person deliberately rather than as ambush.
• The resolution does not have to be that you won. "We tried it their way, it worked, and I was glad we had a way to find out cheaply" is a strong ending.
• Say what the relationship is like now. Interviewers care disproportionately about this, because it tells them what working with you after a disagreement is like.

Tell me about something you shipped that failed.

Two flavours, and choose the one that fits your history:

Technical failure — an outage, a data loss, a design that did not hold. Own it without hedging, quantify impact, describe the mitigation, and spend most of the answer on the systemic fix. "We added a linter, a review checklist and an alert" is better than "I was more careful afterwards", because the first scales beyond you.

Product failure — you built it, shipped it, and nobody used it. This is the more interesting version at staff level, and the useful reflection is almost always upstream of the engineering: why did we not find out sooner? Was there a cheaper way to test the assumption? Did anyone talk to a user? Were you consulted on whether to build it, and if not, why not?

"We spent a quarter building a bulk-edit feature that three customers had asked for. It shipped, and after two months it had 11 uses total. The engineering was fine. The mistake was that nobody — including me — asked what those three customers were actually trying to do; two of them wanted an API, which we already had and had not told them about. What changed is that I now ask for the underlying problem before estimating, and I push for the smallest thing that tests the assumption. On the next feature that turned a proposed quarter into a two-week prototype that we then killed on the data."

What is the most impactful thing you have done that was not writing code?

Strong categories, roughly in ascending order of level signal:

• You mentored someone and they visibly levelled up. Be specific about what you actually did — the thing you changed in how they work — rather than "I mentored a junior".
• You wrote a document that changed a decision. A design doc, a postmortem, a comparison of three options. Bring it up specifically; documents are the primary tool of staff influence and interviewers know it.
• You improved how the team works: a deploy process, an on-call rotation, a review standard, a test strategy. Quantify before and after.
• You killed a project. Stopping expensive work that was not going to pay off is one of the highest-leverage things an engineer can do, and it is rare enough that a good story here is memorable.
• You were the person who found out what the customer actually needed and it changed what got built.

Why are you leaving, and what are you looking for?

Rules that matter more at senior level than junior:

• Never criticise your current employer, manager or colleagues — even when the criticism is deserved and even when the interviewer invites it, which they sometimes do deliberately. The interviewer cannot verify your account, so the only thing they learn is how you talk about people who are not in the room.
• Frame it as movement towards something: scope, a domain, a technical problem, a stage of company. Be specific enough to be credible.
• Have a real answer to "what are you looking for", because a vague one suggests you are applying everywhere and will leave in a year. It should also be specific enough that they can tell you if this role does not have it — which is genuinely in your interest.

"I've had a good three years and I'm proud of the payments work. What I want next is a system where reliability is the hard problem rather than a constraint — my team's roadmap for the next year is mostly feature work on a stable platform, which is the right call for them and not what I want to spend a year on. I'm also looking for a team where design decisions get written down; that has been the thing I've missed most."

Do you have any questions for me?

Ask questions whose answers would change your decision. Six good ones, because two will be answered before you ask:

• "What is the biggest technical problem the team has right now that you have not solved?" — the answer tells you what you would actually work on, and how honest they are.
• "How do decisions get made when engineers disagree about an approach?" — reveals whether there is a functioning technical culture or a loudest-voice one.
• "Walk me through what happens between a change being merged and it reaching users." — the single most informative question about day-to-day quality of life. The length and confidence of the answer tells you everything.
• "How much of the team's time goes to new work versus maintenance and interruptions?" — probes for hidden operational debt.
• "What does on-call look like — how many pages in a typical week?" — a specific number means someone is paying attention; a vague answer is itself the answer.
• "What separates someone doing well in this role from someone doing exceptionally?" — gives you the promotion criteria before you accept.
• To a manager: "What happened to the last two people in this role?"
• To a peer: "What is the most frustrating thing about working here?" — asked warmly, this gets a real answer surprisingly often, and it is the most valuable one you will hear all day.