# Bar Raiser: Architecture Depth, Technical Influence & Ownership This is a senior-level Bar Raiser interview that blends behavioral signal with architectural depth. The interviewer wants evidence that you can design and own complex systems, navigate disagreement to drive shared technical standards, and embody company values like Customer Obsession and Ownership with concrete, first-hand stories. Answer each part from your real experience using specific situations, actions, and measurable outcomes. ### Constraints & Assumptions - Senior IC bar: the interviewer is calibrating whether you operate at the level of a technical leader, not just a strong implementer. - Stories should be **first-person and specific** — "I decided / I drove," with real numbers, not "we generally do." - Each answer should fit in roughly **4–6 minutes** of spoken time, leaving room for follow-ups. - The architecture story should be one **you personally led or co-led**, recent enough that you remember the trade-offs in detail. ### Clarifying Questions to Ask - Would you like the architecture example to emphasize the design decisions and trade-offs, or the delivery/operational outcome? - Should I pick a project where I was the primary decision-maker, or one where I drove alignment across multiple teams? - For the values question, do you prefer an example focused on an individual customer/user, or on a systemic improvement that helped many users? - How much depth do you want on the technical specifics versus the leadership/collaboration aspects? ### Part 1 — A complex architecture you designed (choices & trade-offs) Describe a complex system architecture you designed or led. Explain the problem and constraints, the key technical choices you made, the **alternatives you rejected and why**, and how the design performed against its goals. ```hint Structure Use STAR (Situation, Task, Action, Result) and anchor the whole story on the **central trade-off** — the one hard decision where reasonable engineers could disagree (e.g., consistency vs. availability, build vs. buy, monolith vs. services). That tension is the signal the interviewer is mining for. ``` ```hint Make it senior Quantify both the constraint and the outcome (scale, latency, cost, reliability), and name at least one thing you'd do differently in hindsight — owning the imperfections reads as more senior than a flawless story. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 2 — Driving through technical disagreement & setting standards Tell me about a time you faced a significant technical disagreement on your team, and how you resolved it. Then describe how you have driven the adoption of a technical standard or best practice across people who didn't initially agree. ```hint Where the signal is Show you separate *being right* from *building alignment*. The strong version includes a moment you changed your own position on new data, and a mechanism (RFC/design review, prototype/bake-off, metrics) you used to make the decision objective rather than political. ``` #### Clarifying Questions for this Part - Are you more interested in a disagreement with a peer, or one where I had to influence without authority (across teams or with senior stakeholders)? #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 3 — Customer Obsession or Ownership in action Share a specific example that demonstrates **Customer Obsession** or **Ownership**: a time you went beyond your assigned scope to protect the user experience or to take responsibility for an outcome no one explicitly asked you to own. ```hint Framing Pick a story where the customer/user impact is concrete and where you owned something *outside* your formal responsibility — the gap between "my ticket" and "what the user needed" is exactly where this value lives. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - In your Part 1 architecture, what was the single biggest risk you under-estimated, and how did it surface in production? - In Part 2, was there a case where you disagreed-and-committed to a decision you still thought was wrong? How did that turn out, and would you do it again? - For your Part 3 story, how did you balance the extra ownership you took on against your other committed deliverables — did anything else slip? - Describe a time a major architectural decision of yours turned out to be wrong. How did you discover it, and how did you walk it back?