0Tell Me About a Time You Influenced a Decision Without Having Direct Authority - Google STAR Walkthrough
In this story, the candidate demonstrates key Googleyness by self-initiating a fix outside their team, explicitly stating scope boundaries, and using 'I' statements to highlight individual ownership. They quantify impact with a drop rate reduction and revenue recovery, and reflect on organizational gaps in cross-team reliability. The candidate also shows how they built trust and overcame resistance, essential for influencing without authority. These elements together create a compelling narrative aligned with Google's collaboration values.
Keep the situation concise and focused on the problem and its business impact. Avoid deep system architecture details that lose interviewer interest.
Spending 90 seconds on system architecture before reaching the problem - interviewer loses interest.
Explicitly state the scope boundary to prove ownership was self-initiated and cross-team.
Jumping to investigation without stating scope boundary; ownership proof is absent.
Use 'I' for every sentence to highlight individual contribution. Avoid 'we' to prevent obscuring ownership.
Using 'we' language like 'we figured out the root cause' makes individual contribution invisible.
Include metric delta, business impact, and second-order effect to demonstrate full impact.
Ending with 'things got better and team was happy' - no quantification or lasting impact.
Provide specific, story-related insights rather than generic lessons like 'communication is important.'
Generic reflection such as 'I learned communication is important' that tells nothing specific.
"I did escalate it - I sent them a Slack message and they handled it."
Sending Slack = routing responsibility, not ownership; confirms handoff rather than influence.
I flagged the issue to their tech lead for visibility but brought a complete fix and data-backed analysis. I addressed their concerns patiently, which built trust and led to acceptance without formal authority.
"They were busy, so I just waited until they fixed it."
Passive approach shows lack of initiative and influence.
I encountered initial resistance as the Platform team prioritized their sprint. I overcame this by presenting clear data on business impact and proposing a low-effort fix, which helped align priorities.
"Because I thought it might help catch errors."
Vague rationale lacks business or technical justification.
I added the dead letter queue alert to provide early detection of webhook failures, preventing silent drops and enabling faster response, which improved overall system reliability.
"I would just tell the team to fix it immediately."
Shows lack of collaboration and respect for team autonomy.
Even with authority, I would still prioritize building trust and presenting data to ensure sustainable collaboration and ownership rather than just issuing directives.
- No explicit scope boundary or ownership proof
- Uses 'we' or passive language implicitly
- No quantification of impact
- No demonstration of influence or overcoming resistance
- Generic and vague result
Lead with how I built trust and aligned cross-team priorities to deliver impact.
Interpersonal skills, overcoming resistance, and partnership.
Technical details of the fix.
Focus on self-initiated investigation and rapid prototyping of the fix.
Proactive ownership and speed of execution.
Lengthy negotiation or approval processes.
Highlight how the fix improved payment confirmation reliability and customer experience.
Business impact and customer benefit.
Internal team dynamics.
Focus on technical steps taken to identify and fix the issue. Mention that it was not my team and no ticket existed. Keep reflection technical, e.g., learning to reproduce failures locally.
Add organizational thinking about cross-team SLO gaps and trade-offs in proposing fixes. Articulate how I balanced technical and interpersonal challenges.