Googleynessとは？Google行動面接の質問と対策（2026）

「Googleyness」とは、Googleが面接でカルチャーフィットを見るときに使う行動特性の総称です — 曖昧な状況への対処、フィードバックの受け止め方、壊れた仕組みの改善、ユーザーを守る姿勢などが対象になります。このガイドは、Googleの選考に臨むソフトウェアエンジニアやその周辺職種の候補者向けです。つかみどころのないカルチャーの言葉を、実際に準備できる評価基準に落とし込みます。面接官が評価する4つの軸、それぞれの良いシグナルと悪いシグナル、良い回答と悪い回答を比べた例つきの回答構成、よく出る質問、7日間の準備計画を紹介します。順番に進めてください。まず評価基準を理解し、次に回答の型を身につけ、最後にエピソードをそろえて練習します。

重要ポイント

• Googleynessは行動面接の評価基準であり、性格診断ではありません。評価されるのは4つ、つまり曖昧さの中で成果を出す力、フィードバックを受け止める姿勢、現状に挑む姿勢、ユーザーを第一に考える姿勢です。
• このラウンドは通常、独立して採点される面接で、Leadership and Rapport と呼ばれることが多いです。コーディングの出来が良くても、行動面接ではっきりした問題点が出れば補えません。
• STAR-L（Situation、Task、Action、Result、Learnings）を使いましょう。Googleの面接官はActionを最も深く掘り下げるため、そこで述べる内容には必ず具体的な裏付けが必要です。
• 浅い話を20個用意するより、深く使い回せるエピソードを6〜8個用意しましょう。各エピソードを複数の評価軸に対応させておくと、その場で切り替えられます。
• 自分の行動には「私」、チームの成果には「私たち」を使いましょう。担当範囲があいまいな話し方は、技術力のある候補者がこのラウンドで低く評価される最も多い理由の一つです。

Googleynessが実際に測っているもの

質問の練習に入る前に、この言葉が何を指しているのかを知っておきましょう。世間で思われている意味は誤解だからです。

Googleynessは、個性的であることや外向的であること、チームと似た人であることではありません。仕事での行動の特性をまとめた呼び方です。問題の形が定まっていないときにどう動くか、同僚に設計ドキュメントを厳しく批判されたときにどう反応するか、誰からも頼まれていないことを直すか、締め切りと品質がぶつかったときに誰の利益を重く見るか、といったことを指します。検索するときに「Googliness」や「Googlyness」と書く候補者もいて、リクルーターもこれらを同じ意味で使っています。

準備の仕方を決める構造上の事実が2つあります。

1. 通常は単独で採点されます。 行動面接では、コーディングやデザインの評価と並んで、あなたの選考資料に入るシグナルが作られます。最後にある気軽な雑談ではありません。
2. ほかのすべてのラウンドにも影響します。 コーディング面接官のヒントをどう受け取るか、データモデルに疑問を投げられたときにどう答えるか、リクルーターにどう接するか。これらはすべて観察されている行動です。選考全体が評価の対象だと考えましょう。

考え方を変えると役に立ちます。面接官が聞きたいのは「この人は感じがいいか」ではありません。「この人が加わると、自分のチームのスピードと品質はどうなるか」です。話すエピソードはすべて、この2つ目の問いに答えるものにしましょう。

ミニ事例： 2人の候補者が同じ進捗報告をします。「移行はほぼ終わっていて、エッジケースが少し残っているだけです」。候補者Aはそこで話を終えて次に進みます。候補者Bはこう続けます。「エッジケースは、IDの形式が壊れたレガシーアカウント3件です。チケットを起こし、修正前に切り替えるとダッシュボードが壊れる2つのチームにも知らせました」。どちらも面接の場では感じよく見えます。しかしGoogleyだと評価されるのは候補者Bだけです。2つ目の話し方は「好感が持てるか」だけでなく、「自分のチームのスピードと品質はどうなるか」に答えているからです。

Googleynessの4つの評価軸

枠組みが分かったところで、評価基準そのものを軸ごとに見ていきます。それぞれで候補者が最もよくする間違いも紹介します。

1. 曖昧さの中で成果を出す力

内容： 仕様も担当者も完了の定義もない状態で渡された問題を、前に進める力です。

面接官が重視する理由： Googleの規模では、価値の高い問題の多くは最初から範囲が決まっていません。指示がないと止まってしまうエンジニアは、ときどき間違ったものを素早く作っても修正できるエンジニアよりも、チームにとって高くつきます。

示し方： 混沌とした状況に、あなたがどんな構造を与えたかを説明しましょう。誰と話したか、どのデータを取ったか、何かを学ぶために出せた最小のものは何か、途中で要件が変わったときにどう対応したか、を話します。

よくある間違い： 回答の大半を、プロジェクトの範囲がいかに決まっていなかったかの説明に使ってしまうことです。曖昧さへの不満は、曖昧さが苦手だという印象を与えます。

回答の出だしの例： 「回線の遅いユーザーのチェックアウトの遅延を減らすよう言われましたが、目標値も担当者もありませんでした。まず、接続の種類別に分けた1週間分のクライアント側の計測データを取りました。p90を支配していたのはペイロードの大きさではなく、ブロッキングする設定取得が1つあることだと分かりました。これで、議論の土台になる具体的な目標ができました。」

2. フィードバックを受け止める姿勢（知的な謙虚さ）

内容： 自分自身と自分の成果物を切り離し、設計への批判を攻撃ではなく情報として受け取ることです。

面接官が重視する理由： Googleのエンジニアリング文化は、コードレビューと、オープンに議論される設計ドキュメントで回っています。防御的なエンジニアはレビューのたびに時間をかけさせ、本当の問題を指摘しようとする人の意欲もそっと削いでしまいます。

示し方： 誰かの意見で考えが変わった話をし、相手が何と言い、自分が何を変えたかを具体的に述べましょう。耳の痛い指摘や、自分より経験の浅い人からの指摘であれば、さらに評価されます。

よくある間違い： 自分は同意できず、結果的に自分が正しかったと証明できたフィードバックを選ぶことです。それは謙虚さではなく、自分が正しかった話です。

回答の一部の例： 「チームの新卒メンバーから、私のキャッシュ層では権限が取り消された後も最大5分間、古い権限を返してしまうと指摘されました。最初は、その程度なら許容範囲だと思いました。しかし少し考えて、自分は性能の面でしか考えておらず、セキュリティの面を見ていなかったと気づきました。そこで、権限の書き込み時に明示的な無効化を追加しました。」

3. 現状に挑む姿勢

内容： 壊れていたり遅かったりするものに気づき、指示されなくても、担当外の領域であっても直すことです。

面接官が重視する理由： これはオーナーシップのシグナルです。チケットを片づけるエンジニアと、周りの全員の水準を引き上げるエンジニアを分けるものです。

示し方： 取り除いた具体的な非効率を選び、手を付ける前にそれがどれだけのコストだったかを数字で示しましょう。チームをまたぐ調整が入ると、話はより強くなります。自分の指揮系統の外でより高い基準を求めるのは、難しい形だからです。

よくある間違い： 反抗のように語ることです。「古いシステムはひどかった」という言い方は印象が悪くなります。現状に反対する前に、なぜ今の状態になっているのかを理解していたことを示しましょう。

回答の一部の例： 「結合テストの実行に時間がかかりすぎて、みんながマージを1日の終わりにまとめるようになり、失敗の原因を特定しにくくなっていました。担当者はいませんでした。私がテストスイートのプロファイルを取ると、数件のテストが毎回フィクスチャ全体を再投入していると分かりました。そこで、トランザクション単位で共有するフィクスチャを使うように書き直しました。マージは再び随時行われるようになりました。」

4. 正しいことをする姿勢（ユーザーを第一に考える）

内容： 長期的なユーザーの信頼、アクセシビリティ、プライバシー、安全性を、短期的な納期のプレッシャーと比べて考え、両者が衝突したときに声を上げることです。

面接官が重視する理由： Googleの規模のプロダクトは、1つのチームがスプリントの中からは見えない影響を持ちます。ほかの誰かが気づくだろうと考えず、自分から懸念を挙げるエンジニアを求めています。

示し方： ビジネス上の目標とユーザーの利益がぶつかった場面を見つけ、ユーザーを無視した場合のコストを具体的に示した話をしましょう。「間違っていると主張しました」では弱くなります。「スクリーンリーダーを使うユーザーでは、このフローが完全に失敗し、それはサインアップの N% でした」と言えれば強くなります — 実際に話すときは、自分の本当の数字に置き換えてください。

よくある間違い： 本当の対立がない例を選ぶことです。誰もあなたに反対しなかったのなら、あなたは何も主張していません。

回答の一部の例： 「新しい共有設定は、実験でエンゲージメントが上がったので、初期状態をオンにする計画でした。私は、この設定が、ユーザーが『デフォルトで非公開』を前提に入力したデータを公開してしまうと指摘しました。結果的に、初期状態はオフにして確認のプロンプトを出す形でリリースしました。既存ユーザーが黙ってオプトインされることがないよう、移行の説明文も私が書きました。」

良いシグナルと悪いシグナル

先ほどの4つの評価軸は、一貫した見極めのポイントで採点されます。ここでは、強い採用推奨と見なされる行動と、不合格と見なされる行動を比べます。

パターンは一貫しています。オーナーシップ、根拠、手柄を分かち合うことはGoogleyだと評価されます。責任転嫁、エゴ、データよりも意見を優先することは、問題点と見なされます。

Googleの行動面接の質問への答え方

シグナルを知っていても、話し方がそれを埋もれさせてしまっては意味がありません。次は、シグナルが自然に伝わる回答の構成です。

使う構成は STAR-L です。Situation、Task、Action、Result、そして Learnings（学び）の5つです。最後のLがGoogleでは重要です。面接官は、経験が起きたという事実だけでなく、それによってあなたの仕事のやり方が変わった証拠を求めているからです。基本の方法をまず復習したい場合は、PracHubのFAANGの例つきSTAR法ガイドをご覧ください。

時間配分は意識的に決めましょう。

深掘りの質問が入る前に、全体を3分以内で話し切ることを目標にしましょう。面接官がいちばん深く掘るのはActionだと考えてください。「PMを説得してロードマップを変えさせました」と言えば、次の質問はほぼ確実に「どんなデータを示し、相手はどう反論しましたか」です。あいまいな話はその圧力で崩れますが、具体的な話は掘られるほど強くなります。

Googleの採用チームは、リーダーシップと行動面接のラウンドで候補者をどう指導しているかについて、動画でガイダンスを公開しています。

実践例：同じ話の悪い回答と良い回答

以下の2つは同じ出来事を説明しています。評価されるのは2つ目だけです。

悪い回答（回答例）： 「サービスが何度も落ちていたので、リトライの処理を書き直したら良くなりました。チームも喜んでくれました。」

良い回答（回答例）： 「Situation： 決済サービスで、下流のタイムアウトが連鎖して、週に2回ほどオンコールが呼び出されていましたが、そのアラートの担当者はいませんでした。Task： 自分の担当範囲の外でしたが、私が引き受けました。Action： 1か月分のトレースデータを取り、バックオフのないリトライ経路が1つあり、部分的な障害のときに負荷を増幅させていることを突き止めました。ジッターつきの指数バックオフを提案する短い設計ドキュメントを書きました。シニアエンジニアから、これだと本当の問題である上流の不具合を隠してしまうのではないかと反対されました。もっともな指摘だったので、上流の障害を隠さずに別に表示するダッシュボードを追加しました。フィーチャーフラグの裏でリリースし、段階的にロールアウトしました。Result： その連鎖によるオンコールの呼び出しは止まり、新しいダッシュボードは、その後の数週間で上流のリグレッションを2件見つけました。Learnings： 今はコードを変更する前に、まずオブザーバビリティに手を付けます。このフィードバックで、「症状を直す」という考え方が「障害を見えるようにする」に変わったからです。」

良い回答が、評価軸の名前を一度も出さずに何をしているかに注目してください。担当者のいない問題を引き受け（現状に挑む姿勢）、批判を受け入れて設計を変え（フィードバックを受け止める姿勢）、直感ではなくトレースデータを使い（問題解決）、アプローチの本当の変化で締めくくっています（学び）。これが、口で言うのではなく行動で示すGoogleynessです。

Googleynessのよく出る面接の質問

型が決まったところで、Googleの行動面接で繰り返し出る質問のタイプを、それぞれが測る評価軸と一緒に見ていきます。他社も含めて同じパターンを練習したい場合は、PracHubの問題集で、ほかの評価基準に対しても練習できます。

以下の7番から12番の質問は、PracHub上のGoogle候補者自身の面接レポートに基づいています。オンサイトやテクニカルスクリーンの選考後に投稿されたものです。同じ4つの評価軸に対応していますが、言い回しは面接官が実際にその場で言った内容に近いものです。報告されたGoogleの行動面接の質問をすべて見ることもできます。

1. 「要件がまったく不明確な問題を解決した経験を教えてください。」

測る軸： 曖昧さの中で成果を出す力。

答え方： 見つけた混乱ではなく、自分が与えた構造から話し始めましょう。関係者を洗い出し、足りなかったデータを自分で取りに行ったこと、役に立つ最小の範囲を提案したこと、そして改善を繰り返したことを述べます。

切り口の例： 成功基準が決まっていなかった移行で、測定可能な3つの基準を自分が提案して合意を得た話。

2. 「本番環境やチームに影響した大きなミスについて教えてください。」

測る軸： 知的な謙虚さ、フィードバックを受け止める姿勢。

答え方： 長所を言い換えただけの話ではなく、実際に影響が出た本当のミスを選びましょう。ミスの説明には少しだけ時間を使い、回答の大半を、根本原因、責任追及をしないポストモーテム、そして1件の失敗ではなく同じ種類の失敗をなくす具体的な防止策に使います。

切り口の例： リージョン全体を止めた設定変更で、対策は「もっと気をつける」ではなく、デプロイパイプラインに検証のゲートを入れたこと。

3. 「テックリードやマネージャーと強く意見が対立した経験を説明してください。」

測る軸： 現状に挑む姿勢、協働。

答え方： 反対意見が根拠に基づいていたこと、そして敬意をもって伝えたことを示し、決定の後に何が起きたかを話しましょう。自分の意見が通らなかった判断に全力で取り組んだ話は、多くの候補者が飛ばす部分です。そして、そこがグリーンフラッグとレッドフラッグを分けます。

切り口の例： 別のストレージエンジンを主張して負けたが、選ばれた方を安全に運用できるようにするベンチマークの仕組みを書いた話。

4. 「自分の担当外の非効率なプロセスを改善した経験を教えてください。」

測る軸： 現状に挑む姿勢、オーナーシップ。

答え方： 直す前に、それが組織にどれだけのコストをかけていたかを示しましょう。社内ツール、足りないドキュメント、不安定なテストスイート、数週間かかるオンボーディングなどはどれも使えます。改善前の状態を具体的に説明できることが条件です。

切り口の例： 誰も信用していなかったランブックを、2回分のオンコール当番に同行して観察した後で書き直した話。

5. 「ユーザーにとって正しくないという理由で、機能に反対した経験を説明してください。」

測る軸： 正しいことをする姿勢、ユーザー第一。

答え方： ビジネス上の目標とユーザーの利益の間にある本物の対立を見つけ、長期的なコストを、ほかの人が比較できるほど具体的に示した方法を話しましょう。

切り口の例： コンバージョンの指標を上げたが、権限の許可を断ったユーザーを行き詰まらせてしまったオンボーディングのステップ。

6. 「誰かのオンボーディングやメンタリングをした経験を教えてください。」

測る軸： 協働、自発的に発揮するリーダーシップ。

答え方： 成功は自分の成果ではなく、相手がどれだけ自立したかで測りましょう。最初の説明が伝わらなかったときに説明をどう変えたかを話します。この細部が、単なる仕事の割り振りではなく、本当のメンタリングだったことを示します。

切り口の例： 入社6週間で初めて自分で設計ドキュメントを出したチームメイトと、そこに至るために自分があえてやめたこと。

7. 「要件がまだ曖昧なプロジェクトを率いた経験を教えてください。」

測る軸： 曖昧さの中で成果を出す力、自発的に発揮するリーダーシップ。

答え方： これは自分のメモの取り方ではなく、人についての質問です。答えが出る前に、チームが向かう先をどう与えたかを示しましょう。たとえば、書面にした仮説、未解決の問いごとの決定担当者、前提を確認するか捨てるかを決める期日などです。チームが止まらないように、あえて決めずに残したことも述べてください。

切り口の例： 最善の推測に基づく絞り込んだv0をリリースし、チームが議論していた2つの要件を実際の利用状況で決着させたプロジェクト — PracHub上のGoogle候補者が報告したものです：質問を見る。

8. 「厳しいフィードバックを受けた経験を教えてください。どう対応しましたか。」

測る軸： フィードバックを受け止める姿勢、知的な謙虚さ。

答え方： 後から振り返ってフィードバックが妥当だったように語りたくなる気持ちを抑えましょう。実際の言葉、最初の反応、そしてその反応と次にとった行動とのギャップを話します。見られるのは、理解が合っているかを相手に確認しに戻ったか、そしてその後に具体的に行動がどう変わったかです。

切り口の例： 設計ミーティングでの意見の対立の扱い方についてのレビューコメント。最初は反論したが、ほかの2人のチームメイトに聞いて後から事実だと確認した話 — PracHub上のGoogle候補者が報告したものです：質問を見る。

9. 「大きな失敗と、それをきっかけに変えたことを教えてください。」

測る軸： 知的な謙虚さ、正しいことをする姿勢。

答え方： ほかの人の判断が原因ではなく、自分が実際に責任を負った失敗を選びましょう。自分が間違えた判断と、そのときなぜ正しく見えたのかを述べます。その後は、回答の大半を、続く変化に使いましょう。チェックリスト、ロールバックの方針、エスカレーションの習慣の変更などと、それが後のプロジェクトでも定着したかどうかです。

切り口の例： ロールバックの手段なしで承認したリリース。それが、今も自分が続けているリリース前の定例レビューになった話 — PracHub上のGoogle候補者が報告したものです：質問を見る。

10. 「やりにくいと感じた同僚とどう仕事をしましたか。」

測る軸： 協働、正しいことをする姿勢。

答え方： 同僚を悪者にせず、また自分には何の問題もなかったとも言わないでください。具体的な摩擦、たとえば引き継ぎの漏れや矛盾するレビューと、自分の側でまず何を変えたかを述べます。そのうえで、解決した仕組みを示します。共有ドキュメント、定例の同期、より明確な境界などです。結果は、人間関係ではなく仕事の成果で判断しましょう。

切り口の例： ブロッキングするコメントで自分の作業を遅らせていたレビュアーに、先に制約を聞き、それに合わせてプルリクエストの構成を組み直した話 — PracHub上のGoogle候補者が報告したものです：質問を見る。

11. 「自分が作ったプロジェクトのトレードオフを説明し、その判断を擁護してください。」

測る軸： 現状に挑む姿勢、プレッシャー下での技術的な判断力。

答え方： トレードオフを現実のものにした制約、つまり締め切り、コストの上限、チームの人数、既存のシステムを述べましょう。却下した選択肢と、その代わりに受け入れた具体的なコストを挙げます。反論を想定して、それが本当の質問だと考えてください。理屈が通っているところでは立場を守り、新しい情報で考えが変わる点ではきちんと認めましょう。

切り口の例： 書き込みの複雑さが増すと分かっていながら、ユーザーが不満に感じていたのがクエリの遅延だったため、非正規化した読み取り経路を選んだ話 — PracHub上のGoogle候補者が報告したものです：質問を見る。

12. 「自分と同じものを別のチームが作っていると知ったとき、どうしましたか。」

測る軸： 正しいことをする姿勢、チームをまたいで発揮するリーダーシップ。

答え方： 失敗しやすいのは、自分のバージョンを守ろうとすることです。反論する前に相手の成果物を読みに行ったこと、そして誰のものかではなく、どちらのシステムを残すべきかという形で選択を整理したことを示しましょう。誰を巻き込んで決めたかを述べ、結論が自分のチームが作業をやめて相手のものを採用することだったなら、正直にそう話してください。

切り口の例： 並行して存在していた社内ツールを見つけ、どちらのチームも書き出していなかったユースケースで両方を比較し、データモデルの優れた方に統合した話 — PracHub上のGoogle候補者が報告したものです：質問を見る。

Googleはリーダーシップをどう評価するか（ICの場合も）

こうした質問の多くは、誰もマネジメントしないポジションであってもリーダーシップを探ります。個人貢献者（IC）のトラックの候補者は、これに驚くことがあります。

Googleが評価するのは自発的に発揮するリーダーシップです。チームが危機、方向転換、技術的な行き詰まりに直面したとき、肩書きがなくても誰かが前に出るかどうかを見ます。共通する考え方は、権限なしに影響を与えることです。組織図のどこにいるかではなく、考え方とコミュニケーションでグループを動かします。

ICとして示す方法は次のとおりです。

• 経験の浅いエンジニアをメンタリングし、相手にとって何が変わったかを具体的に述べる。
• 互いに話がかみ合っていなかったチームの間をつなぐ、技術面の結節点になる。
• データで裏付けられる妥協案を仲介して、シニアな同僚同士の行き詰まりを打開する。
• 全員が避けて通る、目立たない共有物（不安定なパイプライン、古いランブック）の担当を自分から引き受ける。

ミニ事例： 2つのチームがそれぞれ、共有イベントストリームのスキーマ検証はもう一方の担当だと思い込んでいて、不正なイベントが両方に流れていました。どちらのリードも作業を引き受けたがりませんでした。1ページの提案を書き、両方のリードを20分間同じ場に集め、担当者を決めて帰るICは、生まれつきのリーダーだと主張するよりも説得力をもって、自発的に発揮するリーダーシップを示したことになります。

マネジメント職を目指す場合は、チームに対して正式に責任を負う立場になると、求められる水準が変わります。この違いは、PracHubのエンジニアリングマネージャー向け行動面接ガイドで扱っています。

優秀なエンジニアが落ちるよくあるミス

エピソードをそろえる前に、失敗のパターンを知っておきましょう。その多くは、面接の場ではなく、準備の段階での見直しで避けられるからです。

ミスを直した例を一文で： 「信頼性を大きく改善しました」ではなく、「リトライが増幅する経路を断ち切り、そのアラートによる週の呼び出し回数はゼロになりました」と言います。同じ出来事を、採点できる形にしたものです。

7日間の準備計画

ここまでの内容は、声に出して練習しなければ何も変わりません。評価基準を実際の話し方に変えるスケジュールを紹介します。

この計画がうまくいくためのルールは3つあります。

• 広さより深さ。 3回の深掘りに耐えて擁護できる6〜8個のエピソードは、要約しかできない20個より強いです。
• 練習の前に対応づける。 2つの評価軸をカバーするエピソードは、どの質問が出るか選べない45分以上のラウンドでは、2倍の価値があります。
• 自分を録画する。 自分の回答を聞くほうが、読み返すよりもずっと早く、口癖や足りない根拠に気づけます。

模擬面接で仕上げましょう。実際に報告された質問で練習すると、面接の場に入る前に、エピソードが通用するかが分かります。さらに、同じ組み合わせをほかのFAANGの行動面接に対しても試しておけば、どの会社から先に連絡が来ても使えます。

よくある質問

この面接ラウンドの準備を始めた候補者から、よく寄せられる質問です。

面接での「Googleyness」とはどういう意味ですか？

Googleが評価する行動の特性です。曖昧さの中で成果を出す力、知的な謙虚さ、フィードバックを受け止める姿勢、システムを改善するために現状に挑む姿勢、ユーザーを第一に考える姿勢が含まれます。専用の行動面接、多くはLeadership and Rapportラウンドと呼ばれるもので評価され、技術面の結果とあわせて採点されます。

Leadership and Rapport面接の最善の準備方法は何ですか？

浅い話を長く並べるのではなく、深い話を少数そろえましょう。候補になる経験を12〜15個洗い出し、そのうち6〜8個をSTAR-Lで書き出し、それぞれを複数の評価軸に対応させます。そのうえで、出そうな深掘りの質問を想定しながら声に出して練習します。上記の7日間の計画では、この流れを日ごとに説明しています。

Googleynessが足りないと、Googleの面接に落ちることはありますか？

あります。行動面のシグナルは、選考資料の中で実際に重みを持ちます。コーディングとシステムデザインのラウンドは通ったのに、行動面接でチームメンバーへの責任転嫁、フィードバックに対する防御的な姿勢、曖昧な問題を構造化できないといった問題点が出て、不合格になった候補者もいると報告されています。

GoogleynessとAmazonのリーダーシッププリンシプルはどう違いますか？

どちらも行動を評価しますが、重点が違います。Amazonのリーダーシッププリンシプルは、公開されている明確なリストで、オーナーシップと実行のスピードに強く結びついています。面接官は回答を特定のプリンシプルに対応づけることが多いです。Googleynessは体系化の度合いが低く、好奇心、協力して問題を解決する力、チームを機能させる力に重きを置きます。実際には、Amazonは実行の決断力を重視し、Googleは難しく不明確な問題で他者とどれだけうまく働けるかを重視します。

実際にいくつの行動面接のエピソードを用意すべきですか？

通常は6〜8個で十分です。ただし、各エピソードが深掘りに耐えられるほど詳しく、かつ複数の評価軸に対応している必要があります。面接官が探るのは深さであり、エピソードの数ではありません。そのため、10分間擁護できる1つの話は、紹介しかできない3つの話より価値があります。

Googleはまだ頭の体操の質問をしますか？

Googleは、学校のバスにゴルフボールが何個入るかを見積もるような典型的な頭の体操の質問について、仕事での成果を予測できないと結論づけ、公に使わなくなりました。現在の行動面接は、実際の過去の経験に焦点を当てています。職種によっては、自由形式の見積もりの質問が今も出ますが、評価されるのは、ひっかけの答えに当たったかどうかではなく、推論と前提です。

Googleynessは別に採点されますか、それとも技術面接に含まれますか？

通常は独立して採点される面接ですが、技術面接の面接官も、行動面での観察を記録することがあります。ヒントをどう受け取るか、自分のアプローチへの異議にどう対応するか、時間のプレッシャーの中でどう伝えるか、などです。選考中のあらゆるやりとりが、行動面の評価の一部だと考えましょう。

同じエピソードを2つの別の質問に使ってもよいですか？

はい。むしろそれを前提に設計すべきです。曖昧な問題、厳しいフィードバック、ユーザーに関わるトレードオフを含むエピソードは、強調する点を変えれば、3つの異なる質問に答えられます。ただし、同じ面接官に同じエピソードを2回使うのは避け、1つのラウンドの中で使い回すことは決してしないでください。

Googleの実際の行動面接の質問で練習する

これをすべて具体的にする最も早い方法は、Googleが実際に聞く質問で練習することです。最近の候補者が報告したGoogleの実際の行動・リーダーシップ面接の質問を見て、選考のそのほかの部分については、より広いGoogleの問題集を確認し、STAR-Lのエピソードを1つずつ、3回の深掘りに耐えるまで検証しましょう。