Start hereWhy Google interviews feel different
Google is known for structured interviews: interviewers work from prepared questions and assess answers against agreed criteria, so candidates for the same role are compared on the same things. That’s good news. It means the interview is less about chemistry and more about whether you make the evidence easy to see.
It also means vague answers score badly. “I’m a strong communicator” gives the interviewer nothing to write down. A specific story — the problem, what you did, what changed — gives them evidence they can map to the criteria in front of them.
My twist on Google prep is simple: prepare for the interviewer’s notes, not for the conversation. After every answer, ask yourself what they could write down. If the honest answer is “not much”, the story needs a sharper problem, a clearer “I” or a real result.
01What Google says it wants to see
Google’s public advice to candidates can be summed up in ten habits. Each one is something you can prepare for:
Connect the role to your resume
Cross-reference the job description with your experience and build an example for each real overlap.
Prepare a broad example library
Expect many “Tell me about a time when…” and “How would you approach this situation…?” questions.
Focus on data
Say what you achieved, how it was measured and what you did to get there.
Show strategic thinking
Explain your assumptions, trade-offs and why you chose your approach.
Listen and clarify
Rephrasing a question, asking for clarification or pausing to think is acceptable.
Navigate ambiguity
Show how you make decisions without complete information.
Show how you work with people
Prepare examples with peers and cross-functional teams.
Demonstrate leadership
Influence, ownership, mentoring and mobilizing others count — not only formal management.
Prepare questions
Interviewing is a two-way process.
Be yourself
There’s no single profile Google hires for, so don’t try to perform one.
02Googleyness, decoded
“Googleyness” sounds vague, which makes candidates nervous. In practice, the questions in these interviews test a handful of behaviors that show up in how you tell your stories:
- Comfort with ambiguity — you move forward without waiting for perfect information, and you’re explicit about your assumptions.
- Bias to action, with judgment — you act, but you can explain why that action and not another.
- Collaboration — you work through disagreement with evidence, not rank or volume.
- Humility and learning — you can talk about feedback and mistakes without getting defensive.
- Doing the right thing — for users, for the team, and when nobody would have noticed.
Notice that the strong version ends with a lesson. That last line — what you learned or now do differently — is often the clearest Googleyness signal in the whole answer. Don’t skip it.
03PAR or SAR
I coach two structures for behavioral answers, and nothing more complicated: PAR — Problem, Action, Result as the default, and SAR — Situation, Action, Result when a story needs more context to make sense.
Why so lean? Long frameworks invite long setups. By the time a candidate has described the background, their role and their objectives, a minute has gone and they haven’t said anything the interviewer can score. PAR takes you straight to the problem, what you personally did and the measurable outcome — which matters even more if you’re interviewing in a second language.
Use SAR when the problem only makes sense with some background — a reorganization, a new market, an inherited system. Keep the situation to two sentences, then move to what you did.
Default: PAR
60–90 seconds. The problem, your actions, the result, one line of learning.
If they ask “tell me more”
Add the situation in two sentences — you’re now telling the SAR version.
If they dig into one point
Go deep on that decision: the options, the trade-off, what you’d do differently.
04Build every answer the same way
Use the same four parts for every behavioral answer. I call it PAR + L: the Learning line turns a good story into a Googleyness answer.
Problem · ~20%
What was wrong, difficult, ambiguous or at risk? Only the context needed to understand it.
Action · ~55%
What you did: your reasoning, decisions, trade-offs and who you brought in.
Result · ~15%
What changed — with numbers wherever they’re legitimate.
Learning · ~10%
One sentence: the principle you took away, or what you now do differently.
05Ten PAR examples
These examples are deliberately generic so you can see the shape of a strong answer. Don’t memorize them — rebuild each one with your own project, your own decisions and your own numbers. Under each, you’ll see what the answer signals and the follow-ups to expect.
A. Conflict with a colleague
“Tell me about a time you disagreed with a colleague.”
ProblemA colleague and I disagreed about how to build a feature. They wanted the fastest implementation; I was worried it would create maintenance and reliability problems later.
ActionInstead of arguing from preference, I wrote up both approaches side by side — effort, operational risk and expected future cost — and proposed a small test of the assumption we disagreed on. We reviewed the results together and agreed a hybrid that kept the delivery date and removed the main risk.
ResultWe shipped on schedule, avoided the reliability issue, and the comparison became a template the team reused for similar decisions.
LearningI turn disagreements into evidence-based decisions rather than personal debates.
Signals: collaboration, judgment, respect. Expect: “What if the test had proved you wrong?” · “How did your colleague react?”
B. Ambiguous requirements
“Tell me about a time you faced ambiguous requirements.”
ProblemThe desired outcome of a project was clear, but several requirements weren’t defined and different stakeholders were working from different assumptions.
ActionI separated what we knew from what we were assuming, identified the decisions that would materially change the build, and met the relevant stakeholders to resolve those first. Where a decision couldn’t be made yet, I proposed a low-risk option and wrote the assumption down so we could move forward without pretending the uncertainty wasn’t there.
ResultWe agreed a shared definition of success, reduced rework and delivered without waiting for every unknown to be resolved.
LearningName your assumptions out loud — it’s what lets a team move fast without being reckless.
Signals: comfort with ambiguity, structured thinking. Expect: “Which assumption turned out to be wrong?” · “Who pushed back?”
C. Critical feedback
“Tell me about a time you received critical feedback.”
ProblemMy manager told me my work was strong, but I went too deep into implementation detail when I updated senior stakeholders.
ActionI asked for specific examples, found the pattern behind them and changed how I structured updates: business impact first, then the decision needed, then the key risk — with technical detail only when asked. I asked for feedback again after the next few presentations.
ResultMy updates became shorter and more decision-oriented, and stakeholder meetings needed far fewer follow-up clarifications.
LearningTechnical completeness isn’t the same as effective communication — I adapt the detail to the audience.
Signals: humility, coachability. Expect: “Did you agree with the feedback at first?” · “How do you give feedback to others?”
D. Tight deadline
“Tell me about a time you had to deliver under a tight deadline.”
ProblemA project had a fixed external deadline, but the original scope was bigger than the time and people available.
ActionI split must-haves from lower-value work, identified the riskiest dependencies and aligned stakeholders on a smaller first release. I set checkpoints on the critical path and escalated the one dependency that could have blocked us early, instead of waiting until the deadline was close.
ResultWe delivered the critical functionality on time and moved the rest into a second phase.
LearningHitting a hard deadline takes active scope management, not asking the team to work faster.
Signals: prioritization, ownership. Expect: “What did you cut, and who disagreed?” · “What would you do if the escalation had failed?”
E. Production issue
“Tell me about a significant production issue.”
ProblemShortly after a release, a production issue started affecting users. The priority was to limit the impact while working out whether the release was really the cause.
ActionI helped isolate the failure with logs and monitoring, compared affected and unaffected paths, and found the change most strongly correlated with the incident. We mitigated the user impact first, then fixed the root cause and added a regression test and a monitoring check for that failure mode.
ResultUser impact was contained, the defect was fixed, and the new test and alert make a repeat much less likely.
LearningSeparate mitigation from root-cause analysis — don’t wait for a perfect diagnosis before you act.
Signals: calm under pressure, user focus. Expect: “How did you communicate during the incident?” · “What did the post-mortem change?”
F. Learning a new technology quickly
“Tell me about a time you had to learn a new technology quickly.”
ProblemI needed to contribute to a project built on a technology I’d never used, and the project couldn’t wait for a long ramp-up.
ActionI identified the minimum concepts I needed to be productive, worked through the official documentation and built an isolated proof of concept, then reviewed my approach with an experienced colleague before integrating anything into the real project.
ResultI became productive quickly without experimenting on production — and I now use the same method whenever I pick up something new.
LearningLearn the minimum that matters, validate it safely, then get an expert’s eyes on it.
Signals: learning agility, good judgment. Expect: “What did the expert change?” · “How do you stay current?”
G. Mentoring a teammate
“Tell me about a time you helped an underperforming teammate improve.”
ProblemA junior teammate kept missing estimates, and the initial assumption was that they just needed to work faster.
ActionI sat down with them to find where the work was actually getting stuck. The real issue was unfamiliarity with part of the system and uncertainty about when to ask for help. I paired with them on the first few tasks, made the escalation points explicit and reduced my support as their confidence grew.
ResultTheir delivery became predictable and they started working independently.
LearningDiagnose a performance problem before you prescribe the fix.
Signals: leadership without authority, empathy. Expect: “What if pairing hadn’t worked?” · “How did you involve their manager?”
H. Process improvement
“Tell me about a process you improved.”
ProblemA recurring workflow had unnecessary manual steps and produced different results depending on who ran it.
ActionI mapped the workflow, found the highest-friction steps, standardized the process and automated the repeatable part. I documented the new version and gathered feedback from the people who used it, rather than designing it in isolation.
ResultThe process took much less manual effort and produced consistent results.
LearningGood process work removes unnecessary steps — it doesn’t just document the existing inefficiency.
Signals: ownership, user focus. Expect: “How did you measure the improvement?” · “Who resisted the change?”
I. Changing priorities
“Tell me about a time your work was deprioritized midway through a project.”
ProblemA project I’d invested significant work in was deprioritized when a more urgent business need came up.
ActionI clarified the new priority, identified what could be preserved or reused, documented what was unfinished, and agreed with stakeholders what should stop and what should continue. I didn’t keep going just because we’d already invested time.
ResultThe team redirected its effort without losing the useful work we’d already done.
LearningTreat sunk effort as information, not as a reason to continue.
Signals: adaptability, business focus. Expect: “How did you feel about it?” · “Did any of the work come back later?”
J. Leadership without authority
“Tell me about a time you led without being the official leader.”
ProblemA project was losing momentum because several teams had different priorities and nobody formally owned the coordination.
ActionI built a shared view of the dependencies, clarified which decisions were blocking progress and brought the right people together around the highest-priority issues. I didn’t try to become the project’s manager — I created enough clarity for the existing owners to decide and move.
ResultThe project regained momentum, and the teams had a clear picture of dependencies and ownership.
LearningLeadership is often creating clarity and enabling others, not holding a title.
Signals: influence, emergent leadership. Expect: “Did anyone see it as overstepping?” · “What would you do differently?”
06The story matrix: 8–12 stories, 29 questions
You don’t need 29 answers. You need eight to twelve strong stories, each flexible enough to answer several questions. Here are the questions candidates hear most often in Googleyness and behavioral rounds, grouped by the story that answers them:
| Story to prepare | Questions it answers |
|---|---|
| Your biggest accomplishment | One of your biggest career accomplishments · A goal you set and achieved · A customer pain point you solved |
| A disagreement you resolved | A disagreement with a colleague or manager · A conflict with a colleague · A time your team disagreed with your idea · A difficult colleague |
| Working with your manager | When your manager set reasonable demands · A situation with unreasonable demands · A time you advocated for yourself or someone else |
| Critical feedback | Critical feedback you received · A time you misunderstood requirements |
| Delivery under pressure | A critical project under a tight deadline · A last-minute project change · How you manage multiple priorities · A challenging situation at work |
| Ambiguity and change | Ambiguous requirements · Your work being deprioritized |
| Alignment and cross-functional work | Getting people aligned around a decision · Working cross-functionally · How you incorporate different perspectives |
| A hard technical problem | A challenging technical problem · A significant production bug · How you ensure code quality |
| Learning fast | Learning a new technology quickly · How you stay current with industry trends |
| Growing others and improving how work gets done | Mentoring a junior team member · A process you improved · How you ensure accessibility |
Not in an engineering role? Replace the technical row with the hardest problem in your own field — a campaign that underperformed, a deal that nearly fell through, a data set nobody trusted.
07“How would you approach…?”
Situational questions have no single right answer. The interviewer is watching how you think. Walk through the same sequence out loud every time:
Clarify
Restate the question and ask one or two questions about the goal.
Define and assume
Define success, then state your assumptions and constraints.
Explore options
Give two or three approaches, not just the first one you thought of.
Decide and explain
Choose one and name the trade-off you’re accepting.
Measure and reassess
Say how you’d know it’s working and when you’d change course.
Example: “How would you approach a new internal tool that nobody is using?”
Clarify“Before I jump in — is the goal adoption in itself, or the outcome the tool was built for, like faster approvals?”
Assume“I’ll assume the goal is faster approvals and that the tool works technically. The constraint is that people already have a workaround they’re comfortable with.”
Options“I could mandate the tool, improve it, or find out first why people avoid it. Mandating it is fast but tends to create quiet workarounds.”
Decide“I’d start with five short interviews with current users of the workaround, fix the top one or two blockers, then relaunch with a single team. The trade-off is a slower start in exchange for real adoption.”
Measure“I’d track approval time and the share of approvals going through the tool, and revisit after four weeks.”
08Resume and project deep dives
Expect an interviewer to pick one project from your resume and keep asking “why?” until they reach the edge of what you know. Prepare every significant project against these seven questions:
- Context — what problem were you solving?
- Role — what exactly did you own?
- Decisions — why did you choose your approach?
- Alternatives — what else did you consider, and why not that?
- Challenges — what went wrong or proved difficult?
- Impact — what changed, ideally with numbers?
- Reflection — what would you do differently today?
09Language that shows your thinking
Google interviewers want to hear your reasoning, so the phrases that connect your thoughts matter as much as the story. If English isn’t your first language, these short phrases do a lot of work:
| When you need to… | Say |
|---|---|
| Buy time without panic | “Good question — let me take a moment to structure my answer.” |
| Clarify the question | “Just to make sure I answer the right question: do you mean… or…?” |
| Signpost a story | “The best example of that is a project where…” |
| State an assumption | “I’ll assume that… — tell me if that’s wrong.” |
| Explain a trade-off | “I chose A over B because… The cost was…, which I accepted because…” |
| Own your part | “The team delivered the project; my part was…” |
| Close with the learning | “What I took from that is…” / “Since then, I always…” |
And three habits to drop: hedging (“maybe we could potentially…”), apologizing for your English (“sorry, maybe I explained it badly”), and saying “we” for everything. For more on this, see the language section of my interview questions guide.
10A seven-day practice plan
Knowing the method isn’t the same as performing it under pressure. If your interview is a week away, this is how I’d use the time:
Day 1 · Map
Match every requirement in the job description to a story. List the gaps.
Day 2 · Build
Write eight to twelve stories in PAR + L, one line per part.
Day 3 · Numbers
Find the real metric behind every result, or a precise description of the change.
Day 4 · Out loud
Record each story, listen back, then tell it again. The second attempt is where it improves.
Day 5 · Hypotheticals
Practice three “How would you approach…?” questions with the five-step sequence.
Day 6 · Mock
A full mock interview with follow-ups, ideally with someone who will push back.
Day 7 · Rest
Light review of your matrix and your questions for them. Then stop.
11Interview-day checklist
- I’ve mapped the job description to my resume
- I have eight to twelve adaptable stories, and I know the metrics behind each
- I can tell each story in PAR in 60–90 seconds — and switch to SAR when it needs context
- I can explain my assumptions and trade-offs out loud
- I have stories for ambiguity, conflict, feedback, leadership, learning and failure
- I can survive three follow-ups on every project on my resume
- I have three thoughtful questions for the interviewer
- For a virtual interview: camera, microphone, Wi-Fi and workspace tested
- A notebook and pen are on the desk
- No search engines, AI tools or other outside help during the interview