You don't fail on system design. You fail in the room with the hiring manager.

This is the one most candidates over-prepare in the wrong direction — recycling a "I led this team of N engineers to ship feature X" story that the interviewer has heard 200 times. What they're actually trying to learn: can you make things happen without the org chart giving you authority?

Example questions

• "Tell me about a time you led without authority."
• "Walk me through a project where you owned the outcome end-to-end."
• "When was the last time you set the direction for your team?"
• "Tell me about a project where you had to convince other engineers to change course."

The shape of a strong answer

Pick a story with messy ambiguity at the start — not "the EM gave me this project," but "we noticed a problem nobody owned." Tell them what was unclear when you started, what you decided to make clear, and what got built because of your call. Quantify the outcome — latency dropped, churn dropped, revenue up, eng-hours saved.

Red flags to avoid

• "We" instead of "I": the interviewer can't tell what you did. They'll downgrade you.
• Story bigger than your level: claiming you architected a 30-person rewrite when you were 2 YOE rings false and you'll get probed.
• No metric: "users were happier" is not a metric. "Support tickets dropped 40%" is.

The candidate who "always finds common ground" is too smooth. The one who "stood firm and proved them wrong" is too rigid. The hire is the one who can name a specific disagreement, explain how they made their case, and explain what they did when the call went the other way.

Example questions

• "Tell me about a time you disagreed with your manager."
• "Describe a technical decision where you couldn't convince the team and had to commit anyway."
• "When have you pushed back against a PM or designer?"
• "What's a hill you'd die on technically?"

The shape of a strong answer

A real disagreement, framed in two parts. Part one: how you made the case — facts you brought, options you laid out, what you concretely proposed. Part two: what happened when it didn't go your way. The interviewer cares about part two more. Did you sulk? Sabotage? Or did you commit, execute the chosen path, and revisit later with data?

A perfect bonus is the rare story where you committed to the call that went against you, it later failed, and the team came back to your view — and you didn't gloat. That's a senior signal.

Red flags to avoid

• Hero ending: "...and they finally saw I was right." Too clean. Reality is messier.
• No concession: claiming you've never had to commit to a decision you disagreed with means either you're 6 months into your career or you're not honest.
• Naming the other person as the villain: even if true, talking down about an ex-colleague is a hire-killer.

This is the question where seniority shows. Anyone can list options. A senior engineer makes a call, lives with the consequences, and can articulate what they'd change with hindsight. The interviewer is trying to find out if you've actually carried a decision long enough to learn from it.

Example questions

• "Walk me through a hard technical decision you made."
• "When have you chosen the boring solution over the exciting one?"
• "Tell me about a time you optimised for short-term over long-term, or vice versa."
• "What's a decision you made that you'd reverse with what you know now?"

The shape of a strong answer

Pick one tradeoff with real consequences. Not "do we use Redis or Memcached" — that's an opinion, not a tradeoff. A real tradeoff: "we knew the sharded-MySQL path would let us ship in a quarter but would cost us cross-shard joins forever. We chose to ship. Here's what that cost us 18 months later." Name the cost. That's what separates seniors from staff.

If they ask "what would you do differently": resist the urge to say nothing. The expected senior answer is "I'd revisit the sharding key — the access pattern I optimised for turned out not to be the dominant one." Specificity, again.

Red flags to avoid

• Both options were good: if your "tradeoff" had no real cost to the path not taken, it wasn't a tradeoff.
• "I'd do it the same way": too cocky. Every senior has at least one decision they'd reverse.
• Story too small: choosing between two libraries isn't a senior-level tradeoff. Pick something with real blast radius.

The trap question. Candidates either (a) tell a "fake failure" ("my biggest weakness is that I work too hard"), (b) tell a real failure and over-distance themselves from it ("the project failed but the team's planning was the problem"), or (c) tell a real failure they're still raw about and dump it on the interviewer.

The hire-able answer is in the narrow middle: a real failure, owned cleanly, processed enough to talk about it calmly, with a specific learning that's been applied since.

Example questions

• "Tell me about a project that failed."
• "When were you wrong about something technical?"
• "Describe an incident you owned that went badly."
• "What's a piece of feedback you got that was hard to hear?"

The shape of a strong answer

Pick a failure that's at the right altitude for your level. Junior: a feature bug that broke a flow. Senior: a project that shipped late and cost the team political capital. Staff: an architectural call that aged badly and required a year of cleanup. Don't tell a junior-altitude failure as a senior — it makes you look like you haven't owned anything serious.

Structure: 30 seconds on what happened, 60 seconds on what your contribution to the failure was, 30 seconds on what you do differently now. The middle section is where the signal is. Most candidates skip it.

Red flags to avoid

• External blame: even partially. If you blame the PM, the platform team, the deadline, the interviewer assumes you'll blame your future colleagues too.
• No specific change: "I learned to communicate better" is empty. "I now write a one-page kickoff doc for every project > 2 weeks because of that miss" is real.
• Still raw: if you're visibly angry about it, the interviewer reads instability.

The shift from senior to staff is almost entirely this question. Can you move things across team boundaries, where you have no authority and people have their own priorities? Most candidates can't articulate a real example. The few who can are usually the ones who got the staff offer.

Example questions

• "Tell me about a time you got another team to do something they didn't initially want to do."
• "When have you had to influence a decision outside your immediate org?"
• "Describe a project that required coordination across multiple teams."
• "How do you build buy-in for a technical proposal?"

The shape of a strong answer

Strong influence stories have a specific moment of pre-work — the 1:1 you took before the meeting, the doc you wrote that made the decision easy, the ally you found who was going to be in the room with you. Generic "I built consensus by listening to everyone" is a non-answer.

Best structure: name the team, name what they were resisting, name the specific thing you did that moved them (it's almost never "I made a great argument in a meeting" — it's usually "I wrote the implementation plan that addressed their concerns before they raised them"). End with the outcome.

Red flags to avoid

• Escalation as a tool: "I got my manager to escalate to their VP" is the opposite of influence. It's the signal you didn't have the tools.
• No concrete artefact: senior+ influence usually involves a doc, an experiment, a prototype — something they can see, react to, modify.
• Single-meeting wins: most cross-team work plays out over weeks. Stories told as "and then in the meeting they agreed" sound rehearsed.

The question with the highest gap between "what candidates say" and "what hiring managers want to hear". Most candidates default to generic flattery: "I love your product, I've used it for years, the engineering culture seems amazing." Hiring managers have heard that 500 times. It signals nothing.

What signals: a specific reason the next two years of your career are best spent here, in this role. Tied to your trajectory. Not their stock price.

Example questions

• "Why our company?"
• "Why this role over the others you're considering?"
• "What does success in this role look like to you?"
• "Where do you see yourself in 3 years?"

The shape of a strong answer

Three layers: (1) a specific thing about the team or product you've researched (their engineering blog post, a talk by an engineer who'd be your peer, a public design doc — not "I read your homepage"); (2) a specific gap in your skills that this role would close, or a specific strength of yours it would put to work; (3) a credible trajectory hypothesis: "in 3 years I want to be the person who…" — and the role should be on the path.

For "where do you see yourself in 3 years", avoid both "doing exactly this role with more scope" (no ambition) and "leading a 50-person org" (no humility). Aim for: "shipping the things that need someone who's done X" — and X is what this role would teach you.

Red flags to avoid

• Pure flattery: "you're the best in the industry" is a signal you haven't done the work.
• Money / location / compensation reasons: even if they're true, never lead with them.
• "I want to learn" without saying what: at senior+, "I want to learn" without specificity reads as drift.