“Our API response times have degraded 40% over six months because we are doing N+1 queries on the orders endpoint. I evaluated three approaches: query optimization, adding a caching layer, and denormalizing the schema. I recommend the caching layer because it gives us the biggest improvement with the least risk to existing queries, and we can ship it in one sprint. The risk is cache invalidation complexity, which I plan to handle with event-driven invalidation using our existing Kafka setup. I need two days of review time from the data team to validate the invalidation strategy.”

“Hey, so I was looking at the deployment pipeline and noticed something weird with the staging environment. I checked the logs and it seems like the config might be off. I think maybe the last PR changed something? Not sure though. Anyway, could someone take a look when they get a chance?”

“@infrastructure-team — Staging deploys are failing since yesterday’s config PR (#2847). Error: REDIS_URL not found in env. Can someone from infra confirm if the env vars were updated for the new Redis cluster? Blocking: QA cannot test the payments feature (due Thursday).”

“This week: worked on authentication. Had some meetings. Also looked at some bugs.”

“Shipped: OAuth2 PKCE flow for mobile clients — merged and deployed to staging. Integration tests passing. Blocked: Cannot deploy to production until the security team completes the token storage review (ETA unknown — escalating Monday if no response). Next week: Session management API. Risk: the spec from product is incomplete on refresh token TTL. Meeting scheduled Wednesday to resolve.”

• “The technical constraint here is X, which means for the business…”
• “We have two options. Option A is faster but riskier. Option B takes two extra weeks but has a safer rollout.”
• “Think of it like [analogy]. The database is like a filing cabinet that is full. We can get a bigger cabinet (vertical scaling) or add more cabinets (horizontal scaling).”

“I see why that approach is appealing, especially the simplicity of implementation.”

“My concern is that it may not scale past 10K concurrent users. When we tried a similar approach on the notification service last year, we hit connection pool exhaustion at 8K users.”

“Could we run a load test with realistic traffic before committing? That would give us concrete data either way.”

• “I see it differently because…” (not “That’s wrong”)
• “Have we considered the case where…” (not “You forgot about…”)
• “What would change your mind on this?” (genuinely curious, not rhetorical)
• “I want to make sure we’re not overlooking…” (collaborative framing)

• “That will never work.” (absolute, no evidence)
• “We already tried that.” (dismissive, no context)
• “I don’t think you understand the problem.” (personal attack)

• “When you say ‘real-time’, do you mean sub-100ms or eventual consistency within a few seconds?”
• “Are we optimizing for latency or throughput here?”

• “What happens if the message queue goes down? Do we lose data or queue it locally?”
• “How does this behave at 10x current traffic?”
• “What is the failure mode if the third-party API is unavailable for 30 minutes?”

• “Have we looked at how the payments team solved a similar problem?”
• “What would this design look like if we had to support multi-region?”

“This is confusing.”

“This function handles three responsibilities (validation, transformation, persistence). Could we split it into three functions? That would make each one independently testable and easier to understand. Something like validateOrder(), transformForDB(), and persistOrder().”

• Bugs or correctness issues
• Security vulnerabilities
• Performance problems that will impact production
• Missing tests for critical paths
• Violations of architectural decisions the team has agreed on

• “Nit: I’d name this userCount instead of cnt, but up to you.”
• “Suggestion: A map might read better than a for-loop here, but either works.”
• “Optional: We could use destructuring here for readability.”

“Why did you do it this way?”

“Curious about the choice to use recursion here — was there a reason you preferred it over iteration? I want to understand in case I’m missing something.”

• Use “I” language: “I found this confusing” vs “This is confusing” (the first is a data point; the second is a judgment).
• State your intent: “Genuine question:” or “Not blocking, just curious:” removes ambiguity.
• Avoid rhetorical questions: “Shouldn’t this be a constant?” reads as passive-aggressive. Say “This value appears in three places. Could we extract it to a constant to avoid drift?”
• When in doubt, add an emoji or explicit tone marker: “This might be over-engineered for the current requirements (not a criticism, just want to check if we’re building for known future needs or speculating).”

• “I think Option A is better for these reasons [evidence]. But if the team decides on Option B, I will build it to the best of my ability and not undermine it.”
• Committing means actually committing: no “I told you so” if it fails, no passive resistance, no half-hearted implementation.

• Silently going along with something you think is wrong (that is “agree and resent”)
• Agreeing in the meeting and complaining in Slack afterward
• Doing a bad job on purpose to prove you were right

• Persist when you have data, the risk is real, and the pushback is based on inertia or politics.
• Let go when the pushback is based on constraints you did not consider, the cost-benefit does not justify fighting, or you have been heard and the decision-makers have all the information.

“I proposed migrating to Kubernetes and got pushback from the ops team. Instead of pushing harder, I asked what their concerns were. They were worried about the learning curve and the timeline. So I proposed a compromise: we would containerize one non-critical service as a pilot, I would run a two-day workshop for the ops team, and we would evaluate after a month. The pilot succeeded, and the team voted to migrate the rest.”

• You and a peer have fundamentally different views and have exhausted direct discussion
• A decision is being delayed and the delay itself is causing damage
• You have identified a risk that is being ignored and you have evidence
• You need a tiebreaker and neither side has authority to decide

“At a fintech startup with 15 engineers, we were processing $2M/day in transactions through a monolithic Rails app that was hitting scaling limits.”

“I was tasked with designing and leading the migration to a microservices architecture for the payment processing pipeline.”

“I evaluated three approaches: strangler fig pattern, big-bang rewrite, and branch-by-abstraction. I chose strangler fig because it let us migrate incrementally without freezing feature development. I started with the highest-risk component — the payment validation service — because it was the bottleneck and would prove the architecture fastest.”

“We migrated the payment pipeline in four months with zero downtime. Processing latency dropped from 800ms to 120ms. The system handled Black Friday traffic (5x normal) without intervention.”

“If I did it again, I would invest more upfront in distributed tracing. We spent two weeks debugging a race condition that would have been obvious with proper observability. I now treat observability as a day-one requirement for any distributed system.”

• 1 sentence (elevator pitch)
• 1 paragraph (executive summary)
• 5 minutes (design review)
• 30 minutes (deep dive)

• Read your code out loud line by line (“OK so now I am declaring a variable…”)
• Go silent for 3+ minutes (the interviewer starts worrying)
• Narrate uncertainty without direction (“I have no idea… maybe… I don’t know…”)

Weak: “I’m not growing.” (vague, sounds like complaining) Strong: “I have built the core payment infrastructure from zero to processing $5M/day. The system is stable, the team is trained, and I am looking for the next zero-to-one challenge. Your company’s real-time bidding system is exactly the kind of complex distributed system I want to build next.”

Weak: “I am a perfectionist.” (cliche, not self-aware) Strong: “I tend to over-engineer solutions. In my last project, I built a generic plugin system when we only needed two integrations. I have learned to ask ‘what do we need in the next six months?’ instead of ‘what might we need someday.’ I now set explicit scope boundaries in my design docs and ask a colleague to review for over-engineering.”

Weak: “We launched late.” (no ownership, no learning) Strong: “I shipped a caching layer without proper invalidation testing. It worked fine for a week, then a race condition caused stale prices to display for 45 minutes during peak traffic. I owned the incident, wrote the postmortem, and implemented three changes: mandatory cache invalidation tests in our test suite, a circuit breaker for stale data detection, and a runbook for cache-related incidents. We have had zero cache incidents since.”

Weak: “In management.” (sounds like engineering is a stepping stone) Strong: “I want to be a technical leader who shapes architecture decisions across multiple teams. Whether that is a Staff Engineer or Engineering Manager role depends on where I can have the most impact. Right now, I am focused on deepening my distributed systems expertise and building my ability to mentor other engineers.”

Strong questions to ask:

• “What does the on-call rotation look like, and how do you handle incident severity?”
• “Can you walk me through how a feature goes from idea to production here?”
• “What is the ratio of new feature work to maintenance and tech debt?”
• “What is the biggest technical challenge your team is facing right now?”
• “How do you handle disagreements about technical direction?“

• Overpromising and underdelivering (even once erodes trust significantly)
• Having opinions about everything but owning nothing
• Taking credit for team work
• Being the “well, actually” person in every conversation
• Dismissing other people’s work or concerns

1. Onboarding guide for your team — reduces ramp-up from weeks to days
2. Runbooks for common operational tasks — transforms tribal knowledge into team knowledge
3. ADRs for major decisions — prevents relitigating settled debates
4. System architecture overview — the doc you wish existed when you joined
5. Common debugging playbook — “If you see error X, check Y first”

• Fix a bug in their codebase and send a PR
• Write documentation for their API that was missing
• Shout out their work in company channels
• Invite them to your design reviews when relevant

“First, I would make sure both sides feel genuinely heard. If people feel the process was fair, they can commit even to a decision they disagreed with. If they feel railroaded, they will resist even a good decision.”

“I would step back and ask the team: what are we optimizing for? Is it speed of delivery, long-term maintainability, operational simplicity, or something else? Once we agree on the criteria, the answer often becomes obvious, or at least defensible.”

“If the team is still split after aligning on criteria, I would propose one of two things. Either we time-box a small prototype, each side builds a proof-of-concept addressing the riskiest assumption, and we evaluate with data. Or, if time pressure does not allow that, I would ask the team to designate a decision-maker, usually the person who will own the implementation, and commit to their call.”

“Whatever we decide, I would explicitly name it: ‘We are going with Solution A. If you preferred B, I respect that, and I ask that you commit fully to A. We will revisit in [timeframe] if the decision is not working.’ The worst outcome is a team that half-builds both solutions.”

• Saying “I would just pick the best one” without explaining how you evaluate “best”
• Defaulting to “we’d vote” — majority rule without discussion breeds resentment
• Avoiding the question by saying “I’d find a compromise” — sometimes there is no middle ground
• Not addressing what happens to the losing side emotionally

“I would never lead with ‘we need to migrate from Postgres to DynamoDB.’ The VP does not care about database engines. I would lead with the business pain: ‘We are losing $X per month in failed transactions because our database cannot handle peak load. Customer complaints about slow checkout have increased 40% this quarter. Our biggest enterprise client has flagged performance as a contract renewal risk.’”

“Executives understand opportunity cost. I would show them what happens if we do not migrate: projected revenue loss over 6 months, engineering hours spent on firefighting instead of feature work, customer churn risk. ‘We are spending 30% of on-call time patching symptoms of this problem. That is 1.5 engineers worth of capacity we are burning just to stay afloat.’”

“I would frame the three months not as a delay but as an investment: ‘If we invest three months now, we recover 1.5 engineers of capacity permanently, we unblock the enterprise tier which is worth $2M ARR, and we reduce incident rate by an estimated 60%. The payback period is four months.’”

“Executives are allergic to risk, so I would preemptively address it: ‘Here is my phased plan. Month one is reversible. If at any point we discover the migration is not delivering expected results, we roll back with zero customer impact. I will provide weekly updates with measurable checkpoints.’”

“I would end with a clear ask: ‘I need your approval to pause feature X for three months. Here is what we defer, here is what we gain, and here is how I will keep you informed.’”

• Leading with technical jargon (“Our connection pool is exhausted and the ORM is generating N+1 queries”)
• Not quantifying the cost of inaction, making it feel like a tech vanity project
• Framing it as “the engineers want this” instead of “the business needs this”
• Not having a phased or reversible plan, making it feel all-or-nothing

“Early in my career at [company], I submitted a PR for a caching layer I was proud of. The senior engineer’s review was blunt: ‘This entire approach is wrong. You are caching at the wrong layer and this will cause stale data in production. Please re-read the architecture doc and start over.’ No softening, no suggestions, just a rejection.”

“My first reaction was defensiveness. I had spent three days on it. But I took an hour before responding. I have learned that my first emotional reaction to critical feedback is almost never the right one to act on.”

“I re-read the architecture doc as suggested. The senior engineer was right. I was caching API responses at the controller level, but our system had multiple write paths that would bypass the cache, leading to stale data. I rewrote the solution to cache at the data access layer, where all writes were funneled through a single path, making invalidation reliable.”

“I also talked to the reviewer afterward. I told them the feedback was correct but that the tone made it hard to receive. They appreciated the direct conversation and started prefixing their reviews with more context. We built a good working relationship after that. I learned two things: how to take harsh feedback without shutting down, and that it is OK to give feedback on how you receive feedback.”

• Claiming you never feel defensive (“I always welcome feedback!” — nobody believes this)
• Turning the answer into a complaint about the reviewer
• Not showing what you actually learned technically
• Missing the chance to talk about how you improved the feedback dynamic