The Team That Wouldn't Write Tests

“You joined a team with 3% test coverage. Two recent prod incidents from regressions. You have no authority. How do you change the culture?”

The Situation

You're a new Staff Android engineer joining a 6-person team. The culture is fast-moving and test-averse — 'QA catches it' is the prevailing attitude. The codebase has 3% unit test coverage. Two of the last four production incidents were regressions that a basic unit test would have caught. The EM is supportive in theory but has never enforced it.

Context

You have no direct authority — you're an IC at the same level as most of the team
Two engineers actively believe tests slow down shipping and will push back
The EM is under pressure to deliver a major feature in 6 weeks
One of the two recent incidents caused a customer escalation that reached the VP level
The team does not have a formal code review checklist or standards doc

The Question

“Tell me about a time you drove a significant change in your team's engineering culture or practices.”

Response Options

One of these is the strongest response. The others reflect common approaches with real trade-offs.

I led by example — wrote thorough tests for all my own code and hoped the rest of the team would follow when they saw the quality difference.

I brought it up in a team retrospective and proposed adding a team norm that all new code requires unit tests.

I escalated to the EM and asked them to enforce a test coverage requirement in code review as a team standard.

I picked one of the two production incidents as a case study, wrote the 3 unit tests that would have caught it, attached them to that PR as a demo, and proposed a low-bar team agreement: tests required for any new code touching data models or business logic. I got two engineers on board as champions before bringing it to retro.

The Debrief

Why the Best Response Works

Answer D works because it makes the argument concrete and irrefutable, then asks for the lowest possible bar. The incident-based demo removes opinion from the equation — three tests that would have prevented a VP escalation is a harder thing to argue against than 'testing is good practice.' Pre-building the coalition means the retro proposal already has visible support.

What to Avoid

Proposing standards without proof and without champions. In a test-averse culture, a rule proposed in a retro becomes a debate. A rule backed by an incident case study and two pre-aligned engineers becomes a norm. The order of operations matters enormously.

What the Interviewer Is Probing

The interviewer is measuring influence without authority — the defining Staff-level skill. Can you drive cultural change at the peer level? The best answers show a clear theory of change: build the proof, reduce the ask, sequence the stakeholders.

SOAR Structure

**Situation:** 6-person team, 3% test coverage, two prod regressions in 4 months. **Obstacle:** No authority, skeptical teammates, EM under feature pressure. **Action:** Case-studied one incident, wrote the 3 tests that would have caught it, pre-aligned 2 teammates, proposed minimal bar in retro. **Result:** Team adopted the lightweight standard; coverage reached 28% in 3 months; no regressions in the following 2 quarters.

The Learning Arc

"This taught me that culture change requires a proof-of-concept, not a proposal. The moment I stopped saying 'we should write tests' and started showing 'here are the 3 tests that would have prevented that VP escalation,' the conversation changed completely. I now apply this framework to every engineering practice I want to introduce: incident → demo → low bar → coalition → proposal."

IC Level Calibration

senior

Write tests yourself, document why, and advocate for it in code review. Be the example and the voice. Offer to help teammates write their first tests.

staff · Primary Target

Use incident data to make the cost of no-tests visible. Build a coalition of 2 engineers before the broader proposal. Set a minimal bar (not 100% coverage — just data models and business logic). Make it easier to write tests than to skip them.

principal

The 3-test postmortem becomes a company template. You advocate for testing standards to be embedded in the engineering onboarding program and the definition of 'done' for all teams. You measure impact across quarters, not sprints.

Company Calibration

Amazon

LP: Insist on the Highest Standards + Hire and Develop the Best