You and a peer favor different solutions.

What is actually happening (the mental model).

You start by genuinely understanding their reasoning, because often they're weighing a constraint you're not — and sometimes you change your mind, which is a feature not a weakness. You keep it about the idea, never the person. Where it's decidable with evidence, you'd rather build a quick spike than argue in the abstract — data resolves what opinions can't. And once a decision is made, even if it wasn't your preference, you disagree and commit: support it fully, because a team half-heartedly executing a decision because one person is sulking is worse than either option done wholeheartedly. Being right matters far less than the team moving forward aligned — and you've been wrong enough times to hold your views loosely.

How to work through it.

1. Understand their reasoning first — they may see a constraint you don't.
2. Argue the idea, not the person.
3. Spike over abstract debate — let data decide where it can.
4. Disagree and commit — support the decision fully once made.

The trap that less-experienced engineers fall into.

Making it personal or ego-driven, arguing in the abstract instead of testing with a spike, and undermining a decision they disagreed with (worse than either option done wholeheartedly).

🎯 Interviewer follow-up questions you should expect.

• "You disagree with a teammate's technical approach — how do you handle it?" You understand their reasoning, argue the idea not the person, spike to let data decide, then disagree-and-commit.
• "What's 'disagree and commit'?" Once a decision is made, support it fully even if it wasn't your preference — alignment beats being right.

A junior on your team needs to grow.

What is actually happening (the mental model).

Your goal is to make them independent, not dependent on you, so you resist just handing them the answer — you ask guiding questions that lead them to it, because the struggle is where the learning happens. You pair regularly, and always give the why behind decisions, because context is what lets them make good calls when you're not there. You calibrate how much you hand off to their level and stretch it over time, create a safe space where a mistake is a lesson not a failure, give specific, actionable feedback, and celebrate their wins. Investing in juniors is one of the highest-leverage things a senior does — one good mentor multiplies the whole team's capability.

How to work through it.

1. Teach problem-solving, not answers — guiding questions, not solutions handed over.
2. Give the why — context, so they decide well without you.
3. Calibrate autonomy to their level; stretch it over time.
4. Safe space to fail; specific feedback; celebrate wins.

The trap that less-experienced engineers fall into.

🎯 Interviewer follow-up questions you should expect.

• "How do you mentor a junior?" Teach problem-solving with guiding questions, give the why, calibrate autonomy, safe space to fail, and specific feedback.
• "Why not just give them the answer?" It keeps them dependent; the struggle is where the learning happens — the goal is independence.

You're reviewing a PR with real issues.

What is actually happening (the mental model).

You review to make the code better and the person better, not to demonstrate you're smarter. You separate blocking issues from nits and label them clearly, so the author knows what must change versus your preference — nothing demoralizes like ten equally-weighted comments where two matter. You phrase concerns as questions ("what happens if this is null?") — less confrontational, and sometimes you're the one missing context. You pick battles, especially with juniors, and call out what's good, because positive reinforcement shapes behavior more than criticism. Tone in reviews sets the whole team's culture, and seniors set the tone.

How to work through it.

1. Blocking vs nit — label clearly; don't drown the author.
2. Questions over assertions — less confrontational, room for you to be wrong.
3. Explain the why; praise the good; pick battles (esp. juniors).
4. Remember: seniors set the review culture.

The trap that less-experienced engineers fall into.

Death-by-a-thousand-nitpicks (demoralizing, esp. for juniors), a superior/gatekeeping tone, and only pointing out the bad — teaching people to fear shipping.

🎯 Interviewer follow-up questions you should expect.

• "How do you review problematic code?" You separate blocking issues from nits, phrase comments as questions, explain the why, praise what's good, and pick your battles — reviews are about mentorship and quality, not gatekeeping.
• "Why does review tone matter so much?" Seniors set the team's review culture and psychological safety.

A reviewer pushes back hard on your code.

What is actually happening (the mental model).

How a senior takes criticism sets the ceiling for how safe everyone else feels giving it, so you take it graciously and engage with the substance, not the ego. If they caught a real issue, you thank them genuinely — you'd rather your reviewer catch it than production. Where you disagree, you push back with reasoning, not defensiveness, and you're open to being wrong. The thing you're most conscious of is that juniors are watching: if the senior gets defensive and territorial about their code, everyone learns that feedback is dangerous and the review culture dies. So you deliberately model that critique of your code is welcome and separate from your worth as an engineer.

How to work through it.

1. Take it graciously — separate ego from code; thank them for catching issues.
2. Push back with reasoning where you disagree; stay open to being wrong.
3. Model it — juniors watch how seniors take feedback; it sets psychological safety.

The trap that less-experienced engineers fall into.

Getting defensive/territorial about their code — which, from a senior, teaches the whole team that feedback is dangerous and kills the review culture.

🎯 Interviewer follow-up questions you should expect.

• "How do you take tough feedback on your own PR?" Graciously, engage the substance, thank them, push back with reasoning where you disagree — and model it, because juniors watch.
• "Why does it matter how you take feedback?" It sets the ceiling for how safe others feel giving it — psychological safety.

A peer is visibly stuck or not delivering.

What is actually happening (the mental model).

You approach with empathy and privately first, assuming good intent — people generally want to do well, so struggling usually means something's in the way. You try to understand the root cause: are they blocked on a dependency, overloaded, dealing with something personal, missing a skill, or unclear on expectations? Each has a different response. Often you can help directly — pair, help break an overwhelming task into pieces, unblock them. What you don't do is gossip or let it become a team narrative, which only makes it worse. If it's beyond peer support, you gently encourage them toward their manager or raise it appropriately — but your first instinct is to support a teammate, not judge them.

How to work through it.

1. Private + empathetic first — assume good intent.
2. Diagnose the blocker — dependency, overload, personal, skill gap, unclear expectations.
3. Help directly — pair, break down work, unblock.
4. No gossip; involve the manager only if beyond peer support.

The trap that less-experienced engineers fall into.

Judging or gossiping (makes it worse), assuming it's a character flaw rather than a solvable blocker, and jumping to escalation as a first move.

🎯 Interviewer follow-up questions you should expect.

• "A teammate is struggling — what do you do?" You keep it private and empathetic, assume good intent, diagnose the actual blocker, and help directly, without gossip, escalating only if it's beyond peer support.
• "Why assume good intent?" Most struggling is a solvable blocker, not a character flaw; support first.

You need to guide the team but have no formal authority.

What is actually happening (the mental model).

Most senior influence is informal — you don't have authority over peers, so you lead by earning it. That comes from being reliably competent and, more importantly, from making other people successful — unblocking them, sharing knowledge, doing the unglamorous glue work nobody else picks up. You propose rather than dictate and build consensus, because a direction the team owns beats one you impose. Credibility compounds: once people trust your calls are sound and you've got their back, they follow willingly. Trying to lead by being the smartest person in the room fails; leading by making the room smarter works.

How to work through it.

1. Earn credibility — reliable competence + making others successful.
2. Do the glue work nobody else picks up.
3. Propose, don't dictate; build consensus.
4. Authority follows credibility — trust compounds.

The trap that less-experienced engineers fall into.

Trying to lead by being the smartest/loudest (people don't follow), and dictating instead of building consensus (no ownership, resistance).

🎯 Interviewer follow-up questions you should expect.

• "How do you lead without formal authority?" You earn credibility through competence and by making others successful, do the unglamorous glue work, and propose rather than dictate — authority follows credibility.
• "What doesn't work?" Leading by being the smartest person in the room doesn't work; leading by making the room smarter does.

The team over-commits and misses sprints repeatedly.

What is actually happening (the mental model).

Chronic over-commitment usually comes from planning as if everyone codes 100% of the time, ignoring meetings, on-call, and interrupts — so you anchor estimates in actual historical velocity, not aspiration or what leadership hopes to hear. You help break work down so estimates are grounded, and you actively protect the team from over-commitment pressure — it's tempting to stuff the sprint to look ambitious, but consistently missing erodes trust more than committing to less and delivering it. You coach the team that saying "that doesn't fit this sprint" is professional, not lazy. Sustainable, predictable delivery beats a cycle of heroics and burnout.

How to work through it.

1. Anchor on real historical velocity, not 100%-coding aspiration.
2. Break work down for grounded estimates.
3. Protect against over-commitment — under-commit-and-deliver beats over-commit-and-miss.
4. Help the team say no to what doesn't fit.

The trap that less-experienced engineers fall into.

Planning on 100% capacity (ignoring meetings/on-call), stuffing the sprint to look ambitious, and chronically missing — which erodes trust more than committing to less.

🎯 Interviewer follow-up questions you should expect.

• "The team keeps over-committing — what do you do?" You plan on real velocity, not 100% coding time, break work down properly, protect the team from over-commitment, and help them say no.
• "Isn't committing to less bad?" No — consistently delivering builds trust; consistently missing erodes it.

One person dominates discussions or dismisses others.

What is actually happening (the mental model).

The risk with a dominating voice is that the team optimizes for the loudest opinion instead of the best idea, and quieter people stop contributing — which loses you their insight. So in meetings you actively make space: "I'd like to hear what Priya thinks before we decide." You model listening and giving credit. If someone's consistently dismissive, you'd address it respectfully, usually privately first, because the goal is to change the behavior, not embarrass them. Protecting psychological safety is a senior responsibility even without a manager title — the team's best thinking only surfaces if people feel safe to speak, and if a senior lets one voice dominate, that safety erodes. For persistent problems, partner with the manager.

How to work through it.

1. Create space for quieter voices — actively invite them in.
2. Model inclusive behavior — listen, give credit.
3. Address dominating behavior respectfully (privately first) — change the behavior.
4. Protect psychological safety — best idea wins, not loudest; involve manager if persistent.

The trap that less-experienced engineers fall into.

Letting the loudest voice dominate (best ideas lost, quieter people disengage), or confronting someone publicly (embarrasses, escalates) instead of privately.

🎯 Interviewer follow-up questions you should expect.

• "One person dominates the team — how do you handle it?" Actively create space for quieter voices, model inclusion, address it respectfully (privately first), and protect psychological safety.
• "Why does it matter?" The team optimizes for the loudest voice instead of the best idea, and loses quieter people's insight.

Only you know how to handle certain incidents.

What is actually happening (the mental model).

Being the only person who can fix something feels good but is actually a failure — it makes you a single point of failure and means you can never disconnect. So you deliberately work to make yourself replaceable: write runbooks for the things only you know, pair with teammates during incidents so they learn by doing, ensure on-call actually rotates rather than defaulting to you, and run game days so people practice before the real thing. The senior mindset is that indispensability is a bug — a resilient team is one where any incident can be handled by whoever's on call, not one that depends on a hero. Your job is to spread what's in your head, not hoard it.

How to work through it.

1. Runbooks for what only you know.
2. Pair on incidents — teammates learn by doing.
3. Rotate on-call — don't default to the hero.
4. Game days to practice; make yourself replaceable.

The trap that less-experienced engineers fall into.

Enjoying being the indispensable hero (a single point of failure, never off), and hoarding knowledge instead of spreading it — so the team can't function without them.

🎯 Interviewer follow-up questions you should expect.

• "Only you can handle certain incidents — is that good?" No — it's a failure and a single point of failure; you write runbooks, pair on incidents, rotate on-call, and run game days to make yourself replaceable.
• "Why is indispensability a problem?" It's a single point of failure and you can never disconnect; a resilient team doesn't depend on a hero.

The team's practices could be better — retros are stale, no learning loop.

What is actually happening (the mental model).

Team culture is set less by posters and more by what senior people model and tolerate day to day, so you're intentional about it. You push for retros that actually produce tracked action items rather than a venting session that changes nothing — an improvement nobody acts on teaches the team that retros are theater. You celebrate wins visibly and treat failures as blameless learning, because that's what makes people willing to take smart risks. You encourage small experiments in how you work and keep the ones that stick. The compounding effect matters: a team that improves how it works a little every couple of weeks is dramatically better in a year, and a senior's steady modeling drives that more than any one big initiative.

How to work through it.

1. Retros with tracked action items — not venting theater.
2. Celebrate wins; blameless learning from failures — enables smart risk-taking.
3. Small experiments in how you work; keep what sticks.
4. Model it steadily — culture = what seniors model/tolerate; it compounds.

The trap that less-experienced engineers fall into.

Running retros that produce no tracked change (theater — teaches the team retros are pointless), and treating culture as HR's job rather than something seniors set by daily behavior.

🎯 Interviewer follow-up questions you should expect.

• "How do you improve team culture/practices?" You run retros with tracked follow-through, celebrate wins, keep learning blameless, and try small experiments, modeling it steadily — culture is what seniors model and tolerate.
• "Why do retros often fail?" They produce no tracked change, so the team learns they're theater.

A new engineer joins and needs to ramp up fast and feel productive.

What is actually happening (the mental model).

A good onboarding is structured, not sink-or-swim — the goal is an early first win (a small, real, shippable task in the first week) that builds confidence and confirms their environment works, plus a buddy/mentor for the questions they're afraid to ask. You front-load the why and the context (architecture, conventions, who owns what) over rote detail, make the first steps documented (setup, deploy, run the tests), and check in frequently early. A senior sees onboarding as an investment: time spent ramping someone well pays back many times over, and a rough onboarding sets a lasting negative tone.

How to work through it.

1. Structured, not sink-or-swim — a clear first-week plan.
2. An early real first win — small shippable task; builds confidence, validates their setup.
3. A buddy/mentor for safe questions; front-load the why/context.
4. Documented first steps (setup/deploy/tests); frequent early check-ins.

The trap that less-experienced engineers fall into.

Sink-or-swim onboarding (slow ramp, low confidence, a bad first impression), and dumping detail without context/an early win.

🎯 Interviewer follow-up questions you should expect.

• "How do you onboard a new team member?" Structured plan, an early real first win, a buddy, documented setup, front-load the why and context.
• "Why an early first win?" It builds confidence, validates their environment, and gives momentum.

A peer is doing something that's a problem — a behavior, a recurring quality issue, a communication style — and you need to give feedback (not just in a code review).

What is actually happening (the mental model).

Good feedback is timely, specific, private, and about behavior/impact — not character. You use a simple structure (situation → behavior → impact: "in yesterday's standup, when X happened, the effect was Y"), lead with genuine intent to help, and make it a dialogue, not a verdict — they may have context you don't. You give it soon (not saved up for a review), privately (praise in public, correct in private), and you balance it with the positive so feedback isn't only ever criticism. Done well, peer feedback strengthens the relationship and the team; done badly (public, vague, character-focused) it damages both.

How to work through it.

1. Situation → behavior → impact — specific, about behavior not character.
2. Timely and private — soon, not saved up; correct in private.
3. Dialogue, not verdict — they may have context; lead with intent to help.
4. Balance with the positive — not only ever criticism.

The trap that less-experienced engineers fall into.

Giving vague, character-focused feedback ("you're careless"), doing it publicly (embarrasses, defensiveness), or saving it up for a review (stale, ambush) — or avoiding it entirely so the problem persists.

🎯 Interviewer follow-up questions you should expect.

• "How do you give a peer difficult feedback?" Timely, private, and specific using a situation-behavior-impact structure, focused on behavior not character, delivered as a dialogue, and balanced with the positive.
• "What makes feedback land?" Specificity, good intent, and making it a two-way conversation, not a verdict.