Preparing for Googleyness and Leadership

In March my preparation document for Google’s behavioral round had a rule in bold: never say “I single-handedly.” Google is collaborative, it said, so frame every story around the team. “We faced X, we built Y, we achieved Z.”

By June, more research had turned up the opposite risk. A story told entirely in “we” gives the hiring committee nothing to grade, because it cannot tell what you did. The fix was not to go back to “I single-handedly” but something more precise: “we” for the context, and a sharp “I” for the specific decision or insight that was mine. Every one of my eight stories had to be rewritten around that distinction.

This post describes how I prepared for the Googleyness and Leadership (G&L) round: a story bank in a conclusion-first structure, the we-versus-I correction, drills on the facts inside the stories, a separate practice track for rapid-fire hypotheticals, and mock interviews in two very different styles. It is part 11 of the 35 companies, 8 offers series. As with every Google post in the series, I do not describe the questions from the real round.

For context, G&L was one 45-minute online round in my Google Software Engineer III loop, held on July 15. My stories came from three places: ranking and personalization at Cars24, a founding engineer role at KotiLabs building an agentic trading platform, and earlier work at 6sense.

The short version:

• Stories: 8 fully written, each with its metric in the second sentence
• Question bank: 95 questions from about 100 sources, later audited to 107 with eight fixes
• My baseline in March: story content rated 4.5 out of 5, delivery 2.5 out of 5
• Outcome: Strong Hire, one level above my coach’s read after the round

Background: what the round grades#

My prep notes broke the round into four dimensions: structured thinking (data-driven reasoning and comfort with ambiguity), leadership without authority (moving people and outcomes without a title), cultural fit (intellectual humility, honesty about failure, a learning orientation), and collaboration (handling disagreement and feedback).

The questions come in two shapes. Google’s own guide to structured interviewing describes behavioral questions, which ask you to describe prior achievements and reveal patterns of behavior, and hypothetical questions, which present a job-related situation and show how you would respond to something new. Recent candidate reports also described a rapid-fire format: several short hypotheticals in a row, each expecting about a minute.

My March baseline made the risk clear. My story content was strong: real problems, real numbers, real decisions. My delivery was weak in three specific ways.

Conclusions buried. I spent a minute on context before saying what happened.

Metrics disappeared under pressure. In an earlier live call, asked about my proudest work, I described it without a single number.

The framing was wrong for the room. I drifted between solo heroics and an undifferentiated “we.”

Better stories do not fix delivery. Only spoken practice with the same structure every time does.

The preparation architecture#

The preparation had five parts, built in order and then cycled through mocks.

graph LR
    A["Research:<br/>~100 sources"] --> B[("Question bank")]
    C["My real work"] --> D[("Story bank:<br/>8 stories")]
    B --> E["Question to<br/>story map"]
    D --> E
    D --> F["Metric drills"]
    E --> G["Mocks: adversarial,<br/>polite, full"]
    F --> G
    H["Hypotheticals:<br/>60-second format"] --> G
    G --> I["Revise stories"]
    I --> D

    class A,C gray
    class B,D blue
    class E,F,H violet
    class G amber
    class I green

The question bank came from a research pass over about 100 public sources, producing 95 questions. In July I audited it against fresh reports, which brought it to 107 questions and produced eight action items.

The question-to-story map linked each common question to the one or two stories that answered it best. Its job was to stop me improvising under pressure. It also exposed a real failure: in mocks I sometimes reached for a secondary story when the primary one fit better.

Eight stories, conclusion first#

Every story followed the same four-part structure, which I called CCAR: conclusion, context, action, result. It is STAR with the result moved to the front. The interviewer knows what happened before hearing the setup, and a story that runs out of time still contains its point.

The target was 90 to 120 seconds per story. If a story ran long, the action section got cut, never the conclusion or the result. Later I added a fifth beat, learning: what I would do differently, which is often the most Googley part of an answer.

The opening of my strongest story shows the shape:

We increased personalization coverage from 65% to 100% for over a million monthly users, the 35% the business had considered impossible to personalize. At Cars24, the recommendation system needed several clicks to build a profile, so users in their first session got a generic feed. I found that those users still left signals in search queries and filters, and proposed using them as implicit preferences. The result was a 150% lift in Click Recall@50.

The eight stories covered every dimension between them. A few examples of what they were about:

Challenging the default. At KotiLabs, the default for an agentic system was to let the LLM generate code for execution. In a system handling real money, I pushed for a week of design first, and drove a model where the LLM emitted a typed instruction format over a closed set of operations, checked by a policy engine before anything ran. That safety design became a selling point with our first regulated customer.

A failure with a real lesson. The same instruction format later suffered scope creep, growing to 50 indicators and 15 operators. That story was built around what went wrong and what I changed, not around a disguised strength.

Doing the unglamorous thing well. In one role I migrated nine production models off a legacy analytics stack using a shadow period, per-model sensitivity checks and a staged rollout. A dry run on one model caught three faulty queries that would have caused silent failures, and the migration finished with zero downtime.

Mentoring. My first mentoring story was too generic and failed in a mock. I rebuilt it from specific events and conversations, which is the only version that survives follow-up questions.

The we-versus-I correction#

The correction described at the top of this post changed every story, and it is the most transferable lesson from this round.

The rule: use “we” to set the collaborative context, then attach your own name to the specific decision, insight or piece of work that was yours. A hiring committee reads the interviewer’s notes, and the notes need a sentence that starts with your contribution.

A related shift came from the same research: what the interviewer grades is how you behave during the round (how you handle a hint, pushback or being stuck), not what you say about your values. “I value collaboration” scores little. Treating the interviewer’s follow-up as useful information, in real time, scores much more.

The facts inside the stories#

Delivery drills found a problem I had not expected: I kept getting facts about my own work wrong.

In metric drills across late June, I said “false negatives” when the result I meant was about false positives. I gave a paper’s accuracy as 70% when it was 79%. I could not recall a click-per-car lift (7%, from 1.2 to 1.28). In one story I used “prompt injection” for a different technique entirely, mixed up a CEO and a CTO, and gave a count of 15 for something that was 50. Several of these errors repeated across days.

Two decisions came out of that.

Separate structure from facts. During story drills I told the coach to grade structure only, not factual fidelity, so I could practice delivery without stopping. Facts went into a separate metric bank, drilled cold on their own.

Do not volunteer what is not locked. Some claims I had used informally (very high accuracy figures, absolute statements about hallucinations) were not in my verified metric bank. I decided never to volunteer them. In a round where every sentence goes into notes, one unverifiable claim can cost more than a strong story earns.

Hypotheticals and mocks#

Rapid-fire hypotheticals are a different skill from stories, and I practiced them separately. The format I settled on had three beats in about 60 seconds: state my approach in one sentence, give one concrete action, state the expected outcome. For a question like “how would you handle someone on your team missing a deadline,” the answer began with the approach (understand before acting), named the action (a direct one-to-one that day, asking what got in the way) and ended with the outcome (the team trusts that deadlines are real and that problems get handled directly).

Mocks then tested everything together, in three styles.

An adversarial interviewer pushed back on every answer. Four answers passed with a small correction; one (“why you”) needed a full revision.

A polite interviewer gave no resistance at all, which turned out to be harder in a different way: one clean pass and four small corrections, mostly where I filled silence with extra context.

A full mock right before the round covered the whole arc. Four answers passed with corrections (introduction, disagreement, failure, ambiguity); three needed revision (a stakeholder story, the mentoring story and “why Google”).

The mocks also found a structural gap. In hypotheticals I asked zero clarifying questions; I answered whatever scenario I imagined rather than the one asked. Two days before the round, this went to the top of the fix list.

Results#

The round came back Strong Hire.

Without describing the questions, the answers that landed best were the ones grounded in specific events with numbers. On one hypothetical I asked a clarifying question before answering and proposed an approach the interviewer engaged with, which was the exact habit my mocks had flagged as missing two days earlier. The interviewer was relaxed and conversational throughout, with no pushback.

My coach’s read after the round was a Hire, not Strong Hire, because no single answer seemed to show work above level. I also corrected two points in its debrief: a job title it flagged as a slip matched the resume I had submitted, and a metric-attribution risk it raised did not apply because the interviewer did not have my resume open. The actual result was one level above its read.

What I’d do differently#

Get the we-versus-I rule right first. I wrote eight stories with blanket “we” framing and then rewrote all of them. Starting with “we for context, I for contribution” would have saved a full rewrite.

Build the metric bank before the stories. Most of my factual errors were about numbers I had produced myself. A verified sheet of every number, written first, would have made every story drill a delivery drill.

Practice hypotheticals from day one. I treated them as a minor format until mocks showed I skipped clarifying questions entirely. They are half the round.

Use real events for every story. The mentoring story failed until it was rebuilt from specific conversations. Every story should start from what happened, not from what the question wants to hear.

Conclusion#

The Googleyness and Leadership round grades how clearly you can show what you did and how you think, in real time, with someone writing notes. Strong content is necessary and not sufficient. What moved me from a delivery rating of 2.5 to a Strong Hire was structure (conclusion first), attribution (“we” for context, “I” for my contribution), facts drilled cold, and enough spoken practice that the structure held under pressure.

Put the result in the first sentence, put your name on your decision, and know your own numbers better than anyone in the room.

Part 11 of the 35 companies, 8 offers series. I join Google as a Software Engineer III, AI/ML, in October 2026.