Scenarios: technical opinions and being wrong

This part is the compendium: a dense bank of specific situations that come up in an engineering job, each shown as a real chat exchange from both chairs. It is a lookup, not a narrative. Skim for the row you are living right now, and note that most of these happen to you one week and are done BY you the next, so the examples run in both directions.

Having an opinion and being wrong are the same skill viewed from two ends. This chapter is a bank of real exchanges for forming a view, defending it with evidence, changing it in public without shrinking, and naming the edge of what you actually know. Each one is a one-line prompt and a strong reply, shown from both chairs, so grab whichever seat you are in today. The move under all of them is the same: soften the person, sharpen the substance.

Reacting to a tool or approach you have never used

  • Asked if you know a tool. Q: "Have you used Temporal for the workflow engine?" A: "Not in production, only a weekend demo. I can get up to speed by Thursday, or defer to Priya who shipped one last year."
  • Team leans toward a new database. Q: "Thinking we move the events table to ScyllaDB." A: "I have never run Scylla, so treat my read as an outsider's: what does it buy us over the Postgres we already operate?"
  • You are handed an unfamiliar CLI. Q: "Can you deploy this with Pulumi before standup?" A: "I have only used Terraform. Give me an hour to read their docs and I will either do it clean or flag that I am not the right hand for it."
  • Vendor pitches their SDK. Q: "Our SDK handles retries for you, sound good?" A: "It might. I have not touched it, so I want to see the backoff config and a failure trace before I trust it in the payment path."
  • Peer excited about a framework. Q: "We should rewrite the dashboard in HTMX, it is so clean." A: "Could be. I have not shipped HTMX, so before I vote I want to see how it holds up with our three biggest tables."
  • You (the reviewer) meet a new pattern. Q: "This uses the actor model, is that a problem?" A: "No, just new to me. Walk me through how a message gets dropped and I will review with fresh eyes rather than pretend."
  • Manager asks your gut on a tool. Q: "Quick gut check, Bun instead of Node for the new service?" A: "Gut says interesting, but I have zero Bun mileage, so my gut is worth little here. I would run a two-day spike before betting the roadmap on it."
  • Someone assumes you know Kafka. Q: "You will set the consumer group offsets, right?" A: "I want to be straight: I have read about Kafka, never operated it. I can learn it or pair with someone who has, your call."
  • New linter proposed. Q: "Let us switch the repo to Biome." A: "No strong view, I have not run it. If it is a drop-in for ESLint plus Prettier and CI stays green, I am easy."
  • Trying an approach live. Q: "Ever done a blue-green cutover on ECS?" A: "First time for me. I will follow the runbook step by step and call out anything that looks off rather than improvise."

Disagreeing with a proposed architecture or design

  • Design doc proposes microservices. Q: "Splitting checkout into five services, thoughts?" A: "I would push back. We are three engineers and one on-call rotation; five services is five pipelines and five ways to page us at 2am. What problem is the split solving?"
  • You want a queue, they want direct calls. Q: "Just have the API call the emailer directly." A: "That couples our checkout latency to their SES quota. A queue costs us a day now and saves us a full outage when their inbox backs up."
  • Shared database between services. Q: "Both services can just read the same orders table." A: "That is the coupling that will bite us in six months. Can we give the second service a read replica or an event feed instead, so a schema change does not break two teams?"
  • Proposed cache with no invalidation story. Q: "We add Redis in front and we are done." A: "The cache is easy, the invalidation is the hard part. What is our story when a price changes and the cached value is 15 minutes stale?"
  • You (the designer) get a simpler counter. Q: "Why not just a cron job instead of this whole pipeline?" A: "Honestly, fair. If we are under a thousand rows a night, cron wins. I over-built for a scale we do not have yet; let me cut it down."
  • Sync where async fits. Q: "The upload should block until the thumbnail is generated." A: "That ties a user's request to ImageMagick's mood. I would return immediately and generate async, then the p99 upload stays under 200ms."
  • Premature abstraction. Q: "I added a plugin interface so any provider can slot in." A: "We have exactly one provider and no second on the roadmap. Can we ship the concrete version and add the interface the day the second one is real?"
  • Disagreeing in a review meeting. Q: "So we are agreed on the event-sourced approach?" A: "I am not there yet. Event sourcing solves audit, which we do not need, and it makes the read path harder, which we do every request. Can we walk the trade one more time?"
  • You favor boring tech. Q: "This is a great chance to try GraphQL federation." A: "It is, but a great chance is not a reason. Our REST endpoints are not the bottleneck; the DB is. I would rather spend that quarter on the query plan."
  • Two-way door reframing. Q: "You are blocking the whole design over this." A: "I am not, and I do not want to. The queue choice is reversible, so ship it. My only hard line is the schema, because that one is expensive to undo."
  • Coupling to a vendor. Q: "Let us build the whole billing flow on Stripe Checkout." A: "For v1, great. My worry is we bake Stripe assumptions into the domain model. Can we keep a thin adapter so a second processor is a week, not a rewrite?"
  • You (author) concede a real gap. Q: "How does this behave when eu-west is down?" A: "It does not, and you just found the hole. There is no failover in this draft. Let me add a section before we go further."

Getting strong pushback on your recommendation

  • Senior disagrees flatly. Q: "No, gRPC here is overkill and you know it." A: "You might be right. My case was streaming and typed contracts; if those do not matter for this endpoint, JSON over HTTP is the boring win. Which part do you not buy?"
  • Pushback with no reason. Q: "I just do not like this approach." A: "That is fair, and I want to fix it. Is it the complexity, the new dependency, or the rollout? Tell me which and I will address that specific piece."
  • You hold your ground with data. Q: "The current index is fine, stop gold-plating." A: "I hear you, and I do not want to over-engineer. But the slow-query log shows this one at 4.2s p99 under load. Can we look at that trace together before we close it?"
  • Manager overrules on timeline. Q: "We do not have time for the migration, ship the hack." A: "Understood, I will ship it. I want it on record that the hack adds a manual step to every deploy, so let us file the follow-up now while we remember why."
  • Talked out of your position. Q: "The lock contention only shows up above 10k RPS, we are at 800." A: "That is the number I was missing. You are right, at 800 this is a non-issue. I withdraw it and I will note the 10k threshold in the doc."
  • Pushback you should escalate. Q: "Just skip the security review, we are behind." A: "I cannot sign off on skipping it for the auth change, that is above my line. Let us get Noor's read for 20 minutes rather than ship it blind. See Chapter 11."
  • Reviewer keeps blocking. Q: "Still a no from me on this PR." A: "Okay, I want to unblock this cleanly. Can you point at the one change that would flip you to approve? If it is the error handling, I will fix that now."
  • You (the pushback giver) soften your no. Q: "Why are you blocking my PR over naming?" A: "The naming is minor and I should have said so; that is a nit, not a block. My actual block is the missing null check on line 88, everything else is optional."
  • Emotional pushback. Q: "I spent all week on this and now you want it gone." A: "I know, and that is a real cost. This is not about the work you put in, it is about the retry storm it can cause. Can we keep 80% of it and just change the failure path?"
  • Pushback that changes your mind halfway. Q: "You are optimizing a path that runs twice a day." A: "Huh, you are right, I read the metric wrong. If it is twice a day, none of this matters. Let me back out the change."
  • Standing firm without heat. Q: "Everyone else is fine with the plaintext logging." A: "They might be, and I still cannot be. We log the full request body including tokens. That is a leak, not a preference, so I want it fixed before merge."

Correcting your own earlier statement

  • Walking back a wrong number. Q: "You said the job takes 30 minutes." A: "I need to correct that. I re-ran it and it is closer to 90 minutes with the full dataset. My earlier number was on a sample, my mistake, plan around 90."
  • You misdiagnosed yesterday. Q: "So it was the network like you said?" A: "No, and I owe you a correction. It was our own connection pool exhausting, not the network. I pointed the wrong way yesterday; here is the actual trace."
  • Reversing a Slack claim. Q: "Earlier you said Redis was the bottleneck." A: "Scratch that. I profiled it properly and Redis is at 2% CPU; the time is in JSON serialization on our side. Correcting the record so nobody chases the wrong thing."
  • Retracting an estimate upward. Q: "You promised this by Friday." A: "I did, and I was wrong to. Once I opened the auth code I found a second integration I missed. Realistic is Wednesday next week; I would rather tell you now than Friday."
  • Fixing a fact mid-meeting. Q: "And we are on Postgres 14, right, as you noted?" A: "Actually let me correct myself, I checked and we are on 12. That changes the upgrade path, so good that we caught it here."
  • You gave bad advice in a thread. Q: "I used the pattern you suggested and it deadlocks." A: "That is on me, my suggestion was wrong for your case. The lock ordering bites when you hold both. Do it this other way and it clears; sorry for the detour."
  • Correcting a public estimate downward. Q: "You flagged this as a two-week job to the whole channel." A: "I did, and it turned out to be two days once I found the existing helper. Updating my earlier message so leadership is not planning around a stale number."
  • Admitting a benchmark was set up wrong. Q: "Your benchmark showed the new code was 5x faster." A: "It did, and the benchmark was flawed: I forgot to warm the cache, so I was measuring cold vs warm. Real number is about 1.3x. Rerunning clean and I will repost."

Correcting a senior engineer or manager

  • Senior states a wrong fact, gently. Q: "The GC pauses because we are on Java 8." A: "I think we actually moved to 17 last quarter, so it is likely G1 doing something else. Want me to pull the GC logs so we are working from the real config?"
  • Manager misremembers a decision. Q: "We agreed to drop the audit log, no?" A: "My notes say the opposite, that we keep it for the SOC2 window. Could be I misheard; the thread is here. Worth a two-minute check before we act on it."
  • Correcting the architect in a room. Q: "The consumer is idempotent, so duplicates are fine." A: "One thing to flag: it is idempotent on the write but not on the email send, so a duplicate does mail the customer twice. Small gap, easy to close, wanted it on the table."
  • Senior's mental model is stale. Q: "Just hit the monolith endpoint like always." A: "That path moved to the orders service in the March split, so the monolith 404s now. New URL is here; I only know because it paged me last week."
  • Correcting up without an audience. Q: "(In a DM) I told the client it is encrypted at rest." A: "Quick heads up before this goes further: the reports bucket is not encrypted yet, that is next sprint. I would soften the claim to 'in progress' so we are not exposed."
  • Manager's number is off in a plan. Q: "We can serve this on the current 2 instances." A: "The load test says 2 tops out at 60% of Black Friday traffic. I would size for 4. Happy to show the graph; I do not want you committing to a number that will page us."
  • You (senior) get corrected and take it well. Q: "Actually I think you have the retry logic backwards." A: "Say more. If retries happen before the circuit breaker trips, then yes I have it backwards and that is a real bug. Let me look. Good catch."
  • Correcting a lead's tool claim. Q: "DynamoDB scans are cheap at our size." A: "At our size the scan is fine today, agreed. My only note is it grows with the table, so I would add a GSI before the table triples. Not urgent, just flagging the cliff."
  • Public correction done kindly. Q: "As Ravi said, the deploy is fully automated." A: "Small correction so nobody gets surprised on call: the DB migration step is still manual. Everything else is automated. Ravi is right about the app tier."

Asking about unfamiliar terminology

  • A term flies by in a meeting. Q: "We will just use CDC for the sync." A: "Can you unpack CDC for me? I want to make sure I am picturing the same thing before I nod along."
  • Acronym soup in a doc. Q: "The SLO is gated on the p99 under the error budget." A: "Two-second check: when you say error budget here, do you mean the monthly allowance or this release's? I want to size my fix to the right one."
  • New jargon from another team. Q: "This runs through the golden path pipeline." A: "I have not heard 'golden path' used here, is that your standard CI template or something custom? Want to use the right name back to you."
  • You (senior) invite the question. Q: "Sorry, what does idempotent actually mean?" A: "Good question, ask it any time. It means running it twice has the same effect as running it once, so a retry is safe. That property is why the queue design works."
  • Term that has two meanings. Q: "We shard by tenant." A: "When you say shard, do you mean separate databases or separate tables in one DB? The word gets used both ways and it changes my answer."
  • Unfamiliar metric name. Q: "Watch the saturation, not the utilization." A: "I know utilization, I am fuzzy on how you draw the line to saturation. Can you point me at the specific dashboard so I calibrate?"
  • Checking you understand before committing. Q: "Make it eventually consistent and we are good." A: "Before I build it that way: eventually consistent means a read right after a write might show the old value for a bit, yes? If a user can see that, we should talk about the window."

Saying you do not know the answer

  • Put on the spot in a meeting. Q: "What is our current p99 on the checkout API?" A: "I do not know off the top of my head. I can have the real number in Grafana in five minutes rather than guess and mislead the room."
  • Asked to predict behavior you cannot. Q: "Will this hold up at 10x traffic?" A: "Honestly, I do not know. Nothing tells me it fails, but I have not load-tested past 3x. I would not promise 10x without running it."
  • Root cause not yet known. Q: "Why did the pods restart at 3am?" A: "I do not have the cause yet. What I know: OOMKilled on three pods, memory climbed for an hour first. I am still finding what fed the climb."
  • You (the asker) get an honest 'do not know'. Q: "No idea, I have never looked at that module." A: "That is a fine answer. Who has? Point me at whoever last touched it and I will start there."
  • Refusing to bluff to a stakeholder. Q: "Can you guarantee zero downtime on the cutover?" A: "I cannot guarantee zero. I can design for it and rehearse it, and my honest estimate is under 30 seconds. Zero is not a number I will promise."
  • Do not know, but know the shape. Q: "Is the memory leak in our code or the library?" A: "Do not know yet. The heap dump points at the library's connection objects, so my money is there, but I have not proven our code is not holding them."
  • Asked about someone else's system. Q: "How does the fraud service score this?" A: "That is not my system and I would only be guessing. Yuki's team owns it; I can loop them in so you get the real answer, not my version."
  • Live debugging, no answer yet. Q: "Is it fixed?" A: "Not sure yet. Error rate dropped after the rollback but I want ten clean minutes before I call it. I will not say fixed until the graph earns it."

Admitting you have not tested something

  • Reviewer asks about edge cases. Q: "Did you test the empty-cart case?" A: "I did not, good flag. I tested the happy path and one item. Let me add the empty and single-item cases before this merges."
  • Shipping with a known gap. Q: "Is the failover path tested?" A: "No, and I want to be clear about that. I unit-tested the logic but never actually killed the primary. I would call this untested under real failover until we run a game day."
  • You (author) volunteer the gap. Q: "Looks good, approving." A: "Before you do, heads up: I have not tested the concurrent-write path, only serial. If that matters for this endpoint, hold the approval and I will cover it."
  • Manager asks if it is safe to ship. Q: "Safe to push Friday?" A: "It passes the tests I wrote, but I have not exercised it under production traffic shape. I would rather ship Monday morning than Friday afternoon on an untested path."
  • Load not tested. Q: "Will the batch job finish in the window?" A: "On my 10k-row sample, yes. I have not run it against the full 4M, so I am extrapolating. Let me run the real size overnight before we trust the window."
  • Admitting a manual-only check. Q: "Is there a regression test for this bug?" A: "Not yet, I verified it by hand. I will add the automated test in this same PR so it does not come back silently."
  • Config path unverified. Q: "Does it read the new env var correctly in prod?" A: "Verified in staging, not prod. The configs differ enough that I would watch the first deploy closely rather than assume it carries over."

Framing a solution as a hypothesis, not a fact

  • Proposing a fix you are unsure of. Q: "What is causing the timeouts?" A: "Working theory, not a conclusion: I think the connection pool is too small for the new traffic. If I am right, bumping it from 10 to 50 clears it. Let me test that before we believe it."
  • Offering a direction, not a verdict. Q: "How should we cut the query time?" A: "My hypothesis is the missing index on user_id. I would try that first because it is cheap and reversible; if the plan does not change, we look at the join order next."
  • You (reviewer) frame a guess as a guess. Q: "Any idea why it is flaky?" A: "A guess, weight it lightly: the test shares a DB fixture, so ordering could bite. Worth a look, but I have not confirmed it, do not rewrite everything on my hunch."
  • Suggesting an experiment. Q: "Should we move to read replicas?" A: "I would frame it as an experiment. Route 10% of reads to a replica for a week and watch replication lag. If lag stays under a second, we expand; if not, we learned cheaply."
  • Naming your confidence level. Q: "Are you sure it is the cache?" A: "Maybe 60% sure. The timing lines up with the TTL, but I have not caught it in the act. Treat it as the lead suspect, not the convicted one."
  • Proposing a rollback as a probe. Q: "What is the plan for the error spike?" A: "Hypothesis: it is the deploy from 2pm. Fastest test is to roll back and watch. If errors drop, we confirmed it; if not, we ruled it out and look upstream."
  • Design as a bet, stated plainly. Q: "Will sharding fix the write contention?" A: "That is the bet, and I want to hold it loosely. Sharding by tenant should spread the hot rows, but if the hotness is one giant tenant, it will not. Can we check the distribution first?"

Admitting you are unfamiliar with part of the system

  • Asked to own an unknown area. Q: "Can you take the billing reconciliation module?" A: "I can, with a caveat: I have never been inside that module. Give me a day to map it, or pair me with whoever wrote it for the first ticket."
  • Paged for a system you do not know. Q: "You are on call, the notifications service is down." A: "I have never operated notifications, so I will be slow. First move: I am pulling in Dana who owns it while I read the runbook, so we are not relying on my blind spots."
  • You (the veteran) hand off a blind spot. Q: "You have been here longest, you must know the CDN config." A: "You would think, but no, that predates me and I have never touched it. Marta set it up; she is the one to ask before we change anything."
  • Honest about a legacy corner. Q: "Why does the export job double-encode?" A: "I genuinely do not know that corner of the code; it is older than my time here. Let me read the git blame and the original ticket before I answer, so I am not guessing at a load-bearing quirk."
  • Scoping your review honestly. Q: "Can you review the whole PR including the ML scoring?" A: "I can review the API and data layer well. The ML scoring is outside what I know, so I would flag that part for Ravi rather than rubber-stamp math I cannot judge."
  • New to the codebase. Q: "Where does the retry live for the webhook?" A: "I am two weeks in and have not found that path yet. Point me at the file and I will trace it; I would rather learn it than pretend I already know."
  • Admitting a gap while still helping. Q: "Is the Kafka consumer safe to restart?" A: "I do not know the consumer well enough to promise that. What I can do is check the offset-commit config with you, because that is what decides whether a restart replays or drops."
  • Owning the boundary of your map. Q: "Will your change affect the search indexer?" A: "Maybe, and I cannot see far enough into the indexer to be sure. I would rather ask the search team for a five-minute read than assume my change is clear. See Chapter 21."

Don't be confused: "I do not know" and "I have not tested it" are different admissions. The first is about knowledge you lack; the second is about evidence you have not gathered yet. Say which one it is, because the fix differs: one needs a person to ask, the other needs an hour to run something.

Don't be confused: Framing a fix as a hypothesis is not hedging or weakness. Hedging hides you from being wrong; a hypothesis invites the test that proves you wrong fast. State your confidence as a number or a suspect, name the experiment that would settle it, and you look more senior, not less.

👉 Owning a wrong opinion cleanly is the same muscle you use to give and take a code review without heat. On to Chapter 47.